RE: [xliff] XLIFF 2.0 example files for segmentation

[Yves Savourel <ysavourel@enlaso.com>]

Hi Arle, all,


> Look at his second XLIFF snippet, which uses 
> <segment> in it. One of his scenarios was to go 
> from that to the third snippet (which uses different 
> <segment>s) but with the goal of spitting 
> out the final XLIFF snippet (which uses the 
> original <segment>s). Not so easy to do.

I see three steps: and 2 versions of the XLIFF for step 1 and 3.
(Snippet 1 and 2 are the same step, but without and with <segment>. Same for snippet 4 and 5. At least that's what I'm understanding...)

I see only:
Step 1: non sentence-segmented ("block")
Step 2: sentence-segmented ("sentence")
Step 3: non sentence-segmented ("block")

I don't see two different steps that are sentence-segmented. In other words: The third step is the final step. Or I'm missing something (which is quite possible :)


> ...So what does <segment> accomplish for us? If it's 
> needed, how do we deal with the expectation that 
> one tool that uses it in its files should be able 
> to get back a file with the same <segment> structure 
> after another tool has refactored it (one of Dave’s 
> scenarios)?

I'm still not getting this I'm afraid. Why would you want to preserve the exact same segmentation if your tool decide to segment things differently?

For example: I get a unit with 5 segments. Either I like it and keep it that way, or for some reason I decide to change the segmentation and change it to, for instance, 4 segments. I just write out an XLIFF output that reflect the changes (translation added, re-segmentation, status updated, etc.).

David's scenario, as far as I understand, is to remove any sentence-segmentation for the final step and get back its original "block" segments. Not to preserve an existing "sentence" segmentation that would exist before step 2.

So <segment> is very much useful: to hold a given segment content. Which may happened to be the full content of <unit> when the initial XLIFF is generated.

Cheers,
-ys