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

[Manu Sporny <[e-mail]>]

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... Here's some background, Mark:

https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-496004819

... and why we're having this discussion:

https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-496006350

... and what the current proposed spec text in the Verifiable
Credentials Data Model specification regarding i18n states:

https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/641.html#internationalization-considerations

> 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: تصميم و إنشاء مواقع الويب

> 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.

> 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?
> 
> Agreed, not well specified. But -d- is not needed in the first place,
> so moot.

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

It was meant to achieve the same thing this achieves:

https://www.w3.org/TR/string-meta/#dom-localizable-dir

> 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.

> 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.
> 
> Agreed, that would be a major drawback.  But -d- is not needed in
> the first place, so moot.

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.

> 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?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches