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] XLIFF 2.0 Core finished?

Hi Yves,

Thank you for the update. Since I see this is an open question, potentially open for suggestions, I would like to add my own for consideration.

In my opinion, a translatable segment has only two possible states: Untranslated and Translated. 

Untranslated means that we know that segment is not translated and Translated means that we know that the segment is translated, no matter how dubious. For example, we know that a 80% fuzzy match does not aim to be the translation of the original because we know for a fact that nothing was done to address the missing 20%. On the other hand, we know that a machine translation of a segments aims to be the translation of the full segment, no matter how bad it can possibly turn out to be.

Therefore the state of an 80% primed into target is "Untranslated" and the state of a machine translated segment is "Translated". The essence is to notify if the text in target has any foundation to be a valid translation or not.

Depending on application, each state can have one or more stages, supported under a different attribute that could be named "stage", which will depend on the workflow needs for users/allowed by tools. 

In other words, in my opinion the "state" attribute tries to describe basic information, and the proposed additional "stage" attribute could support any workflow needs no matter how complex or tool/company specific. We, as a LSP, can have workflow stages as specific as "client query pending", which are nevertheless vital for a flawless execution. 

Also mostly workflow stage (translated, reviewed, QAed, etc) we are concerned about is typically more relevant file-level information, not segment-level information so segment-level stage information becomes eventually obsolete when the whole file is understood to be at a given stage.

I think that trying to consolidate workflow stage and segment state in a single attribute as is is done currently in XLIFF 1.2 is making the state attribute unreliable unless you own the whole stack of tools used in the process.

De: Yves Savourel [yves@opentag.com]
Enviado el: martes, 22 de mayo de 2012 13:22
Para: Josep Condal; xliff-comment@lists.oasis-open.org
Asunto: RE: [xliff-comment] XLIFF 2.0 Core finished?

Hi Josep,

While the discussion is currently about extensibility, the core is not complete yet.
But it is well advanced.

The topic about knowing if a segment is translated or not is still under work:


From: Josep Condal [mailto:pcondal@apsic.com]
Sent: Tuesday, May 22, 2012 2:31 AM
To: xliff-comment@lists.oasis-open.org
Subject: [xliff-comment] XLIFF 2.0 Core finished?

Hi All,

I see in the TC mailing list that focus in XLIFF 2.0 has now moved mainly to extensibility.

Has work on the XLIFF 2.0 unnegotiable Core been mostly completed?

In particular I'm interested on if for XLIFF 2.0 there will be a univocal way to determine if a segment is translated or not.


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