- 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