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