[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Simplified XLIFF element tree
Hi Asgeir, all, A last note before closing the laptop for a full week off: > after translation: > <trans-unit> > <source> > <seg id='seg1'>This is the first sentence.</seg> > <seg id='seg2'>This is the second sentence.</seg> > </source> > <target> > <seg id='seg1'>Første setning.</seg> > <seg id='seg2'>Andre setning.</seg> > </target> > </trans-unit> I find that approach would be simple and easy to work with. One possible slight change could be to always have at least one <seg>. Maybe it would be more clear to express this using different names to avoid associating our knowledge of the current <trans-unit>, etc. to those elements. For example: Un-segmented: <unit> <source> <part id='seg1'>First sentence. Second sentence.</part> </source> </unit> Segmented and translated (same as Asgeir): <unit> <source segmented='yes'> <part id='seg1'>First sentence. </part> <part id='seg2'>Second sentence.</part> </source> <source> <target segmented='yes'> <part id='seg1'>Første setning. </part> <part id='seg2'>Andre setning.</part> </target> </unit> > However, there probably need to be some ability to manage > state and workflow on the segment level, but that could > in a similar way live under the <trans-unit> element > and reference the segment ids. And, for attributes, by simply moving the relevant ones to the <part>. It would be easy to map xml:tm to this: <tm:te> to <unit> and <tm:tu> to <part>. It would also allow Rodolfo to always have its XLIFF pre-segmented, and any tool could easily access the un-segmented content when needed: the sum of all <part> elements (and possibly the content in between if we would decide to allow content in-between). And we would have no duplication of content. Cheers, -yves
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]