> Hi again,
>
>> You could also set default strings such as  
>> "successful_registration".t
>> then refactore them in english even if english is the base language.
>
> I want to avoid unnecessary database calls; English strings don't need
> to be translated to English.
>
>>> 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
>
> I believe there may be a misunderstanding here: in the code I still
> want to see the entire message that the user will see. That's why I
> came up with coupled strings that consist of an id plus the entire
> message - the message is there for ease of reading and the id is there
> for faster database calls.
>
> Je pense que peut-être je n'ai pas été assez claire: dans le code je
> voudrais bien voir le message entier, par example "You have
> successfully registered".t, pas seulement :successfull_registration.t
> (aussi parce que c'est difficile à éditer après, il faut aller dans la
> base de données et c'est ca que je veux éviter) et certainement pas
> seulement "#115#".t !  Alors je crée des strings qui contiennent l'id,
> mais qui contiennent aussi le message entier, comme "#115#> You have
> been successfully registered".t - ca serait un string comme ca, et
> Globalize ferait le découpage. De telle facon, on pourrait toujours
> lire le message et le modifier, mais Globalize ne ferait pas la
> recherche de tr_key = "You have been successfully registered" dans la
> base de données, Globalize chercherait seulement pour les traductions
> de tr_key = 115. Et si le wording change, les traductions sont
> toujours trouvables par tr_key 115.
>
> Amicalement,
>
> Judith