RE: LTLI draft: changes

Comments follow:

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

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

3. 3rd paragraph. This phrase is missing the "in": 

"is to identify language *in* terms of"

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").
--

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.
--

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"
--

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).

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.

9. Penultimate paragraph in Section 1.4. Instead of "The language parameter
may be available", say "Language tags may be available". 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).

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".

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

----

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年5月13日 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 Monday, 15 May 2006 18:09:35 UTC