MQXLIFF file have source/target in mq:historical-unit

[YvesS]

The .mqxliff files use the XLIFF source and target elements in their own mq:historical-unit elements. This causes the parser to try to process the target when it should not.

(Example file is not a public file).

Reported here: https://groups.yahoo.com/neo/groups/OmegaT/conversations/messages/41799

[Chase Tingley]

The XLIFFParser plays a little fast and loose with matching element names without regard for where they occur in the file.

We will need some kind of memoQ sample file to test this against, though.

[Chase Tingley]

Gábor from Kilgray sent me the 3 attached samples, along with this comment:

I’m attaching three lean .mqxliff files from 8.2 (no skeleton or preview to keep it small). They are three subsequent minor versions of the same document. Minor versions keep track of a document’s evolution within a project, in between snapshots that are typically created at export, or when a translator or reviewer delivers their work, etc.

The general idea is that memoQ stores only actually different states of each trans-unit (document row). I.e., if a unit didn’t change between multiple minor versions of the full document, then that state of the unit is represented by a single historical-unit. The from/to values say the range of minor versions for which the unit had this state.

[Chase Tingley]

Also attached: the latest MQXLIFF schema, posted with permission.

[Chase Tingley]

@ysavourel -- You saw the original file that this was reported against, right? Could you take a look at these samples and see what looks different?

If I do a basic roundtrip of these 3 MQXLIFFs, I don't see anything unusual -- they extract the expected 3 trans-units, and if I update the targets in XLIFF, I see updated trans-unit/target in the output, while the historical-unit/target is left untouched. All of that seems correct.

Is there some other option or content structure in play?

[YvesS]

I did tried things out briefly when that bug was reported, and from what I can recall, I think the issue was that we were not re-writing correctly the <target> used in the mq:historical-unit> element.

But I have tried round-trips as well, and even opened the file in OmegaT and translated everything, and the target file seems to have nothing changed in that element.

I don't think we have done anything to the XLIFF Filter that has changed the behavior though. I'll send you the original files privately.

[YvesS]

Here is the issue in the original target file:

<mq:historical-unit mq:minorversionend="1" mq:minorversionstart="0" mq:status="NotStarted" 
 mq:segmentguid="67438cb5-738c-486b-bdc6-5e48cef23ccd" mq:lastchangedtimestamp="0001-01-01T00:00:00Z"
 mq:maxlengthchars="-1" mq:nosplitjoin="false" mq:firstlabel="1" mq:lastlabel="1" mq:autosplitjoinstate="0"
 mq:lastmodifrole="0" mq:multipleexactmatch="false">
 <source xml:space="preserve" mq:segpart="1" mq:hasfollowingobject="hasfollowingobject">Operation</source>
 <target xml:space="preserve"-ERR:PROP-NOT-FOUND-></target>
 ...

But I was not able to reproduce it so far.

[Chase Tingley]

Hmm, strange. It looks like an issue with the property ref we insert for ITS stuff, but I can't reproduce it either.

I don't know much about how the OmegaT plugin works, is there any reason that would be effecting this?

[YvesS]

Not as far as I know.

I've tried doing a translation of that file in OmegaT and was able to open, translate and save, all without getting that issue.