Preferred Values for Irregular Tags

Phillips, Addison addison at amazon.com
Wed Jan 20 19:53:47 CET 2010


The largest benefit would be: all of the old RFC 3066 tags would be deprecated or redundant. There would be no reason for a user to *start* using any of these old tags, since their meaning would be encapsulated by a modern tag. This has nothing to do with whether existing content takes notice of the change. Implementations of BCP 47 are still required to accept and deal with these tags. But this would hopefully close off further use and adoption of these special case tags. [i-default, of course, can't go away, but it's a special case anyway.]

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Michael Everson
> Sent: Wednesday, January 20, 2010 10:47 AM
> To: ietflang IETF Languages Discussion
> Subject: Re: Preferred Values for Irregular Tags
> 
> On 20 Jan 2010, at 18:36, Mark Davis ☕ wrote:
> 
> > The grandfathered tags behave differently than anything else. All
> > the other tags are productive: you can combine them in different
> > ways with expected results, while the grandfathered tags are
> atomic;
> > you can't combine one of them with, say, a region. Moreover, you
> can
> > write APIs to deal with that structure, returning the base
> language
> > code, script code, etc. The uniformity of program APIs is of
> extreme
> > importance when you are dealing with massive amounts of program
> code.
> >
> > Of course we could parse en-GB-oed. But it doesn't fit into the
> > regular ABNF production rules, and so doesn't work well in APIs.
> 
> So you can do it.
> 
> > Out of the billions of possible language tags (without even
> counting
> > combinations using variants), there are literally only a handful
> of
> > grandfathered codes (that cannot be correctly mapped to regular
> > language tags). If we can fix these few, then there is nothing
> > standing in the way of everyone being able to use all of them
> > effectively.
> >
> > That is, for existing data, we (and others like us) would convert
> > tags like en-GB-oed on input to regular tags; then the
> information
> > is still accessible. Otherwise our only choices are to dump the
> data
> > or map to the 'closest' code.
> 
> So you can do it, but you're threatening to "dump the data" if you
> don't get what you propose?
> 
> I'm finding it hard to find anything positive in what you have
> proposed. Perhaps there is something positive there, but I am not
> seeing it.
> 
> Michael Everson * http://www.evertype.com/
> 
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages


More information about the Ietf-languages mailing list