Right-to-left-language-induced GUI bugs | Hacker News Reader

Right-to-left-language-induced GUI bugs

twitter.com

69 pointsjan_Inkepa24 comments

The fact that Arabic letters work at all on modern computers is pretty amazing. In addition to the fact that Arabic letters connect to each other (and so they look different in isolation versus connected), Arabic letters change slightly in look depending on what is next to them: they have similar but distinct forms depending on whether the letter is in the initial, medial, or final position of the word chunk (I say "chunk" because most letters connect to the next letter, but some do not). When writing, you usually know what word you're trying to write, so you mentally "compose" the positions of each letter before writing. But when typing, the computer cannot know that, so the letter forms are constantly changing on-the-fly as you type. The program is constantly looking at what was just typed, and whether it then needs to go back and modify the previous letter to link properly.

How is that technically more difficult than the program moving a half written word to a new line if you exceed the maximum line length?

I had never really considered RTL design until I decided on a whim to support Arabic in an app [1], and before doing so I would have easily laughed at this. After doing so, I can completely understand it. It seems so simple—text just goes from right to left instead of left to right, but truly grokking that seems impossible for me. It's like riding a bike with the handlebars backwards [2]—it just doesn't work in your brain, as much as your higher-level thoughts seem to understand it. I was lucky that Flutter did almost all of the heavy lifting for me, but I spent more time than I'd like to admit ironing things out and I still don't think it's quite right.

[1] https://github.com/hamaluik/timecop [2] https://www.youtube.com/watch?v=oI2aMKwXXnE

First of all, thank you very much for translating the app to Arabic. There is a huge lack of good apps in Arabic.

But I went to your website, timecop.app, and the Arabic is disastrous. Even the name of the app is translated wrong. I didn't download the app because it costs money and I don't really need it, but from what I saw (Name and feature list), the Arabic needs a lot of work.

Thanks for checking it out! For the most part, the translations are all automatic via Google Translate—I only speak English and “cereal box French”. I know the quality of some translations are terrible, but for me it was more an exercise and learning experience in localization (for example I never would have learned about my inability to think in right-to-left had I not auto-translated to Arabic).

The app hasn't made anywhere near enough money to warrant paying professional translators to translate things, but if you know anyone who wants to contribute, I'd happily take a pull request at [1]—I've already had people submit an Italian translation, and fixes for Russian and Japanese.

[1] https://github.com/hamaluik/timecop

This is only tangentially related, but for some string handling code that needed to work on unicode, I wrote a property based test that used the Hebrew alphabet.

Trying to reason about a failing test case using string indexes when the printed text is RTL was humbling.

For me an interesting part of this (other than slapstick value) that these are all web-apps. In previous eras (Delphi, say), you had IIRC total separation between “interface direction” and writing direction in labels/fields+, but they’re a lot more coupled now that most apps are really just html documents behind the scenes.

I don't know of any UI frameworks that deal with GUI in a reliably writing-direction-agnostic way (RTL,LTR,TTB,BTT) that would allow for easy localisation of text and layout. In principle it should be possible in CSS I think, but I'm unaware of any guidelines for this - anyone here have any pointers?

+ which is also maybe a bug - often it seems you want the interface to be mirrored between RTL and LTR apps.

GTK+

Thanks to Behdad Esfahbod, it had very reliable layouting for exotic scripts since 2.0 times

Ah, cool - thanks for the reference!

I found one talk from 15 years ago where he goes into detail about it, for anyone who's interested - http://behdad.org/download/Presentations/bidi-layouts/

Pango is a jewel of the free software world.

Some good info on that from an article a few days ago can be found here: https://news.ycombinator.com/item?id=22967701. The new CSS logical properties[0] are a great asset that will make handling many considerations a bit easier.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical...

The Apple GUI frameworks (AppKit, UIKit) have supported automatic LTR/RTL of GUI layouts since at least 10.7 (2010). The basic view anchors are 'top', 'bottom', 'leading', and 'trailing'. 'Left' and 'right' are also available, when the physical direction is needed, but rarely used.

If doing stuff for the web, and happen to be using Vue.js, Vuetify has good support for RTL languages:

https://vuetifyjs.com/en/customization/rtl/

They have some nicely detailed docs! Thanks :)

Making usable interfaces that work in a single directions is really hard. Making them work in both is much much harder.

The bugs might be funny, but I have great respect for the programmers trying to make their applications more accessible, be it for right-to-left languages or otherwise.

(I wrote the linked tweets.)

Safari's scroll snapping doesn't work in RTL at all. This industry is quite something.

I wonder why this issue isn't raised more often if it's the reality for millions of users of RTL-written languages. Or do most of them switch the language of web apps to English anyway? (I do - not because of bugs, but because of missing features)

I expect they mostly use websites for their language rather than international ones.

As an user of a language with diacritics back in the 2000s, I certainly switched to English whenever I saw broken encodings.

I can only imagine the incentive must be greater if a site is actively broken or unusable.

At least here in Morocco a lot of people make up transliterations into the Latin alphabet on the spot and those are read RTL.

All major application platforms have decent support for RTL, but more often than not it's up to a developer to use the built-in tools (or develop new ones if they had chosen to use a non-standard UI implementation). It might seem that supporting RTL is as easy as flipping a switch and calling it a day, but it's really not. Developers have to invest resources into supporting foreign (from their point of view) layouts.

Interestingly, the issue seems to be similar to that of missing accessibility features. I believe the reason here is the same — if you don't expect many users who would make use of the feature, it gets overlooked.

Power structures! At least in my country, most (good) developers are more comfortable in English, because English is the way to economic success (thanks colonialism). These people are not really interested in doing the hard work necessary to fix the many RTL bugs present in various programs.

For my language, Urdu, the web is far more broken than for Arabic. RTL fonts used on most major websites are adequate for Arabic, but not for Urdu, because the Urdu script contains additonal characters that Arabic script does not have. Moreover, Arabic fonts are in the Naksh calligraphic style, while Urdu speakers are more comfortable with the Nastaliq calligraphic style.

I personally use Greasemonkey to force Nastaliq fonts for RTL content on various major websites.

Someone should show this guy apps or websites that use traditional Mongolian writing, which is written in vertical lines:

https://president.mn/mng/

if anyone is interested, I made a thing that tracks (among many other things) RTL support in various frontend frameworks

https://react-ui-roundup.dimitrimitropoulos.com/

github: https://github.com/dimitropoulos/react-ui-roundup

Reply on news.ycombinator.com