Subject: RE: [Ltru] editorial comments on draft-07 (part 2)

From: "Addison Phillips" <[email-masked]>
Date: Tue, 6 Dec 2005 13:06:05 -0800

Comments follow.

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Duerst
> Sent: Tuesday, December 06, 2005 1:59 AM
> To: LTRU Working Group
> Subject: [Ltru] editorial comments on draft-07 (part 2)
> 
> [co-chair hat off]
> 
> and on we go...
> 
> 3.1 Choosing a Type of Matching, continued.
> - third-to-last para: I find the HTTP example problematic.
>    It somehow suggests that is what HTTP says. As Mark has explained,
>    it is close to what servers do, but not what the spec says.
>    It also ignores the possibility of "300 Multiple Choices"
>    responses (see
>    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1)
>    I'm not exactly sure what to do, probably the best thing is
>    to find another example.
[Addison Phillips] 

Return a 300 for a 404? Ick.

I agree a better example is called for. How about a more generic:

--
For example, if process were to insert a human readable error message into a protocol header, it might select the text based on the user's language preference. Since it can return only one item, it must choose a single item and it must return some item, even if no content matches the language priority list supplied by the user.
--

> - second-to-last para: 'examine the values': What exactly does
>    that mean? Maybe change to something like "don't need any
>    additional information about any specific subtags".
[Addison Phillips] 

No, I think it is more general than that: they do not care about the contents other than to find the boundaries between the subtags. This is a source of great efficiency, at the expense of certain kinds of error checking or more interesting processing (such as equating 'no' and 'nb'). How about:

--
<t hangText="Note: ">Most types of matching in this document are designed so that implementations are not required to validate or understand any of the semantics of the subtags supplied and, except for scored filtering, they do not need access to the Language Subtag Registry. This has great benefit for speed and simplicity of implementation.</t>
--

> - dito: "Language Registry Subtag": Please provide a reference
>    (to draft-initial, I guess)
[Addison Phillips] 

We can't really reference draft-initial. How about we reference where it is defined, i.e. RFC 3066bis (draft-registry), Section 3?

> - dito, last sentence: simplify to "This simplifies and speeds
>    up implementations." (you can add 'greatly' if you want to keep it)
[Addison Phillips] 

How about:

--
This simplifies and speeds the performance of implementations.
--

("Speeds up" could be read to mean implementation time)

> - last para: I think this paragraph should be moved to section 4.
[Addison Phillips] 

Not sure. Kept in place for now.
> 
> 3.2 Filtering
> - 1st para: 'arbitrary number' -> 'arbitrarily large number' ?
[Addison Phillips] 

Done.

> - 2nd para: '_least_ specific': please add that it is therefore
>    shortest
[Addison Phillips] 

Sentence changed to:

--
In filtering, the language range represents the <spanx>least</spanx> specific (that is, the fewest number of subtags) language tag which is an acceptable match.
--

Note that "shortest" in characters isn't always the least specific. 

> - third bullet: 'in specific range' -> 'in a specific range';
>    also, 'range of languages' is similar (but not the same as)
>    'language range' (the former being semantics, the later syntax),
>    so maybe a different word from 'range' is better.
[Addison Phillips] 

Done. Used "set of languages" in place of various range locutions, which is in keeping with the use of LPLs instead of ranges in the schemes.

> - 3rd last para: 'would put ... priority order' ->
>    'would order the results [by priority]' ?
[Addison Phillips] 

Done.

> - last para: 'each language tag to a language range':
>    unclear why 'each' on one side, but 'a' on the other side,
>    suggest to use 'a' for both
[Addison Phillips] 

Changed to read:

--
A distance metric assigns a numeric value to the comparison of each language tag to each language range that represents the 'distance' between the two.
--

> - dito: distance indicated -> distance indicates
[Addison Phillips] 

Typo fixed.

> - dito, last sentence: 'or it can': what does 'it' refer to?
>    maybe 'implementations', but then numbers don't match
[Addison Phillips] 

Fixed.

> 
> 3.2.1 Filtering with Basic ...
> - There is nothing explaining what happens with language
>    priority lists.
[Addison Phillips] 

Fixed by rewriting the first para to match that in extended filtering.
> 
> 3.2.2 Filtering with Extended ...
> - 1st para: 'Extended Range Matching scheme': is that the
>    terminology we use? The term 'basic matching' is also
>    used in this paragraph, but lower case.
[Addison Phillips] 

