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: [xliff] RE: Inline attributes and canCopy


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:

- 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



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