Re: Bidi issues

Hello Roy,

At 16:34 03/08/07 +0100, Roy Badami wrote:

>  > Arabic domain names, they always did it as MOC.BARA.BEW
>  > (inverting not only each component of web.arab.com, but
>  > also the order of the labels) rather than BEW.BARA.MOC
>  > (just inverting the labels internally).
>
>Just some very quick thoughs
>
>But as I understand the bidi algorithm (and I don't really claim to
>understand bidi, so please correct me if I'm wrong) although
>WEB.ARAB.com will render sensibly in a RTL context:
>
>com.BARA.BEW
>
>It will render weirdly in a LTR context:
>
>BARA.BEW.com (with the labels in the wrong order).

Well, the question is which order is the right one.
In an LTR context, BARA.BEW.com is obviously better.
In an RTL context, you are right that WEB.ARAB.com
is probably better. Now the problem of course is
that we can't have it both ways.

Now take another example, www.BARA.com. This again in
an LTR context looks better as www.BARA.com; in an RTL
context, it will look better as com.BARA.www.
To some extent, the more LTR pieces you have, the better
it looks in LTR context, and the more RTL pieces you have,
the better it will look in RTL context. But judgement is
difficult, and creating an algorithm that counts pieces,...
would be too complex. So we took LTR as a base, rather
than RTL.



>And the domain WEB.ARAB.foo.com won't render sensibly in either context
>
>LTR: BARA.BEW.foo.com
>RTL: foo.com.BARA.BEW

If you know that periods are special, and read each label
independently, then you are right. But the feedback we got
is that people not familiar with domain names or URIs
won't necessarily know that. For people who don't know
that, they probably always read 'foo.com' LTR, and
'BARA.BEW' RTL.


>So you need something more than just the bidi algorithm to display
>mixed LTR/RTL domains sensibly.  ie the UI needs to know to display
>the labels in order from least significant to most significant (in the
>users prefered writing direction).

There is no place here for "user's preferred writing direction".
If we put something on the side of a bus, or on a name card,
the user's preferred writing direction is lost.


>It's easy to do this by getting the UI to insert suitable embedding
>codes prior to rendering; I'm sure this was discussed on the IDN list,
>but I haven't had time to refer back to it.

I'm not sure it was discussed on the IDN list. The IDN list mainly
cared about getting a predictable display for single labels.
It was the solution originally proposed for IRIs.


>I'm not sure the same issues really occur with local parts, though,
>since separators only have local significance.  There isn't really any
>global 'right' order in which to display the segments of a local part,
>since the very notion of segments is internal to IMAA.

That's a statement that makes sense to somebody understanding the
specs in detail. What we have to care about is the end users.


Regards,    Martin.

Received on Thursday, 7 August 2003 16:17:28 UTC