Subject: RE: [xliff] RE: Inline attributes and canCopy
Hi Yves, all,
Thanks for sharing your implementation! We’ll take a look from our side and let you know by the end of the week.
Hi Ryan, all,
> Thanks Yves, when you have something working in Lynx, can you share
> the full implementation with me and we'll look at what we can do to
> at least have parity.
I've implemented a verification that tries to detect when two source/target codes with the same ID are not "corresponding". It’s just my best solution so far, but I’m obviously open to adjustments. I have not yet made a formal release with the change: It would be nice to get the feedback from other implementers and TC members.
Such two codes are seen as corresponding if:
- Both are either spanning (<pc>/<sc><ec>) or both standalone (<ph>)
And if they have, at least, the following properties identical:
They may have different values for all the other properties: the rational to not include the others (like data, dir, subType, etc.) is that they might be changed when they are in the target.
For the annotations: I check for identical values on:
You can see the source code here:
Note that the code performs the verification on the parsed elements, so, for example, there is no distinction between the attributes disp, dispStart and dispEnd: In the object model it's just the disp property of that tag object.
You can play with the new behavior in the online validator: http://okapi-lynx.appspot.com/validation
(The issue Nesho found with <cp hex='7FFFFFFF'/> is also fixed)
There are a few test files (bad_NotCorrespondingCode*.xlf) here:
But we should also add valid test files.