Directional isolate characters were introduced in Unicode 6.3 after it became apparent that directional embeddings usually have too strong an effect on their surroundings and are thus unnecessarily difficult to use. The new characters were introduced instead of changing the behavior of the existing ones because doing so might have had an undesirable effect on those existing documents that do rely on the old behavior. Nevertheless, the use of the directional isolates instead of embeddings is encouraged in new documents – once target platforms are known to support them.

[[If the dir attributes of the <source> or <target> elements differ: The content of the <source> or <target> elements set to adifferent directionality than the directionality for the <source> or <target> elements of the joined segment MUST be enclosedbetween Unicode bi-directional control characters reflecting their original directionality (U+202A and U+202C for left-to-rightspans, and U+202B and U+202C for right-to-left spans).]]

On Sat, Nov 30, 2013 at 1:56 PM, Yves Savourel <ysavourel@enlaso.com> wrote:Hi all,As mentioned here: https://lists.oasis-open.org/archives/xliff/201311/msg00138.html, I've been trying to implement segmentationmodification for XLIFF 2.0 for a while now and I have a few comments.For reference, the cs02 section for this is here:http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd02/xliff-core-v2.0-csprd02.html#d0e9317--- The section (starting with its new title) keeps talking about "segmentation modification" and "resegmentation". Could we justtalk about segmentation modification everywhere? The two things are the same thing.--- That section has many constraints and processing requirements.It was quite difficult to follow when I tried to implement it.For example: (take a deep breath) "Modifiers MUST copy all attributes including values, except for the id and order attributes, fromtheir original instances on or within the original <segment> element onto both instances on and within the resulting two <segment>or <ignorable> elements, except for attributes that do not have valid instances on the eventually resulting <ignorable> element."To make a long story short and get to the point, I think that section should be re-worded to be simpler, organized by action (splitor join), and completed with a few things (some subState PRs, explicit directionality conversion, etc.)The proposed modified text is in the attached document.I believe it covers what is needed, but it's a complex set of PRs and it should be carefully checked by all. For example I'd like aconfirmation on the Unicode control characters used for the directionality conversion.Thanks,-yves