> Thank you very much for all your responses!
>
> I guess the problem is that I really like the implicit working of
> Globalize, that the other programmers can just type "You have been
> successfully registered.".t and that string will be automatically
> looked up and/or added to the database for translation. Using a
> different tr_key there, ideally an integer id for database purposes,
> would make the code much less readable and the addition of new strings
> or changing of old ones would become a pain, unless there's something
> I'm not aware of.
> So I thought of a solution that is both readable and scalable: in
> addition to allowing strings like "You have been successfully
> registered".t , I'd also allow "#115#> You have been successfully
> registered".t, where 115 is the tr_key extracted by Globalize. Then
> people or a script can periodically go over strings and add in those
> ids to speed up retrieval from the database (code-writing code would
> be better - LISP anyone?). There are three imaginable possibilities of
> handling strings that don't have an id yet:
> 1. searching for the original text in the "text" column to find the
> id, and using that id to find the translation (2 database calls)
> 2. storing the original text in a new "orig_text" column that is not
> accessed otherwise, so that translations can be retrieved using one
> call only
> 3. ignoring them and returning the original text
>
> I'm not sure which is the best. Anyway, what do you you think of  
> this idea?
>
> Also, there was another suggestion for improvement in my original e-
> mail:
> <quote>
> 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.
> </quote>
>
> Best wishes,
>
> Judith
>