Running Rails 2.2 with i18n
Just a quick note that this blog is now running Rails 2.2 and makes use of the new i18n framework. Although this site is completely in English, the same application is also serving another blog in German. Moving the blog application from ruby-gettext translations to Rails i18n was quite a bit of work since the i18n simple backend works differently and after all, I had to recreate all translation files.
In the end, it works very well and reliable. While working with i18n views, I had some small ideas for improving translation handling in views -- maybe I can come up with some minor improvements after thinking about it some more.
The main difference between gettext and Rails i18n is the usage of translation keys. With gettext, you place full strings of the "master language" (usually English) into the views. With Rails i18n, you build up a hierarchical structure of translation symbols (like "sidebar.latest.title") and associate them with real text in translation files. Currently there's no tool to extract symbols used in views to assist you to keep translations complete (like rgettext does for gettext), but I guess helpers will appear soon.
For my translations, I used the i18n simple backend, which comes with Rails and stores translation strings in simply .yml files. However, the Rails i18n framework actually is much more than just translations in .yml-files. It allows translation backends to hook into the Rails core with a documented interface, which promises to be more stable and reliable than monkeypatching solutions (e.g. like ruby-gettext does). In theory, it should be possible to create an i18n backend that utilizes gettext -- which certainly is still very interesting e.g. to upgrade existing applications or for large applications with many translators (since the gettext format is widely supported by a lot of tools and services).