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

From: Martin J. Dürst <[email-masked]>
Date: Sun, 26 May 2019 02:22:05 +0000

I just found the following announcement (see end of this email).

I'm forwarding it to the ietf-languages list because that's where a lot 
of the language tagging experts are.

(Manu, I suggest you subscribe to this list for the duration of this 
discussion, to make sure you are not missing any comments.)

The draft is very short. Having had a quick look at it, I came up with 
the following comments:

- The (only) example, "ar-d-rtl", doesn't exactly reflect what we
   consider good language tagging practice. It's similar to something
   such as en-Latn, where the "Latn" script subtag is just plain obvious
   and therefore not needed. So some examples that show more clear
   cases where the directionality information is necessary should be
   given.

- There is quite a bit of information about duplicate extensions and
   canonicalization. As far as I understand, this is just repetition
   from RFC 5646, but this should be stated more clearly. Maybe move
   the text about duplication to the canonicalization (sub (1))section,
   and start that section with a sentence saying: "This section explains
   the rules regarding duplicate information and canonicalization
   defined in RFC 5646. The full rules are given in RFC 5646, and in
   case of conflicts, RFC 5646 is correct."

- There's absolutely no text about where this extension would be
   helpful or useful. As far as I understand, it's not appropriate
   e.g. for HTML, because HTML has the dir attribute. There should
   be a clear discussion about places where this extension is
   desirable (maybe even needed) and places where it's irrelevant,
   useless, confusing, or counterproductive.

- There should be a discussion about how this extension interacts
   (or not) with "bidi formatting characters".

- There should be some text about what "auto" exactly means.
   It's probably something like "first strong", but it could
   be something else (e.g. majority of strong,...)

- There may also be a need for a subtag meaning "just follow
   the context around you", which is different from "auto".

- The registration form gives a mailing list of
   [email-masked]. While this may be the mailing list
   where the idea for this kind of extension originated, it doesn't
   feel like being the right place for discussions that may come up
   e.g. 5 or 10 years down the line.

- I'd make canonicalization, as well as examples, independent
   sections and in any case eliminate the third level of the TOC
   hierarchy (the current 2.1.1).

Regards,   Martin.

-------- Forwarded Message --------
Subject: I-D Action: draft-msporny-d-langtag-ext-00.txt
Date: Sat, 25 May 2019 14:12:29 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

         Title           : BCP 47 Extension D
         Author          : Manu Sporny
	Filename        : draft-msporny-d-langtag-ext-00.txt
	Pages           : 4
	Date            : 2019-05-25

Abstract:
    This document specifies an Extension to BCP 47 which provides subtags
    that specify language direction.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-msporny-d-langtag-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-msporny-d-langtag-ext-00
https://datatracker.ietf.org/doc/html/draft-msporny-d-langtag-ext-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
.

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 26 May 2019 06:10:23 +0000

There is a discussion in the W3C space (and particularly the Linked Data, I.e. the RDF/JSON-LD space) about this. I happen to think Manu has jumped the gun, but it is an internet draft and thus is meant to spark discussion of this sort. When I'm at a real computer in the morning I'll send some links for those interested in this debate.

On May 25, 2019, at 19:29, "Martin J. Dürst" <[email-masked]> wrote:

Regards,   Martin.

-------- Forwarded Message --------
Subject: I-D Action: draft-msporny-d-langtag-ext-00.txt
Date: Sat, 25 May 2019 14:12:29 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

..

_______________________________________________
Ietf-languages mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-languages

---

From: Manu Sporny <[email-masked]>
Date: Sun, 26 May 2019 11:22:40 -0400

> discussion, to make sure you are not missing any comments.)

Subscribed, thanks Martin. :)

On 5/26/19 2:10 AM, Phillips, Addison wrote:
> There is a discussion in the W3C space (and particularly the Linked 
> Data, I.e. the RDF/JSON-LD space) about this. I happen to think Manu 
> has jumped the gun, but it is an internet draft and thus is meant to 
> spark discussion of this sort. When I'm at a real computer in the 
> morning I'll send some links for those interested in this debate.

Yes, I jumped the gun to push the conversation along... background for
those that need it:

The W3C Verifiable Credentials defines a data model for the expression
of things like Professional Licenses, Driver's Licenses, Education
Certificates, Passports, Business descriptions (summary, hours of
operation, etc.). The data model works across a variety of syntaxes
(JSON, JSON-LD, N-Quads, HTML, CBOR, etc.). We want first-class i18n
support, and a common approach to base direction has proved to be
challenging across all of the expected syntaxes. One approach is to
extend the language tag to also support base direction in a way that is
backwards compatible. The proposal can be found here:

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

