Distinguishing Greek and Greek
mark.davis at jtcsv.com
Mon Mar 14 17:08:50 CET 2005
Sure. When cearching for content appropriate to language, both Java and ICU
use progressive truncation. So if you ask for data appropriate for
en-US-foobar, it first looks for that precisely, then en-US, then en.
----- Original Message -----
From: "Harald Tveit Alvestrand" <harald at alvestrand.no>
To: "Mark Davis" <mark.davis at jtcsv.com>; "Addison Phillips"
<addison.phillips at quest.com>; "IETF Languages Discussion"
<ietf-languages at iana.org>; "Michael Everson" <everson at evertype.com>
Cc: <cldr at unicode.org>
Sent: Sunday, March 13, 2005 10:54
Subject: Re: Distinguishing Greek and Greek
> --On 8. mars 2005 17:04 -0800 Mark Davis <mark.davis at jtcsv.com> wrote:
> > I was simplifying the example, but it is also a simplification to say
> > "language matching" does X; you have to specify the domain. HTTP Accept
> > language matching behaves the way you say, but it is quite common to use
> > the MSFF matching rules in other areas, both for locale matching and
> > language matching. For the latter, what you would typically have is a
> > hierarchy of information, something like the following, with some holes.
> can you give a reference for "MSFF matching rules"?
> HTTP Accept matching is a superset of the matching implied by the RFC 3066
> definition of "language-range", but this one is a new acronym for me.
More information about the Ietf-languages