Subject: RE: [Ltru] Matching: Ranges vs. range lists

From: "Addison Phillips" <[email-masked]>
Date: Wed, 16 Nov 2005 07:46:07 -0800

I have been trying to do that. See the "Lookup" section (which does more-or-less this).

General observation: making general observations about the text is vexing for the editors. Try to make specific suggestions about specific pieces of text.

I'm going to finish up a bunch of edits based on Martin's emails today along with my work to fix the "application" vs. "application or protocols" text handling and submit my proto-draft-06. I think this is the proper course of action, given that no one has objected to the new format and it will make editing the document easier if I don't have to maintain two rapidly diverging documents.

Addison

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: 2005年11月16日 1:50
> To: LTRU Working Group
> Subject: [Ltru] Matching: Ranges vs. range lists
> 
> [This mail is somewhat related to my mail entitled
> Matching: Filtering and Lookup: What's the fundamental difference.]
> 
> I think the current draft is not careful enough to distinguish
> between single ranges and lists of ranges.
> 
> I think that each specific matching section (e.g. basic range
> lookup, and so on) should first define whether a given range matches
> against a given tag (the result ideally being binary), and then
> go on and talk about the cases of having more than one tag
> and/or more than one range, in a well organized fashion.
> 
> Regards,   Martin.
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Mark Davis <[email-masked]>
Date: Wed, 16 Nov 2005 08:56:22 -0800

I'd like to discuss the following. I don't think it is controversial 
(but I've been wrong about that before!). If we can agree on the 
concept, then I'll suggest some additional text.

One of the key issues is making sure that lookup allows for correct 
handling of the default fallback. This is important because different 
systems do it differently. Lookup on a single language tag progressively 
truncates. It switches to the default language before going to root (the 
last resort). So suppose that the default language is ja-JP (Japanese in 
Japan). We would search as follows:

<br> en_US_California<br> en_US<br> en<br> ja_JP<br> ja<br> ROOT<br>

There are different ways to extend this to a /list/ of languages, such 
as what one has in HTML. Suppose we have a situation where the 
Accept-list of languages is *<ru, en-US, fr>*, and the actual installed 
languages for the product are *ja* and *en*, with the default language 
set to *ja*. There are several ways to walk the language hierarchy, some 
of which may get an unwanted answer.

   1. If the normal lookup is used /serially/, then one will check for
      *ru*, not find it, then go to the default language: *japanese*.
      /This is clearly not what is wanted/.
   2. If an /exact match/ on languages is used, then one would check for
      *ru*, not find it, then check for *en-us*, not find it, check for
      *fr*, not find it, and also end up with the default language:
      *japanese*. /Also not desired./
   3. Instead, one should only switch to the /default language at the
      end of the list/. That is, one would do normal lookup, but
      stopping if the language switches to the default language. That
      way we would get *en* in the above example. This is effectively
      the same as modifying the accept list to add truncated languages,
      e.g. changing the above example to *<ru, en-US, en, fr>* and only
      then switching to the default.
          * One might extend this to add only languages where they would
            not "block" later ones on the list, e.g. *<ru en-US fr
            en-GB-plum>* => *<ru en-US-California en-US fr en-GB-plum
            en-GB en>*. However, that is only really an issue where one
            has multiple countries/variants in a list, not grouped
            together. That is probably pretty rare, and is not worth
            designing for.
          * Notice that (c) is a compatible extension to the normal
            lookup used by Java, ICU, and other systems. If there is
            only one item in the list, the same results would be produced.

Addison Phillips wrote:

>>------------------------------------------------------------------------
>>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 16 Nov 2005 16:34:28 -0800

--On 16. november 2005 08:56 -0800 Mark Davis <[email-masked]> 
wrote:

> en_US_California
> en_US
> en
> ja_JP
> ja
> ROOT

I don't think I agree. My interpretation is that "default language" is a 
per-application decision, not a part of the language matching rule, and 
treating it as part of the langauge matching rule will just add confusion.

But I have to read the matching draft carefully before I'm sure what I 
disagree with, or how to express it.