RE: [xliff] Accepting Suggested Translations In XLIFF

2) Problem restatement

I have a software file that needs translation

I have a large database containing previous translations of source segments

I can query this database for valid translations that I can reuse

Where I have no translation that I can automatically reuse, I can query the database for candidate matches, and include these translations as suggested translations using the alt-trans structures.

I need to monitor how these suggested translations are used by translators:

a) If a translator can use these suggested translations, then I can justify paying less for the translation of the file

b) If a translator accepts one of these translations, and the translation is found to be in error, either in a review cycle, or as a reported error in a running product, then I need to identify that this mistranslation came from my suggestion lookup mechanism and either fix the mechanism, or reduce the scores generated by this mechanism.

Conversely, good translations made from these suggestions can be monitored to increase the scoring of the successful mechanisms

c) Sometimes translators may use one of my suggested translations as a starting point for the actual translation. I want to see how much a translator needs to modify what is suggested. I can then compare what is sent with what is returned

To enable this I want a translation tool to intercept the action of a translator accepting an alt-trans, either for translation or as a starting point for translation

For example, A translation tool may show all related alt-trans elements for a trans-unit in a drop down. When the translator selects one of these entries, the tool will capture and mark the selected alt-trans, with this mark included in the returned translated XLIFF file

3) Related issues

There was a previous but inconclusive discussion regarding marking each alt-trans regarding its usage

For example, other users may wish to use alt-trans to specify previous or discarded translations, which is the reverse of what I want to do

4) Proposals

a) Simple attribute

Include a new Boolean attribute "accepted" in alt-trans. Default is no

When a translation tool is used to propagate the alt-trans target to the parent trans-unit target, this attribute is set to yes

E.G.

<trans-unit id='hi'>
    <source>Hello world</source>
    <target>Hola mundo</target>
    <alt-trans accepted="yes">
     <target>Hola mundo</target>
    </alt-trans>

</trans-unit>

For -

Very simple

Against-

Requires schema change

Enforces behaviour of translation tool

b) Extension attribute

Same as above but using an extended attribute, with usage being recommended rather than required

E.G

<trans-unit id='hi'>
    <source>Hello world</source>
    <target>Hola mundo</target>
    <alt-trans xliffextension:acceptedtranslation="yes">
     <target>Hola mundo</target>
    </alt-trans>

</trans-unit>

For -

Also very simple

Against-

Requires agreement between all parties as to name of attribute and behaviour of translation tool

c) Note

Recommend a standard <note> structure

E.G

<trans-unit id='hi'>
    <source>Hello world</source>
    <target>Hola mundo</target>
    <alt-trans>

    <note>Accepted</note>
     <target>Hola mundo</target>
    </alt-trans>

</trans-unit>

For -

Also very simple

Against-

Requires agreement between all parties as to structure of note and behaviour of translation tool

d) New state attribute

Include a new "state" attribute within alt-trans with a closed list of values

E.G

rejected_translation

previous_translation

translation_candidate

accepted_translation_candidate

<trans-unit id='hi'>
    <source>Hello world</source>
    <target>Hola mundo</target>
    <alt-trans state="accepted_translation_candidate">

<target>Hola mundo</target>
</alt-trans>

<alt-trans state="translation_candidate">

<target>&Hola mundo!</target>
</alt-trans>

<alt-trans state="previous_translation">

<target>Hola mundo</target>
</alt-trans>

</trans-unit>

For -

Also captures other usages for alt-trans and prevents improper usage

Against-

Requires schema change and agreeing closed list of usages

Mat

xliff message