There is a massive thread w/ background here:

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

... which led to this I-D, written by someone that is definitely not an
expert in this area (me):

There is a time pressure here. Our i198n concerns have been hanging out
there for more than 9 months and our WG charter is up in a couple of
months. We need to wrap this up in 3 weeks. Or to put it another way, if
we don't wrap this up in 3 weeks, we won't be addressing this issue,
which would be a shame.

In any case, if you're going to engage in this discussion, the issue #3
above is probably the place to do it.

Martin, I'm tracking your comments here:

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

Martin, almost all, if not all, of your input is reasonable and I'll
make those changes if it looks like there is consensus to proceed with
draft-msporny-d-langtag-ext-00.. that is, if Addison doesn't strangle me
first. :P

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 26 May 2019 18:46:37 -0600

Manu Sporny wrote:
 
> There is a time pressure here. Our i198n concerns have been hanging
> out there for more than 9 months and our WG charter is up in a couple
> of months. We need to wrap this up in 3 weeks. Or to put it another
> way, if we don't wrap this up in 3 weeks, we won't be addressing this
> issue, which would be a shame.
 
I know it is flippant to say "that's not our problem," and I apologize in advance for that, but trying to push through this extension quickly, without consulting or even notifying the language-tagging community, does not seem to me an appropriate way to compensate for this lapse. It was only by chance that Martin happened to spot this I-D and was able to bring it to our attention.
 
Apparently Addison did know about this effort, and is credited in the Acknowledgements section of the I-D, but it would be nice if the author(s) of an extension proposal would check in with ietf-languages as part of their effort. RFC 5646 does not require this; I wish it did. The IETF at large and W3C are not experts in this field, and probably will not be able to detect significant operational problems in such a proposal.
 
> In any case, if you're going to engage in this discussion, the issue
> #3 above is probably the place to do it.
 
I believe THIS LIST is the place to discuss this I-D. (Definitely not on some GitHub account.)
 
I have other questions and/or concerns, some of which overlap with Martin's:
 
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?
 
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?
 
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?
 
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.
 
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.
 
Without these issues being addressed in a satisfactory way, I would lobby IETF not to approve this I-D.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

---

From: Michael Everson <[email-masked]>
Date: Mon, 27 May 2019 03:20:50 +0100

I don’t buy the whole enterprise. Why does this need to be tagged? The encoded characters have RTL or LTR properties. The script codes can be parsed with knowledge of what script is what. Why is that not adequate?

> On 27 May 2019, at 01:46, Doug Ewell <[email-masked]> wrote:
>

---

From: Mark Davis ☕️ <[email-masked]>
Date: Mon, 27 May 2019 15:52:23 +0200

Doug, I agree most of the points you are making, especially #1.

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. But instead of that hack, as you point out, one can
deduce the direction from the language tag. The best way to do this is to
get the ordering from CLDR for an ordinary language tag like "ar" or
"ar-Arab".

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

2. But let's suppose that you have just "ar". Since the script is not
explicit, the best way to get it is also CLDR. You can use
https://github.com/unicode-org/cldr/blob/master/common/supplemental/likelySubtags.xml,
which has a mapping from language or language+region to default
language-script-region. So "ar" => "ar_Arab_EG", from which we get the
script "Arab", and then use step 1. Or from "fr" you'd get "Latn" and map
it to RTL=NO.

A few more comments below.

On Mon, May 27, 2019 at 2:47 AM Doug Ewell <[email-masked]> wrote:

> I know it is flippant to say "that's not our problem," and I apologize in
> advance for that, but trying to push through this extension quickly,
> without consulting or even notifying the language-tagging community, does
> not seem to me an appropriate way to compensate for this lapse. It was only
> by chance that Martin happened to spot this I-D and was able to bring it to
> our attention.
>
> Apparently Addison did know about this effort, and is credited in the
> Acknowledgements section of the I-D, but it would be nice if the author(s)
> of an extension proposal would check in with ietf-languages as part of
> their effort. RFC 5646 does not require this; I wish it did. The IETF at
> large and W3C are not experts in this field, and probably will not be able
> to detect significant operational problems in such a proposal.
>
> 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?

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

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.

rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz IS A LONG
WORD.

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

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

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.

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

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

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 27 May 2019 11:07:39 -0600

Mark Davis wrote:

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

Yes, all right, if you are a text process that renders or formats text, but you don't know that the Arabic script is RTL, then fine, use CLDR to tell you that. OK.

> script "Arab", and then use step 1. Or from "fr" you'd get "Latn" and
> map it to RTL=NO.

You don't need CLDR for this step. The BCP 47 Language Subtag Registry could have told you that:

