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.
I have stumbled upon this too. But I don't really care what the locale
is called underneath. 95% of the time I'm just making a dutch-only
website, so it's just a I18n.default_locale = 'nl-NL' in an
initializer and done!
And then some find and replace to rename en-US to the locale you want.
I'd much rather have i18n_label included or a default translations
directory generated by the rails command and an initializer that
automatically loads that. It would create some unity in i18n
implementations. I suggest the app/i18n/ directory.
It's that or a rewrite of the error messages system, to solve that
annoying problem that the attribute is always at the start of a
message. I might do that anyway, coming weeks.
On Thu, Nov 13, 2008 at 21:56, Sven Fuchs <svenfu...@artweb-design.de> 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.
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.
On Thu, Nov 13, 2008 at 11:56 PM, Sven Fuchs <svenfu...@artweb-design.de>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.
> 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.
> On Thu, Nov 13, 2008 at 11:56 PM, Sven Fuchs <svenfu...@artweb-design.de>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.
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 <svenfu...@artweb-design.de> 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.
> 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 <svenfu...@artweb-design.de> 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.
> > 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 <svenfu...@artweb-design.de> 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.
> > > 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 <svenfu...@artweb-design.de> 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.
> 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).
> On Thu, Nov 13, 2008 at 11:56 PM, Sven Fuchs <svenfu...@artweb-design.de > > 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.
> 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.
> On Nov 16, 7:34 am, Karel Minarik <karel.mina...@gmail.com> 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 <svenfu...@artweb-design.de> wrote:
>>> Hi Mike,
>>> welcome to the list.
>>> Have you had a look at Globalize2's fallbacks?
>>>> 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 <svenfu...@artweb-design.de> 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.
Depends on the application and usecase you're looking at :)
E.g. for German you often need to have different number and currency
formats for different countries (Germany, Austria, Switzerland). And
then you sometimes need to have different private-use tags for
"informal" and "formal" German language (just different ways to say
the same thing).
>>> 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 <svenfu...@artweb-design.de> 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.
> > 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 <svenfu...@artweb-design.de> 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.
>> 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.
>> On Thu, Nov 13, 2008 at 11:56 PM, Sven Fuchs <svenfu...@artweb- >> design.de>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.
I just subscribed to the group and this is (obviously) my first post.
First of all, good work on the I18n API. Nice to finally have a
solution that makes it to the Rails core ;-)
On the issue of "language-region" vs "language" as the basic locale
unit, I would have to argue that region and language should not be
dissociated. A locale is the combination of both values, not just one
of them. "language-region" should remain the basic unit to establish a
localization context.
That inherently makes localization/internationalization more tedious
to deal with, but in the end, a solution should not change or degrade
the initial problem. Especially if we are talking about an API.
It should be left to each application to provide workarounds if
someone finds it too cumbersome to deal with "language-region" instead
of just "language". Fallbacks should be the domain of plugins or
custom code, not the Rails core. If someone comes up with a good
fallback mechanism, then it should simply be documented (or made into
a plugin).
Anyhow, if someone leaves out the region to establish a locale
context, then it means (as you stated) that the region is implicitly
defined by the person making that decision. It can be done with a
single line of code to map the "language" value to a "language-region"
value, as in:
"en-US".gsub(/\-[A-Z]+$/,'')
Moreover, looking at the rails-i18n repository (
http://github.com/svenfuchs/rails-i18n/tree/master/rails/locale ), it
looks like, even before it's officially released, people are already
contributing for many locales. My guess is it won't be long before we
end up with pretty much all the locales we want. Rails developers who
currently develop or maintain multilingual web sites all have an
existing solution to localization and have most likely translated the
Rails core for the languages they support. It's just a matter of
producing that content in the format expected for the I18n API.
