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