Subject: RE: [Ltru] matching: Language Range Lists

From: "Addison Phillips" <[email-masked]>
Date: Mon, 3 Oct 2005 08:52:36 -0700

My concern with "language range lists" is that they have precious little to do with language tag matching. They are used by language negotiation mechanisms in concert with matching to produce an ordered set of results. But they are not part of the matching of tags: they are part of a negotiation mechanism. 

Negotiation mechanisms that order results are important, surely. I'd be happy to describe negotiation schemes in general and best practices for implementing same. But LRLs by themselves are kind of pointless, don't you think? 

Personally, I think we should do negotiation schemes separately, but if we want to mention them in this document (and we should decide which), then we should talk about them directly and not fool around with language range lists (are we going to enumerate all the different potential separator characters?!?)

Might I propose the following instead of your text:

--
2.X Language Negotiation Using Ranges

Any of the language tag matching mechanisms described above can be used to match a specific piece of content to a specific request. When a user requests content, though, it may be necessary to order the set of matching results and to consider more than one language range in order to identify the best match for the user's preferences. This process is called 'language negotiation'.

In language negotiation, the user specifies a list of language ranges, possibly weighted or ordered according to the user's preferences. A negotiation mechanism can produce a single information item or a list of ordered results depending on the needs of the application and might consider additional information not contained in language tags in deciding which content to return and in what order. 

For example, [Accept-Lang] Accept Language, as described in Section 14.4 of the RFC 2616 (HTTP 1.1), as well as in RFC 3282, describes a list of language ranges ordered by 'weights'. Here are some examples of how this list of language ranges could be used with the matching mechanisms described above when negotiating language content:

* items go here.....
--

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Davis
> Sent: dimanche 2 octobre 2005 10:05
> To: Peter Constable
> Cc: [email-masked]
> Subject: Re: [Ltru] matching: Language Range Lists
> 
> My concern with language range lists is that the lookup is *not* simply
> looking up each language until you get a match, either in the
> Accept-Language language range lists, the Apple language range lists, or
> the CLDR language range lists. So I would like *at least* an informative
> note to that effect, that people know that they should not simply apply
> the matching algorithms listed in the document to a list.
> 
> I suggest something like the following language.
> 
> 
> 2.3 Language Range Lists
> 
> A language range list is a ordered list of zero or more language ranges,
> perhaps with additional structure to give additional priorities among
> the elements of the list. These are used in Accept-Language
> [Accept-Lang], and in various implementations such as Apple's language
> lookup and CLDR's language fallback. The lookup and matching within
> language range lists require somewhat different lookup and matching
> mechanisms in order to produce reasonable results, so it should not be
> assumed that it is sufficient to serially apply the mechanisms specified
> in this document to such a list.
> 
> 
> [Accept-Lang] Accept Language, as described in Section 14.4 of the RFC
> 2616 (HTTP 1.1)
> 
> 
> Peter Constable wrote:
> 
> >>From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >>Randy Presuhn
> >>
> >>
> >
> >
> >
> >
> >>Total agreement.    Our charter is quite narrow and specific regarding
> >>this
> >>deliverable.  It says:
> >>
> >>| The second document will describe matching algorithms for use with
> >>| language tags. Language tags are used in a broad variety of contexts
> >>| and it is not expected that any single matching algorithm will fit all
> >>| needs. Developing a small set of common matching algorithms does seem
> >>| likely to contribute to interoperability, however, as it seems likely
> >>| that using protocols could reference these well-known algorithms in
> >>| their specifications.
> >>
> >>I believe the fact that it talks about "matching algorithms" rather than
> >>"negotiation mechanisms" is important, and has direct consequences
> >>for the document.  Specifically, what we say about negotiation
> mechanisms
> >>will need to be non-normative, included merely as use cases justifying
> >>our decision to document specific algorithms.
> >>
> >>
> >
> >I agree. For that reason, I think that if we want to include some
> discussion of language range lists, then (i) it should be because we think
> there are particular issues in relation to matching on lists of ranges
> that need particular consideration over and above matching a single range
> alone, and (ii) we should not give any specification of syntax for lists:
> that is entirely up to the particular negotiation protocol to determine.
> >
> >
> >
> >Peter Constable
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Ltru mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> 
> 
> _______________________________________________
> 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: Mon, 03 Oct 2005 09:46:52 -0700

What I am concerned about isn't really about  negotiation. A language 
range list is still static: an example is where a user wants to indicate 
that the languages s/he wants are "br; fr", asking for Breton text if 
available, otherwise French. This is being communicated to a target 
process, but there is no negotiation going on. It is not as if the 
process will negotiate back with the user: "Hmm. Don't have Breton, and 
have only partial French; how about Greek?".

This isn't to say that some processes might have language negotiation, 
but that is a very different kettle of fish.

A language range list is really just an extension of a language range. A 
language range is like being able to specify a color with (bl.*), which 
will match "blue" and "black"; a language range list is like being able 
to add other possibilities, such as  (bl.*|gree.*) which also picks up 
"green" (but not "grey"). Your text also limits the scope to matching, 
when lookup is equally applicable.

Mark