RTL: WTF: Read the web like Right-to-Left readers do | Hacker News Reader

RTL: WTF: Read the web like Right-to-Left readers do

rtl.wtf

62 pointsrobin_reala52 comments

RTL language users expect everything, not just the text, to be mirrored. But is that a neccessity or just a weird convention due to path dependence? Cars aren't right hand drive in arabic speaking countries, things like scissors are still made predominantly for right handed people. The cursor keys are on the right hand side of the keyboard, and so on. Why would you swap the navigation of a website from the left to the right side, or the window controls on Windows from the right to the left? Where "we" English speakers put these things is arbitrary, too. It's more related to the position of the mouse hand than the reading direction, if anything.

Personally, I think the convention to flip almost everything is due to old technological constraints. In old windows versions, there was no primary support for right-to-left. Instead, you had a "mirrored" arabic font, you would draw to the window as usual (without changing coordinates), and then mirror the whole window [1]. That is why the highlights on buttons seem to come from the top right on RTL windows! Some things like the folder icons or pictures are mirrored again so they have the correct orientation.

[1]: https://docs.microsoft.com/en-us/globalization/localizabilit...

Actually, yes, some semantic flipping is important. For example, when conveying a direction, in a right-to-left language, it should be flipped (the earliest step being on the right-most, while the latest step being on the left-most). Conveying a “go back” symbol, it would also have to be flipped.

Almost all interfaces use a flow-like layout model, “anchoring” components to some corner of the window or a parent component, and finding the first available space after laying out previous components. This is a model that works well with how we look at things.

Users of left-to-right, top-to-bottom languages are used to starting in the top left corner and heading right and down: that’s where our eyes naturally go, and how we interact with books and such. So in user interfaces, we anchor most things to the top left corner.

Users of right-to-left, top-to-bottom languages are used to starting in the top right corner and heading left and down. So it makes sense for RTL user interfaces to anchor things to the top right corner in the same way and progress leftwards.

User interfaces are largely built to match how eyes scan, because there’s not a huge difference between reading and writing prose, and reading and interacting with user interfaces.

(I’d say your cars comparison is not relevant; there’s very little inherent reason to prefer one side to the other. Scissors are only a smidgeon more relevant, being based on predominant handedness, and LTR is probably more popular than RTL for similar reasons, RTL being harder to ink cleanly if you’re right-handed.)

Cars are a weird example: they’re right-hand drive for well over two billion people, regardless of LTR or RTL text.

I don't think that Arabic users all require that all the controls be flipped. It's mainly the text that needs to be right-to-left, plus a couple of other things.

Counter-intuitively, it may well be easier to implement mirroring all the controls than it would be to implement mirroring only where it is really needed.

I've seen examples from translated schoolbooks where they replaced the text on the mirrored page. That must have led to some weird geography classes.

It's not a requirement in theory, but how text aligns with the elements around it is massively important for usability. When you flip text, without flipping the layout and surrounding elements, it almost always becomes less useable as the text was originally designed with certain alignments in mind that no longer occur.

Also, speaking as a frontend engineer, it's usually much easier to flip everything as not doing so also increases the chance of weird text alignment/wrapping & overlap bugs.

Consider a horizontal navigation bar with these links from left to right: Privacy Policy, Gallery, Directions and Contact Info, Our Products and Services and finally Home. The most important, relevant links are presented "last" and are hard to find. This would be the experience of a RTL user if you only swapped in translations and did not mirror

RTL language users expect that reading will be done in RTL, not that everything will be done RTL. Scissors are the way they are because most people have stronger right hands than left hands, and that applies regardless of native or preferred language. The cursor keys are likely on the right for the same reason.

Website navigation is presumably derived from reading - if you generally read RTL, then your eyes will start at the top right of the screen/page and scan to the left. Where it gets interesting is on small touch screens like phones. Perhaps we ought to optimize that for single-hand use and put the hamburger menu icon on the right side to make it easier to reach with your thumb when in your right hand, regardless of language orientation.

In any case, my experience is that in a lot of RTL software[0] navigation is flipped, and the "previous/next page" arrows are reversed as well. But in meatspace this is less practical so at least in Israel, the play/forward/rewind buttons on old tape recorders (for example) will be with a LTR orientation. I suspect that if Israel was manufacturing their own music players a few decades ago things might look different today.

Now imagine you work at Spotify and you need to decide how to display the play/skip/previous controls in RTL. Do you mimic normal RTL forward/back and reverse the controls or go for skeumorphism and use the same controls your users already know?

[0] Locally made software such as yad2.co.il is more likely to do this because it's RTL-first. Google doesn't flip their pagination, possibly because they use the 'o's in their logo to link to to page numbers and they don't translate or reverse their logo. Bing does reverse the pagination. DDG sidesteps the problem by having a "Load more" button.

> Cars aren't right hand drive in arabic speaking countries, things like scissors are still made predominantly for right handed people. The cursor keys are on the right hand side of the keyboard, and so on.

None of these deal with text alignment problems, I guess.

> Why would you swap the navigation of a website from the left to the right side

