RE: [xliff-comment] XLIFF 2.0 Core finished?

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi,

XLIFF 1.2 will not be updated. Its defects will remain there while we focus
on XLIFF 2.0. Updating XLIFF 1.2 and publishing an errata costs too much
time and effort.

Nevertheless, you should notice that the definition of <target> in XLIFF
1.2, as available at
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#target,  is quite
clear:

	"Target - The <target> element contains the translation of the
content of the sibling <source> element."

As you correctly say, the content of <target> must be a translation of
<source> or it must be blank. There is no doubt. 

Some tools place a copy of <source> content in <target> instead of leaving
target empty. That is not compliant with the specification.

The "state" and "state-qualifier" attributes are there to help you evaluate
the quality of the target content. This attribute combination might not be
enough for you, but it covers most needs for a regular user. I would say
that for this particular case, the defects you observe are in the tools
poorly implementing support for XLIFF 1.2, not in the specification.

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 12:14 PM
> To: Rodolfo M. Raya; xliff-comment@lists.oasis-open.org
> 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.
> 
> Regards,
> Josep.
> 
> ________________________________________
> 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.
> 
> 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/
> 
> 
> 
> --
> 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/