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).
>
>
> 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://github.com/joshmh/globalize2/tree/master/lib/globalize/locale/
>>
>> ...
>>
>> 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
-~----------~----~----~----~------~----~------~--~---
