This is still an open issue. John discussed the choices in <a href="http://www.alvestrand.no/pipermail/ietf-languages/2004-August/002214.html">http://www.alvestrand.no/pipermail/ietf-languages/2004-August/002214.html</a><br>
<br>To add examples and some pros & cons to his list:<br><ol><li><span>Allow the individual language codes</span></li><ul><li><span>cmn-CN is valid</span></li><li><span>zh-cmn-CN is not</span></li><li><span>+ Simplest approach, no new structure.
</span></li><li><span>- fallback requires extra information.</span></li></ul><li><span>Allow the higher-order code extended by an individual language code</span></li><ul><li><span>cmn-CN is not valid</span></li><li><span>
zh-cmn-CN is valid</span></li><li><span>- means adding more structure (which we have allowed for).</span></li><li><span>+ automatic fallback</span></li><li><span>- testing for validity is slightly more complicated (need to check that the combination of lang + extlang is valid)
</span></li></ul><li><span>Allow both 1 and 2 as synonyms.</span></li><ul><li><span> zh-cmn-CN and cmn-CN are both valid and synonymous.</span></li><li><span>- means adding more structure (which we have allowed for).</span>
</li><li><span>± automatic fallback (if we canonicalize to the longer form)<br></span></li><li><span>- testing for validity is slightly more complicated (need to check that the combination of lang + extlang for the long form is valid)
</span></li></ul></ol>A big question in my mind is the stability of the macro language inclusion relationship. If there is the remotest chance that they will change, eg that someday de becomes a macro language that includes de, sli, sxu, ltz, vmf, etc. (
<a href="http://www.ethnologue.com/show_family.asp?subid=90073">http://www.ethnologue.com/show_family.asp?subid=90073</a>) then the only choice we have is #1.<br><br>The more I think about it, the more I like #1. We already have to do
<span>fallback between language subtags (think no, nb, nn), and this recasts the issue into providing additional data so that if I don't find language subtag X, I can what is the next best choice Y.</span><br><br>Also see
<a href="http://www.sil.org/iso639-3/macrolanguages.asp">http://www.sil.org/iso639-3/macrolanguages.asp</a>, <a href="http://www.sil.org/iso639-3/scope.asp#M">http://www.sil.org/iso639-3/scope.asp#M</a><br><br>Mark<br><br>
<div><span class="gmail_quote">On 8/23/06, <b class="gmail_sendername">Addison Phillips</b> <<a href="mailto:addison@yahoo-inc.com">addison@yahoo-inc.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>> But the macrolanguage in 639-3 doesn't just create itself, does it?<br>> Suppose -- this is my whole point really -- suppose this happened in the<br>> 3066ter era. The Registry would contain primary language subtags "diq"
<br>> and "kiu". Now suppose 639-2 adds "zza" and we need to add it as well.<br>> We would have to reclassify "diq" and "kiu" from primary to extended,<br>> right?<br><br>
Stability rules prevent this from happening: a subtag cannot change its<br>stripes, or the whole meaning of the term "stability" goes out the<br>window. In that case, users would need to decide if 'zza' or 'diq'/'kiu'
<br>were more appropriate for their content. Another potential solution<br>would be that language subtag 'diq' might be deprecated in favor of the<br>prefix "zza-diq" (using a new extlang 'diq').<br><br>Addison<br>
<br>--<br>Addison Phillips<br>Globalization Architect -- Yahoo! Inc.<br><br>Internationalization is an architecture.<br>It is not a feature.<br>_______________________________________________<br>Ietf-languages mailing list
<br><a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br><a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br></blockquote>
</div><br>