Hello,

first of all I'd like to thank you all very much for your work on the
Globalize Rails plugin. I found it very intuitive to use for my new
project, a multilingual social networking site. Way to go!

There are a couple issues I would like to address though, hoping
somebody has the answers.

1. In the sample translation interface (thanks for providing this!),
the translator always has to translate into whatever locale his
browser told the site to use. That's great for a default, but the
translator should be allowed to choose his target language. I have
spent a couple hours now trying to get a simple language picker to
work and there are two major obstacles: one is that there is no list
of locale codes, yet I can only change the locale knowing those codes.
Globalize_languages stores a whole lot of codes that probably won't be
used anywhere, but not even the most common locale codes! This is
annoying; I don't want to hard-code my list. The other obstacle is
that whenever I pick a locale in my controller, something resets it to
whatever the browser detects. The browser detect should only be done
when the user first enters the site and after that people should be
allowed to change their locale based on their preference.

2. While the pre-translated month names are really useful, the
.localize function still expects ME to provide the date format (such
as mm/dd/yyyy for American and dd.mm.yyyy for German and yyyy年mm月dd号
for Chinese). How am I supposed to know what the most common way of
writing a date is in whatever language, and why would I want to
hard-code that when .localize is supposed to take care of localizing
the date? I suggest the creation of functions like .localize_shortdate
that will output a correctly-formatted short date for the chosen
locale. Not as much variety as playing around with those variables
yourself, but at least you'll know that all your international users
will be able to understand the date. I can help with that if an
experienced globalize_rails plugin developer will guide me.

3. Is anybody using globalize_rails on a huge site? I believe that the
structure of globalize_translations is enough to make servers crack.
Why is the English text and the settings repeated for every single
translation? Is there no way of having a numerical index that would be
faster to search? Ideally, when a site gets really huge, each
language's texts would be completely separated into different tables,
so that they could be stored on different servers to reduce the load.

Just my two cents.

Best wishes,

Judith