Re: [Ietf-languages] Fwd: I-D Action: draft-msporny-d-langtag-ext-00.txt

[Martin J. Dürst <[e-mail]>]

Hello Manu, others,

On 2019/05/28 05:10, Manu Sporny wrote:
> On 5/27/19 9:52 AM, Mark Davis ☕️ wrote:
>> I think what they are trying to do is shoehorn in a parameter that
>> lets them set the paragraph embedding level
>> (https://unicode.org/reports/tr9/#BD4) for the Bidi Algorithm.
> 
> Hmm, no, I don't think that's it...

It's pretty much it. To be more precise, maybe change it to "(paragraph) 
embedding level", because it could be intended for sub-paragraph 
embeddings, too.


>> 1. So from the tag "ar-Arab", we get the script "Arab". Then use
>> https://github.com/unicode-org/cldr/blob/master/common/properties/scriptMetadata.txt,

> which has a mapping from script to direction (RTL=YES). (I'm pointing to
>> trunk, just so people can read the file easily; one would use the
>> latest release.)
> 
> What about for something like this, where BiDi doesn't work?
> 
> HTML و CSS: تصميم و إنشاء مواقع الويب

What does not work here?
[Please be aware of the fact that not all email software will render 
this the same.]

Similar to Mark's "rindfleisch..." example, it's probably intended to be 
an Arabic sentence that starts with a word in Latin script and therefore 
risks to be displayed with overall (paragraph) direction of LTR. 
Unfortunately, the only Arabic word I can read here is "و" (and), so I'm 
not totally sure I'm right. It would be good to have explanations for 
examples.

>> It isn't that Arabic would be displayed left to right, it is what
>> establishes the paragraph ordering. The problem arises when you have
>> mixed text. Look at the following example, using the convention that
>> lowercase = English and uppercase=Arabic. The majority of the text
>> and the first strong character are both English, but the sentence is
>>   meant to be used in an Arabic environment, so the default paragraph
>>   embedding level needs to be RTL.
> 
> Yep.

Why are you agreeing here when this is just an explanation of the term 
"paragraph embedding direction" that Mark used at the start of the mail, 
where you disagreed to this?

>> 3. I also agree with Martin that the definition "automatically
>> detected" for subtag 'auto' is not adequate. How does it differ from
>> leaving off the D extension altogether?

I think there might be an important difference. Leaving off the D 
extension may mean one of two things:
1) Determine the embedding direction by some kind of "auto" algorithm
    (ideally clearly specified, desirably by reference)
2) Use the intrinsic directionality derived from the language (and maybe
    script and region) subtags

These two are not the same. If anything, we seem to move into the 
direction of 2), which would mean that "auto" may still be desirable.

> Folks have argued against `auto`, happy to remove it if that's what
> folks in this group think we should do.

It's good to know that you're flexible. But this is just a small detail, 
it could go either way. What we have to make sure is that we get the
big issues right (or "as right as possible").

> It was meant to achieve the same thing this achieves:
> 
> https://www.w3.org/TR/string-meta/#dom-localizable-dir

I'll note that this seems to prefer alternative 1), and we should 
clearly align one way or another if this is going to get deployed.

>> While this is true, for the fast majority of cases, LTR and RTL are
>> the important issues. Most computer systems don't really handle
>> vertical natively; one needs to have more specialized text processing
>> systems, and that is not, I imagine, the target for this syntax.
> 
> We're happy to add other directionalities that folks in this group think
> we should add.

Again a small issue. My personal understanding is that directionality is 
needed only for mixed directional stuff, and that's as in mixing LTR and 
RTL. Vertical writing is at a higher level.

>> 5. Given #4, the lack of a registry for the proposed extension, or
>> even the mention of one, is a significant problem. The set of exactly
>> 3 values associated with this extension ('ltr', 'rtl', and 'auto')
>> would be fixed; adding to it would require updating the RFC, which is
>> much more work than updating a registry.

> Sure, we can add a registry, I can make that change in the next version
> once it becomes clear that the proposal has merit and won't be rejected
> by this or the W3C i18n community.

This is again a small issue. I think it's good to have a registry if 
additions can be easily envisioned, but I can't imagine the need for any 
additions soon. And please note that an updating RFC could essentially 
only contain the new tags. It doesn't have to repeat the text in the 
original RFC.


>> Without these issues being addressed in a satisfactory way, I would
>> lobby IETF not to approve this I-D.
>>
>> I don't see that there is any reason to approve it, given that it is,
>> as far as I can tell, completely unnecessary and would just
>> complicate implementer's lives to no good end.
> 
> Given the new information above (links to use cases, background
> discussion), are you still of the opinion that there is no need for the
> extension?

The extension might be okay if your community can convince us that this 
extension will be strictly limited to those formats (and instances) 
where it's really needed, and that it's stripped or transferred to other 
syntactic elements (e.g. dir attribute for HTML) when that's more 
appropriate.

Regards,   Martin.