<br><br><div class="gmail_quote">2009/9/12 Kent Karlsson <span dir="ltr">&lt;<a href="mailto:kent.karlsson14@comhem.se">kent.karlsson14@comhem.se</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>
<font color="#800080"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Not that I&#39;m necessarily arguing that a language tag extension should be defined for this (in particular I&#39;m not arguing for using BLEU scores), but I&#39;d just like to clarify a few things.<br>

</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
<br>
Den 2009-09-12 09.06, skrev &quot;Felix Sasaki&quot; &lt;<a href="http://felix.sasaki@fh-potsdam.de" target="_blank">felix.sasaki@fh-potsdam.de</a>&gt;:<br>
<br>
</span></font><div class="im"><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Of course one could define several machine translation related extensions, <br>
<br>
</span></font></blockquote></div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><font color="#800080">I think so far, just one extension related to this has been alluded to, varyingly using &quot;-t-&quot; or &quot;-m-&quot; in examples as singletons for it (in messages earlier in this thread).<br>

</font><br>
</span></font><div class="im"><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">but at some point the suitability of language tags is really in question. E.g. how would you represent a bleu score as an extension? The point is that proper metadata for evaluation of machine translation soon goes beyond a simple &quot;can be represented as a closed set of strings&quot; pattern. <br>

</span></font></blockquote></div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
<font color="#800080">The RFC describing the extension can allow for numbers to be expressed in the extension, as long as the number is expressed as strings (could be several per number) of ASCII letters and digits of length 2-8. The RFC need not enumerate them. In particular, subtags that occur in an extension have no relation to subtags that occur in the LSR.<br>
</font></span></font></div></blockquote><div><br><br>I am aware of that. I was not aware that there is no need to have a closed set of strings for extensions, thanks for the clarification.<br><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><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><font color="#800080">
<br>
However, I&#39;m not arguing for actually doing this.</font></span></font></div></blockquote><div><br><br>I am relieved :)<br><br>Felix<br><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><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><font color="#800080"> So far there is no consensus that an extension for &quot;translation status&quot; or similar should be defined.<br>

<br>
        /kent k<br>
<br>
</font><br>
</span></font><blockquote><div class="im"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Felix<br>
<br>
2009/9/11 Kent Karlsson &lt;<a href="http://kent.karlsson14@comhem.se" target="_blank">kent.karlsson14@comhem.se</a>&gt;<br>
</span></font></div><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><div class="im">What you say is correct for a (single) variant subtag, as initially suggested, but extension subtags<br>

work differently. See <a href="http://tools.ietf.org/search/rfc5646#section-2.2.6" target="_blank">http://tools.ietf.org/search/rfc5646#section-2.2.6</a>. Data like that you refer<br>
to can be put in the part that follows the extention &quot;singleton&quot;.<br>
<br>
Note also that section 2.2.6 starts:<br>
<br>
&quot;Extensions provide a mechanism for extending language tags for use in<br>
   various applications.  They are intended to identify information that<br>
   is commonly used in association with languages or language tags but<br>
   that is not part of language identification.<br>
&quot;<br>
<br>
        /kent k<br>
<br>
<br>
<br></div>
Den 2009-09-11 18.35, skrev &quot;Felix Sasaki&quot; &lt;<a href="http://felix.sasaki@fh-potsdam.de" target="_blank">felix.sasaki@fh-potsdam.de</a> &lt;<a href="http://felix.sasaki@fh-potsdam.de" target="_blank">http://felix.sasaki@fh-potsdam.de</a>&gt; &gt;:<br>

<br>
</span></font><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><div class="im">I would agree with Yves Savourel that for translation tool developers, this kind of information is better provided via a different field. Other practical information which one could not pack into a broad data category &quot;machine translation&quot; easily (to use Peter&#39;s terminology), but not easily in the &quot;language tag&quot; field would be: name of system that generated the translation (maybe several ones where used ...), quality of the input, quality rating of the system (e.g. BLEU score). IMO these fine grained differences are necessary for making use of this kind of metadata, and I don&#39;t see a clear use case for a broad &quot;machine translated&quot; sub tag.<br>

<br>
Felix<br>
<br></div>
2009/9/11 Kent Karlsson &lt;<a href="http://kent.karlsson14@comhem.se" target="_blank">kent.karlsson14@comhem.se</a> &lt;<a href="http://kent.karlsson14@comhem.se" target="_blank">http://kent.karlsson14@comhem.se</a>&gt; &gt;<br>

</span></font><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
Den 2009-09-11 17.32, skrev &quot;Peter Constable&quot; &lt;<a href="http://petercon@microsoft.com" target="_blank">petercon@microsoft.com</a> &lt;<a href="http://petercon@microsoft.com" target="_blank">http://petercon@microsoft.com</a>&gt; &gt;:<br>

<br>
&gt; From: <a href="http://ietf-languages-bounces@alvestrand.no" target="_blank">ietf-languages-bounces@alvestrand.no</a> &lt;<a href="http://ietf-languages-bounces@alvestrand.no" target="_blank">http://ietf-languages-bounces@alvestrand.no</a>&gt; <br>
<div class="im">
&gt; [<a href="mailto:ietf-languages-bounces@alvestrand.no" target="_blank">mailto:ietf-languages-bounces@alvestrand.no</a>] On Behalf Of Felix Sasaki<br>
&gt;<br>
&gt;&gt; There is a difference in the case of XLIFF. If the extension subtag is just<br>
&gt;&gt; similar,<br>
&gt;&gt; but not identical to MT related information in other technologies like XLIFF,<br>
&gt;&gt; you<br>
&gt;&gt; will end up with a mess of *values*. This is IMO different from the script<br>
&gt;&gt; subtag<br>
&gt;&gt; case: Here you have the same values, but different *occurences*<br>
&gt;<br>
&gt; Expressed with different terminology: you end up with a mess of data<br>
&gt; categories; in the script subtag case, you have a single data category with<br>
&gt; many values.<br>
<br>
I don&#39;t think that should be a major issue. XLIFF, and other formats having<br>
separate attributes for this, could simply have that attribute take<br>
priority, even to the extent that &quot;language extensions&quot;, in particular one<br>
that overlaps with an attribute, can be completely ignored in those formats.<br>
<br>
        /kent k<br>
<br>
<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
</div><a href="http://Ietf-languages@alvestrand.no" target="_blank">Ietf-languages@alvestrand.no</a> &lt;<a href="http://Ietf-languages@alvestrand.no" target="_blank">http://Ietf-languages@alvestrand.no</a>&gt; <br><div class="im">

<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
</div></span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
<br>
</span></font></blockquote></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
<br>
</span></font></blockquote>
</div>


</blockquote></div><br>