<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2"> </HEAD> <BODY> <TT>On Wed, 2005-02-16 at 17:49 +0100, Bruno Haible wrote:</TT> <TT>Hi,</TT> <TT>> If your tools contains a logic saying</TT> <TT>> </TT> <TT>>     If an <alt-trans> is a 100% match and there is no <target> in the</TT> <TT>>     containing <trans-unit>, promote the <alt-trans>'s <target> to</TT> <TT>>     the containing <trans-unit>.</TT> <TT>> </TT> <TT>> then it will not work reliably. </TT> <TT>The logic in our XLIFF editor is exactly what you describe, but there is</TT> <TT>no reliability problem. </TT> <TT>> The <alt-trans> can come from different</TT> <TT>> sources: translation memory pertaining to the same project and translator,</TT> <TT>> translation memory coming from different project or different translators,</TT> <TT>> automatic translation attempts, dictionary lookups. </TT> <TT>There is a catch here: translators are in control of the translation</TT> <TT>memory and glossaries used. They decide what TM database to use and what</TT> <TT>TBX glossaries they want to consult.</TT> <TT>Further, translation is copied from the <alt-trans> to the <trans-unit></TT> <TT>but it is not approved. The translator decides if the choice is right or</TT> <TT>not.</TT> <TT>> There needs to be an</TT> <TT>> indicator for the level of trust that an <alt-trans> can have, so that</TT> <TT>> the rule mentioned above is only executed when the origin of the</TT> <TT>> <alt-trans> is trusted. An <alt-trans> attribute like 'origin' should do</TT> <TT>> it.</TT> <TT>We do certainly use the "origin" attribute, but its value is not an</TT> <TT>obstacle for copying a 100% match to the target.</TT> <TT>Translators can tell if a match was an internal repetition (same</TT> <TT>sentence repeated somewhere else in the file), extracted from TM (light</TT> <TT>blue background) or originated in Machine Translation (yellow</TT> <TT>background). The GUI provides feedback as needed. </TT> <TT>> The po2xliff converter should then set this 'origin' value to an untrusted</TT> <TT>> one that prevents automatic insertion of <target>.</TT> <TT>That would not change the default behavior of the XLIFF editors. </TT> <TT>The "origin" attribute is usually set by the TM system, not by the</TT> <TT>converter.</TT> <TT>> For the non-automatic case, where an explicit translator action is needed,</TT> <TT>> we have the choice between putting the fuzzy translation into the <target></TT> <TT>> and label it with a certain state, or putting it into an <alt-trans>.</TT> <TT>You can also put the text in the <target> and set the "approved"</TT> <TT>attribute to "no".</TT> <TT>> Putting it into the <target> is not so good, because</TT> <TT>>   - the "state" is something related to the workflow between translators,</TT> <TT>>     QA, etc.</TT> <TT>The value of the "state" attribute is meaningful for the XLIFF editor,</TT> <TT>not for the converter. The converter can't control the values set by the</TT> <TT>translator at translation time.</TT> <TT>>   - the translator is more tempted to say "OK" to a wrong fuzzy translation</TT> <TT>>     when it is presented as <target> than when it is presented as</TT> <TT>>     <alt-trans><target>.</TT> <TT>Temptations will exist.</TT> <TT>What would happen if the <alt-trans> is marked as a 100% match? wouldn't</TT> <TT>the translator be tempted to accept it too?</TT> <TT>Regards</TT> <TT>Rodolfo</TT> <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> -- Rodolfo M. Raya <<A HREF="mailto:rodolfo@heartsome.net">rodolfo@heartsome.net</A>> Heartsome Holdings Pte. Ltd. </TD> </TR> </TABLE> </BODY> </HTML>