langauge vs. locale (was: RE: Suppress-Script candidates (was: Re:frr, fy, ngo, tt))

Peter Constable petercon at microsoft.com
Thu Sep 28 02:21:48 CEST 2006


[This is running a risk of straying off topic for this list, but I'll post this here since it ‎still pertains to Don's questions regarding whether particular reg entries should have ‎certain info added to them.‎]


> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Kent Karlsson


> > that region is a key attribute of a locale,
> 
> ...no.

Please explain. I guess this might depend on one's view of what the minimal set of information categories that are required for a locale consists of.

 
> > locale ID must always include a region component as well as a
> > language component.
> 
> CLDR locales don't. Just about all locale data can, and often should,
> be in the "language only" named locales. Very rarely is there a difference
> from those locales that belong in the "language_territory" sublocales.

Not being a participant in the CLDR project, I'm not in a good position to evaluate the intent of the data I see there. I do note that, e.g. there is a file "en.xml". But clearly there is no such thing as a region-neutral English locale: every English speaker lives in a region where one of "M/d/yy" or "d/M/yy" is the preferred short date format (and probably the majority live in regions that prefer the latter), but this data file is not neutral wrt short date format: in spite of the name, the data it contains really is applicable to the US. Now, perhaps the intent here is that this is data that can be used as a default if region-specific data is not available, but it seems to me that's just a round about way of saying that en-US is used as the default locale for English.


> Yes, but choosing (a single) currency or a choosing a measurement
> system does not belong in a locale. Doing that is a mistake, similar to
> that of selecting character encoding via locale (as, unfortunately done
> in Unix/POSIX locales).

These are only ever defaults. It's not appropriate to assume that every English speaker in the US wants a short date format of "M/d/yy", but it is an appropriate default in that scenario. In the same way, it's not appropriate to assume that a user in the US will always use imperial units of measure, but it is reasonable to treat imperial units as a default. Same for currency.


Peter Constable


More information about the Ietf-languages mailing list