Preliminary proposal for deprecating grandfathered tags under
RFC3066ter
John.Cowan
jcowan at reutershealth.com
Fri Sep 30 16:45:01 CEST 2005
Tex Texin scripsit:
> 1) so we have tlh, which can be tlh-Latn and tlh-? for klingon?
> ;-)
In fact, the Okuda script doesn't even have an ISO 15924 code. tlh *is*
tlh-Latn.
> 2) If we have a registry that is a comprehensive list of all the tags, why
> do we need to deprecate existing tags and make new ones just for consistency
> of naming convention? It adds duplication, and since we can't get away from
> supporting the original tag, it is just more work.
2a) A lot of the grandfathered tags are extremely obscure, probably with
few or no live uses.
2b) If you've got a generative mechanism that handles 99% of the cases,
and you can get it to handle 100% of them (well, except for that pesky
i-default) with a little work, why not?
2c) The grandfathered tags don't participate in tag generation: for example,
zh-min-nan has markedly different flavors in CN and TW, but you can't
generate zh-min-nan-CN and zh-min-nan-TW to handle them if you need to.
The 3066ter language subtag zh-nan (well, technically a language subtag
followed by an extlang subtag) will be part of the generative system.
Two corrections while I'm at it (and thanks, Doug): zh-min-nan becomes
zh-nan, not zh-min; and en-gb-oed can't be made redundant because oed is
not a valid variant subtag, so we need to either register oedict (or the
like) and deprecate en-gb-oed in favor of en-gb-oedict, or else leave
en-gb-oed alone.
--
Don't be so humble. You're not that great. John Cowan
--Golda Meir jcowan at reutershealth.com
More information about the Ietf-languages
mailing list