[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] XLIFF 2.0 example files for segmentation
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]