RE: [xliff] XLIFF 2.0 example files for segmentation

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> What you are implying is that the extraction tool 
> could create the XLIFF file using only the "core" 
> elements, but the associated merge tool would have 
> to be aware of all of the core and module elements in 
> order to accurately process the translated XLIFF file.

No, like you, I certainly think that is unrealistic.

I'm simply saying that the merging process should be able to merge the <unit> regardless how many segments it counts.

And that is one of the reasons I think <segment> should be part of the core: The segmentation representation is just too important to the localization process to be an optional module.

The cost of dealing differently between sentence-segmented file and un-sentence-segmented files because of different representations would be much higher than the cost of forcing all tools to work with <segment>.

This is about setting the lowest common supported features for the tools: If we set it too low (i.e. not including segmentation representation) we will have many interoperability problems.

Beside, <segment> is justifiable even in the non-sentence-segmented file: it's the element that hold the source and optionally the target of the content. In the initial XLIFF it just happened to be a single one for each <unit> and that may change during the process. It's one specific case in a more generic pattern. Again, maybe the element name causes the confusion. Just replace <segment> with something like <part>.


> 1. All tools processing an XLIFF file has to assume 
> that all core and module features are completely 
> supported.
> Is this really the case?

I think not. Like you said, there would be no point in having core and modules then.

All tools should support all features of the core obviously. And none of the optional modules should prevent a tool that supports only the work to work.

Cheers,
-yves