Adding code equivalents

Doug Ewell doug at ewellic.org
Sat Dec 12 17:59:51 CET 2009


Mark Davis ? <mark at macchiato dot com> wrote:

> I agree that it would have been good to add the equivalents, not only 
> for those but for the others where possible. That is, when we see 
> "eng-840" (and these codes *do* occur in the wild), we can 
> canonicalize to en-US. We are doing that in CLDR, and I think it would 
> have been productive to add to BCP47.

I disagree.  Do we really suppose those numeric country code elements 
occur in the wild?  I doubt there are that many people besides members 
of this list, the UNSD, and Gwillim Law who even know they exist.  As 
for the 3-letter language code elements like "eng" that have a 2-letter 
equivalent, adding them to the Registry -- even as Deprecated -- would 
most assuredly have the effect to many users of "legitimizing" them for 
BCP 47 use.  Each of us can judge whether we think that is desirable.

> However, it would take a revision to do that, which I doubt we are up 
> for. And while the Deprecated and Preferred Value does provide a 
> mechanism that does work, I suspect that people would probably like a 
> different term than Deprecated for such items, to indicate that they 
> are not just not in canonical form, but are actually invalid -- but 
> that they can be turned into valid by replacing by the preferred 
> value.

I would not support adding known-invalid entries to the Registry.  We 
might just as well add "english", "french", and scores of cross-language 
translations, as people have been known to use those names in language 
tags too.  And I would not support drawing a distinction in the Registry 
between "deprecated but valid" and "deprecated and invalid."  It would 
not change the way people use the Registry, but it would add complexity 
and confusion.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­



More information about the Ietf-languages mailing list