Hi Rodolfo,
I'm not sure (yet) that moving the state attribute from <target> is safe to do. Adding it to <segment> seems like a good enough idea. I would lean toward not moving the state attribute from <target> until we consider the use cases that could convince us that a collection of state attributes in several <segment> elements could always be interpreted to inform us of the overall state of the larger <target> (my stance is based on the assumption that a <target> can/will contain several <segment> elements).
- Bryan
-----Original Message-----
From: Rodolfo M. Raya [mailto:]
Sent: Friday, April 22, 2011 8:51 AM
To:
Subject: RE: [xliff] Translation status values for 2.0
Hi Yves,
I would move the "state" attribute from <target> to <segment> element and review the list of possible values and perhaps change its name.
We still need to know if a segment is approved or not, regardless of its current status (a segment may be approved by a translator but require further proofreading in a later stage). We still need two separate attributes unless we define a value set that allows us to differentiate when the translation can be included in the final document.
I can modify the schema and add the "state" attribute to <segment>, using a tentative list of values that will have to be reviewed later. Should I post an updated schema?
Regards,
Rodolfo
--
Rodolfo M. Raya <>
Maxprograms http://www.maxprograms.com
> -----Original Message-----
> From: Yves Savourel [mailto:]
> Sent: Friday, April 22, 2011 12:12 PM
> To:
> Subject: [xliff] Translation status values for 2.0
>
> Talking about attributes: one information that is important and may be useful
> to have as part of the core is the status of the translation.
> In 1.2 for example we have a approved in <trans-unit> and state in <target>.
> I think this need to be re-work in a way that allows to know the status of the
> segment via one attribute.
>
> Looking at the different tools and their usage of state, it seems it varies a lot.
> But this is one specific list of values that is going to be important to get
> carefully defined so it has some logical progression but covers as much as
> possible the states required by the different tools. Each value needs to be
> carefully defined so misue risks are reduced. We may also want to talk
> directly to developers and see how they map their values to it.
>
> -ys
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
