Skip to content
Browse files

Added note about Rails' i18n pragmatic to locale keys and differences…

… between eg. en-US / en-UK.

Based on feedback from Matt Falkenhagen, http://groups.google.com/group/rails-i18n/browse_thread/thread/64ce98be0fe48388?hl=en
  • Loading branch information...
1 parent 0b02e44 commit c73f17f379e0e53b7845c4c4a1a5dd4b5ea62dc3 @karmi karmi committed Jan 26, 2009
Showing with 2 additions and 0 deletions.
  1. +2 −0 railties/doc/guides/source/i18n.txt
View
2 railties/doc/guides/source/i18n.txt
@@ -94,6 +94,8 @@ This means, that in the +:en+ locale, the key _hello_ will map to _Hello world_
The I18n library will use *English* as a *default locale*, ie. if you don't set a different locale, +:en+ will be used for looking up translations.
+NOTE: The i18n library takes *pragmatic approach* to locale keys (after http://groups.google.com/group/rails-i18n/browse_thread/thread/14dede2c7dbe9470/80eec34395f64f3c?hl=en[some discussion]), including only the _locale_ ("language") part, like +:en+, +:pl+, not the _region_ part, like +:en-US+ or +:en-UK+, which are traditionally used for separating "languages" and "regional setting" or "dialects". (For instance, in the +:en-US+ locale you would have $ as a currency symbol, while in +:en-UK+, you would have €. Also, insults would be different in American and British English :) Reason for this pragmatic approach is that most of the time, you usually care about making your application available in different "languages", and working with locales is much simpler this way. However, nothing stops you from separating regional and other settings in the traditional way. In this case, you could eg. inherit from the default +en+ locale and then provide UK specific settings in a +:en-UK+ dictionary.
+
The *translations load path* (+I18n.load_path+) is just a Ruby Array of paths to your translation files that will be loaded automatically and available in your application. You can pick whatever directory and translation file naming scheme makes sense for you.
NOTE: The backend will lazy-load these translations when a translation is looked up for the first time. This makes it possible to just swap the backend with something else even after translations have already been announced.

0 comments on commit c73f17f

Please sign in to comment.
Something went wrong with that request. Please try again.