Adding code equivalents

Doug Ewell doug at
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  |
RFC 5645, 4645, UTN #14  |  ietf-languages @ ­

More information about the Ietf-languages mailing list