On a second thought, I must say, that the {LOCALE}-{REGION} *does*
make sense for locales like English (or Chinese).There could be a pragmatic and valid need to differentiate between `en- US` and `en-UK`: different time formats, different currency... Karel On Nov 14, 3:14 pm, Sven Fuchs <[EMAIL PROTECTED]> wrote: > Hi Mike, > > welcome to the list. > > Have you had a look at Globalize2's fallbacks? > > http://github.com/joshmh/globalize2/tree/master/README.textilehttp://github.com/joshmh/globalize2/tree/master/lib/globalize/locale/... > > On 14.11.2008, at 14:54, mikeee wrote: > > > > > I'm running into the non-fallback issue in a site I'm building that > > has to support 103 locales but only 6 of them are actually localized > > into different languages. But I do need the country code part to > > localize date/time and currency formats. An example would be that > > the Thai locale isn't "translated" yet so it should render text in > > English as the fallback but for formatting purposes (dates, times, > > currencies,etc) it should use the Thai localizations. > > > To me this has caused massive bloat of the locale files because 90% of > > them are largely identical due to there only being 6 translations at > > launch because I can't say, if language code "XX" is not available, > > fallback to "en" but use country "YY" for the date, currency formats. > > > Maybe this is an extreme case but it's a very real case for a very > > real big commercial website and I presume other enterprise scale > > applications have similar needs. Lots of large companies only > > localize the countries that actually provide them with enough business > > to justify the costs associated with doing large scale localization. > > > Mike > > > On Nov 13, 3: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? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
