What's the recommended rails way to I18n in Rails 3

Question

First to confirm is I am not going to provide anything in the database with multiple languages. I am just talking about the text on the page.

I am a little bit confused about the statement in Rails Guide:

The i18n library takes a pragmatic approach to locale keys (after some discussion), including only the locale (“language”) part, like :en, :pl, not the region part, like :en-US or :en-GB, which are traditionally used for separating “languages” and “regional setting” or “dialects”. Many international applications use only the “language” element of a locale such as :cs, :th or :es (for Czech, Thai and Spanish). However, there are also regional differences within different language groups that may be important. For instance, in the :en-US locale you would have $ as a currency symbol, while in :en-GB, you would have £. Nothing stops you from separating regional and other settings in this way: you just have to provide full “English – United Kingdom” locale in a :en-GB dictionary.

Suppose I would like to have a complete set of english localization, which contains the US part and the GB part.

So I need to have en.yml, en-US.yml and en-GB.yml, 3 files in the locale folder,

-- Rails Root
  |-- config
    |-- locale
      |
      |-- en.yml
      |-- en-US.yml
      |-- en-GB.yml 

and when I set I18n.locale = 'en-US' then it will use the text translations in en-US.yml. Is it the recommended way to do I18n in rails 3?

And is it good that I keep the identical part in en.yml (like Monday Tuesday , they are the same in US and GB) and keep the different things(something like the currency sign) in separated files en-US.yml and en-GB.yml? is it possible that rails could automatically find the identical part in en.yml? As I tested, it's not supported out of the box

Answer 1

To avoid having duplicates of all the translations that en-US and en-GB have in common you can define custom fallback routes for different translations.

I18n.fallbacks.map(:"en-GB" => :"en")

or

I18n.fallbacks[:"en-GB"] # => [:"en-US", :en]

So should en-GB not have a certain translation you can fall back to en.yml or en-US.yml. In that way you can keep the region-specific translations in the en-US.yml and en-GB.yml, while everything they have in common can be in en and have the two fall back on en when you are unable to find a specific translation in en-US.yml or en-GB.yml.