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

From: "Peter Constable" <[email-masked]>
Date: Mon, 3 Oct 2005 12:12:43 -0700

I guess my point is that if we're going to say something about LRLs, make it worthwhile for the reader. What you had really wasn't enough to be worthwhile, IMO. It seems to me that adding just a little more would make it useful without going way out of scope into negotiation mechanisms. Others may feel that saying anything is out of scope, and perhaps that's the prevailing opinion. I'm not opposed to saying *something* about LRLs, provided it achieves some useful purpose.

Peter

> -----Original Message-----
> From: Mark Davis [mailto:[email-masked]]
> Sent: Monday, October 03, 2005 9:14 AM
> To: Peter Constable
> Cc: [email-masked]
> Subject: Re: [Ltru] matching: Language Range Lists
> 
> There appear to be conflicting opinions among the group. Some didn't
> want any mention at all, and you are wanting more. I tried to satisfy
> this by supplying what I think is the minimum informative note: just
> enough to alert people to the fact that there is a potential issue that
> they should be aware of. It feels like if I supply more, the people who
> don't want anything will react. And we certainly don't want to do
> anything that would delay the process of getting this out, since some
> people feel like the language tags document is tied to this one
> (although I don't think there is any requirement there).
> 
> Mark
> 
> Peter Constable wrote:
> 
> >Mark:
> >
> >I have no problem with the kind of thing you've suggested here. It
> satisfies my two conditions: it's focusing on issues that go beyond
> matching a single range and it doesn't specify any particular syntax.
> >
> >What I would like to see change from what you've suggested is to see
> further elaboration. Right now, all you've done is (i) define _language
> range list_, (ii) give a few examples of them, and (iii) state that
> matching on LRLs has different requirements than matching on a range. What
> are those other requirements? Even if there's nothing that could be
> stipulated normatively, it would help to be informative. What you gave
> below is minimally informative: it tells me there are issues I should be
> aware of, but then leaves me to go looking at some specs that uses LRLs to
> try to work out what those issues might be. Even if it's not a
> comprehensive discussion, a brief description of couple of particular
> issues would clue the reader in to what those issues are.
> >
> >
> >Peter Constable
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Mark Davis [mailto:[email-masked]]
> >>Sent: Sunday, October 02, 2005 10:05 AM
> >>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: "Addison Phillips" <[email-masked]>
Date: Mon, 3 Oct 2005 12:16:10 -0700

+1

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

Internationalization is not a feature.
It is an architecture. 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Constable
> Sent: lundi 3 octobre 2005 12:13
> To: [email-masked]
> Subject: RE: [Ltru] matching: Language Range Lists
> 
> I guess my point is that if we're going to say something about LRLs, make
> it worthwhile for the reader. What you had really wasn't enough to be
> worthwhile, IMO. It seems to me that adding just a little more would make
> it useful without going way out of scope into negotiation mechanisms.
> Others may feel that saying anything is out of scope, and perhaps that's
> the prevailing opinion. I'm not opposed to saying *something* about LRLs,
> provided it achieves some useful purpose.
> 
> 
> Peter
> 
> 
>