Type: language
Subtag: ar
Description: Arabic
Added: 2005-10-16
Suppress-Script: Arab      ← THIS
Scope: macrolanguage

I mean, jeez, that's why we invented Suppress-Script in the first place. (Well, sort of. We invented it to go the other way, when you're *creating* a tag, so when you're tempted to write "ar-Arab" you can stop and just write "ar" instead. But this scenario works just as well.)

If you have a more complex matching scenario in mind, involving region and variant subtags, or crossing over from Breton to French or whatever, then go ahead and use CLDR. Or, I suppose, you can also use it here if you already didn't know Arabic was a RTL script in #1 and you had to have CLDR available for that anyway.

This is a lot like RFC 4647 matching: it isn't good enough for all scenarios, so you might need customized or more ambitious matching algorithms for those, but for many simpler cases it's just fine. But it DOES exist and there's no need to pretend it doesn't and invent another basic scheme.

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

It still doesn't sound as though inserting 'ltr' or 'rtl' into the language tab would solve this problem. We have Unicode bidi controls for this. (I know HTML has its own tags for this, which are preferred in that context, but the GitHub thread indicates this isn't mostly about HTML.)

>> 4. Scripts exist in other directionalities besides LTR and RTL...
>
> While this is true, for the [v]ast 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.

Today, yes. N years from now, when these specialized text processing systems become mainstream, maybe it will be a different story. You don't want to lock out that possibility by hard-coding the set of allowable values into the RFC for all time.

> 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

Agreed, obviously.

What we need to do is get together with the folks on the GitHub thread and explain the situation to them, how this proposed solution is neither necessary nor sufficient, and show them the right way(s) to do what they need.

---

From: Mark Davis ☕️ <[email-masked]>
Date: Mon, 27 May 2019 21:07:28 +0200

Below

On Mon, May 27, 2019 at 7:07 PM Doug Ewell <[email-masked]> wrote:

> Yes, all right, if you are a text process that renders or formats text,
> but you don't know that the Arabic script is RTL, then fine, use CLDR to
> tell you that. OK.
>
> I mean, jeez, that's why we invented Suppress-Script in the first place.
> (Well, sort of. We invented it to go the other way, when you're *creating*
> a tag, so when you're tempted to write "ar-Arab" you can stop and just
> write "ar" instead. But this scenario works just as well.)

> If you have a more complex matching scenario in mind, involving region and
> variant subtags, or crossing over from Breton to French or whatever, then
> go ahead and use CLDR. Or, I suppose, you can also use it here if you
> already didn't know Arabic was a RTL script in #1 and you had to have CLDR
> available for that anyway.
>
> This is a lot like RFC 4647 matching: it isn't good enough for all
> scenarios, so you might need customized or more ambitious matching
> algorithms for those, but for many simpler cases it's just fine. But it
> DOES exist and there's no need to pretend it doesn't and invent another
> basic scheme.
>

There are Suppress-Script values for 134 languages, while there are 1,320
language-script values in CLDR; plus it has cases where the best script
depends not only on both the language and the region (eg az-IQ).

If someone wants to limit their usage to what's in Suppress-Script, it is
up to them. But my advice (which is what I was providing) would be to use
the more complete set in CLDR.

> It still doesn't sound as though inserting 'ltr' or 'rtl' into the
> language tab would solve this problem. We have Unicode bidi controls for
> this. (I know HTML has its own tags for this, which are preferred in that
> context, but the GitHub thread indicates this isn't mostly about HTML.)
>
It wouldn't, and as I said (how did you miss this?), I agree that having
-d- is a bad idea.

What I was explaining was that "what rendering process is likely to display
Arabic left-to-right?" is not the right issue. You don't need to know the
paragraph embedding level to display pure Arabic. If you are curious about
the BIDI algorithm, you can consult the spec, or better yet, the W3C page
on it.

> Today, yes. N years from now, when these specialized text processing
> systems become mainstream, maybe it will be a different story. You don't
> want to lock out that possibility by hard-coding the set of allowable
> values into the RFC for all time.
>

Again, -d- is a bad idea anyway, whether or not there is a registry, or
that there are more values at the onset. There are bigger fish to fry.

> What we need to do is get together with the folks on the GitHub thread and
> explain the situation to them, how this proposed solution is neither
> necessary nor sufficient, and show them the right way(s) to do what they
> need.
>

I think Addison and Manu will probably be taking feedback from this list
back into the GitHub thread.

---

From: Manu Sporny <[email-masked]>
Date: Mon, 27 May 2019 15:33:26 -0400

On 5/26/19 8:46 PM, Doug Ewell wrote:
> I know it is flippant to say "that's not our problem," and I 
> apologize in advance for that, but trying to push through this 
> extension quickly, without consulting or even notifying the 
> language-tagging community, does not seem to me an appropriate way
> to compensate for this lapse. It was only by chance that Martin
> happened to spot this I-D and was able to bring it to our attention.

We requested a review of the Verifiable Credentials specification (via
[email-masked]) in 2018 and again in Feb 2019.

I'll refrain from being flippant and not say "That you're just hearing
about this is 'not my problem'... how was I to know where you hang out
on the Internet and that you had an opinion about this? Why aren't you
also hanging out in public-i18n-core?". :) -- but, I don't think doing
stuff like that will get us to better i18n, which is what I'd like us to
focus on. :)

