Change Rails default locale from :"en-US" to :en?

[Sven Fuchs]

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?

[Iain Hecker]

Hi,

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!

I'd rather see the default_url_options fixed
(http://groups.google.com/group/rails-i18n/browse_thread/thread/1e06acc9a3ece0c3)

You can do something like this on the vendor/rails directory if you like:

find | grep en-US.yml | xargs cat $1 >> app/i18n/en/rails.yml

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.

--
Iain Hecker
http://iain.nl/

[Yaroslav Markin]

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.

--
Yaroslav Markin

[Karel Minarik]

I am 100% for something like :en or 'en' for the default locale. I
don't use 'cz-CS' in my locales either, just 'cz'.

Using 'en-US' has *only* academical benefits in my eyes. It's not
pragmatic.

Karel

On Nov 14, 8:04 am, "Yaroslav Markin" <yaroslav.mar...@gmail.com>
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.
>

[Redd Vinylene]

On Fri, Nov 14, 2008 at 11:42 AM, Karel Minarik <karel....@gmail.com> wrote:
>
> I am 100% for something like :en or 'en' for the default locale. I
> don't use 'cz-CS' in my locales either, just 'cz'.
>
> Using 'en-US' has *only* academical benefits in my eyes. It's not
> pragmatic.
>
> Karel

For what it's worth, I named mine to just "en" too. English is
English, if you got a local dialect then fine, use it.

--
http://www.home.no/reddvinylene

[Raul Murciano]

2008/11/14 Redd Vinylene <reddvi...@gmail.com>:

>> Using 'en-US' has *only* academical benefits in my eyes. It's not
>> pragmatic.

Exactly.

> For what it's worth, I named mine to just "en" too. English is
> English, if you got a local dialect then fine, use it.

Agreed 100%

--
Raul Murciano - Freelance Web Developer
http://raul.murciano.net

[mikeee]

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

[Sven Fuchs]

Hi Mike,

welcome to the list.

Have you had a look at Globalize2's fallbacks?

http://github.com/joshmh/globalize2/tree/master/README.textile
http://github.com/joshmh/globalize2/tree/master/lib/globalize/locale/fallbacks.rb

[Karel Minarik]

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

> http://github.com/joshmh/globalize2/tree/master/README.textilehttp://github.com/joshmh/globalize2/tree/master/lib/globalize/locale/...

[José Valim]

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.

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

> >http://github.com/joshmh/globalize2/tree/master/README.textilehttp://......

[Yaroslav Markin]

Hmm. How about we just make

  I18n.language == :en
  I18n.locale == :"en-US"

with I18n.language defaulting to I18n.locale.split("-")[0] ?

What do you think?

On Sun, Nov 16, 2008 at 2:26 PM, José Valim <jose....@gmail.com> 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.

--
Yaroslav Markin

[Sven Fuchs]

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"

[Sven Fuchs]

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.

[Sven Fuchs]

On 16.11.2008, at 10:34, Karel Minarik 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...

For sure!

There are valid and "pragmatic" needs for fallback patterns like this:

zh-Hant-CN-x-private1-private2
zh-Hant-CN-x-private1
zh-Hant-CN
zh-Hant
zh

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).

[mikeee]

Hi SVen -

Thanks - I'll take a look at GLobalize when I get a chance.

Cheers
Mike

On Nov 14, 9:14 am, Sven Fuchs <svenfu...@artweb-design.de> 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/...

[Sven Fuchs]

I've added a ticket to Rails Lighthouse and Jeremy seems to agree, too:

http://rails.lighthouseapp.com/projects/8994/tickets/1391-use-en-as-a-default-locale-instead-of-en-us-for-shipped-locale-data

Will try to come up with a patch asap.

[CharlesB]

Hi all,

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.

Regards,

Charles Bedard