[OASIS Issue Tracker] (XLIFF-72) XLIFF 2.1 spec: the dir values are not sufficient for proper BiDi support

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/XLIFF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68866#comment-68866 ] 

David Filip commented on XLIFF-72:
----------------------------------

Thnaks, Steven, why not use this?

I propose to append the explanatory text to the last Note at the end of the BiDi section 4.7.6 http://docs.oasis-open.org/xliff/xliff-core/v2.1/cos01/xliff-core-v2.1-cos01.html#BiDi
like this:
Please note that this specification does not define explicit markup for inline directional Overrides or Embeddings. In case those are needed, Extractors and Modifiers will need to use [UAX #9] defined Directional Formatting Characters.
For instance, HTML elements <bdi> and <bdo> need both Extracted as a <pc> or <sc/> /<ec/> pair with the dir attribute set respectively. All XLIFF defined inline directionality markup isolates and <sc/> /<ec/> isolated spans can reach over segment (but not unit) boundaries. This needs to be taken into account when splitting or joining segments [link to 4.8.3] that contain inline directionality markup. Albeit It is not advisable to split segments, so that corresponding inline directionality markup start and end would fall into different segments, such a situation is not too confusing. If this happens, the "watertight" BiDi box will simply span two or more segments. This is not too confusing because no XLIFF defined directionality markup is allowed on <source>, <target>, or <segment>, so all higher level protocol inheritance of directionality is from <unit> or higher.  


> XLIFF 2.1 spec: the dir values are not sufficient for proper BiDi support
> -------------------------------------------------------------------------
>
>                 Key: XLIFF-72
>                 URL: https://issues.oasis-open.org/browse/XLIFF-72
>             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
>          Issue Type: New Feature
>          Components: other
>    Affects Versions: 2.1_cos01
>         Environment: http://markmail.org/thread/mjlilczn64jvh2yw
>            Reporter: David Filip
>            Assignee: David Filip
>              Labels: editorial, ready-for-vote
>             Fix For: 2.1_cos02
>
>
> I am looking at this:
> http://docs.oasis-open.org/xliff/xliff-core/v2.1/xliff-core-v2.1.html#dir
> The possible values are lrt, rtl, and auto
> (with auto "determined heuristically, based on the first strong directional
> character in scope, see [UAX #9]").
> That is the same as the HTML dir attribute
>     https://www.w3.org/TR/2014/REC-html5-20141028/dom.html#the-dir-attribute
> But that is not enough, because the direction based on the first char
> results in bad rendering at times.
> So the HTML standard added <bdi> and <bdo>
> And also CSS needed to add even more control, with unicode-bidi:
>    https://www.w3.org/TR/CSS2/visuren.html#direction
> The values in the CSS2 standard seem to be normal, embed, bidi-override,
> inherit
> But more are coming: normal, embed, isolate, bidi-override,
> isolate-override, plaintext
> (https://www.w3.org/TR/css-writing-modes-3/#unicode-bidi)
> Mozilla and Chrome (and probably others will follow) already support these
> values:
>     https://developer.mozilla.org/en-US/docs/Web/CSS/unicode-bidi
> Chrome also supports "initial" (I don't check about Firefox)
> So the proposed values for dir seem insufficient.
> Kind of a pity to release something that is already outdated, without
> learning from what others did...



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)