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:] 

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