OASIS XML Localisation Interchange File Format (XLIFF) TC

Title: [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 : - B oth 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 other s (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: https://bitbucket.org/okapiframework/xliff-toolkit/src/1349e1470f2422752f675a98cf3bcff433569e6d/okapi/libraries/lib-xliff/src/main/java/net/sf/okapi/lib/xliff2/reader/XLIFFReader.java?at=master#cl-1627 Note that the code perform s the verificat ion on the parsed elements, so , for example , there is no distinction between the attributes disp, dispStart and dispEnd: I n 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 ( T he issue Nesho found with <cp hex = '7FFFFFFF' /> is also fixed) There are a few test files ( bad_NotCorrespondingCode * .xlf ) here: https://bitbucket.org/okapiframework/xliff-toolkit/src/master/okapi/libraries/lib-xliff/src/test/resources/invalid/ But we should also add valid test files. Thanks, -yves

Title: [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.   Ryan   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Saturday, June 20, 2015 10:20 PM To: xliff@lists.oasis-open.org 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: https://bitbucket.org/okapiframework/xliff-toolkit/src/1349e1470f2422752f675a98cf3bcff433569e6d/okapi/libraries/lib-xliff/src/main/java/net/sf/okapi/lib/xliff2/reader/XLIFFReader.java?at=master#cl-1627 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: https://bitbucket.org/okapiframework/xliff-toolkit/src/master/okapi/libraries/lib-xliff/src/test/resources/invalid/ But we should also add valid test files. Thanks, -yves