[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [xliff] RE: Inline attributes and canCopy
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:
- type
- canOverlap
- canDelete
- canRemove
- canReorder
- subFlows/subFlowStart/subFlowEnd
- canCopy
- copyOf
- disp/dispStart/dispEnd
- equiv/equivStart/equivEnd
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:
- type
- translate
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.
Thanks,
-yves
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]