RE: [xliff] Translating XLIFF 1.2

[Yves Savourel <ysavourel@translate.com>]

Hi Rodolfo,

> ... The introduction of Segmentation section must be
> changed, as it currently says that it "may be important 
> for the user agent to break down the content of the 
> <source>". It should clearly state that such operation 
> is required.

I would disagree: Why would we want to make <seg-source> mandatory?

XLIFF provides a way to represent segmentation if you wish to, it does not force anyone to use segmented document. There are quite a few tools that do perfectly well in their domain without segmentation.


>... some developers like me would interpret that segmentation 
> can happen when the XLIFF file is created and write code 
> that is valid according to the schema and the specification 
> document, but wrong according to the intended spirit of the 
> standard.

Most developers I know would simply read the Segmentation section of the specification and implement it if they needed to. There is not much to interpret in that section I think.

Segmentation can certainly be done before the XLIFF file is created: XLIFF is just a file format. You just have to code it using <seg-source> to be interoperable.

If a tool generates code where each <source> is an actual segment and does not uses <seg-source> to indicates that, it is still valid and following the specification, but it is simply not segmented from the view point of XLIFF. It's also sad because other tools won't be able to do much as far as manipulating segments in that file.

Let's see it another way: You said another way to represent segmentation would be to use a <group> for the paragraph and the <trans-unit> for its sentences. I'm pretty certain any internal data structure that can generate such representation can also generate the <seg-source> model. If it has all the info to generate one it has them to generate the other as well.

So, while the specification could probably use adjustments and more specific wordings--in segmentation and other areas--I don't think the current <seg-source> description warrants the deep changes you are listing for 1.2.

Cheers,
-yves