RE: [xliff] Y8 - translation state

I like the simplicity of the state attributes described here, and I think this solution presents a good compromise for the difficult problem of facilitating countless unknown and varied proprietary states.

I am wondering about the definition of “final”. Can I assume that this will be a reliable indicator of readiness to proceed to the next workflow step? Or, should this be a more authoritative “final”, where no further changes are anticipated (i.e. ready to publish)?

In Microsoft, we’ve had similar discussions around how to map high level translation status with myriad low-level localization process sub-states. Given the inevitable complexity around these low level states, we aren’t interested in defining or tracking everything that happens during the translation/editing/proofreading phase. Instead, what becomes important is identifying readiness to “move forward” – i.e. when a translation is ready for the next step in the overall workflow (which doesn’t imply any overall finality). Once this time has been identified, further in-house validation/processing may occur. But how could we identify this readiness given the generic “translated” and “reviewed” states that most tools will support? Do you anticipate all/any of these factors to be managed via custom second-level states entirely?

Thanks,

Kevin.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Tuesday, October 02, 2012 7:53 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Y8 - translation state

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

---------------------------------------------------------------------

To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org

For additional commands, e-mail: xliff-help@lists.oasis-open.org

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Helena S Chapman
Sent: Tuesday, October 02, 2012 7:26 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Y8 - translation state

I think this is an interesting proposal though I am having a difficult time picturing how different companies with different processes would take advantage of this. So I am thinking from IBM perspective and the examples would change to:

state='new'
state='pretranslate'
state='translated'
state='translated/xyz:someMTEngine'
state='translated/xyz:post_edit_done'
state='translated/xyz:post_translate' or state='post_translate'?
state='reviewed/xyz:rejected-by-client-review
state='reviewed/xyz:translator-review-done
state='reviewed/xyz:client-review-done
state='final'

The struggle I have is. State needs to be tracked somehow but since different organizations would have even different processes and definitions on what "translated" even means, how do we ensure consistency across various processes? To me, for example, "state='reviewed/xyz:translator-review-done" is redundant if a segment is already "translated", I can assume a translator has reviewed that as they translate the segment unless in some other companies, one can use 3rd party review service to validate the output by translation service suppliers. 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.

Best regards,

Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323 or T/L 938-6323
Waltham, Massachusetts

From: Yves Savourel <ysavourel@enlaso.com>
To: <xliff@lists.oasis-open.org>
Date: 10/02/2012 07:35 AM
Subject: [xliff] Y8 - translation state
Sent by: <xliff@lists.oasis-open.org>

Hi all,

I had a long standing action item to come up with an initial list of values for the translation state.
I've looked at the various tools and proposals, and they differ often widely.
Some indicates what should be do, other what has been done, and there is no apparent consensus on the steps between the first and the last states.

So, I would propose:

-- a) the attribute state is optional but as a default value.

-- b) like for some other customizable indicators, I would propose to use a composite value:

The first part would be required and one of the following values:

'new' - no work has been done on this segment
'translated' - the segment has been translated in some way, it possibly needs to be reviewed, QAed, etc.
'reviewed' - the segment has gone through review, it possibly needs to have extra QA, or checking steps done
'final' - the segment is final

The second part would be the now familiar prefix + custom value.

The order of the value indicates the level of readiness of the translation. For example, a custom value added to 'reviewed' must indicates a state of readiness greater than a custom value added to 'translated'.

This would allow tools to add their own stages at the different levels, but provide common broad indicator of the state of the translation.

For example a segment could go through the following states:

state='new'
state='translated
state='translated/xyz:edit1-done
state='reviewed/xyz:translator-review-done
state='reviewed/xyz:rejected-by-client-review
state='reviewed/xyz:translator-review-done
state='reviewed/xyz:client-review-done
state='final'

-- c) The approved attribute is segment is conflicting with the state. For example what is the expectation when approved is set to yes but state is set to new?

Most of the comments I've seen point out these kinds of problem. I think we should have only one way to indicate what the status of the translation is, and it should probably be 'state'.

Somewhere in the specification we have this: " A <unit> element is considered to be translated when all its <segment> children with translate attribute not set to no have the approved attribute set to yes."

I'm not sure this is needed. Since the state is customizable, I'm not sure XLIFF can prescribe when a segment is ready or not.

Cheers,
-yves

---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org

xliff message