From: "Peter Constable" <[EMAIL PROTECTED]> > All I have said is that the notions of "locale" and "language" are > distinct, that in general non-linguistic locale parameters such as > number format are not appropriate things to declare about documents, and > so we should not design systems or protocols that assume that locale > tags can be inserted in document metadata attributes where a language > tag is specified. And that it's not helpful in getting people to > understand what is or isn't good to do for someone providing some degree > of leadership in the area to use the terms "language" and "locale" > interchangeably.
A locale for me goes MUCH farther than the simple slection of a few textual-related settings. In fact, any parameter that a user may which to customize to fit his need or expectations about what a software will do can be part of the general concept of "Locale". MacOS has standardizeed since long a good term for it: "Preferences" (rather than the ambiguous term "Options" found too often in Windows). Well Windows has a very large concept of Locales: see all what can be set in the HKEY_CURRENT_USER registry hive (and also, under some limits a few settings in HKEY_LOCAL_MACHINE, althoug hit is personalized only for all users of the same local system)... This goes much further than what one would define in a few POSIX environement variables. Windows has shown since long that this information is interchangeable, and is so valuable that there are hackers and merchants promoting adwares that want to steal that precious information: a complete Locale contains many things that are part of user's privacy. Defining standard "Locale IDs" will be too difficult (in fact impossible given the unbounded range of orthogonal settings). If standardization must occur, it's for some important settings that are part of a "Locale". So I think that what needs to be registered is those settings: - Language-IDs (as set in POSIX's "LANG" or "LC_ALL" environment variables). - timezones (as set in POSIX's "TZ" environment variable) and a few others if they can be thought of general interest, interchangeable, and mostly orthogonal. Let's not try making all fit in one standard ID, as I think it will never work. However, the impossibility of defining standard "Locale IDs" does not forbid defining a standard syntax to serialize lists of settings that are part of a Locale, and defining standard mechanisms to match and resolve them.
