W3C home > Mailing lists > Public > www-i18n-comments@w3.org > April 2006

Re: Comment on LTLI WD: purpose?

From: Mark Davis <mark.davis@icu-project.org>
Date: Wed, 26 Apr 2006 10:12:14 -0700
Message-ID: <444FA9EE.8020608@icu-project.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:32:35 GMT