Localization (l10n) refers the adaptation of crabgrass to meet the linguistic, numeric, cultural and other requirements of a specific region. This might include:

1. Translating the UI
2. Numeric, date and time formats
3. Use of currency
4. Keyboard usage
5. Collation and sorting
6. Symbols, icons and colors
7. Culturally appropriate icons

L10n is not to be confused with i18n (internationalization), which refers to the capacity to be able to localize.

l10n plugins for rails compared¶

Here is a handy comparison chart of l10n plugins.

desired features for crabgrass:

• An easy way for people to contribute to the translations. This probably means a web UI of some kind, and the ability to do auto-stale or other method of tracking which translations are out of date.
• The translations should be part of the code base and released with the code.
• You should be able to selective override translations in an engine.
• Symbolic keys

possible features available in plugins:

• auto-discovery: are the strings needing to be translated automatically discovered or do you have to manually know what they are? This could be totally automatic, or via a rake task.
• auto-stale: if you change the original string, is there an easy way to identify that the translations need to be updated?
• storage: are the translations stored in gettext files, yaml files, or the database? They each have their advantages and disadvantages. One big advantage with file-based storage is that the translations can be part of the code repository. One big advantage with the database is that it makes is easier to auto-discover and auto-stale and to create a UI in rails to let people edit the translations.
• symbolic keys: the translation key should be symbolic, like :confirm_destroy_page rather than "Are you sure you wish to destroy that page?". Otherwise, if you fix a typo in the original the other translations can get lost. This feature is explicit in some plugins. Even when the feature is not explicit, you can always just specify a symbol, but then it means you see the symbol if the key is untranslated instead of the text.
• local views: can you create views that are keyed on a region and language? ie app/users/view/show.en_US.rhtml
• rails helpers: does the plugin override standard helpers with localized ones? For example, select_date(), distance_of_time_in_words(), Date.to_formatted_s, Time.to_formatted_s, Number.to_currency.
• rails messages: does the plugin translate the text in all the validation messages in rails?
• formats: will numbers, currency, and dates be correctly displayed for the active region and/or language?

localization¶

I don’t know anything about it.

gibberish¶

auto-discovery: no
auto-stale: no
storage: yaml files
symbolic keys: yes
formats: none?
rails messages: no
rails helpers: no

Plugins:

• add "rails messages" and "rails helpers" features to gibberish
• store translations in a database

globalize¶

“Globalize is generally said to be the most powerful all-in-one solution for Internationalization of Ruby on Rails applications.” (from the website). I think this is very much true.

Globalize is not lightweight. It attempts to be a full solution that covers all the bases and also can be used to translate content. For example, it includes l10n data for 7599 languages and 239 countries.

I (elijah) have used globalize for nest, and there are some things I like. I like the ability of users to enter new translations through the rails app itself and that it supports auto-discovery and auto-stale (with a little hacking). I don’t like that it hits the database so much (untranslated strings always result in a db query), that caching of strings in memory doesn’t work by default without hacking the code, and that when you edit an existing translation you have to restart mongrels to see the change (which defeats a lot of the fun of having users be able to edit the translations).

The other thing that is attractive about globalize is that it handles number, date, and currency formats really well, and has data for what seems to be every country on earth.

auto-discovery: yes
auto-stale: yes (not by default, but you can add updated_at to the view_translations table)
storage: database
local views: yes
formats: number, date, currency.
symbolic keys: no
rails messages: yes
rails helpers: yes
other features: allows for translation of content not just the UI.

Code example:

<%= "First name".t %> # globalize style
<%= _("Last name") %> # gettext style

many more…¶

There are many others, but those are the top three, I think.