MailingList
« Return to Thread: globalize_translations table
Re: globalize_translations table
by Sprachprofi
::
Rate this Message:
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
> 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
« Return to Thread: globalize_translations table
| Free embeddable forum powered by Nabble | Forum Help |
Created dynamically
by
Nabble
