Variant subtag proposal: ALA-LC romanization of Russian

[CE Whitehead]

Hi!
A generic prefix field is very broad indeed and cannot be narrowed later!
But I am not particularly tied to one or the other solution as far as generic and specific prefixes go;

however, there is no way I would consider registering all possible specific prefixes at once for [alalc97]--just those requested.  
Also, I am sort of in favor of deprecating [heploc] for the logic of things
(though it seems a shame to register a subtag and then deprecate it; it's not a good precedent to set normally I don't think)!


Phillips, Addison addison at amazon.com 
Wed Nov 18 16:48:40 CET 2009 
>> > For my needs, this approach would be sufficient. Indeed, would it
>> > be a
>> > workable short-term solution to change my variant subtag request
>> > to
>> > the subtag "alalc97", which could be processed on its own merits
>> > in
>> > the short term (with only the prefix ru-Latn), then modified to
>> > include other possible prefixes (cs-Latn, tt-Latn, etc.) if the
>> > community so decides?
That is a possibility--as prefixes can always be added. 

And it perhaps solves the problem of deprecation in a case where the romanization scheme is modified before a particular prefix is requested.
>> 
>> It would be easy enough to specify the range of use for alalc97 now.

> I'm not so sure.

> If a subtag has Prefix fields, then it should try to list the full range of appropriate prefixes. 

> This may be a quite lengthy list and difficult to maintain. If it has *no* prefix, then it is what we are calling a 

> "generic variant". Lack of a prefix should not imply that a subtag is useful with every possible language tag. It 

> merely means that the registry does not specifically recommend a fixed set of language tags for use.

>> 
>> > I also have a slight concern that a broadly defined "alalc97"
>> subtag
>> > would be overlap with existing romanization variants; to draw
>> from the
>> > most recent romanization discussion, text in the LOC Hepburn
>> > romanization of Japanese could be marked as either
>> > jp-Latn-hepburn-heploc or jp-Latn-alalc97.
>> 
>> Then we specify the range of use for alalc97 now, and explicitly
>> omit Japanese since it is already covered.

> 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.
Somewhat agreed here though it's only been seven weeks.  But it would make sense to register alalc97 for both Russian and Japanese I guess--that would insert some logic and consistency and unity in the variant subtag list.
> 
>> > Similarly, if a new set of ALA-LC romanization tables is released,
>> but it differs only in its
>> > treatment of a few languages, would we then have identical text
>> that can be marked equally well as ru-Latn-alalc97 or ru-Latn-
>> ala09 ?
>> 
>> Then alalc09 is only registered for use with the changed (or new)
>> languages.

> 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. 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.
This is a problem.  I still like the idea of registering this subtag with the list of possible prefixes (two at this moment; Russian and Japanese); at least more prefixes can be added later; if we make this a generic prefix, it gives everyone the use of this subtag without further ado of course--if that is needed. 
But this is a much more specific case than fonipa and fonupa and it seems strange having both generic.

> The registry does not exist to completely remove all possible choice (and thus all possible error) in language 

> tagging, so I tend to favor rather less documentation in the registry.


Hmm.  Of course, it would be nice to remove the possibilities for error as much as a list of subtags can.

Best,

--C. E. Whitehead
cewcathar at hotmail.com
> Addison

> Addison Phillips
> Globalization Architect -- Lab126


 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20091120/35616c2c/attachment.htm