OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff] Updated schema for XLIFF 2.0 plus examples


Thanks for the updated files and examples Rodolfo.

I like very much the simpler mechanism to have translatable segments and non-translatable parts at the same level (rather than the non-translatable parts as elements inside the <segment> like before). 

But I would still make a semantic distinction between "segment" and "segment translate='no'" as used here. "Ignorable" (whatever the element name ends-up being ) as a concept is different from a segment.

To me, the non-translatable/ignorable parts here are not segments they are inter-segments. I think the need to have their own element rather than overloading the semantic of <segment translate='no'>.

A segment marked as translate='no' is a content that for some reason is non to be translated. If it is joined with another segment it probably should remain non-translatable.

While the parts outside segments are content that are made non-translatable/ignorable by some segmentation and simplification mechanisms, basically to clean up the segment content. When joined with a segment such part becomes part of the segment content and is likely to become 'translatable'. For example, when you un-segment Rodolfo's example segmentation2.xlf you expect unsegmented.xlf.

So in summary:

- <segment> to store the segment (and some of those may be non-translatable)
- <some-element-name> (<ignorable> was just fine for me) to store the parts outside the segments.

Both at the same level, under <unit>.

-ys



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]