A few corrections. - MD<br><br><div><span class="gmail_quote">On 12/8/06, <b class="gmail_sendername">Doug Ewell</b> &lt;<a href="mailto:dewell@adelphia.net">dewell@adelphia.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Frank Ellermann &lt;nobody at xyzzy dot claranet dot de&gt; wrote:<br><br>&gt; I still don't like any &quot;generic&quot; variants, and think that extension<br>&gt; registries are a better approach.&nbsp;&nbsp;On the other hand it's hard to to
<br>&gt; develop a proper extension from scratch, so maybe experimenting with<br>&gt; fon* variants for now is a good thing.&nbsp;&nbsp;Until somebody has the time to<br>&gt; identify rules for a future &quot;f&quot; extension, deprecating the registered
<br>&gt; fon* variants.<br><br>Michael is right on this one.&nbsp;&nbsp;Variants like &quot;western&quot; applied to the<br>&quot;Western&quot; version of different languages would violate Section 3.5<br>(&quot;change the semantic meaning&quot;) and should not be accepted.&nbsp;&nbsp;IPA is
</blockquote><div><br>I disagree -- there is no general consensus on that; it was just silly to resort to constructed terms in a foreign language to avoid having useful, productive variants. (Might as well have had esternWay and easternYay.)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">different; by design it can be applied to virtually any spoken language.<br>(Note that this is not true for SAMPA, one of the many mappings of IPA
<br>onto ASCII; it is language-dependent.)<br><br>I've pretty much given up on extensions.&nbsp;&nbsp;The language tag people (OK,<br>John Cowan) say they are for non-linguistic information, but it seems<br>unlikely to me that the non-language tag people will go to the effort of
<br>writing an RFC and getting it through IETF, and setting up a mailing<br>list.&nbsp;&nbsp;They'll probably do what they have always done, create their own<br>syntax.&nbsp;&nbsp;Even ICU has create the ersatz variants &quot;revised&quot; and &quot;posix&quot;
</blockquote><div><br><span></span>The history is a bit off here. &quot;revised&quot; and &quot;posix&quot; predated 4646 by quite some time. The Unicode CLDR project was at its most recent version, 
      V1.4, on 2006-07-16, while RFC 4646 was only finally approved afterwards, in September 2006.<br><br>Moreover, the Unicode CLDR project has been moving towards changing these to be 4646 codes in LDML, as variants get encoded that can handle them (even if, like polytonic, suboptimally). This has been communicated in several emails on LTRU. The only remaining outlying case is POSIX, which we didn't think the ietf-languages group would buy off on. (It basically means using &quot;neutral&quot; terms corresponding to usage in computer languages). If someone where to come up with a good way to replace that with a 4646 variant tag, I think the CLDR group would be all ears.
<br><br>In a few cases, we use private use codes for cases where 4646 is
insufficient. Those are documented in <a href="http://unicode.org/reports/tr35/#Identifiers">http://unicode.org/reports/tr35/#Identifiers</a>, and available in machine-readable form. We also clarify which codes are to be used for unknown or
invalid codes (subtags).<br>
<br>There is also a transformation of CLDR locales into conformant 4646 tags (and back): see<br> <a href="http://unicode.org/reports/tr35/#Identifiers">http://unicode.org/reports/tr35/#Identifiers</a> . We do intends to file for an extension, basically so that we can use something like -u- instead of -x-ldml
<br><br>The most problematic case remaining for international identifiers is currencies, which ISO documents and maintains badly, and doesn't guarantee stability. ZWD for example, stands for two different currencies, which differ by a factor of 1000!!!!
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">instead of trying to register the former as a variant or create an<br>extension for the latter.
<br><br>--<br>Doug Ewell&nbsp;&nbsp;*&nbsp;&nbsp;Fullerton, California, USA&nbsp;&nbsp;*&nbsp;&nbsp;RFC 4645&nbsp;&nbsp;*&nbsp;&nbsp;UTN #14<br><a href="http://users.adelphia.net/~dewell/">http://users.adelphia.net/~dewell/</a><br><a href="http://www1.ietf.org/html.charters/ltru-charter.html">
http://www1.ietf.org/html.charters/ltru-charter.html</a><br><a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br><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>