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?


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       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

> -----Original Message-----
> From: Josep Condal [mailto:pcondal@apsic.com]
> Sent: Tuesday, May 22, 2012 10:26 AM
> To: Yves Savourel; xliff-comment@lists.oasis-open.org
> 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 [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:
> http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/TranslationState
> 
> cheers,
> -yves
> 
> 
> 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.
> 
> 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: 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
> Join OASIS: http://www.oasis-open.org/join/




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