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