Because text with alignment is part of the UI; perhaps it’s better if the text flow and UI flow match.

> Personally, I think the convention to flip almost everything is due to old technological constraints.

This could be easy to verify. E.g.: are there newspapers that predate Windows, where text is RTL but other layout elements flow from left to right?

.ecneirepxe tfel-ot-thgir ,reporp a etamixorppa ot siht ekil yalpsid ot txet deen dluow uoy ,noinipo ym n'I

Surprisingly readable

איבן בטר, וואי נוט רייט איט אין אה פרופר רייט טו לפט לנגואג׳?

Because then the site would not demonstrate the pain caused by poor RTL support, as most of its target audience will not be able to make sense of the script.

The point is that even when you understand the script and the language, you find yourself looking at a website with messed up formatting, punctuation in the wrong place, and broken sentences when BiDi gets involved. Those of us who deal with this all the time are used to it, but most people have no idea how broken things are.

Except that what this site is demonstrating isn’t so much “right-to-left” as “the pain users of right-to-left languages experience when you implement things badly, especially with regards to BiDi problems”.

Not sure I understand how it demonstrates BiDi problems.

The real BiDi problems come when you got a context of LTR in RTL.

For example:

אני חושב שזה cool לכתוב מילה באנגלית.

This is where things goes wrong. And we didn't even start with text selection...

The site demonstrates the problems in two ways:

① Setting `text-align: right` so that you can feel the weirdness that `text-align: left` will produce for RTL languages.

② And for BiDi: setting `direction: rtl`, and using a mixture of strong LTR characters (e.g. letters) and neutral characters (e.g. punctuation). This combination results in the neutral characters going RTL, which is why you end up with things like “.solve them” and “→ ?What is this” rather than “solve them.” and “What is this? →”.

It’s demonstrating things that are commonly done wrong the other way (when the document says it’s LTR, but contains RTL text).

It's not the homepage but the site has an entire article on the exactly this.

https://rtl.wtf/explained/bidiintro.html

I think all West Asian scripts are is right-to-left, then top-to-bottom. I think Japanese/Chinese scripts can be top-to-bottom, then right-to-left, but may vary. I don't think there's are any bottom-to-top?

> I don't think there's are any bottom-to-top?

There are philipino and indonesian scripts which ars written bottom-to-top, though they are read left to right.

Ogham is bottom to to though.

I think there’s also a script which is read and written based on cardinal directions, but i can’t find it. I was expecting it to be indigenous australian (as several IA people use absolute directions as a matter of course).

That's really fascinating. Thanks for sharing

What exactly due you mean by "West Asian"? Georgian and Armenian are left-to-right.

I was painting with too broad a brush. Of course it's not all languages across that region

.pot ot mottob morf ti daer ot evah ouy taht si hgouht sdrawkcab gnitirw htiw melborp ehT .ti edulcni dna kcabdeef ruoy etaroprocni lliw srenwo etis eht ebyaM .dnif ot gnipoh saw I pilf niarb eht saw sihT.

nah, if you use `unicode-bidi: bidi-override` and force `direction: rtl` it'll still flow top to bottom. a conlang I speak is cursive RTL so I've made extensive use of this. side-note: it's a major peeve of mine that Unicode's entire Private Use Area is plain Latin in terms of properties. there's no way of setting RTL other than using CSS or prefixing an RTL Override character, which gets old fast in text editors. no font system, including Graphite, lets you override Unicode glyph properties to my knowledge.

The problem is that the site does not even render all the errors.

From the site:

> Arabic is Right-to-Left. There are about 19 Arabic-speaking

> countries in the world with combined population close

> to 350 million speakers.

What happens in practice:

> Arabic-speaking 19 Arabic is Right-to-Left. There are about

> countries in the world with combined population close

> million speakers. 350 to

I don't get it. Why is the punctuation right to left, but the text itself is left to right?

Part of the joke. It's a common error when the RTL text isn't configured correctly.

It’s not a joke, that’s the whole point of the exercise. Showing you “when you get it wrong, RTL content experiences weirdness like this”.

Yeah, that part struck me as odd as well.

How about top-to-bottom text?

Example: website of the President of Mongolia: https://president.mn/mng/

Interesting example, had no idea what to expect when I clicked.

FWIW, Mongolian is normally written using Cyrillic alphabet these days, which you can see in practice if you remove /mng/ from that URL: https://president.mn/

The old script is a very interesting test case, though. Since it's an alphabet, and it has varying letter shapes for different positions, as well as ligatures, it has all the same complexities as Western scripts - but then it's vertical on top of that. Few software can handle that well.

Unfortunately, that site does scrolljacking, and takes over all scroll actions rather than just vertical ones, completely ruining scrolling on what I think will be basically all laptop touchpads these days (ancient laptops with coarse touchpad scrolling might be less badly affected).

Precise symptoms vary by browser; in Firefox you’re likely to just get jumped from one end to the other very quickly (because it lets the JavaScript take over, and the JavaScript ignores the scrolling delta and jumps by a fixed amount on each event), while in Chromium horizontal scrolling doesn’t get destroyed quite so much, it just becomes flickery, because Chromium lets the JavaScript change the scroll position (turning your 1px scroll into a big jump) and then changes it back, apparently. I haven’t investigated why.

