Subject: RE: [Ltru] Re: 3166-1 state machine

From: "Peter Constable" <[email-masked]>
Date: Thu, 31 Mar 2005 09:09:33 -0800

> From: [email-masked] [mailto:[email-masked]]
On Behalf Of
> Jukka K. Korpela

> Well, yes, it is an error, but a common one. Even the Dublin Core
> documents have contained it...

> Is there a point after which erroneous usage becomes common enough to
be
> taken so seriously that it be recognized?

Certainly a valid question for a case like "UK". It is one thing to
specify what is *supposed* to be done; it is another for implementations
to actually support de facto practice.

Peter Constable

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 31 Mar 2005 10:05:58 -0800

> Is there a point after which erroneous usage becomes common enough to be
> taken so seriously that it be recognized? That would mean keeping "UK" as
> country code unassigned (reserved) and treating any use of "UK" as country
> code as an error in principle but with the error recovery that it is
> interpreted (perhaps with a warning) to mean 'United Kingdom'. Someone
> might say that this would mean virtually accepting "UK" as synonym for
> "GB" - and this might be regarded as a very bad move.

No. It makes a mess.

While many users regrettably don't know that UK is not the country code to use in language tags, allowing both as synonyms makes life a lot harder for the kinds of processes that language tags are designed for.

For example, in a web page, if I use the CSS :lang pseudo attribute to assign a style to content in a particular language:

  p:lang(en-GB) {  color: blue; }

Then the user agent (for example) has to perform complex matching of tags in the document to see if the rule should be applied.

  <p xml:lang="en-UK-x-example">This text is blue?</p>

Processes that currently rely on left-prefix matching (which is to say, nearly all of them) must now normalize both requests (in this case the CSS rule) and content (in this case the XHTML).

One of the nice benefits of having a registry is that users at least can look up the valid values somewhere and not have to go to four or five places not identified by the standard to find out what to use.

> But after all, metadata is about giving information about data, and if an
> author labels his data as, say, applying to country "UK" or being in
> language "en-UK", shouldn't we work by what we know he must have _meant_,
> instead of just blowing horns and sending error messages around?

Well, RFC 3066 matching by non-validating processors does work with those tags, from the point of view that if you ONLY use en-UK then all is well. If you don't want to know the meaning of the tag, then "en-UK" works as a blob of identifier. RFC 3066bis even allows the unknown 'UK' subtag to be recognized unambiguously as a region. If you care about the meaning of the subtag, then it becomes important, though. And content authors or end users who use "en-UK" will not find all of the content that they "know" they are asking for but which the machines, poor little grasshoppers, can't match to the more proper 'GB' subtag.

Don't forget: this isn't just a few tags that we're talking about here. This processing would have to be applied to ALL tags and ranges. And no doubt where we allow one exception there will be others. Lots of tags for the same thing makes life easy on content authors, who don't have to learn anything, but makes life much harder for implementations or, ultimately, the much larger audience of end users.

Best Regards,

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 Jukka K. Korpela
> Sent: jeudi 31 mars 2005 08:37
> To: LTRU Working Group
> Subject: Re: [Ltru] Re: 3166-1 state machine
> 
> On Tue, 29 Mar 2005, Doug Ewell wrote:
> 
> > > For some time I thought that en-UK is correct... :-(  Maybe I
> > > confuse it with a locale.  Google claims to have 300,000 hits
> > > for "en-uk" (quoted), most of them probably irrelevant.
> >
> > That's not evidence of ccTLDs in language tags, that's just an error.
> > :-)
> 
> documents have contained it, e.g.
> http://dublincore.org/documents/1999/07/02/dces/
> (the current version has it fixed to en-GB).
> 
> The error is understandable, since the official name of the country is
> "United Kingdom" (long form: "United Kingdom of Great Britain and Northern
> Ireland"). Besides, the official European Union policy is to use "UK" as
> the country code (otherwise using ISO 3166 except for Greece).
> 
> Is there a point after which erroneous usage becomes common enough to be
> taken so seriously that it be recognized? That would mean keeping "UK" as
> country code unassigned (reserved) and treating any use of "UK" as country
> code as an error in principle but with the error recovery that it is
> interpreted (perhaps with a warning) to mean 'United Kingdom'. Someone
> might say that this would mean virtually accepting "UK" as synonym for
> "GB" - and this might be regarded as a very bad move.
> 
> But after all, metadata is about giving information about data, and if an
> author labels his data as, say, applying to country "UK" or being in
> language "en-UK", shouldn't we work by what we know he must have _meant_,
> instead of just blowing horns and sending error messages around?
> 
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
> 
>

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 31 Mar 2005 20:34:05 -0800

Peter Constable <petercon at microsoft dot com> wrote:

>> be taken so seriously that it be recognized?
>
> Certainly a valid question for a case like "UK". It is one thing
> to specify what is *supposed* to be done; it is another for
> implementations to actually support de facto practice.

I can certainly imagine an language-tag-generating application being
kind and forgiving enough to replace 'UK' with 'GB'.  That would be up
to the application, though, not part of the standard.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/