Rails: Internationalization
I'm reading through Agile Web Development with Rails. I'm surprised at how naive the I18n support in Rails appears to be.
It seems to get number formatting right, but it gets a lot of other things wrong. For instance, as far as I can tell reading the book, it assumes all languages have the same pluralization forms as English. It forces you to create YML-based "constants" for all your localization strings. Hence, your templates contain things like I18n.t('checkout.submit') instead of, say, _("Submit your order"). I have no clue what happens if you're missing a constant in your YML. I also don't think it understands how to degrade gracefully. For instance, if I ask for some weird sub-dialect, I bet it doesn't know how to fall back to the main language. Furthermore, the YML files painfully duplicate strings for translation. I haven't seen anything for dealing with the Accept-language header, but that could just be the book's fault.
I may be misunderstanding some things, but I think the gettext library used in C, Python, etc. is much smarter and more convenient.
Please feel free to tell me how wrong I am. However, if you do, you must also explain how the heck Russian speakers can possibly cope with their crazy pluralization rules in real time ;)
It seems to get number formatting right, but it gets a lot of other things wrong. For instance, as far as I can tell reading the book, it assumes all languages have the same pluralization forms as English. It forces you to create YML-based "constants" for all your localization strings. Hence, your templates contain things like I18n.t('checkout.submit') instead of, say, _("Submit your order"). I have no clue what happens if you're missing a constant in your YML. I also don't think it understands how to degrade gracefully. For instance, if I ask for some weird sub-dialect, I bet it doesn't know how to fall back to the main language. Furthermore, the YML files painfully duplicate strings for translation. I haven't seen anything for dealing with the Accept-language header, but that could just be the book's fault.
I may be misunderstanding some things, but I think the gettext library used in C, Python, etc. is much smarter and more convenient.
Please feel free to tell me how wrong I am. However, if you do, you must also explain how the heck Russian speakers can possibly cope with their crazy pluralization rules in real time ;)
Comments
In large applications and in some languages there may well be more than one translation for a single English string.
Imagine that Profile can mean many different things. Profile of a face (noun), Profile the code (verb), online user Profile, etc.
Some languages may well have different translations.
I guess this generally bites only for large complex software with lots of short strings (think Software rather than Web pages)
Mark
I think this isn't all that uncommon. For instance, in the Rails book, they use "Campo" for "Field". I do believe "Campo" means a grassy field, not a field in a form. Certainly, if you have an app that had a form field where you could configure the name of the grassy field you wanted to have a picnic in, you'd have to provide a bit more context.
However, my point remains that once you've translated "Software:Field" in one place, there's no need to translate it in 50 other places ;)
Gettext is nicer most of the time, but you need to work around the limitations when the same text needs to be translated to multiple different texts depending on context. The problem is that unless you the developer do all the translations, you will not know when you are going to hit this issue. Therefore I regrettably favor the symbolic string values that must be fetched for every language. I believe Java and Mozilla use this way.
However, do we really need to duplicate the word "Save" umpteen times in the translation file so that the translators can translate it differently every time? Will they actually take the time to understand the differing context of the word "Save" every single time?
The truth of the matter is that translators work with translation memories anyway. Every time they see the word "Save", they're just going to click "Ok" in their translation tool to copy the same translation they used last time. They won't even think about context.
I think to do it right, translators *must* be given access to the application and the ability to really see the string in context. They should probably start with a simple, naive translation (which they would do anyway) and then work with the app and the coders to change strings where the context warrants it.
Doing L10n right is hard, and it gets exponentially harder as you try to do a better job. There are no silver bullets.
As for the "Save" example, to prevent the scenario I presented, you should put in a new mnemonic for every use of "Save". For the most part the translators will just automatically pick the same translation. But if there is a case where they need to differentiate, they can. It is not possible if the developer has used the same mnemonic more than once.
Some translation tools provide ways to let developers provide comments for localizers. I think these are necessary for some concepts, even if you let the localizers run the application with and without their localizations. I think a decent example from Chandler is "item". There is no way you could translate that out of context, and even if you see the app and where it is used, you may still have trouble getting the exact meaning. The localization comment can describe the concept in detail so that accurate translation becomes possible. Alternatively you could provide documentation and/or glossary to help translators.
But yeah, localization is hard. We should all switch to Finnish ;)