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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

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

Subject: RE: [xliff-comment] RE: Feedback from OpenTM2 XLIFFinteroperability enhancements

Thanks Yves.  The difficulty specifying the possible states is a clue to me that this isn't quite the right question.  Consider that a translation project may be going through a complicated, user-defined workflow.  I don't think we'd ever arrive at a list of states that covers everything.  Even mapping from a point in an arbitrary user-workflow to an XLIFF state sounds like a hard problem.

I like what Christian Lieske said in that thread about "processing requirements/expectations", and I think that is the right focus.  Developing a comprehensive ontology of states does not necessarily help answer the essential question, "what am I supposed to do with this segment?".  I think coming up with a good answer for that should be the main goal.  It is a much more manageable problem, and it does more for interoperability because you don't have to wonder whether the next tool will interpret the state the way you meant it.

Capturing the "phase" in the workflow ("translated, flagged by the automatic length checker, shortened, passed linguistic review, rejected by legal review, sent back to translator, who is on vacation so reassigned, ...") can be accomplished with a trail of notes/comments/history entries that is primarily human-readable, rather than trying to squeeze it into a machine-readable state.

From: Yves Savourel [yves@opentag.com]
Sent: Tuesday, May 10, 2011 6:30 PM
To: xliff-comment@lists.oasis-open.org
Subject: RE: [xliff-comment] RE: Feedback from OpenTM2 XLIFF interoperability enhancements

Hi Andrew,

> One more issue.  Another problem I faced is, how to
> interpret the states a trans-unit may be in.
> The two relevant attributes are, the translate attribute
> of a trans-unit, and the state attribute of the target.

We had a start of discussion about this here: http://lists.oasis-open.org/archives/xliff/201104/msg00058.html

As for which attribute of 1.2 would be involved in the state of the translation I would think of 'state' in <target> and 'approved' in <trans-unit>.

In 2.0 we certainly want something well-defined. But it will be difficult to reach a good solution as the workflow vary widely from system to system, and so does the meaning each system put behind terms like 'edit', 'review', etc.


This publicly archived list offers a means to provide input to the
OASIS XML Localisation Interchange File Format (XLIFF) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: xliff-comment-subscribe@lists.oasis-open.org
Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
List help: xliff-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xliff-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff

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