Subject: RE: [Ltru] Re: Matching metrics

From: "Addison Phillips" <[email-masked]>
Date: Thu, 7 Apr 2005 09:35:35 -0700

> There is no one solution, because sometimes script will be more
> important than region and variant, and sometimes one of the other two
> will be the most important.  The charter acknowledges this: "it is not
> expected that any single matching algorithm will fit all needs."

RFC 3066 already recognizes that its hierarchy and real languages in the world at large may not map smoothly together. Two languages that share prefixes may not be mutually intelligible, for example.

While it is possible that a human being can look at a language tag and "intuit" the author's intended meaning from it, this isn't something an algorithm can do.

I think that RFC 2616 prefix matching is actually sufficient for most needs. Introducing "extended language ranges" coupled, possibly, with John's matching scheme will help ease the transition, but it isn't strictly necessary. Consider:

  Accept-Language: en-US; q=1.0, en-Latn-US; q=0.9

You can do the right thing using RFC 2616 without any fancy wildcards or expansions.

Addison

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 Doug Ewell
> Sent: jeudi 7 avril 2005 00:16
> To: LTRU Working Group
> Subject: [Ltru] Re: Matching metrics
> 
> Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:
> 
> > In column 2 (en-GB-scouse) en-Brai-GB-scouse beats
> > en-GB-Latn and en-Latn-US-scouse.
> 
> Well, it should, shouldn't it?
> 
> John's algorithm will work fine for some cases.  Yours, with weights of
> 4-3-1-2 or 4-2-1-3 or whatever, might work better in some cases and not
> as well in others.
> 
> 
> -Doug Ewell
>  Fullerton, California
>  http://users.adelphia.net/~dewell/
> 
> 
> 
> _______________________________________________
> 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: "McDonald, Ira" <[email-masked]>
Date: Thu, 7 Apr 2005 09:49:34 -0700

Hi,

Inline.

Cheers,
- Ira

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Addison Phillips
> Sent: Thursday, April 07, 2005 12:36 PM
> To: Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: Matching metrics
> 
> 
> RFC 3066 already recognizes that its hierarchy and real 
> languages in the world at large may not map smoothly 
> together. Two languages that share prefixes may not be 
> mutually intelligible, for example.
> 
> While it is possible that a human being can look at a 
> language tag and "intuit" the author's intended meaning from 
> it, this isn't something an algorithm can do.
> 
> I think that RFC 2616 prefix matching is actually sufficient 
> for most needs. Introducing "extended language ranges" 
> coupled, possibly, with John's matching scheme will help ease 
> the transition, but it isn't strictly necessary. Consider:
> 

But most browsers and servers still don't properly support
'q' factors.

And most non-HTTP applications using language tags (or all?)
don't have anything like 'Accept-Language' with 'q' factors.