Expunged this terminology in favor of filtering and no formal name for each. Perhaps we should have formal names, tho?

> - dito: we should first describe how a single extended language
>    range matches, and only then go to describe how language
>    priority lists are dealt with.
[Addison Phillips] 

Actually, I went the opposite direction per Harald (and my own personal preference). The schemes are all in terms of LPLs, with matching described between ranges and tags.
> 
> 3.2.3 Scored Filtering
> - 1st para: 'beneficial' -> 'useful' (beneficial sounds a bit
>    too much like we're trying to save the world)
[Addison Phillips] 

Yes.

> - 2nd para: 'must be canonicalized' -> 'MUST ...' ?
[Addison Phillips] 

Yes. And I rephrased this section to be more like the other filtering sections and to proceed from an LPL.

> - 3rd para: 'language element': I checked RFC 3066bis, and
>    didn't find 'element' at all. Please allign terminology.
[Addison Phillips] 

I clarified by making clear that "element" is actually an item of the scored filtering scheme not defined elsewhere.

> - 4th para: 'language-tag' -> 'language tag'
[Addison Phillips] 

Done.

> - dito: Thus a pattern ...: merge with following list.
>    (if not, then at least change 'a pattern' to 'the pattern')
[Addison Phillips] 

"thus the language range "*"...

> - "Examples of various tag's distances": "tag's" -> "tags'"
[Addison Phillips] 

This was already changed.

> - "might give a small distance to the difference closely related"
>    -> "might give a small distance to closely related"
[Addison Phillips] 

I rephrased as:

--
... an implementation might assign a smaller distance to the difference between closely related subtags...
---

> - The paragraph with that sentence, and the examples following,
>    seem to turn up in slightly different form in other places.
>    Please check if it doesn't make sense to move that topic
>    to a general place.
[Addison Phillips] 

It has different meaning here. I suspect that, with some additional inspection, I can find the other generic instances and harvest them for inclusion in Section 4 somewhere.

> - Region: UM: add a parenthesis at the end of that line
[Addison Phillips] 

Done
> 
> 3.3 Lookup
> - General: This is a long section, I propose to create some
>    subsections, as follows:
>    - one for the general stuff at the start
>    - one for the discussion of priority lists (in -07 starting
>      just before the end of page 15)
>    - one for extended language ranges (after what's Figure 8
>      in -07)
[Addison Phillips] 

This section is heavily rewritten and now considerably shorter. Please consider that first.

> - 1st para: talk about single language ranges only here,
>    about priority lists later.
[Addison Phillips] 

Went the opposite direction globally, as noted above.

> - "only the closest matching item ...": Add something to say
>    that it's returned only if it is less specific.
[Addison Phillips] 

Perhaps "closest" isn't the right term: it is the FIRST item found that is returned. I split this into two sentences and added one that mirrors the other types of matching:

---
When performing lookup, each language range in the language priority list is considered in turn, according to priority. By contrast with filtering, each language ranges represents the <spanx>most</spanx> specific tag which is an acceptable match. The first information item found with a matching tag, according the user's priority, is considered the closest match and is the item returned.
---

> - "Selection of a graphic containing text": I don't like
>    this example, because it is bad accessibility practice.
[Addison Phillips] 

I changed "graphic" to "item"...

> - after bullet list: "in the Lookup scheme": probably better
>    lower-case.
[Addison Phillips] 

Done.

> - same para: 'would progressively search': Change to
>    "progressively searches"
[Addison Phillips] 

Done.

> - There are about 6 cases in the draft where 'zh' turned
>    into 'z.', please change back.
[Addison Phillips] 

Already noted.

> - "as with xml:lang in the XML specification":
>    - This may be understood to mean use of xml:lang in the
>      specification itself. Please clarify.
[Addison Phillips] 

Done.

>    - A reference to the XML spec should be added non-normatively.
[Addison Phillips] 

Already done.
> 
> More to follow tomorrow.     Regards,   Martin.
> 
It is getting a lot harder to edit draft-08 based on comments on draft-07. Please hurry :-)
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Dec 2005 06:31:19 +0100

Addison Phillips wrote:
 
>> dito: "Language Registry Subtag": Please provide a reference
 
> We can't really reference draft-initial.

You could (informative reference), but as placeholder for the
"real" registry it's a dubious idea.

