RE: [xliff] Y8 - translation state

[Yves Savourel <ysavourel@enlaso.com>]

Hi Helena,

> ...since different organizations would have even different
> processes and definitions on what "translated" even means,
> how do we ensure consistency across various processes?

The idea is that they would not have different definitions of what the first part means. XLIFF would define what these values mean exactly. But the users would have complete control over the second part. The only requirement would be that they must make sure to classify their different states in one of the to-level ones.

For example, in your case you listed:

state='new' 
state='pretranslate'
state='translated' 
state='translated/xyz:someMTEngine'
state='translated/xyz:post_edit_done' 
...

It would probably be something like this:

state='new' -> the entry is new, nothing has been done to it.
state='translated/ibm:pretranslate' -> some pre-translation step has been applied, possibly from TM(?)
state='translated/ibm:someMTEngine' -> an MT engine has been applied
state='translated/ibm:post_edit_done' -> a human has done the post editing
etc.

basically: you would still control the state. But another tool could get a basic knowledge of the status of the translation by looking at the first part of the value: 'translated' means the target is there, it may be done by a human a machine, some leverage, etc. We don't know that. But we know it has not gone through a review step yet.


> Also, if the input goes directly from MT to publishing 
> channel, the only really interesting state to me would be 
> "new" and "final". Anything in between is too hard to 
> track and define consistently. 

And that's fine too. The idea is not that the segment must go through all the steps, just to provide a) a rough idea of the stats of the translation with the first part, and b) allow tool to fine-tune the meaning of the state.

Cheers,
-yves