Rails internationalization

This post is about my experiences with Rails’ ri18n and gettext packages. Here are my discoveries:

1. Don’t use ri18n because you can only use one language at the time. I can’t think about any real world scenario where that’s acceptable, unless maybe in an intranet application.
2. When using gettext, don’t forget to require "gettext/rails" and call init_gettext "yourapp" in your application controller, or you’ll get a puzzling undefined method untranslate_all? error when building the po files. There are no comparable problems with ri18n as all the initialization code is contained into the config files.
3. Do not expect GetText.update_pofiles to create the .po files in the locale directories on the first run. Just copy the .pot file in each of them, changing the suffix to .po. Those files will be updated on the next runs.
4. Gettext doesn’t harvest expressions like #{_(“str”)}, which ri18n’s parser handles happily. This is very bad when working with here documents (var = <<END_OF_STRING)
5. gettext tries to guess translations of new messages, based on similar existing ones. It obviously doesn’t make a good job at it (AI’s not here yet) but al least it marks those messages as “fuzzy”. Remember to review them because fuzzy messages won’t make their way into the .mo files (error message: Warning: fuzzy message was ignored.)

Overall ri18n would be a clear winner, superior to gettext in almost every feature. Unfortunately it fails on a show stopper issue, so I have to cope with gettext shortcomings. It’s a hard world…