Dear Josep,
You need to separate two things:
1) segment translation status
2) target state
In XLIFF a segment can be either translatable or not. This is indicated with
an attribute. In turn, a translatable segment can be approved or not. This
status is indicated in a separate attribute.
An XLIFF document is considered translated when all translatable segments
are approved. This is clearly indicated in the new specifications.
Target status is a different problem. A translation inserted in target could
be perfect or completely wrong. It could have been entered by a professional
translator or generated by a machine. It could have been inherited from a TM
system and need review. There is a whole set of combinations that need to be
analyzed and the XLIFF TC has not started working on this yet for XLIFF 2.0.
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
> -----Original Message-----
> From: Josep Condal [mailto:]
> Sent: Tuesday, May 22, 2012 10:26 AM
> To: Yves Savourel;
> 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.
>
> Regards,
> Josep.
>
> ________________________________________
> De: Yves Savourel []
> Enviado el: martes, 22 de mayo de 2012 13:22
> Para: Josep Condal;
> 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:
> http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/TranslationState
>
> cheers,
> -yves
>
>
> From: Josep Condal [mailto:]
> Sent: Tuesday, May 22, 2012 2:31 AM
> To:
> 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.
>
> Regards,
> Josep.
>
>
> --
> 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:
> Unsubscribe:
> List help:
> 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
> Join OASIS: http://www.oasis-open.org/join/
