RE: [xliff] XLIFF 2.0 example files for segmentation

[Yves Savourel <ysavourel@enlaso.com>]

Hi David,

> The product developer would expect to get this translated 
> file back after translation, which maps to the version
> of the XLIFF file which he sent out for translation.
> ...
> Are these realistic examples?

Not the last part in my opinion.

In you scenario it feels like there are two distinct file formats: one without <segment> that is fine for core-only tools, and one with <segment> that works only with tool that implement an optional the segmentation representation.

But core-only tools must be able to work even when optional modules are used in the document.

And it seems your scenario assume it's not the case: the product developer expects that the file to merge must have its segmentation representation removed to be able to work.

A realistic scenario, in my opinion, would be for the third file (translated and sentence-segmented) to come back to the product developer. And the merging tool should be able to work with it.

In that scenario you then have only two solutions:

A) <segment> is part of the core.

Or B) sentence-segmentation representation need to be coded completely differently so a tool that would not understand it would still work. But the example with the <source> sometime at the <unit> level and sometime at the <segment> level, is not really workable as Rodolfo pointed out. The only thing that could work for B would be something like in v1.2 where there is a copy of the content. And that would lead back to many of the issues we are trying hard to get rid of in 2.0.

I think for the many reasons already mentioned the solution A is vastly preferable.

Cheers,
-yves