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

[Manu Sporny <[e-mail]>]

On 5/26/19 8:46 PM, Doug Ewell wrote:
> I believe THIS LIST is the place to discuss this I-D. (Definitely
> not on some GitHub account.)

The discussion is also happening in these places:

https://github.com/w3c/vc-data-model/issues/436
https://github.com/w3c/rdf-dir-literal/issues/3
https://github.com/w3c/vc-data-model/pull/641
https://github.com/w3c/json-ld-syntax/issues/11
https://github.com/json-ld/json-ld.org/issues/583

I gave up attempting to herd all of these cats to the same location long
ago, so the only thing I can do is bridge the conversation between the
various groups.

I'm happy to put this group as the one that is "in charge" of the
extension... if the proposal goes anywhere.

> 1. In the proposal's lone example, the Arabic script is a 
> right-to-left script. How does "ar-d-rtl" indicate right-to-left 
> directionality in a way that "ar-Arab" does not?

It's a bad example. Is this one better?

HTML و CSS: تصميم و إنشاء مواقع الويب

> 2. Given #1, and given that the script subtag 'Arab' is a 
> Suppress-Script for the language subtag 'ar' (which means "ar" is 
> equivalent to "ar-Arab" for almost all purposes), how is "ar" not 
> sufficient? I agree with Martin's comment here: what rendering 
> process is likely to display Arabic left-to-right?

What about if we switch to the example above?

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

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

It was meant to achieve the same thing this achieves:

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

> 4. Scripts exist in other directionalities besides LTR and RTL. 
> Chinese, Japanese, and Korean can be written top-to-bottom, 
> right-to-left. Mongolian in Mongolian script is properly written 
> top-to-bottom, left-to-right, but is sometimes (although
> incorrectly) rendered LTR as well. Some languages have been written
> boustrophedon, either with or without reversing the glyphs when
> transitioning from LTR to RTL. None of these scenarios are covered in
> the proposal, but some of them seem much more in need of explicit
> marking than the Arabic example.

Ok, then which ones should we 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.

Sure, we can use 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.

I'm tracking your concerns (and responses) here:

https://github.com/digitalbazaar/d-langtag-ext/issues/2

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