localization comparison

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:

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.

 

this is my proposal:

  • use gibberish. it is sexy and new!
    • symbolic keys are groovy
    • lightweight is nice
  • create a separate mini web app to do the translations with these features:
    • database storage
    • export to .yml files needed by gibberish
    • allow anyone to update the translations and rollback translations (which are tracked with acts_as_versioned)
    • ability to identify stale translations
  • add ability in gibberish to load multiple yml files, with new files overriding the strings in default files. maybe this already works?
 
 

I’m going to run with Elijah’s above proposal, since it will be a good project for me to build my rails skills.

Here are some hypothetical use cases:

  1. Abie knows more than one language (hypothetical…). He has a few minutes to help out riseup, so he goes to translate.riseup.net and authenticates with his riseup username/password. He gets a nice, manageable list of crabgrass things that need to be translated, and text fields to type in the translations (all of which is easily accomplished without using the mouse). The changes go into a yml file, and a cron job on translate.riseup.net commits the changes to svn.
  2. Jessi was doing some crabgrass development, and she changed some text strings in some views and helpers and committed the changes to the crabgrass subversion repository. A cron job on translate.riseup.net scans the source a few hours later and adds the new text strings to the database of things that need to be translated.
  3. Get a report on how much translation is happening and how many strings/words need to be translated—this could also allow translators to browse and search for translations, translate specific strings, see recent translations, and rollback to previous translations
  4. Email interface for one-a-day translation by people with just enough time to deal with one extra email a day (?)
 
 

rails now has a simple l10n api www.artweb-design.de/2008/7/18/the-ruby...

i’m gonna use it like this until we decide to use a plugin or roll our on option.

 
 

I and a group of friends (we actually are going to start a tech-activist collective soon) would like to provide a german localization for crabgrass. Can we just start or do we should wait until you decide which rail gem thingy you want to use? Do you have any tips? We could also creat some howto for people that want to translate can follow.

 
 

hey, good timing. pietro has been writing a bunch of code to do the translations. this week we are combing through the code converting text to make it localizable. next week will will set up the web ui to allow people to translate the strings.

 
 

that sounds great :)

 
   

translation workflow is something like this:

  1. enable gibberize mod
  2. rake cg:l10n:extract_keys
  3. look at ‘lang/defaults_from_source.yml’ to make sure all keys look fine
  4. rake cg:l10n:load_keys
  5. use gibberize ui to translate into a bunch of languages
  6. rake cg:l10n:extract_translations # will put all available translation in ‘lang/$locale_code.yml’

there is also the task ‘cg:l10n:load_translations’ that will load translations from ‘lang/*.yml’ into the translations db so translations can be shared/updated between crabgrass installations.

I’ll update gibberize mod and docs/multilingual to reflect that.