Re: [xliff] XLIFF 2.0 example files for segmentation

[Arle Lommel <alommel@gala-global.org>]

OK.I think I've got it, assuming that Step 1 and Step 3 have the same Tool or at least treat segmentation the same way:

Step 1: XLIFF file (a) without <segment> (snippet 1) OR (b) XLIFF file with <segment> (snippet 2) -- TOOL A
Step 2: XLIFF file with <segment> structure different from snippet 2 (snippet 3) -- TOOL B
Step 3: XLIFF file (a) without <segment> (snippet 4) OR (b) XLIFF file with <segment> structure identical to snippet 2 (snippet 5) -- TOOL A

I think we agree on that. What I didn't see before was that in your view step 3 just trashes the segmentation from Step 2 and replaces it with its own segmentation, so it isn't that Step 3 is somehow recovering something from Step 1, but rather that the happens to get the same result both times (which makes sense). I'd read it as Step 3 has to RECOVER the segmentation from Step 1. If that's not the case, then the stuff about hierarchy is just a result of misunderstanding the usage scenario.

-Arle


On Nov 9, 2011, at 14:00 , Yves Savourel wrote:

> 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
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org
>