OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xliff] Xliff TC Teleconference Meeting - 15th April 2003

Hi Doug and all:

Sorry I didn't reply sooner - was caught up in meetings all day.

To add a bit more detail to what Gerard offered in his mail - I need "new" in order to identify new objects have been added without determination of what needs to happen to them,  for instance when objects from a new build are merged into an existing,  perhaps partially translated, XLIFF file.

What to do with these items (ie,  mark them as "needs-translation", or identify them as in a "finished" state) may only be determined by inspection and manual assignment of an appropriate status by a localization engineer.

I think an item with a "new" state could transition to any other basic state (with exception of "translated",  and "leveraged" ,  and "needs-review-...".  Also,  note that I'm not suggesting that "new" is a required initial state - if your processes are automated enough then you could specify at authoring point that the item begins with an initial states of "needs-translation" or whatever is appropriate.


Doug Domeny wrote:
Thanks for the explanation. It now makes sense to me to have "new" as a value. In my case, I would skip the "new" state and go directly to "needs-translation" because I create the XLIFF with only text that needs to be translated.
Yves, I recommend adding an explanation similar to Gerard's in the specification document for the "new" value of the "state" attribute.


Doug Domeny
Software Analyst

Ektron, Inc.
+1 603 594-0249 x212

-----Original Message-----
From: Gerard Cattin des Bois [mailto:gcatt@windows.microsoft.com]
Sent: Wednesday, April 16, 2003 6:28 PM
To: ddomeny@ektron.com; xliff@lists.oasis-open.org
Subject: RE: [xliff] Xliff TC Teleconference Meeting - 15th April 2003

Toni actually proposed the new as a way to pre-process the data in order to determine whether the data needs to be translated, localized or does not need anything. This is a useful feature to scope the localization effort and determine loc readiness and needs.
So, what happens next from New? Possibly needs-<something>, or a localization directive may be added such as locks.

Gérard Cattin des Bois
Lead Program Manager, LocStudio Services
Windows Productivity Tools Team
gcatt@microsoft.com  (425) 706-1592
Symptom and sign of Inner Peace: An unmistakable ability to enjoy each moment...

-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com]
Sent: Wednesday, April 16, 2003 10:09 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Xliff TC Teleconference Meeting - 15th April 2003

What is the difference between state="new" and state="needs-l10n" or one of the other "needs-" values?
I use an XSLT to extract all the <trans-unit> elements that need to go to the translator by keying on the value of the state attribute. If the values starts with "needs-" then the <trans-unit> is retained. Other values cause the <trans-unit> to be filtered out of the XLIFF document that is going to the translator. I use XLIFF documents to store the text, so the <trans-units> that are added or modified have their state changed to "needs-translation" or other value that starts with "needs-".
Following is the XSLT template used to filter out <trans-unit> elements whose state attributes do not start with "needs-".
<xsl:template match="xlf:body/xlf:trans-unit[not(starts-with(xlf:target/@state, 'needs-'))]">
 <!-- discard trans-unit elements that are already translated -->
The value "new" does not indicate what should happen next. It is ambiguous whether it needs to be translated or not. I would expect one of the following would be used instead: needs-translation, needs-l10n, needs-adaption.
I recommend removing "new" from the list of possible state values.


Doug Domeny
Software Analyst

Ektron, Inc.
+1 603 594-0249 x212

-----Original Message-----
From: Enda McDonnell [mailto:EndaMcD@alchemysoftware.ie]
Sent: Wednesday, April 16, 2003 5:44 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] Xliff TC Teleconference Meeting - 15th April 2003

Xliff TC Teleconference Meeting - 15th April 2003


3. State Attribute

Enda explained his document/proposal. This basically outlines 3 issues for the TC

    a. Add Finished to the state attribute list?
    b. Split the state attribute value list into two lists, state and state-qualifier?
    c. Move the workflow items to phase.?

Much discussion ensued, the following is the outcome..



It has been decided to add 'final' to the list of state values.

Also, other values have been amended; here is a list of the basic translation states that were decided upon.

new (new item added since last release)
needs-translation (only the text needs translation)
needs-l10n (both text and non-textual information* needs localisation)
needs-adaption (only non-textual information needs adaptation)
needs-review-translation (only the text needs review)
needs-review-l10n (both text and non-textual information needs review)
needs-review-adaption (only non-textual information needs review)
leveraged (indicates a change was made by an automated process
translated (indicates )
signed-off (inidcates that changes are reviewed and approved)
final (indicates the terminating state**)

It is expected that a segment pass through these, or a subset of these states during localisation.

* Non-textual information refers to information such as co-ordinates, font information, mirroring, etc.
** Signed off may also be used as a terminating state


Tony Jewtushenko					mailto:tony.jewtushenko@oracle.com
Principal Product Manager				direct tel: +353.1.8039080
ST Tools Technology Team
Oracle Corporation, Ireland

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]