> So the scenario I pulled from Dave's example,
> file with <segment>s is refactored as file
> with different <segments>s but has to be
> restored to original <segments> is a chimera.
A bad dream indeed.
> ..then Dave's example would need to lose
> snippets two and five. Is that right?
1 and 4, and 5 is not needed. But the merger should work with either 3 or 5.
> If segmentation is moved to the translation domain
> and adjusted at translation time, aren't we saying
> that segmentation is really a function of the import
> filter (and hence beyond the scope of XLIFF),
> just as it would be for any other file format?
> I don't need to indicate segmentation in Word or
> IDML, so what makes XLIFF different in this regard?
Well the "re-" segmentation is moved out of the extraction tool domain. But there is a block-level segmentation too: You do use it in Word and IDML: paragraphs, footnotes, table cell, etc.
Likewise that "block"-level segmentation is done by the extraction tool: <unit> hold a "block" which initially is stored in a single <segment>.
Why use both <unit> and <segment> initially? Why not just <unit> like in David's snippets 1 and 4?
Because it's just more efficient. Maybe forget about block/sentence and see it that way: until it (optionally) gets segmented further that content is the "segment" for that unit. So why shouldn't be in <segment>?
Think about Word and pages: your content is in a single page or several: you decide where the page breaks are. Even when there are no page break there is a page. A <segment> is similar to a page.
Cheers,
-ys
