RE: [xliff] Accepting Suggested Translations In XLIFF

Hi Matt,

Thanks for an interesting suggestion. I have also been looking for a similar mechanism in XLIFF recently. I have a couple of comments:

1) In addition to identifying which <alt-trans> was used I would like to have a mechanism for the user to indicate why changes were made, e.g.:

Because a fuzzy match needed to be modified to fit (normal behaviour for fuzzy matches)
Because the context requires a different translation (the new translation should be added to a TM, while still keeping the original proposed translation)
Because the proposed translation is incorrect (the original proposed translation should be updated in a TM)

As can be seen from above this information is important for translation memory assets and the like.

I hope we can combine this into your proposal.

2) Regarding your suggested option d), introducing a new “state” attribute:

I am of the opinion that we should not mix this functionality with the unrelated problem of revision tracking. They are two different issues and should thus be handled with different mechanisms.
As a side note: In fact the concept of revision tracking brings other problems related to this: for example, how can one indicate that a particular <alt-trans> was used in one version, while a different <alt-trans> was used in another version? But this is probably not so important, as in most cases only the last used <alt-trans> would really be of interest.
Also I think we should use “-“ rather than “_” as word separators in the attribute values, to be consistent with the rest of the XLIFF specification.

3) The XLIFF specification allows multiple <target> elements inside an <alt-trans>. Unless we change this (which I am definitely for!) we would need to use your suggested attribute on the <target> element rather than/in addition to on the <alt-trans>.

4) To cover what I raised in 1) above I would propose:

Use an attribute named “applied” (either in the XLIFF namespace or as a recommended extension).
The attribute should be for the <alt-trans> element.
Only one <target> element is allowed when this attribute is used.
The attribute can have the following values:

no – (default) this translation suggestion was not used.
exact – the translation was an exact match that was used without modifications
changed-fuzzy-adapted – the translation was used but had to be adapted as it was not an exact match
changed-inline-elements-adapted – the translation was used, the text was not changed, but the content and/or type of inline elements (i.e. embedded tags) was modified
changed-different-context – the match was used but the text (and possibly tag) content was changed to fit a different context
changed-incorrect-content – the match was used but changed due to mistakes in the previous translation

Applied to your example:

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

</trans-unit>

Let me know what you think.

Magnus

From: Matthew Lovatt [mailto:matthew.lovatt@oracle.com]
Sent: Monday, November 15, 2004 11:24 AM
To: xliff
Subject: RE: [xliff] Accepting Suggested Translations In XLIFF

1) Previous mails

2) Problem restatement

3) Related issues

4) Proposals

1) Previous mails

Issue raised:

http://lists.oasis-open.org/archives/xliff/200407/msg00000.html

Response from Yves

http://lists.oasis-open.org/archives/xliff/200407/msg00003.html

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