<br><br><div class="gmail_quote">2009/9/11 Doug Ewell <span dir="ltr">&lt;<a href="mailto:doug@ewellic.org">doug@ewellic.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Felix Sasaki &lt;felix dot sasaki at fh dash potsdam dot de&gt; wrote:<br>
<br>
&gt;&gt; The problem with this is that it applies to XLIFF (XML Localization<br>
&gt;&gt; Interchange File Format) only. A language tag extension, in contrast,<br>
&gt;&gt; can be used anywhere language tags can already be used.<br>
&gt;<br>
&gt; Yes, but in XLIFF it is a common to store such information in a<br>
&gt; separate field, that is not as part of a language identifier (which<br>
&gt; are used as well in XLIFF, via xml:lang). Having a language identifier<br>
&gt; with similar information would create confusion.<br>
<br>
</div>The same argument was made against script subtags during the development<br>
of RFC 4646.<br></blockquote><div><br><br>There is a difference in the case of XLIFF. If the extension subtag is just similar, but not identical to MT related information in other technologies like XLIFF, you will end up with a mess of *values*. This is IMO different from the script subtag case: Here you have the same values, but different *occurences* (e.g. a script field in XSL-FO and an language tag in XSL-FO). Difficult to handle, but still much easier than a different set of values.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
&gt; I did not propose the table as an input for variant subtags. I rather<br>
&gt; think that people who mostly need the use case discussed in this<br>
&gt; thread (the localization industry) lalready have the means the need -<br>
&gt; they just do not rely on language tags for the purpose of identifying<br>
&gt; machine translated content.<br>
<br>
</div>In fact, the thread started with someone saying they did not have a<br>
means to identify machine-translated content, and were looking to<br>
language tags to fill the void.<br></blockquote><div><br><br>True indeed. But there seemed to be some unawareness of existing mechanisms to indicate &quot;content X was created via MT&quot;, and the suitability for the needs expressed in this thread. <br>
<br>Felix<br></div></div>