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] Simplified XLIFF element tree


> It's very easy to segment text at the time of extraction.
> By doing this, you don't need unsegmented content in the 
> XLIFF file. I've been doing for many years and I can tell 
> you it works.

I have the feeling you are missing the point Rodolfo. We all know segmentation can be done when extracting.

The idea is that extraction and segmentation are two different actions, belong to two different domains, and that XLIFF must not assume all tools will work like one specific tool.



> I do not agree that the <trans-unit> should have access 
> to the unsegmented content.

I disagree with that. For example we must be able to re-segment a segmented content.

Ironically as I write this email I'm spending my day trying to resolve how we are going to leverage a TM on a mass of XLIFF files that have been pre-segmented but don't match the TM segmentation.

It's XLIFF, it should be simple: just ignore the pre-segmentation.

But, you know what: I cannot because the files are coming from Swordfish and I cannot access the un-segmented content. There are not even <group> to delimit the <trans-unit> that belong to the same text-block. (I wish I was making this up, but I don't: <tool... tool-version="2.0-5 7DA-8-A"></tool>)

So, believe me right now I want very much 2.0 to provide access to un-segmented content in a non-optional way.

-ys 



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