- From: Mark Davis <mark.davis@icu-project.org>
- Date: Wed, 26 Apr 2006 10:12:14 -0700
- To: Felix Sasaki <fsasaki@w3.org>
- CC: Martin Duerst <duerst@it.aoyama.ac.jp>, Anne van Kesteren <annevk@opera.com>, www-i18n-comments@w3.org, member-i18n-core@w3.org
My suggested rewrite: OLD Language and locale values are values which are compliant to [RFC 3066bis] <http://www.w3.org/International/core/langtags/#rfc3066bis>. Their purpose is 1. the identification of a human language, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. 2. the identification of a locale, that is a collection of international preferences, generally related to a geographic region that a (certain category) of users require. These are usually identified by a shorthand identifier or token that is passed from the environment to various processes to get culturally affected behavior. Language and locale are distinct properties. Language is a core component of locale, but a locale can identify information that is not associated with language, such as a timezone. Thus the terms language and locale should not be used interchangeably, although there is a close relationship between these properties. Syntactically, locale IDs are sometimes distinguished from language IDs by the use of "|_|" instead of "|-|", but this syntactic distinction cannot be relied upon. Historically, locale IDs sometimes included charset parameters - that usage is strongly discouraged. NEW Language identifiers follow the specification in [RFC 3066bis] <http://www.w3.org/International/core/langtags/#rfc3066bis> (where they are called language tags). Their purpose is the identification of a human language, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. Locale identifiers are used to identify a collection of international preferences, often related to a geographic region that a certain category of users require. Syntactically, locale identifiers follow the same structure as language identifiers ([RFC 3066bis] <http://www.w3.org/International/core/langtags/#rfc3066bis>) except that they may contain extensions, and are sometimes distinguished from language identifiers by the use of "|_|" as a separator instead of "|-|". (However, this syntactic distinction cannot be relied upon, so implementations should be lenient in accepting either separator.) Language and locale are distinct entities. The language is a core component of locale, but a locale can also identify information that is not associated with language, such as a timezone. Thus the terms language and locale should not be used interchangeably, although there is a close relationship between these properties. Historically, locale identifiers sometimes included charset parameters - that usage is strongly discouraged. <http://www.w3.org/International/core/langtags/#rfc3066bis> Felix Sasaki wrote: > Hello Martin, all, > > I implemented Martin's comments. I have one problem remaining: > How to define "locale" ... > The new section 1.5 says: > [Language and locale values are values which are compliant to [RFC > 3066bis].] > Which is not 100% true, since RFC3066bis talks only about language values. > > I also don't understand Martin's comment: > [ - Don't hide what specs should do in a conformance section.] > > Please have a look at the draft at > http://www.w3.org/International/core/langtags/ > > Regards, Felix. > > >> Hello Anne, >> >> I think you are right that it is difficult to understand >> at the moment why this document is needed on top of what >> in a few weeks or months should be BCP 47 (what's currently >> RFC 3066bis + the current matching draft). >> >> I think there are various reasons for this. Because this is >> only a first working draft, we can still improve this. >> Here a few suggestions (mostly for Felix): >> >> - Mention the relevant IETF base specs explicitly in the >> abstract. [but avoid copying the abstract in the STOD] >> >> - Reduce definitions. Terms such as "extended language range" >> should not be redefined here. The correct way to write >> this is not >> [Definition: An extended language range is a language range >> as described in sec. 2.2 of [RFC 3066bis].] >> but something like this: >> This documents uses the terms ..., "extended language range",... >> from [RFC 3066bis]. >> This will be much shorter, and avoids the impression that >> "extended language range" is a term invented in this spec. >> >> - Don't hide what specs should do in a conformance section. >> >> - Don't mix basic explanations (incl. definitions) with content >> of the spec, as in section 2.2. You can't *define* language >> and locale identifiers (or tags, the term 'values' is a bad >> choice in this case) to conform to RFC 3066bis syntax and >> then again *define* in very general terms what these things >> are for. >> >> Anyway, this is just a first draft, so further suggestions >> of how to improve the document are very welcome. >> >> Regards, Martin. >> >> >> At 18:11 06/04/24, Anne van Kesteren wrote: >> >>> On Mon, 24 Apr 2006 07:18:25 +0200, Felix Sasaki <fsasaki@w3.org> wrote: >>> >>>>> It's not entirely clear to me what the purpose of having >>>>> http://www.w3.org/TR/2006/WD-ltli-20060419/ is. It seems to state that >>>>> you have to follow RFC 3066bis (or BCP 47, later on the Recommendation >>>>> track) in this and that regard and that's basically it. At least, >>>>> according to section 3. This same section states: >>>>> >>>>> The purpose of the criteria is to provide a stable >>>>> source for requirements for language and locale >>>>> identification. >>>>> >>>>> ... isn't that what BCP 47 is for? >>>>> >>>> BCP 47 is for language identification. The important bit in ltli will be >>>> the differentiation between language and locale. This will rely mainly >>>> on RFC 3066bis. >>>> >>> Wasn't BCP 47 going to be 3066bis? (I was talking about the revised BCP >>> 47, sorry for being unclear.) >>> > > >
Received on Wednesday, 26 April 2006 17:12:18 UTC