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 -~----------~----~----~----~------~----~------~--~---
