MIME-Version: 1.0
Received: by 10.100.9.6 with SMTP id 6mr205897ani.2.1226834809194; Sun, 16 Nov 
	2008 03:26:49 -0800 (PST)
Date: Sun, 16 Nov 2008 03:26:49 -0800 (PST)
In-Reply-To: <620ae6f6-a557-4c3b-acb4-81623bf20673@s9g2000prm.googlegroups.com>
X-IP: 189.120.182.222
References: <451509E8-805B-47AD-B0D7-FAA6724C9711@artweb-design.de> 
	<50692358-b2cb-45db-93ec-fe53dc3f5df2@p35g2000prm.googlegroups.com> 
	<3F3D52A3-A46A-45CE-84B8-BF46FBD05E51@artweb-design.de> <620ae6f6-a557-4c3b-acb4-81623bf20673@s9g2000prm.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) 
	Gecko/2008102920 Firefox/3.0.4,gzip(gfe),gzip(gfe)
Message-ID: <f08b47c1-4de3-4df0-9812-2bf6c8c5f74d@35g2000pry.googlegroups.com>
Subject: Re: Change Rails default locale from :"en-US" to :en?
From: =?ISO-8859-1?Q?Jos=E9_Valim?= <jose.va...@gmail.com>
To: rails-i18n <rails-i18n@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Can't we implement it in a way we will define how Rails locale should
be called?

  I18n.rails_locale =3D :en

And those who want "en-US":

  I18n.rails_locale =3D :"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. =3D)

Regards,
Jos=E9 Valim.

--
http://josevalim.blogspot.com/
http://www.pagestacker.com/

On Nov 16, 7:34=A0am, 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=A0pm, 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://...=
...
>
> > 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. =A0But I do need the country code part to
> > > localize date/time and currency formats. =A0 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% o=
f
> > > 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. =A0 =A0Lots of large companies only
> > > localize the countries that actually provide them with enough busines=
s
> > > 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 reall=
y
> > >> argue for picking anything else because this is in fact the locale t=
o
> > >> 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 literall=
y
> > >> 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 =A0
> > >> Rails
> > >> can find its own translations. How cumbersome.)
>
> > >> I guess way more than 80% of all applications will be perfectly happ=
y
> > >> with only supporting language locales and ignoring the country/regio=
n
> > >> 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?
>