RE: [xliff] Translating XLIFF 1.2

[Yves Savourel <ysavourel@translate.com>]

Good morning Rodolfo,

>> 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.
>
> Are you saying that tools that require <seg-source> are 
> unable to add it? 

No. I'm saying that if <seg-source> is not there, that means the <source> has no segmentation information.

Another tool can read the file and apply its own segmentation, and if that specific <source> as only one sentence, find only one segment.

The problem is that because such file is not following the way XLIFF represents segmentation, the tool won't be able to see the different 'segments' as part of the same paragraph, and therefore won't be able to manipulate them as needed (e.g. let the translators join/resplit)


> You said that segmentation belongs to translation domain, 
> so a translation tool that receives what you call an 
> "unsegmented" file should be able to "segment" it by 
> adding those <seg-source> you consider required for 
> interoperability.

I'm not the one calling or considering anything: the specification does :)

Segmentation is represented by <seg-source> (there is no fudging about that: I'm just reading the specification), therefore if it's not in the file, it means the file is not segmented.


> If tools that use XLIFF 1.2 segmentation cannot segment 
> an unsegmented document, then something is wrong and it's 
> indeed a sad situation.

I have no idea where you are getting this from. Any tool can obviously apply some segmentation on the XLIFF it reads and use <seg-source> to represent it in the output.

What is sad is that if a tool creates XLIFF documents that use one trans-unit to store a single segment resulting from a segmentation, it does not follow the specification regarding segmentation and therefore does not allow other tools to be fully interoperable with its documents.

Using that method is just like using a custom namespace with an non-XLIFF element that stored segment boundaries: It gives us a valid file, but uses a proprietary way of represent segmentation.

The bottom line is that there is only one way to represent segmentation in XLIFF, it's the <seg-source> model. I personally think the specification is rather clear about it, but that it just my opinion. If there is another way described in the text, please point it to us.

Cheers,
-ys