aboutsummaryrefslogtreecommitdiffstats
path: root/railties
diff options
context:
space:
mode:
authorKarel Minarik <karmi@karmi.cz>2009-03-01 12:37:03 +0100
committerKarel Minarik <karmi@karmi.cz>2009-03-01 12:37:03 +0100
commit959b827e40248691864221d9d8561f17fb5755a6 (patch)
tree20fb4ab5c50e83e84efcbbb6b7d5989336e5f707 /railties
parent92dd9b3e9f7bffe16ec53aeefd048d7da4eb1543 (diff)
downloadrails-959b827e40248691864221d9d8561f17fb5755a6.tar.gz
rails-959b827e40248691864221d9d8561f17fb5755a6.tar.bz2
rails-959b827e40248691864221d9d8561f17fb5755a6.zip
Clarified info about "pragmatic approach to locale codes" and removed speculation about "locale inheritance" in the I18N guide [thanks Kip]
See http://groups.google.com/group/rails-i18n/msg/7b4513b3ca8abbf5
Diffstat (limited to 'railties')
-rw-r--r--railties/guides/source/i18n.textile2
1 files changed, 1 insertions, 1 deletions
diff --git a/railties/guides/source/i18n.textile b/railties/guides/source/i18n.textile
index f5a50ee78b..d882a65d8d 100644
--- a/railties/guides/source/i18n.textile
+++ b/railties/guides/source/i18n.textile
@@ -91,7 +91,7 @@ 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 "some discussion":http://groups.google.com/group/rails-i18n/browse_thread/thread/14dede2c7dbe9470/80eec34395f64f3c?hl=en), 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.
+NOTE: The i18n library takes *pragmatic approach* to locale keys (after "some discussion":http://groups.google.com/group/rails-i18n/browse_thread/thread/14dede2c7dbe9470/80eec34395f64f3c?hl=en), 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". Many international applications use only the "language" element of a locale such as +:cz+, +: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-UK+, 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-UK+ dictionary. Various "Rails I18n plugins":http://rails-i18n.org/wiki such as "Globalize2":http://github.com/joshmh/globalize2 may help you implement it.
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.