RE: [xliff] subState question

[Ryan King <ryanki@microsoft.com>]

Thanks Yves for the reply. In actuality, we decided to implement something more like this: state=”translated” and subState=”xyz:auto”; which gives us our “auto-translated super-state”. So now we’ll know that the target was auto-translated, not human translated. If we also include a match, then we’ll be able to get additional data for the segment, which can help users decide what to do with it (review, revert, finalize, etc.). For example:

 

<mtc:matches>

<match id=”m1” ref=”#s1” type=”mt” similarity=”100” origin=”auto-translation service” matchQuality=”100”>

 <source>This tutorial teaches you how to create a simple "Hello, world" app.</source>

 <target>Este tutorial te enseña cómo crear un simple "Hola, mundo" app.</target>

</mtc:matches>   

<segment state="translated" subState="xyz:auto" id="s1">

 <source>This tutorial teaches you how to create a simple "Hello, world" app.</source>

 <target>Este tutorial te enseña cómo crear un simple "Hola, mundo" app.</target>

<segment>

 

It would be nice, of course, to have a standard way to specify that a target has been translated by a match. With TMMT scenarios becoming more commonplace, content providers will need a way to do this. A tangential question then comes up if I have more than one match referencing a segment, such as several suggestions, but one of them was actually used in auto-translation, how do I know which one it was? Currently, our implementation takes the match with the highest matchQuality, but other implementations may use highest matchSuitability, or some other criteria to govern this. A common way to define which match among several was used for auto-translation could also be helpful. Anyway, maybe these are all 2.2 features?

 

Thanks,

Ryan

 

From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Tuesday, April 28, 2015 7:47 PM
To: Ryan King; xliff@lists.oasis-open.org
Subject: RE: [xliff] subState question

 

Hi Ryan,

 

This is a very good question.

 

As you noted, 2.0 doesn’t have any provision for specifying the type of candidate when using it in the main target element, and that would certainly be something quite useful.

 

I suppose based on the definition of subState nothing prevent you to use the Candidate module subState values there. Ideally we should have some defined way of doing this.

 

-ys

 

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Tuesday, April 21, 2015 2:02 PM
To: 'xliff@lists.oasis-open.org'
Subject: [xliff] subState question

 

Hi XLIFF TC,

 

As a module, translation candidates support is not required. In the case where it is not used, if a target segment has been auto-translated, can subState be something like this:

 

<segment state="translated" subState="xyz:mt" id="1">

          <source>This tutorial teaches you how to create a simple "Hello, world" app.</source>

          <target>Este tutorial te enseña cómo crear un simple "Hola, mundo" app.</target>

<segment>

 

Basically use the values defined for match.type (http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#candidates_type) as subState values?

 

I see the following processing requirement for extension mechanisms, but not sure if this is intended to apply to subState or other “sub” values:

4.9.3 Processing Requirements

·        A user extension, whether implemented using <mda:metadata> or using a custom namespace, MUST NOT provide the same functionality as an existing XLIFF core or module feature, however it MAY complement an extensible XLIFF core feature or module feature or provide a new functionality at the provided extension points.

Thanks,

Ryan