2008/5/16 Judith Meyer <
yutian.mei@...>:
> 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.
You could also set default strings such as "successful_registration".t
then refactore them in english even if english is the base language.
> 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?
>
Ids as integers are fine for a quick database access, but from a
semantic point of view, I would never tolerate in my code #115# : this
is just unreadable and unmaintanable.
I would prefer setting up symbols like :successfull_registration.t
--
Jérôme Lipowicz