Add Likely Subtags first step

[Doug Ewell]

Mark Davis ☕️ wrote:

> I would be very much in favor of deprecating all of the grandfathered
> codes, and if supplying preferred values.

I was sure we had had this discussion at least once before.

> BCP47 says the following. Unfortunately, we used the "extended
> language range" instead of a language priority list, which would have
> made it easy. So that means we have to list the alternatives in a
> comment instead of having them be machine readable:

It has been this way from the beginning of RFC 4646, and doesn't appear 
to have caused major difficulty. In any case, this point affects ISO 
639-based deprecations at least as much as deprecations of grandfathered 
tags, so I don't see why it's particularly relevant here.

> Of these grandfathered codes, then, the following have not been
> deprecated. I suggest that we deprecate each of them, and supply
> alternatives where possible (in the description, and for zh-min)...
>
> cel-gaulish

I am fine with Kent's suggestion: deprecate, and add a comment listing 
subtags for four specific Gaulish languages (though it should list just 
the subtags, not the descriptions for those subtags, like every other 
time we have done this).

> en-GB-oed

If Michael is fine with 'oxford', I won't argue. I thought it was a 
conscious decision that 'oxford' might misleadingly imply the city 
rather than the dictionary.

> i-default

As Addison pointed out, like others before him, "i-default" is NOT 
Undetermined. If we must break RFC 2277, we should assign a language 
subtag of 'default' instead of distorting the meaning of 'und'.

> i-enochian

This should be language subtag 'enochian'.

> i-mingo

​I am fine with Kent's suggestion of a variant under 'see'.

I am also fine Kent's suggestion to add a comment to "zh-min" showing 
the subtags (no descriptions) of individual Min languages.

Note carefully that I am proposing 5- to 8-letter registered language 
subtags in this message. I am not impressed by arguments that RFC 
3066-era parsers can't handle them.

--
Doug Ewell | Thornton, CO, USA | http://ewellic.org ­