Hi all,
hope this is not a traited point...
I'm french and i used drupal for making an I18n website.
My pb is that one time i make my code (in english) and translate it into languages, if i make a change on english transatable string, i have to retranslate, and upload, corresponding string for all other language.
Exemple:
t("how stupide is that")
---french >>> C'est stupide
---spanich >>> Esto es estúpido
Now let suppose for optimise my english web page i want to change it to "this is stupide"
t("this is stupide")
---french >>> lose
---spanich >>> lose
So i have to make the traduction a new time and upload it to both language...
A nice way will be
t("this_is_stupid_key")
---english >>> this is stupide
---french >>> C'est stupide
---spanich >>> Esto es estúpido
Like this i can change english without having to change it on other language.
What you guys think about that ?
Comments
Yes, this is a known issue
Yes, this is a known issue and sadly it is how Drupal localization works atm.
At the moment you have two ways to work around that:
Update the text in your locales_source table with your module's update scripts
Use i18nstrings for translating so instead of t() you'd need to use i18nstrings() and to implement a few more hooks...
Thanks for the reply
I will give a try to your solutions.
Make your shopping easier: http://www.ookoodoo.com
Clone the English language file
Another solution would be to clone your English language file and treat the copy as a translation of the unaltered original English. Only modify this copy.
That way you can keep the original English as "keys" to both your modified English version and all the other languages without the relation between the original strings and their translations getting lost.
This is similar to British and American English for example.
hth
Frank
Frank
My LinkedIn profile
this looks greats !
Could you explain a bit more this solution please.
What did you mean by "clone your english language file".
In my case i set my website as english one by default
and set an other langage to french.
And then i export my .po files for french / translate / import.
Do you mean that i can export a "en .po file" / translate or make my english corection / and then import ???
thanks for the help i really apreciate it !
Make your shopping easier: http://www.ookoodoo.com
A tainted workaround
That's ok if you are the one making the changes to the English strings. But it doesn't help if the developer decides to make changes to strings. You get the new English string with your next module update but you lose all translations (you don't really lose them, they just lie orphaned in your database). This is the intended behaviour if the meaning of a string changes, but it is an annoyance if it's just a small correction (e.g. a typo or a different wording).
Using strings that are actually displayed as keys for the locale system is both, a boon and a curse. Advantages are a considerably better performance on English-only sites and a guaranteed fallback if something in the local module goes wrong. Also, developers can just code along without the need of tools for generating keys or referring to a central registry to avoid key collisions. Disadvantages are the one in the top posting and the inability to disambiguate English strings that have more than one translation, depending on the context. This is a big issue for all translation teams.
2 versions of English
Hi Nicolas,
Let me explain a bit more:
Actually, this is just an idea off the top of my head. I haven't tested it yet in practice. So I am really curious whether this is a viable solution to your problem.
Cheers
Frank
PS:
Please refrain from private mail for matters of public interest but use the forums instead. Thank you.
Frank
My LinkedIn profile
Thanks for that Franck I will
Thanks for that Franck
I will give it a try as soon as possible and let know the result on the initial post.
Best Regards
Nicolas
Make your shopping easier: http://www.ookoodoo.com
I made an issue about this
I made an issue about this long ago,
http://drupal.org/node/630432
Now it even has a (very low-fi) demo module attached.
An alternative keyword-based translation system could easily live and grow in contrib for a while, and then it could be used by other modules.