Preliminary proposal for deprecating grandfathered tags under RFC3066ter

[John.Cowan]

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