Rails 2.2 localization and gettext
The next version of Rails (which most probably will be version 2.2) will come with an integrated internationalization (i18n) API. Here's an overview of how this affects an application if you've used the gettext gem so far.
First of all, the new Rails i18n API isn't meant to completely replace existing localization plugins like gettext. More precisely, it's an API built into the Rails core to provide easier access for i18n plugins. The API, for example, makes it much easier to customize number, currency, date and time formats as well as error messages (e.g. in validations) and output of helpers like distance_of_time_in_words.
The gettext gem provides three essential parts to you application:
* Rails helper methods like _ that look up a string at runtime and output its translation
* A translation storage backend (.pot/.po files which are compiled .mo files)
* A parser (rgettext) that reads through the files of an application, extracts used string and adds new strings to the translation storage to have them translated
The new Rails i18n API only covers half of that, but hooks into Rails in a much nicer way since it's tightly integrated into the Rails core. Gettext needed to do a lot of monkey patching to enhance Rails' functionality, which easily leads to problems (like this) whenever the Rails core is changed.
So currently, the new Rails i18n API and the gettext gem are separate approaches that don't benefit from each other. Let's hope, that this will change in future... Combining the common interface of the new i18n API with a gettext backend could lead to the Rails internationalization solution that you've ever been dreaming of, featuring:
Stable integration of i18n functionality (i18n)
Using the built-in i18n API, localization functions can be provided in a stable way across future Rails versions. I.e. much less monkey patching to Rails and a much less fragile plugin.
Localization many formats
The i18n API allows you to easily localize numbers, currencies, dates and times as well as helpers like distance_of_time_in_words (which previously needed to be monkey patched manually).
Popular data format supported by a wide range of translation tools (gettext)
There are lots of translation tools that can read and edit gettext .po files. From editor syntax highlighting to translation tools with dictionaries of common translations or websites that do crowdsourcing translations.
Automatically extract strings to translate (gettext)
With gettext comes the rgettext parser that scans and parses the application source to extract strings that need to be translated. If strings are added, modified or removed later, rgettext can be used to update the translation tables (.po files) automatically, so the translations can be completed easily.
The latter might be hard to implement using the new i18n API, since with the i18n API, you are supposed to use string identifiers like t(:greeting) in views, but with gettext, one usually uses the English texts like _('Hello world') in the view (although you can also use string identifier with gettext, it's not commonly used and becomes confusing when doing the translation).