Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
If I18n.translate() fails in a locale, try a broader one. ie. If it fails in en-UK, try in 'en', or 'en-US', 'en-AU', 'en-CA' or other 'en' locales you have installed. This allows simple inheritance to cater for small but important differences between regions of the same language.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Type||Name||Latest commit message||Commit time|
|Failed to load latest commit information.|
I18N Translation Helper ======================= Installation ============ As a plugin: script/plugin install git://github.com/kipcole9/rails-i18n-translation-inheritance-helper.git Or from git directly as a plugin to your project: git submodule add git://github.com/kipcole9/rails-i18n-translation-inheritance-helper.git vendor/plugins/i18n_translation_helper Description =========== Adds a fallback chain to translation lookup in Rails i18n. When installed (plugin, or otherwise mixed in) the method 'translate' will now attempt to find a translation in a broader scope locale or 'sister' locals if there are any. This means that it is more practical to have regional variations of locales where there are only minor differences. This updated version defines a lookup_chain as follows: 1. lookup in supplied or default locale (ie. "en-UK") 2. then in the broader locale ("en") 3. then any 'sister' locales ('en-GB', 'en-US', 'en-AU', ...). NOTE === To lookup the 'sister' locales requires that the version of I18n installed supports the #available_locales call. This call is supported in the I18n gem version: svenfuchs-i18n (0.1.2) or in sven's github repository. You can also add the required functions by adding the following to an initializer in your rails project: module I18n class << self def available_locales backend.available_locales end end module Backend class Simple def available_locales translations.keys end end end end Performance =========== Note that for the simple cases of a skinny narrow scope locale (ie 'en-GB') where most keys are stored in the broader locale (ie. 'en') then performance will be twice as slow on average compared with the standard I18n#translate function. More experimentation to come yet..... How this fits in an application =============================== For example, the only practical difference between en-US and en-UK would be the currency symbol ($ or £). By default, the full set of rails 'en' rails localisation files would need to be copied and maintained. With this approach, an 'en-UK' localisation file for rails just has to maintain the differences from the 'en' version. An example would be: en-UK: support: number: # Used in number_to_currency() currency: unit: "£" Any lookup in the 'en-UK' local that fails will be redirected to the 'en' locale for translation. This approach can also be used for regional language variations in other languages as well (pt-PT vs. pt-BR; fr-FR vs. fr-CA; es-ES vs. es-MX) - for both application localisation files and for rails' own localisations. This would be better (and would execute faster) if implemented in the I18n core module directly. Example ======= Using the en-UK localisation file above: I18n.locale = "en-UK" I18n.translate('support.number.currency.unit') => "£" # Resolved from 'en-UK' I18n.translate('support.array.words_connector') => ", " # Resolved from default 'en' Also added is a new function #locate which can be used as a debugging tool to tell you in which locale a translation was found. I18n.locate('support.array.words_connector') => "en: ', '" Contact ======= kip cole 9 at g mail dot com (remote the spaces etc etc) Copyright (c) 2009 Kip Cole, released under the MIT license