RE: LTLI draft: changes

I'm puzzled about some comments, since my impression was that you and Mark
had agreement on the changes in the target sections (I did not much more
than implementing your discussion). But I'm o.k. with that.

Please give feedback until Thursday morning, otherwise I republish. (if
there are only editorial comments, I republish as well). Note that with
republishing I don't want to stop discussion, but give the public a notice
what we have changed.

Regards, Felix


> Comments follow:
>
> 1. Section 1.1, 1st sentence, 2nd para. Change "The identification" to
> simply "Identification" (cleaner in English).

done.

>
> 2. 2nd sentence. Change "encompass" to "include" (clearer)

done.

>
> 3. 3rd paragraph. This phrase is missing the "in":
>
> "is to identify language *in* terms of"

done.

>
> 4. This particular paragraph is playing kind of loose with values and
> identification and so forth. I think it would be clearer and crisper to
> say
> something like:
>
> --
> The current best practice when developing specifications for language
> identification is to refer to [RFC 3066], using a formulation like "RFC
> 3066
> or its successor". Recently a successor for [RFC 3066] has been developed,
> called [RFC 3066bis]. This specification takes [RFC 3066bis] as the basis
> for language identification, and [RFC 3066bis Matching] as the basis for
> matching of language identifiers ("tags").

done.

> --
>
> 5. I don't think the following is quite right, since it mixes a lot of
> high-level, previously un-introduced, concepts together without explaining
> them:
>
> --
> Locales can be inferred from language identifiers (for example in the HTTP
> Accept-Language header) or use identical tags in data items (elements,
> attributes, headers, etc.) that serve only the purpose of locale
> identification.
> --
>
> It might be better to say:
>
> --
> Locales can be identified in several ways. One method is by inference from
> language tags. For example, by an implementation could map a language tag
> from an existing protocol, such as HTTP's Accept-Language header, to its
> locale model. Locales may also be identified directly by using the
> language
> tag syntax in data items (elements, attributes, headers, etc.) that
> explicitly serve the purpose of locale identification.
> --

done, though I wonder if "For example, by an implementation could map a
language tag from an existing protocol, such as HTTP's Accept-Language
header, to its locale model." is a correct English sentence. Well, you
know better than me ...

>
> 6. Note that 3066bis and draft-matching will together form BCP 47 (this
> is,
> in fact, the delay in getting 3066bis published). So this sentence is
> redundant:
>
> --
> However, [BCP 47] and [RFC 3066bis Matching] are always the "Best Common
> Practice"
> --

done, deleted the sentence.

>
> 7. Section 1.3, 2nd paragraph: "The scenarios can be divided in two
> areas:".
> Four areas, actually, if one keeps languages and locales separate (I think
> it'll be clearer if you do).

done, please have a look.

>
> 8. Section 1.4. I don't like example 1 at all. I don't think the W3C
> should
> be theorizing about what particular implementation schemes should do
> internally with regard to mapping standard locale identifiers to local
> locale identifiers. As written, users will be confused about whether or
> not
> underscores are permissible or encouraged or what. While Mark's
> documentation for CLDR is clear and I support it for that purpose, it does
> NOT belong in this document. In fact, the whole purpose in CLDR of
> canonicalization to 3066bis format is so that it fits the Requirements you
> are writing in this Specification.

I have taken the example out again, but note that Mark said at
http://lists.w3.org/Archives/Public/www-i18n-comments/2006May/0004.html :
"I'm ok with that [taking the text out]. Then this can be recast as an
example (an important one)."

>
> 9. Penultimate paragraph in Section 1.4. Instead of "The language
> parameter
> may be available", say "Language tags may be available".

done.

In fact, I would
> tighten up your terminology as we've done with 3066bis and be strict about
> saying "language tags" (and not "parameters", "values", "identifiers", and
> so forth).

Done for "parameters", "values", "identifiers". The change is sometimes
difficult, look at this sentence:
"Existing standards which make use of language identification includes the
xml:lang attribute in [XML 1.0], ..."
saying "tags" instead of "identification" doesn't make sense here.
Also, in your text proposal "Historically, natural language identifiers"
it seems to me "identifiers" is more appropriate than "tags".

>
> 10. "This document uses the term language value which is defined in [RFC
> 3066bis].". Hmmmm.... the term "value" is not defined (formally or
> otherwise) in 3066bis and the word value is almost universally applied to
> mean the contents of a subtag. For example:
>
> "Subtags of type 'Region' that have a Preferred-Value mapping in the IANA
> registry (see Section 3.1) SHOULD be replaced with their mapped value"
>
> The term your want is "language tag". While you're at it, you should
> probably define "subtag".

done.

>
> 11. NB> I ignored the contents of the requirements, since time didn't
> permit
> me to review them today.

that's good. As I said in my previous mail: I'm only proposing a
republication of the draft ASAP, since we have so many changes.

>
> ----
>
> Hope that helps, although I know that it's probably *not* what you were
> hoping to get....
>
> Addison
>
> Addison Phillips
> Internationalization Architect - Yahoo! Inc.
>
> Internationalization is an architecture.
> It is not a feature.
>
>> -----Original Message-----
>> From: www-i18n-comments-request@w3.org [mailto:www-i18n-comments-
>> request@w3.org] On Behalf Of Felix Sasaki
>> Sent: 2006?513 20:35
>> To: www-i18n-comments@w3.org; public-i18n-core@w3.org
>> Subject: LTLI draft: changes
>>
>> Hi all,
>>
>> Sorry, this took longer than expected ... please have a look at the
>> editor's copy at http://www.w3.org/International/core/langtags/ .
>>
>> I implemented the discussion at www-i18n-comments until
>> http://lists.w3.org/Archives/Public/www-i18n-comments/2006May/0006.html
>> changes are in sec. 1.4, see
>> http://www.w3.org/2006/05/09-i18ncore-minutes.html#action11
>>
>> I also implemented  the proposal from Francois / Richard to have
>> examples for the terms used, see
>> http://www.w3.org/2006/05/09-i18ncore-minutes.html#action12
>> changes are in sec. 2.1 (a new example).
>>
>> The last change: I added a revision log, see App. C.
>>
>> Please give feedback until next week Wednesday morning (European time, I
>> will be on travel). If nobody disagrees until Wednesday, I will request
>> republication of the draft.
>>
>> We have not yet addressed all proposals from Addison on new / different
>> conformance criteria, see
>> http://lists.w3.org/Archives/Public/www-i18n-comments/2006May/0000.html
>> (search for "General: I really think "), or wrote something for sec. 5
>> "Guidelines for the Interoperable Implementation of this Specification"
>> . I would propose to discuss these issues after republication of the
>> draft, since
>> a) I expect the discussion to take some time
>> b) we made a lot of changes in the last weeks, which we should bring to
>> the public rather sooner than later. Note that
>> http://www.w3.org/International/core/langtags/ is quite different from
>> http://www.w3.org/TR/2006/WD-ltli-20060419/ ...
>>
>> Regards, Felix.
>
>

Received on Tuesday, 16 May 2006 10:23:11 UTC