The reality is quite the contrary to what you suspect... a subset of
"us" have made this our problem and would like help figuring out the
right way to address it. We are under time pressure, which is not your
problem, but it doesn't alleviate the time pressure we're under. There
was plenty of time to address this issue, no one did, I'm making one
last attempt (because it's all the time I have) before this version of
our spec is set in stone.

To be clear, there is no attempt to "push this extension quickly"...
there is an attempt to try to see if there is a viable solution
quickly... because, again, it's all the time I have.

This is an attempt to see if the extension would work for the set of use
cases we're grappling with and then provide some guidance in our
specification. If there is no consensus on what the guidance should be,
I will happily say nothing about how one achieves good i18n wrt. base
direction across JSON-LD, JSON, CBOR, and other syntaxes (other than
pointing to STRING-META and shrugging).

Here's the use case if you (or anyone else) is still interested in helping:

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

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

... and what the current proposed spec text regarding i18n states:

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

Fundamentally, we're attempting to suggest a design pattern that will
gain adoption among JSON, RDF, JSON-LD, HTML, CBOR, and other syntaxes
that is capable of encoding both language and base direction in a way
that is backwards compatible *for simple use cases*, and deferring to
HTML snippets for the more complex use cases.

draft-msporny-d-langtag-ext-00 is misleading... it is just one
(alternative) piece of a potential solution that's proposed in the
proposed spec text above.

-- manu

---

From: "Gordon P. Hemsley" <[email-masked]>
Date: Mon, 27 May 2019 15:40:28 -0400

To jump on the bandwagon of pointing to places where this has already
been handled, CSS has whole specification for writing modes from a
presentational perspective:

https://www.w3.org/TR/css-writing-modes-3/

Gordon P. Hemsley
[email-masked]
http://gphemsley.org/

---

From: Manu Sporny <[email-masked]>
Date: Mon, 27 May 2019 15:58:41 -0400

> 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

---

From: Manu Sporny <[email-masked]>
Date: Mon, 27 May 2019 16:00:06 -0400

On 5/26/19 10:20 PM, Michael Everson wrote:
> I don’t buy the whole enterprise. Why does this need to be tagged? 
> The encoded characters have RTL or LTR properties. The script codes 
> can be parsed with knowledge of what script is what. Why is that not 
> adequate?

Here's some background, Michael:

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

-- manu

---

From: Manu Sporny <[email-masked]>
Date: Mon, 27 May 2019 16:10:22 -0400

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:

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

> 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

Yep.

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

> While this is true, for the fast majority of cases, LTR and RTL are 

We're happy to add other directionalities that folks in this group think
we should add.

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

> 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

---

From: Manu Sporny <[email-masked]>
Date: Mon, 27 May 2019 16:23:12 -0400

> https://www.w3.org/TR/css-writing-modes-3/

I fail to see how that helps express these concepts in a unified way
across JSON, JSON-LD, RDF, and CBOR (to name a subset of the syntaxes
that we're concerned about). I mean, it is helpful to see the options...
it's not helpful in that none of those options or design patterns exist
for the syntaxes previously mentioned.

Here's some background, Gordon:

-- manu

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 27 May 2019 14:56:02 -0600

Mark Davis wrote:

> There are Suppress-Script values for 134 languages, while there are
> 1,320 language-script values in CLDR; plus it has cases where the best
> script depends not only on both the language and the region
> (eg az-IQ).
>
> If someone wants to limit their usage to what's in Suppress-Script, it
> is up to them. But my advice (which is what I was providing) would be
> to use the more complete set in CLDR.

Fair enough. The draft had suggested a really rudimentary example, for which I suggested a rudimentary solution. But CLDR is certainly more thorough.

>> language ta[g] would solve this problem...
>
> It wouldn't, and as I said (how did you miss this?)

I didn't.

> , I agree that having -d- is a bad idea.
>
> What I was explaining was that "what rendering process is likely to
> display Arabic left-to-right?" is not the right issue. You don't need
> to know the paragraph embedding level to display pure Arabic. If you
> are curious about the BIDI algorithm, you can consult the spec, or
> better yet, the W3C page on it.

OK, so the issue is that (in layman's terms) they need to declare the paragraph to be of a certain directionality, even if the text that begins the paragraph (or some other text that would set the tone for directionality) might not be of that directionality. Is that right? If so, I contend that a plain old language tag should still be a sufficient indicator of that:

<span lang="ar">rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz IS A LONG WORD.</span>
(example is HTML, substitute your favorite text format that uses language tags)

I know you agree with me. When I make an argument against this solution, it is not intended as a rebuttal to your argument against the solution.

> There are bigger fish to fry.

Noted, and thanks for the reminder.

---

From: Manu Sporny <[email-masked]>
Date: Mon, 27 May 2019 17:19:56 -0400

On 5/27/19 4:56 PM, Doug Ewell wrote:
> OK, so the issue is that (in layman's terms) they need to declare
> the paragraph to be of a certain directionality, even if the text
> that begins the paragraph (or some other text that would set the tone
> for directionality) might not be of that directionality. Is that
> right?

Basically, but you're missing a number of requirements, please refer to
the background information I noted in my initial response to you.

> If so, I contend that a plain old language tag should still be a 
> sufficient indicator of that:

Yes, but that was rejected as a solution a long time ago. Some of our
implementers are running in constrained environments and do not want to
require a full blown HTML processor to understand language and base
direction. There are use cases where you can't escape that (such as Ruby
markup), but for the simple ones... they want a simpler solution than
"include this gigantic HTML processor in your solution".

> <span 
> lang="ar">rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz
>
> 
IS A LONG WORD.</span> (example is HTML, substitute your favorite
> text format that uses language tags)

This is not a solution as it would require a full blown HTML processor
to understand the variations in an interoperable way (like, for example,
what do you do when the tags mismatch, or there is a syntax error)?

-- manu

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 27 May 2019 15:24:56 -0600

> [email-masked]) in 2018 and again in Feb 2019.

I am sorry that your timely requests for review went unanswered. Sometimes the wheels turn slowly through no fault of the requester.

> stuff like that will get us to better i18n, which is what I'd like us
> to focus on. :)

I apologized before for that unfortunate expression, and I apologize for it again now. It was a bad choice of response; it was neither productive nor indicative of willingness to help. I'm sorry.

Many of us, and I'm sure you as well, have heard requests over the years of this form: "We have use case A, and we propose to solve it with mechanism B." Use case A may be completely genuine and cause real-world problems, but it does not necessarily follow that mechanism B is a good or suitable solution. Repeating the arguments for use case A and emphasizing the timeliness factor does not change mechanism B into a good solution.

We are trying to explain alternative solutions that will satisfy use case A.

It is certainly not your fault or anyone else's that we did not include something in Section 3.7 of BCP 47 about encouraging authors of extension RFCs to contact [email-masked] for feedback and review. BCP 47 does mention the ietf-languages list in more than a dozen places, so for those who have read the document, it might seem like an appropriate place to send a request for such feedback. We are not just all over the Internet.

> This is an attempt to see if the extension would work for the set of
> use cases we're grappling with and then provide some guidance in our
> specification.

Here is the question that keeps popping into my head (also when following the thread on rdf-dir-literal):

How does a language tag that just indicates the language, or language plus script, NOT solve the need to indicate base directionality?

Mark gave an example of a short paragraph that doesn’t begin with the "right" directionality, so an attempt to auto-detect would guess wrong. But if you tagged that paragraph as "ar", shouldn't the base directionality be that of Arabic — that is, RTL?

> Here's the use case if you (or anyone else) is still interested in helping:

It does seem to me that on the GitHub thread, the use case is being framed in terms of the proposed solution. Here is an example:

"you cannot necessarily get the direction information just from the language."

"Sorry, I meant that this is already true for many languages, but not all. For those languages where it is possible, that information comes from the language tag (e.g., "en" means the direction is "ltr"). That indicates to me that a sensible solution to this problem is to add the direction information to the language tags that do not imply it already (via an -d- language tag extension)."

My question is, for what combinations of language and script is it *not* possible to figure out the directionality?

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 27 May 2019 15:38:33 -0600

> https://github.com/json-ld/json-ld.org/issues/583

All right, multiple GitHub accounts. 😊

> 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 appreciate that problem. I understand you volunteered (or were volunteered) to coordinate this, and any procedural problems or quirks are not your fault.

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

My understanding of the group's viewpoint is that if you tag this string as "ar", its correct directionality will (or may) not be honored, but if you tag it as "ar-d-rtl" then it will. Is this correct? This would also answer #2.

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

That's actually helpful; it provides a definition for 'auto' ("directionality determined by Unicode Bidi Algorithm") which does not exist in the current I-D.

> Ok, then which ones should we add?

Well, if you define a registry and provisions for amending it, then you don't have to have all the answers right away.

> 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 think this would help, but I don't think we can guarantee that it is the only objection that people here or at W3C will have. For me at least, the "ar" versus "ar-d-rtl" question above is paramount.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 27 May 2019 15:48:22 -0600

Manu Sporny wrote:

> implementers are running in constrained environments and do not want
> to require a full blown HTML processor to understand language and base
> direction. There are use cases where you can't escape that (such as
> Ruby markup), but for the simple ones... they want a simpler solution
> than "include this gigantic HTML processor in your solution".