I consistently say that scrolljacking is always bad, because it’s simply not possible to get it right (the web doesn’t expose the right primitives to make it work). This is one of the exceptionally few cases where carefully limited scrolljacking of vertical scrolling to horizontal might be warranted (though it’d still be severely imperfect because the web doesn’t have the right primitives to make it work properly), because of comparatively poor support for this text direction on some devices, but the implementation employed is awful, making it work tolerably for old coarse-scrolling mice while ruining it for newer hardware.

Weird, horizontal scrolling works completely smoothly and as expected for me on Firefox on Windows. I tried:

* Two-finger scroll on my touchpad, moving horizontally

* Middle clicking with the mouse so the scrolly icon thing comes up (it shows as a left-right icon rather than the normal up-down one) and then gently moving the mouse left and right

I’m on Linux. This stuff is notoriously fiddly and inconsistent across platforms. I think the relevant code is https://president.mn/mng/wp-content/themes/president/fronten...; at a five-second glance, it’s not doing any sort of sniffing, so it’s most likely the events being passed around are simply different in some way. And that kinda demonstrates why it’s such a dangerous thing to fiddle with, and why scrolljacking is a bad idea. Looks like it might be trying to ignore horizontal scrolling. Dunno what’s happening with it.

Firefox/Linux here and it works fine for me? It scrolls horizontally which I assume is the expected behaviour.

I just pulled out an old laptop, still Arch Linux, but i3 (X) rather than Sway (Wayland), and only Firefox 65 just yet because I haven’t done the two years’ worth of updates since I last touched it (think I did two years’ worth of updates that time too!). It has a coarse-scrolling touchpad and uses the syntaptics driver. Vertical scrolling doesn’t scroll smoothly or by the right amounts, but generally works. Horizontal scrolling is more or less just completely broken except at high speeds: it scrolls rightwards for a bit, and then jumps to the left by a sizeable chunk, so if you’re scrolling too slowly you’ll end up behind where you even started.

(Upgraded to 89, symptoms are the same, or possibly even worse on horizontal scrolling, but I can’t compare it any more because downgrading is more trouble than it’s worth. And also I broke something as part of the two-years-of-upgrades jump and it won’t boot for now. First time I’ve managed that: achievement unlocked! :-) )

Vertical and horizontal scroll is working totally fine for me. Edge/Macos. I tried with the in-built touchpad and an external mouse with a scroll wheel.

I ... think you just broke the website of the President of Mongolia by posting it here.

Wow, thnx for the link.

Wow. That absolutely breaks my speed-reading practice. Did not expect that. Reading it feels like wading through molasses.

It's good, but to really feel the kick, one needs RTL menus, navigation bars, forms, etc. That's where spatial habits really break.

Fun fact: classical Chinese were written top-to-down, right-to-left order.

I wonder what UI design would be like for that.

Modern Japanese are still written that way. There are several apps/editors that support that writing mode because it's one of the requirements in the publishing industry in Japan.

More precisely, newspapers, most books (except technical/scientific ones) and magazines are written in the vertical form. Comics too. Business documents are typically all horizontal.

Also they have a uber-complex w3c standard (draft) to support this system: https://w3c.github.io/jlreq/#vertical_writing_mode_and_horiz...

One thing I wonder is that I saw several vertical Japanese writings in the web (TtB inline, RTL block) but virtually no vertical UIs. I believe there is not much technical difference between two. I'm not a native Japanese speaker so my experience might be not representative though.

I just find it fascinating that a language can be fluid in the direction of reading.

> Fun fact: classical Chinese were written top-to-down, right-to-left order.

Why past tense? Traditional Chinese is still written this way in Taiwan and I think to a degree Hong Kong. I purchased a copy of Three-Body Problem typeset this way while staying in Taiwan three or so years ago.

Relatedly, the TB-RL[0] system leads to some fun confusing cases for beginner learners, where in the city you may see signs for cafes or restaurants with text apparently written horizontally, but backwards. In fact, it’s just like the vertical signs on sides of buildings in the US, but in this case the sign uses TB-RL: each letter is on a new line, and lines go right to left.

[0] Top-to-bottom, right-to-left.

For me, Wikipedia was my first realization that RTL webpages exist. If you switch to an Arabic or Hebrew article you'll see what I mean. Even the Wikipedia globe graphic goes to the top right instead of the top left.

I don't know any of the languages so I don't know if the problems presented here apply to Wikipedia but it's a cool demonstration regardless.

What I do in my Debian machines is flip horizontally each display on xfce startup, and then flip the trackball x-axis.

Everything comes out nicely right to left.

As a RTL reader I can confirm I'm used to this. I did not find the web page strange

Right to left readers do not read right-adjusted text left-to-right, so this site makes no sense. It introduces a strawman awkwardness which doesn't exist in true right to left text.

Reply on news.ycombinator.com