backpeddling on suggestion

Addison Phillips [wM] aphillips at webmethods.com
Sat Aug 14 23:24:17 CEST 2004


lux is not a subtag in the prototype registry. Things starting with i-* are all either permanently grandfathered or redundant. Yay.

Bokmal and Nynorsk are both deprecated. The two grandfathered tags you cite are also aliases for the ISO 639-1 tags nb and nn respectively.

The complete list of grandfathered tags that might "want" to become redundant in the future is:

grandfathered; i-ami; 'Amis; 1999-05-25; ;
grandfathered; i-bnn; Bunun; 1999-05-25; ;
grandfathered; i-enochian; Enochian; 2002-07-03; ;
grandfathered; i-mingo; Mingo; 1997-09-19; ;
grandfathered; i-pwn; Paiwan; 1999-05-25; ;
grandfathered; i-tao; Tao; 1999-05-25; ;
grandfathered; i-tay; Tayal; 1999-05-25; ;
grandfathered; i-tsu; Tsou; 1999-05-25; ;
grandfathered; zh-gan; Kan or Gan; 1999-12-18; ;
grandfathered; zh-min; Min, Fuzhou, Hokkien, Amoy, or Taiwanese; 1999-12-18; ;
grandfathered; zh-min-nan; Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo; 2001-03-26; ;
grandfathered; zh-wuu; Shanghaiese or Wu; 1999-12-18; ;
grandfathered; zh-yue; Cantonese; 1999-12-18; ;

Of these, the i-* tags are permanently grandfathered. If ISO 639-3 registers codes for them in the future, they will be aliases for the i-* tags and not the other way around. This is explicit in the text.

That leaves just 'gan', 'wuu', 'yue', 'min', and 'min-nan'. 'zh-min' and 'zh-min-nan' are permanently grandfathered tags, given the existance of 'min' in ISO 639-2 with a different meaning and assuming that the subtag 'min' will not be registered with a different meaning as a extlang. (Note that it could be registered as an extlang with a different meaning. Presumably that won't happen, since it would be confusing.)

Luckily, extlang in the current draft references nothing and cannot be used currently. One of the nice things about having an IANA Language Subtag Registry is that if and when extlang tags do get created, they can be registered in whatever is the most reasonable form. Just because ISO 639 does something no longer means that RFC 3066bis language tags have to do exactly the same thing. If a particular new ISO 639 code registration causes a problem, then the langtags registry can work around it. draft-langtags has to be revised before ISO 639-3 macro languages can be used as extlangs anyway, so we can solve those problems then, when looking at the completed ISO 639-3 work, instead of guessing now.

I think that macro languages will be a bit confusing, since they complicate the language tag choices (is it supposed to be 'zh-min-nan', 'zh-nan', or 'nan' or what???). 

Anyway, does anyone have a reason not to work towards completing draft-langtags as it sits? Even if Peter is right, there doesn't seem to be a reason to change any of the text currently in the draft. Perhaps we should preserve this problem in aspic while ISO 639-3 grapples with it...

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no 
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Peter Constable
> Sent: 2004年8月14日 13:42
> To: ietf-languages at alvestrand.no
> Subject: RE: backpeddling on suggestion
> 
> 
> I wrote:
> 
> > (There isn't a problem with "nan", though: I have assigned it in the
> draft 
> > table for ISO 639-3 to Min Nan.) 
> 
> There also isn't a problem in the following cases related to existing
> registrations:
> 
> gan = Gan Chinese
> wuu = Wu Chinese
> yue = Yue Chinese
> hak = Hakka Chinese (used in i-hak)
> ami = Amis (used in i-ami)
> bnn = Bunun (used in i-bnn)
> pwn = Paiwan (used in i-pwn)
> tao = Tao (used in i-tao)
> tay = Tayal (used in i-tay)
> tsu = Tsou (used in i-tsu)
> 
> The draft code table for ISO 639-3 is now consistent with these alpha-3
> subtags found in IANA registrations.
> 
> 
> There *is* a potential problem with
> 
> bok for Bokmal Norwegian (ISO 639-2 = nob; bok is not assigned in ISO
> 639-2)
> nyn for Nynorsk Norwegian (ISO 639-2 = nno; nyn = Nyankole)
> 
> though the two registered tags that use these (no-bok, no-nyn) are
> deprecated.
> 
> Another potential concern is
> 
> lux = Luxembourghish (used in i-lux, ISO 639-2 is ltz; lux is not
> assigned in ISO 639-2)
> 
> 
> 
> Peter
>  
> Peter Constable
> Globalization Infrastructure and Font Technologies
> Microsoft Windows Division
> 
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages



More information about the Ietf-languages mailing list