OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] Conformance / Compliance


Interoperability has two outstanding aspects:

1) Compliance of XLIFF documents.
2) Compatibility in processing.

With the conformance clause we can set the rules that deal with documents and their validity.

Processing expectations should be included in the specification, next to each feature. But we need coherency in the specification.

Yves' example of support for the "translate" attribute is interesting. You can set the value of this attribute in <trans-unit> elements but if you use <source-seg> in your XLIFF files, you cannot apply it at segment level. This is a problem with the specification that tools cannot address.

A problem I see frequently is related to the "approved" attribute. For interoperability, I expect that an XLIFF enabled tool would let the user set the value of the "approved" attribute, but the specifications don't say anything about it. We can avoid this problem by stating some rules in the specification, something along these lines but not necessarily this:

       "When generating the final document, the value of the "approved" attribute must be considered. If its 
       value is "yes", use the translations provided in the <target> element. Otherwise, use the text included 
       in the <source> element."

By including some text that indicates what to expect considering the elements and attributes present in the XLIFF file, we can start solving the interoperability between tools. A paragraph like the one above will tell the tool maker that something has to be done with the "approved" attribute.

In the same way, the specification could include text like this:

      "When a translation unit has the "translate" attribute set to "no", the content of the unit can be displayed 
      to the user as context information, but the user must not be able to modify the translation unit."

XLIFF 1.2 allows users to indicate the state of <target>'s content. That's valuable information for reviewing a translation, but not all tools support setting values for the "state" attribute. The specification defines what "state" means, but does not tell implementers when and how to use it. Nothing says that when a translation has been added to a previously empty target, the state should change from "needs-translation" to something else.

We need to start including in the specs what "XLIFF enabled tools" should do with each and every attribute or element we include in the specs. If there are no defined expectations for a given element, we should consider dropping it.

Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com

> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Tuesday, June 01, 2010 2:41 PM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] Conformance / Compliance
> Hi all,
> Very interesting discussion today. Hopefully we can continue on the mailing
> list.
> May be there are different aspects to to consider in "compliance".
> I agree with Rodolfo that for conformance we can only talk about the
> document. XLIFF has a specification, along with a schema, and a document is
> or not conformant to those. No tools involved. And applications like
> XLIFFChecker can hopefully check that conformance.
> But that is only one facet of the compliance problem.
> I don't think OASIS has a formal way to handle the other facet: processing
> expectations.
> And to me that is where the biggest interoperability issue resides.
> Users don’t care if their document is conformant, they care if their tools can
> read it, work with it, and generates back a file that the initial tool can be
> happy with.
> This usually translate into being able to ascertain that a tool uses the proper
> XLIFF construct to act on a given aspect of the document.
> For example, in 1.2, there is a translate="yes/no" attribute that indicates if
> the trans-unit content needs to be translated or not. I would expect a "XLIFF-
> compliant" tools to use that attribute to both indicate that status of a trans-
> unit (when generating XLIFF), and to read that information when sorting out
> what is translatable or not in the file (when loading XLIFF).
> There has to be ways to prescribe those processing expectations in the
> standard. We are not in the conformance aspect anymore, I agree. But this
> facet is as important to XLIFF as document conformance is, otherwise we will
> keep having documents that are not really seamlessly useable for exchange,
> because the tools pick and choose how they work with the standard.
> I don't know how that can be achieved. I think having a much more modular
> XLIFF and stricter modules (e.g. less attr="x-whatever") could help. It is a
> difficult problem, because we need to make sure while the format is more
> strict, the tools still have ways to implement things how it works best for
> them.
> I feel certain this is an aspect we have to tackle to have a XLIFF 2.0 that "really
> works".
> Cheers,
> -ys
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php

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