Hi Yaroslav, On 14.11.2008, at 08:04, Yaroslav Markin wrote: > Maybe making some kind of fallback would be a solution? > http://www.unicode.org/cldr/data/charts/summary/root.html > http://www.unicode.org/cldr/data/charts/summary/en.html > > It may be the same kind of language, but we may need different > locales for translation. The only thing wrong with current en-US > approach is trouble with using locale name in routes, I think.
Sure, fallbacks are something that many applications would want to use. I don't think it's a good idea to include that to Rails itself though - at least not now. We should first battletest solutions. In Globalize2 there's a fallbacks tool included and I think it is compatible to what cldr does. That said, people wanting to use fallbacks is even another point for renaming the Rails default locale from :"en-US" to just :en. The locale data shipped with Rails (ActiveRecord, ActiveSupport, ...) is the default data for Rails. When people want to use different formats, messages or whatever for languages like en-GB, en-AU etc. they'd want to overwrite the defaults in more specific locales. Locales usually fall back from en-AU to en (see [1]). That won't work with the default data being shipped in en-US then. People would need to map en-AU falling back to en-US. They could just use the default fallback path So that IMO is another point for renaming :"en-US" to just :en for the shipped Rails default data. (The other point is the simple usecase that you just have some simple locales like en, fr, es, de and want to expose them in your URLs - you'd then need to do fancy mappings so I18n would find the Rails locale data for :en accordingly). [1] http://www.rfc-editor.org/rfc/rfc4647.txt Section 3.4 "Lookup", "Example of a Lookup Fallback Pattern" > > > On Thu, Nov 13, 2008 at 11:56 PM, Sven Fuchs <[EMAIL PROTECTED] > > wrote: > > I stumble across this bit every time I start doing something "real" > with Rails I18n and this makes me think. > > For Rails we've picked the default locale :"en-US" because we've > thought it'd be the most defensive claim to make. Nobody could really > argue for picking anything else because this is in fact the locale to > which Rails always (implicitely) was localized. > > But it is also artificial in that Rails I18n itself does not support > locale fallbacks (e.g. looking up :en when :"en-US" is not available) > so when we work with only Rails we either have to use en-US literally > as a locale or somehow map it manually. (E.g. when one wants to use a > route like /en/:ressource one needs to map :en to :en-US so that Rails > can find its own translations. How cumbersome.) > > I guess way more than 80% of all applications will be perfectly happy > with only supporting language locales and ignoring the country/region > tag (like :en, :fr, :es, :de, ...). > > So my feeling is that we should change the Rails default locale > from :"en-US" to just :en as long as it is still possible. > > That might expose us to arguments that we implicitely define English > as American English but on the one hand I'd say that the gained > simplicity and convenience outweighs this and on the other hand we > might argue that Rails actually always implicitely already did that. > > WDYT? > > > -- > Yaroslav Markin > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rails-i18n" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rails-i18n?hl=en -~----------~----~----~----~------~----~------~--~---
