RE: [xliff] Translation state (Y8)

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo,

So 'approved' would indicates what segments should be merged back if I understand correctly?

Currently the definition is overlapping what we have come up for state (or vice-versa):

"Approved - Indicates whether the translation of a <segment> element is final or has passed its final
review."

We also 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 against having something that indicate what should be merged into the translated original document at some point in time. We just need to make sure 'approved' and 'state' (assuming the F2F consensus gets approved by a quorum) don't overlap.

That was one of the issue raised by users for 1.2: approved and state could have contradictory values.

Cheers,


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Monday, October 29, 2012 5:33 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Translation state (Y8)

Hi Yves,

Approved and state are two different things. You may have something as approved that's good enough for a first pass but needs further review before it gets marked final.

Translation projects with four stages (translation, proofreading, review and second review) are quite common in my work area. A segment is normally marked as "approved" by the proofreader and only the reviewers set the state to "final".

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] 
> On Behalf Of Yves Savourel
> Sent: Monday, October 29, 2012 9:25 AM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] Translation state (Y8)
> 
> Hi all,
> 
> With regards to indicating the state of a given translation. During 
> the face-to- face meeting in Redmond, the group came up with a 
> consensus. Which was the following:
> 
> -1) the translation state would be moved to the <segment> element 
> (rather than set in <target>)
> 
> -2) the translation state would be composed of two attributes:
> 
> - A 'state' attribute that indicates a top-level state through the 
> following
> values: initial, translated, reviewed, and final.
> 
> A 'subState' attribute that indicates a user-defined sub-state within 
> the current state. The state attribute is required to be set if subState is specified.
> The value for subState is a QName-like value: <prefix>:<value> where 
> <prefix> represent the "authority" (e.g. company, standard, etc.) that 
> defines the values, and <value> the value.
> 
> 
> I think there are two things we have not defined (at least there is no 
> record of it):
> 
> - a) Does 'state' have a default? If yes, what is it?
> 
> (I would say, yes it should have a default, and that should probably be 'initial'.
> Or if we don't agree on a default, maybe we can just make state required?
> The idea is that we should make sure we always have a state)
> 
> 
> - b) What about the 'approved' attribute? It seems to be somewhat 
> overlapping the functionality of the state and both are now in the 
> <segment> element.
> 
> (I would think we drop approved as 'approved='yes' is the same as
> state='final'?)
> 
> Cheers,
> -yves
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org



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