Variant subtag proposal: ALA-LC romanization of Russian

[Doug Ewell]

"Phillips, Addison" <addison at amazon dot com> wrote:

> I would prefer, as noted, to deprecate the existing subtag 'heploc' 
> instead. Deprecation does not make the subtag illegal. It provides a 
> mapping to a Preferred-Value.

So 'heploc' was added to the Registry just 7 weeks ago, and we are 
already talking about deprecating it.  I think that sets a record of 
some sort, one that probably doesn't evoke an image of great stability, 
even though deprecation does not, in fact, make the subtag illegal.

An additional problem is that 'heploc' was very intentionally given a 
Prefix of "ja-Latn-hepburn" so that hierarchical fallback would work as 
expected.  The proposed action would undo that.

I'm just exposing problems here, not proposing any real solutions.  Too 
much time at work spent on QA testing, maybe. :-)

> Note that, assuming 'alalc97' is not a generic variant and has Prefix 
> fields in its record, wholesale removal of Prefixes is not permitted 
> (RFC 5646, Section 3.1.8), nor is there a mechanism for deprecating 
> only certain uses of a subtag.

Actually, wholesale removal -- that is, removal of all the prefixes, 
thus making a non-generic variant into a generic one -- is permitted, 
because that widens the range of recommended tags.  What's not permitted 
is to remove some of the prefixes, but not all.

If we do go with a "Library of Congress romanization" subtag that is 
intended to apply to different languages, then I do agree it should be 
generic (no prefixes) from the outset.  But I'm still waiting for a 
certain participant, who has not yet commented on this, to step in and 
say this is a bad idea.

> However, a comment field could be inserted guiding users towards 
> 'alalcXX'. If 'alalc97' is generic, then a new subtag could have 
> prefixes or could also be generic with a note to provide guidance on 
> usage.

Do the revised versions really differ so much from previous versions 
that users would want to tag them separately?  Would that do more harm 
than good for matching and lookup?

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­