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 Rodolfo,

The XLIFF 1.2 spec reads "The optional 'approved' attribute indicates whether the translation has been approved by a reviewer.", so my understanding is that we should not expect that a compliant tool will set approved="yes" for a 100% match leveraged from a translation memory or a machine translated segment.

For example, we received today a file for a user complaining that segments were not shown in our QA tool.  The file contained translate="no" as an attribute for trans-unit.

In this case, we can unambiguosly tell the user "Your XLIFF file is wrong. You should change it or have it changed it." because the translate="no" attribute clearly specifies in the XLIFF 1.2 spec that the segment should not be touched.

In this case, the spec was a great success, because we can tell univocally right from wrong and the other party knows exactly what it must do to fix it if they want to be compliant with XLIFF.

But this is not the case for translatable segments that are not yet approved by a reviewer. 

All we can implement are hacks on attributes whose default value is "undefined". 

There are suggestions to infer state based on if target exists or not, but the XLIFF 1.2 spec fails to say something like "If there is a target text, it must be the translation of source, otherwise it must be blank.", and therefore a file generated with for example "tikal -x filename" is perfectly valid according to XLIFF 1.2 and you cannot know if segments are translated or not. You can only guess. 

According to XLIFF 1.2 you can only know if they have been approved by reviewer and even that is optional and still perfectly XLIFF 1.2 compliant.

In my opinion something is missing in the spec, either it is a translated="yes|no" attribute to replace or complement the approved="yes|no", a remark that says that populated or existing target means it is translated, a  state="translated|untranslated" with a mandatory default value plus a stage atribut for workflow, I don't know, some kind of anchor.

De: Rodolfo M. Raya [rmraya@maxprograms.com]
Enviado el: martes, 22 de mayo de 2012 15:38
Para: Josep Condal; xliff-comment@lists.oasis-open.org
Asunto: 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.

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,
> 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
> 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
> information, and the proposed additional "stage" attribute could support
> 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
> I think that trying to consolidate workflow stage and segment state in a
> attribute as is is done currently in XLIFF 1.2 is making the state
> 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
> yet.
> But it is well advanced.
> The topic about knowing if a segment is translated or not is still under
> 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
> 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
> 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
> 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]