Suggestion: registration of variant subtags for Aluku, Ndyuka, and Pamaka (Suriname/French Guiana English-based Creoles)

CE Whitehead cewcathar at hotmail.com
Wed Jan 28 02:55:50 CET 2009


Hi. Doug, Peter, thanks for your corrections.  (My last post was sort of hasty, maybe.)  
(I assume M. Lang wants NM because MN is taken but I think we only register region codes when a UN M.49 code becomes available with no ISO 3166 code??? or else when a 3166-1 code is created with no corresponding UN M.49 code???  Both seem like odd situations???  Someone please clarify this discussion for me; I thought we only registered variants, but it seems that the language subtag reviewer can also, in some unusual circumstances, register region codes??) Back to the variants:  I'm fine with waiting till till  RFC 4646 is published before considering M. Vaillant's variants; (Sorry; I thought that discussion was o.k. since we had discussed "erzgeb" while waiting for a successor of RFC 4646 ; see http://www.alvestrand.no/pipermail/ietf-languages/2008-March/007672.html but of course, there will -- hopefully-- not be that long a wait for RFC 4646 & it makes sense to wait!) Thanks!--C. E. Whiteheadcewcathar at hotmail.com  Lang Gérard gerard.lang at insee.fr Mon Jan 26 15:49:10 CET 2009 > Dear Doug,

> 2-The alpha-2 code element "MF" is associated with the country name "SAINT-MARTIN (FRENCH PART)", so that M is for Saint-Martin, and F for French part. 
> And if SINT-MAARTEN, that will soon no more be part of Netherlands Antilles, becomes a new entry inside ISO 3166-1, a code element like NM (N for Netherlands and M for Maarten) would be very good to see the separation of the territory of this islands betweem two sovereignties ! 
> Bien cordialement.
> Gérard LANG > Doug Ewell doug at ewellic.org Mon Jan 26 01:12:13 CET 2009  > CE Whitehead had written:>> As far as I understand, it is possible to change the ISO639-3 codes >> and language names (Joan Span's posting has just reminded me of this), >> but you are right; I do not think a change to the code itself would be >> worth pursuing; if you wished to add additional names however, that >> would be fine:> Peter Constable <petercon at microsoft dot com> replied:>> It is *not* possible to change the ID of an already-encoded category, >> so requesting such a change is definitely not worth pursuing. Changing >> the name without changing the semantic is possible, however, and >> changes to a semantic are possible with restrictions so as to avoid >> causing existing usage to become invalid.> I'm only guessing, > . . . > I think maybe it needs to be stated again that neither this list nor > LTRU is the place to request changes to ISO 639-3, or even to offer > advice about what changes can be made to 639-3.  The RA has a very open > and accessible change-request mechanism, at least when compared to other > ISO standards, and we ought not to try to act as a surrogate for that.> CE continued (I missed this earlier):>> And we can still approve the variant subtags (once RFC 4646 is >> published?  Is that the consensus?)> RFC 4646bis, not 4646.> I don't understand why this would be a question of "consensus."  Once > the language subtags are in the Registry -- call it Date D -- we can > review any proposals related to those subtags, such as M. Vaillant's > variants, and the Reviewer can act upon them.  We just can't take any > action on these proposals until Date D. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090127/66317e7b/attachment.htm 


More information about the Ietf-languages mailing list