Wait, now I'm very lost.

How does the simple language tag "ar" "require a full-blown HTML processor" in a way that the more complex language tag "ar-d-rtl" does not?

>> <span lang="ar">
>> rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz
>> IS A LONG WORD.</span>
> to understand the variations in an interoperable way

Do you mean that the processor you envision would pick up a BCP 47 language tag, ignore the language part ("ar") altogether, and look only at the direction extension ("-d-rtl")?

If so, this is very much an abuse of the concept of language tagging.

If not, this is more complex than processing "ar", not less.

> (like, for example, what do you do when the tags mismatch, or there is
> a syntax error)?

I don't see how you can avoid solving problems like these, regardless of the approach you adopt.

---

From: Richard Wordingham <[email-masked]>
Date: Mon, 27 May 2019 23:34:45 +0100

On Mon, 27 May 2019 14:56:02 -0600
"Doug Ewell" <[email-masked]> wrote:

> > display Arabic left-to-right?" is not the right issue. You don't
> > need to know the paragraph embedding level to display pure Arabic.
> > If you are curious about the BIDI algorithm, you can consult the
> > spec, or better yet, the W3C page on it.  
> 
> OK, so the issue is that (in layman's terms) they need to declare the
> paragraph to be of a certain directionality, even if the text that
> begins the paragraph (or some other text that would set the tone for
> directionality) might not be of that directionality. Is that right?

So how do you use a present-day language tag to set the paragraph
direction for Middle Egyptian in hieroglyphs?  Do you have to do
something like ensuring that the scope of the Middle Egyptian language
tag doesn't extend to the starts of paragraphs?  (Reminder: Ancient
Egyptian Egyptian hieroglyphs could be laid out in either order;
right-to-left was the default, but nowadays the default is left to
right, apparently even in Arabic publications!

And what if you want to have English text in right-to-left paragraphs?  

Richard.

---

From: "Gordon P. Hemsley" <[email-masked]>
Date: Mon, 27 May 2019 20:11:11 -0400

> for the syntaxes previously mentioned.

Unifying "JSON, JSON-LD, RDF, and CBOR" is not my concern.

My concern is that numerous people who work with languages,
localization, and internationalization on a daily basis have already
considered these issues, and they are not as simple as a layperson may
believe. It would be wise for groups who do not work directly with
languages, writing systems, or locales on a daily basis to heed the
advice and prior work of experts before endeavoring to standardize
something that would affect those people. This is not a standard one can
throw together in haste.

> .... and why we're having this discussion:
> 
> .... and what the current proposed spec text in the Verifiable

My original e-mail was meant to be informational, but now that I have
reviewed the links that you have included in multiple replies, I am
further convinced that the existing work, the listed requirements, and
the ramifications of the proposed solutions have not been sufficiently
considered.

--
Gordon P. Hemsley
[email-masked]
http://gphemsley.org/

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 27 May 2019 18:24:56 -0600

> right, apparently even in Arabic publications!

Mark suggested that even the present-day Chinese, Japanese, Korean, and Mongolian use cases were somewhat out of scope, so I suspect Middle Egyptian might also be beyond the use case that is being discussed here.

The quick answer is that BCP 47 language tags do not cover that. That is what the D extension proposal aims to solve.

My arguments regarding the proposed D extension have been that:

(a) for the posited use cases, primarily Arabic, the proposed solution is not necessary, because explicit or implicit script subtags already indicate direction, and

(b) for use cases such as mine, the proposed solution is not sufficient, because the repertoire is not extensible.

> And what if you want to have English text in right-to-left paragraphs?

I assumed we were sticking to real-life use cases. That said, in BabelPad I get the desired result with a Latin-script line by prefixing it with RLO.

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 28 May 2019 00:29:27 +0000

Some background would be probably useful in this discussion. I’m playing catch-up here due to the U.S. holiday.

This is an outgrowth of a recent review of a number of specifications at W3C (in Manu’s case, specifically the Verifiable Claims spec). Like many current specs, VC uses JSON as a file format and depends on Linked Data specifications such as RDF and JSON-LD. The W3C I18N working group identified some time ago that these formats do not provide for metadata to set the base direction in the UBA and we’ve been raising the visibility of this—we have an open issue with the TAG and comments on a variety of specs.

Here are useful links for context: [1][2]. To document the requirements and current status Richard Ishida and I have been editing a W3C note “string-meta” [3] which might make a good explainer (send comments to our github).

The problem here is there are specs that need to progress in maturity, whose authors accept the need to manage base direction, but which have no way to do so with RDF/JSON-LD compliant serializations.

From the discussion below/elsewhere, I’m obviously aware of this I-D. However, I do not agree with it at present. I think that there are other, better ways to address this issue.

I’m not going to respond to the entirety of this thread because this discussion is better off happening at [1], in the RDF space, where it is actually a problem and I would urge those interested to decamp there.

Additionally, I am hosting a call on Wednesday at 1300 UTC. Details can be found at [1].

Thanks,

Addison

Addison Phillips
Sr. Principal SDE – I18N (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[1] https://github.com/w3c/rdf-dir-literal/issues/3<https://github.com/w3c/rdf-dir-literal/issues/3#issuecomment-495937506>
[2] https://github.com/w3ctag/design-reviews/issues/178
[3] https://w3c.github.io/string-meta/ (or the official copy: https://www.w3.org/TR/string-meta)

From: Mark Davis ☕️ [mailto:[email-masked]]
Sent: Monday, May 27, 2019 6:52 AM
To: Doug Ewell <[email-masked]>; Phillips, Addison <[email-masked]>
Cc: Manu Sporny <[email-masked]>; Martin J. Dürst <[email-masked]>; IETF Languages Discussion <[email-masked]>
Subject: Re: [Ietf-languages] Fwd: I-D Action: draft-msporny-d-langtag-ext-00.txt

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. But instead of that hack, as you point out, one can deduce the direction from the language tag. The best way to do this is to get the ordering from CLDR for an ordinary language tag like "ar" or "ar-Arab".

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

2. But let's suppose that you have just "ar". Since the script is not explicit, the best way to get it is also CLDR. You can use https://github.com/unicode-org/cldr/blob/master/common/supplemental/likelySubtags.xml, which has a mapping from language or language+region to default language-script-region. So "ar" => "ar_Arab_EG", from which we get the script "Arab", and then use step 1. Or from "fr" you'd get "Latn" and map it to RTL=NO.

On Mon, May 27, 2019 at 2:47 AM Doug Ewell <[email-masked]<mailto:[email-masked]>> wrote:

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.

rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz IS A LONG WORD.

Agreed, not well specified. But -d- is not needed in the first place, so moot.

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.

Agreed, that would be a major drawback.  But -d- is not needed in the first place, so moot.

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.

--
Doug Ewell | Thornton, CO, US | ewellic.org<http://ewellic.org>

_______________________________________________
Ietf-languages mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-languages

---

From: Martin Hosken <[email-masked]>
Date: Tue, 28 May 2019 09:58:38 +0700

Dear All,

If it so happens that we do decide that directionality is worth marking, I would plead that we not allocate a whole namespace to this just for two members, but simply define 2 (or 3) variants: bidirtl, bidiltr. There can only be 26 namespaces and there are way too few to treat them like CSS axes.

Yours,
Martin

---

From: Mark Davis ☕️ <[email-masked]>
Date: Tue, 28 May 2019 06:05:05 +0200

Mark

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

I assume that by the phrase "BiDi doesn't work" you mean that the original
author's intended display is not achieved.

It would help if you clearly provided examples of the source text, and what
is desired. While the paragraph direction is important, it is often *not*
enough to get exactly the right display, such as when there are neutral
characters on the boundaries between RTL and LTR text that shouldn't follow
the paragraph direction. For that the author needs finer-grained control
over the direction. That can be achieved using the bidi control characters
in Unicode, or by markup in higher-level languages (such as HTML/CSS). The
markup approach is cleaner, where possible. Where the environment does not
permit markup, the Unicode characters can be used to exactly control the
bidi display.

It appears that your use case has extremely limited markup, just the
language tag, and just for a whole paragraph, and that you don't have the
ability to add any further markup, and are driven to overloading the
language tag for that purpose. Even assuming that, you have not made it
clear why simply the language tag of "ar" — *from which the paragraph
direction could be derived* — is not sufficient for your use case of
setting the paragraph direction.

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 29 May 2019 07:19:42 +0000

Hello Manu, others,

On 2019/05/28 05:10, Manu Sporny wrote:
> 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.

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

>>   embedding level needs to be RTL.

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?

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

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

> We're happy to add other directionalities that folks in this group think

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.

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

> discussion), are you still of the opinion that there is no need for the

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.

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 29 May 2019 07:19:56 +0000

Hello Manu, others,

On 2019/05/27 00:22, Manu Sporny wrote:
> challenging across all of the expected syntaxes.

Yes. This is nothing more than expected. Working across syntaxes (and 
data models!) IS hard. You shouldn't work under the assumption that this 
is easy, and you shouldn't try to make it seem easy when it's not.

> One approach is to

As very experienced people such as Ivan Herman (@iherman) and Charles 
McCathieNevile (@chaals) have expressed in that thread, it's 
inappropriate to force something like this direction information on HTML 
(which has solved the problem since more than 20 years, see 
https://trac.tools.ietf.org/html/rfc2070). It would be very much the 
tail ("Verifiable Credentials") wagging the dog.

So at a minimum, you have to make sure that when data gets converted 
from RDF to HTML, the -D extension gets removed and the corresponding 
HTML dir attribute gets added (and vice versa for the conversion in the 
other direction). You should also check out formats such as CBOR, which 
work somewhat differently from JSON, RDF, or HTML. This is actual work, 
make sure it gets done.

Once you realize that actual work is involved, you may realize that 
using a separate attribute (or whatever the equivalent in other formats) 
may not be that bad a solution.

> we don't wrap this up in 3 weeks, we won't be addressing this issue,

This wouldn't be the first standards effort where a group's duration is 
extended, and it wouldn't be the last. And in this case, an extension 
might actually be justified. After all, this is something that shouldn't 
just work for Verifiable Credentials, but for a lot of other RDF, 
JSON-LD, JSON,...

3 weeks or 2 months are nothing given that the first teleconference I 
have been on discussion language tags in RDF was more than 20 years ago.
(see https://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ and search for 
xml:lang).

> above is probably the place to do it.

I'll try. But I know I'm better with email than with github issues, sorry.

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

Thanks.

> draft-msporny-d-langtag-ext-00.. that is, if Addison doesn't strangle me

Okay.

Regards,   Martin.

---

From: John Cowan <[email-masked]>
Date: Wed, 29 May 2019 17:56:14 -0400

On Wed, May 29, 2019 at 3:20 AM Martin J. Dürst <[email-masked]>
wrote:

> RTL. Vertical writing is at a higher level.

Bidirectionality does in fact exist in vertical writing:  when a horizontal
script
is embedded into CJK or Mongolian (which are written downwards),
Latin and similar scripts appear rotated 90 degrees clockwise and are
written downwards also, but Arabic appears rotated 90 degrees
counterclockwise and is written and read upwards.

(This means that in Arabic in Mongolian, the ancestral Aramaic letters
that underlie Mongolian are upside down from the Arabic perspective.
Mongolian writing evolved from RTL writing by turning the page;
it is common for RTL writers to write vertically while still reading
horizontally.)

---

From: Richard Wordingham <[email-masked]>
Date: Thu, 30 May 2019 05:40:06 +0100

On Mon, 27 May 2019 18:24:56 -0600
"Doug Ewell" <[email-masked]> wrote:

> > something like ensuring that the scope of the Middle Egyptian
> > language tag doesn't extend to the starts of paragraphs?
> > (Reminder: Ancient Egyptian Egyptian hieroglyphs could be laid out
> > in either order; right-to-left was the default, but nowadays the
> > default is left to right, apparently even in Arabic publications!  

> (a) for the posited use cases, primarily Arabic, the proposed
> solution is not necessary, because explicit or implicit script
> subtags already indicate direction, and
> 
> (b) for use cases such as mine, the proposed solution is not
> sufficient, because the repertoire is not extensible.
> 

> I assumed we were sticking to real-life use cases. That said, in
> BabelPad I get the desired result with a Latin-script line by
> prefixing it with RLO.

Surely RLO would result in English being written backwards?

‮As here!

I believe that may result in right-to-left direction (as with my
email cient) because there is no overriding protocol, so first strong
character determines. In normal text, one can achieve that effect with
RLM or ALM if there is no contradictory higher level protocol. The most
striking effect that I can think of on purely English text is that
'unjustified' text typically ends up flush right rather than flush
left.

There was a period when LibreOffice used to misinterpret my
keystrokes as commanding a change of paragraph direction to
right-to-left.  The result was misery as I searched for the command to
undo the uncommanded change of direction.

Richard.