Skip to main content

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 ;)


Marco Monteiro said…
This comment has been removed by a blog administrator.
jjinux said…
I forgot to mention that automatic extraction of strings to be translated is much nicer.
jjinux said…
This comment has been removed by the author.
jjinux said…
Since there's no gettext command to automatically extract strings that have been flagged for translation, I'm guessing there's also no msgmerge command to merge an old, translated translation catalog with a new, untranslated translation catalog.
Mark M said…
I would say one thing regarding the duplication of strings.

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)

jjinux said…
Mark, you're right. In gettext, I have do things like _("Software:File") instead of just _("File") when the context is unclear.

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 ;)
Heikki Toivonen said…
While localizing Chandler we also hit the problem of needing to translate the same English word to two (or more) different strings in other languages. We solved it by painstakingly choosing different words for the original English version so that translations could be made. However, the English Chandler also ships with English translation, so we could have chosen gibberish for these instances and rely on localizers reading the localization comments and translating the meaning, not the gibberish string.

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.
jjinux said…
Most of the time, you should use a real string. In times where it is ambiguous, you can fall back to a made up string. Problem solved ;)
Heikki Toivonen said…
The problem is, like I tried to explain, that you won't know in advance what strings are ambiguous. If you use strings, the best you can hope for is to have localizers complain to you. Often localizations happens after a release, so you end up with a situation where you need to do a new release because language A needs disambiguation of string "foo" and this can be repeated for each and every localization attempt. This can be costly if you have help, documentation, screenshots, videos etc. that would need to be updated.
jjinux said…
Ok, well argued Heikki.

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.
Heikki Toivonen said…
The way I do localization, and I suspect most others do as well, is use the app in the original language first to get a feel for it. Then try to translate as many strings as possible without referring to the UI all the time. Then attack the rest by locating the string in the UI to see the context. Finally after everything is translated, use the translation and try to spot and fix awkward/incorrect translations.

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 ;)
Anonymous said…
but isn't gettext is supported by I18n? Afaik it's a wrapper for Simple backend translation library, which is what you're really critiquing... i think?
jjinux said…
I'm sorry, I don't quite understand what you're saying. Can you explain?

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p