Re: [xliff] Y8 - translation state

[Helena S Chapman <hchapman@us.ibm.com>]

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