RE: [xliff] Conformance / Compliance

[Yves Savourel <ysavourel@translate.com>]

> 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."

Exactly. I'm guessing this is the type of 'processing' Asgeir was thinking about during the call. The question is how can we verify/enforce/validate (whatever it should be called) that a given tool does behave according those rules? Having a conformant file before and after does not help that.

If we don't have that second facet to our compliance, we will keep having tools that read and write conformant XLIFF documents but cannot really work well with other tools. And the standard will be seen as inadequate.


> 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.

+1. Very well put.


> 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.

Inline spans of text that should not be translated can be marked up with <mrk mtype="protected">.

But your point that the current 1.2 segmentation representation not addressing certain things is certainly valid for something like "approved" and other important attributes. The main issues with the current 1.2 solution came from the fact it was design to keep backward compatibility. One of the things I expect from 2.0 is a more integrated representation of the segmentation, with clear associated processing expectations.

Cheers,
-ys