[UA-discuss] Regarding "RTL"

Sat Feb 21 05:10:53 UTC 2015

Dear Mark, All,

There is a community led effort called the Task Force on Arabic script IDNs
(TF-AIDN)
<https://community.icann.org/display/MES/Task+Force+on+Arabic+Script+IDNs>
whom we can reach out to get the relevant feedback on such issues, as
Universal Acceptance is one of the objectives for this task force. 

We have a few members from the task force signed on this list but I can
assist coordinating with TF-AIDN, in case there are specific queries from
this group.  

Regards,
Sarmad

From: ua-discuss-bounces at icann.org [mailto:ua-discuss-bounces at icann.org] On
Behalf Of Mark Svancarek
Sent: Saturday, February 21, 2015 12:05 AM
To: ua-discuss at icann.org
Subject: [UA-discuss] Regarding "RTL"

Hi, I had some questions regarding my recent usage of the term “RTL”.  By
this I mean “right to left”, a characteristic of Arabic and Hebrew.  At
Microsoft we also call this “bidi” (bidirectional).

Here’s a discussion regarding RTL.  (I’ve also attached a much more detailed
explanation, which includes Microsoft’s recommendations, but it’s in
PowerPoint.  Hopefully you already use a compatible viewer.)

Bidi display of IRIs (URLs/URIs)

Bidirectional display of IRIs (an IRI with some Right-To-Left characters,
eg: Arabic) has some odd quirks.  There’s an IETF WG working on creating an
IRI RFC.  It’d be nice if we could help ensure that there were reasonable
standards for the display of bidi IRIs.  The existing IRI drafts suggest
using the Unicode Bidi Algorithm to display IRIs, but that has some
problems.

User and government feedback indicates that our current behavior is a bit
unexpected.  Currently we have some odd quirks about the display of Bidi
IRIs in Microsoft.  This is just an example, other places may have different
odd quirks.

Logical Order

IE with LTR context

IE with RTL context

http://www.microsoft.com

http://www.microsoft.com

 <http://www.microsoft.com> http://www.microsoft.com

http:// <http://اا1اا.بب2بب.ةة3ةة> اا1اا.بب2بب.ةة3ةة

http:// <http://اا1اا.بب2بب.ةة3ةة> اا1اا.بب2بب.ةة3ةة

 <http://اا1اا.بب2بب.ةة3ةة> http://اا1اا.بب2بب.ةة3ةة

http://a1a. <http://a1a.اا2اا.بب3بب.d4d> اا2اا.بب3بب.d4d

 <http://a1a.اا2اا.بب3بب.d4d> http://a1a.اا2اا.بب3بب.d4d

http:// <http://اا1اا.b2b.c3c.بب4بب> اا1اا.b2b.c3c.بب4بب

http:// <http://اا1اا.b2b.c3c.بب4بب> اا1اا.b2b.c3c.بب4بب

 <http://اا1اا.b2b.c3c.بب4بب> http://اا1اا.b2b.c3c.بب4بب

As we can see, the order of some of the elements may seem counter-intuitive.
The highlighted sections start in one direction, but then jump or rearrange
direction so that the elements don’t follow the same order. 

The Unicode Bidi algorithm has the idea that some characters aren’t
inherently RTL or LTR.  Instead they take on the properties of the
characters surrounding them.  This is why some pairs get “flipped” in the
rendered order.

User Expectations

Limited usability investigations have demonstrated that users expect IRIs
and other paths to be in the form of an ordered list.  The “separators” of
the various fields vary, but the entire unit is treated as a list.  E.g.:
http://www.microsoft.com is a list { “http”, “www”, “microsoft”, “com” }.
Users expect it to be rendered “in order” with the first element, then
second, etc.

What is a bit unclear is exactly which direction the users expect the lists
to be rendered in.  There seem to be 2 main options for what users expect:

*         Always render the path elements from Left to Right (e.g.
“www.microsoft.com <http://www.microsoft.com> ”) regardless of the script.

*         Always render the path elements from Right to Left in a Bidi
context (application), e.g.: “com.microsoft.www//:http”, EVEN FOR ASCII
IRIs.  

We need to confirm what the user expectations are for Bidi Display, and
ensure that any edits to IETF IRI standards match those expectations. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/mailman/private/ua-discuss/attachments/20150221/7d11524c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5118 bytes
Desc: not available
URL: <https://mm.icann.org/mailman/private/ua-discuss/attachments/20150221/7d11524c/smime.p7s>