On 16.11.2008, at 12:26, José Valim wrote: > Can't we implement it in a way we will define how Rails locale should > be called? > > I18n.rails_locale = :en > > And those who want "en-US": > > I18n.rails_locale = :"en-US" > > The default could be "en-US" since it's more "complete", who is not > satisfied can change it for whatever they want.
I'm not sure :) Rails will probably always only ship with data for one locale. So that's either :en or :"en-US". In the spirit of "doing the simplest thing that ever could work" for Rails ... it seems wrong to me to introduce such a thing like a rails_locale. Gotta keep in mind that we should do the simplest possible thing that makes sense in Rails itself and then rework from and add on top of that in plugin-land ... at least until we identify stuff that *needs* to go into Rails AND until we know how exactly it must be done. > > > If everyone agree, I could try a patch. =) > > Regards, > José Valim. > > -- > http://josevalim.blogspot.com/ > http://www.pagestacker.com/ > > On Nov 16, 7:34 am, Karel Minarik <[EMAIL PROTECTED]> wrote: >> 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:// >>> ...... >> >>> 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 -~----------~----~----~----~------~----~------~--~---