> How about we reference where it is defined, i.e. RFC 3066bis
> (draft-registry), Section 3?

Or use the "real" IANA URL (TBD) of the tag registry, it will
exist before the matching draft gets an RFC number.  Ideally
it will be <URL:http://www.iana.org/assignments/language-tags>.

It's ready when the "IANA" flag in the queue will be removed:
http://www.rfc-editor.org/queue.html#draft-ietf-ltru-registry

                           Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Wed, 07 Dec 2005 20:07:34 +0900

Comments below. Simple "done"s and "fixed"s are acknowledged and removed.

 >Return a 300 for a 404? Ick.

Apache did this quite a bit before the introduced the directives
to set default languages,...
And in some way, it actually makes quite a bit of sense.
If you (or your browser) tells the server that you understand
English and German, and the server has French and Chinese,
then it may be better to send you back a page saying
"Sorry, your choice is not available, but we have French or Chinese,
which do you want" than to just send you Chinese and let you find
another language version from somewhere on that Chinese page.
There may even be a chance to have at least the "multiple choice"
page in a large number of languages.

 >For example, if process were to insert a human readable error message into
 >a protocol header, it might select the text based on the user's language
 >preference. Since it can return only one item, it must choose a single item
 >and it must return some item, even if no content matches the language
 >priority list supplied by the user.
 >--

okay.

 >No, I think it is more general than that: they do not care about the
 >contents other than to find the boundaries between the subtags. This is a
 >source of great efficiency, at the expense of certain kinds of error
 >checking or more interesting processing (such as equating 'no' and 'nb').
 >How about:
 >
 >--
 ><t hangText="Note: ">Most types of matching in this document are designed
 >so that implementations are not required to validate or understand any of
 >the semantics of the subtags supplied and, except for scored filtering,
 >they do not need access to the Language Subtag Registry. This has great
 >benefit for speed and simplicity of implementation.</t>
 >--

okay.

 >We can't really reference draft-initial. How about we reference where it is
 >defined, i.e. RFC 3066bis (draft-registry), Section 3?

Fine with me.

 >>    up implementations." (you can add 'greatly' if you want to keep it)

Okay.

 >Not sure. Kept in place for now.

I'll probably come back to this on my next read.

 >In filtering, the language range represents the <spanx>least</spanx>
 >specific (that is, the fewest number of subtags) language tag which is an
 >acceptable match.
 >--
 >

Ok, good point.

 >Done. Used "set of languages" in place of various range locutions, which is
 >in keeping with the use of LPLs instead of ranges in the schemes.

I think Mark specifically didn't like 'set', because it's different
from list.

 >A distance metric assigns a numeric value to the comparison of each
 >language tag to each language range that represents the 'distance' between
 >the two.
 >--

I agree that strictly speaking, it's "each", but that's
usually understood when using "a" (meaning "an arbitrary"),
and

A distance metric assigns a numeric value to the comparison of a
language tag to a language range that represents the 'distance'
between the two.

in my view really is easier to read than your text.

 >Expunged this terminology in favor of filtering and no formal name for
 >each. Perhaps we should have formal names, tho?
 >
 >Actually, I went the opposite direction per Harald (and my own personal
 >preference). The schemes are all in terms of LPLs, with matching described
 >between ranges and tags.

See separate mail on this issue.

 >I clarified by making clear that "element" is actually an item of the
 >scored filtering scheme not defined elsewhere.

Will check on next round.

 >"thus the language range "*"...

ok.

 >It has different meaning here. I suspect that, with some additional
 >inspection, I can find the other generic instances and harvest them for
 >inclusion in Section 4 somewhere.

Please go ahead, at least with the inspection.

 >This section is heavily rewritten and now considerably shorter. Please

Will do.

 >Went the opposite direction globally, as noted above.

Again, see separate mail.

 >Perhaps "closest" isn't the right term: it is the FIRST item found that is
 >returned. I split this into two sentences and added one that mirrors the
 >other types of matching:
 >
 >---
 >When performing lookup, each language range in the language priority list
 >is considered in turn, according to priority. By contrast with filtering,
 >each language ranges represents the <spanx>most</spanx> specific tag which
 >is an acceptable match. The first information item found with a matching
 >tag, according the user's priority, is considered the closest match and is
 >the item returned.
 >---

okay.

 >I changed "graphic" to "item"...

okay.

Regards,   Martin.