Comment 35 for bug 2002290

Hi M.Hanny,

Thanks a lot for spreading the word about BiDi support in VTE!

Really no need to apologize about your English! I'm not a native English speaker either, and your English is at least as good as mine. We have no communication issues at all!

---

> Ideally, there shouldn't be a text in other languages when the system language is set to Arabic. E.g the output of "apt" should be fully translated to Arabic [...] This is a very long journey and it may take many years until we reach that point.

I disagree with you in this point. There will always be English text in the output of "apt", such as package names, I don't think they will ever be translatable (and would arguably be a mistake to go in this direction). For rapidly changing data, such as package descriptions, it's practically impossible for all translations to be fully up-to-date all the time. Think of software like dmesg printing system logs, software printing hardware information (such as identification strings of various components), think of software showing system directories' and files' names etc. Think of commands that print whois data, show a mysql table along with the column names, show source code etc. Think of ssh'ing to a remote host. Think of the long tail of utilities you find on the web that someone quickly hacked together but there's no demand to get translated to languages other than English.

Although not relevant to the world of terminal emulation, I've just checked the completeness of the Arabic translation of the GNOME desktop at https://l10n.gnome.org/teams/ar/, and it's very very far from being fully green.

You'll never have a terminal emulation experience that is fully in a foreign (I mean non-English, not necessarily RTL) language, for two reasons. One is that due to the very nature of things there'll always be tons of English stuff in the terminal, the second is that it's a utopic and reasonably unreachable dream to have all software's UI strings be fully translated to all languages. A 100% fully Japanese, or fully Hungarian, or fully Arabic experience in terminal emulators, no English word whatsoever, is neither "ideal" nor in my opinion is reachable in our lives.

> However, in order to get there, we need to start somewhere. [...] this could open the door for a wide range of CLI-based computing for RTL languages speakers [...]

I agree with this one, and I hope I could make an important step here.

> The political factor is also important. I don't want to talk about politics here of course

I don't want to talk about politics either. My work was driven by getting closer to equality for people, no matter if I agree or disagree with certain things they do; as well as by the technical challenge itself. That being said, you raised excellent points here.

> The dominant majority of Arabic users at least are using English as a system-wide language. When I made polls asking them why, they say that there are many bugs and problems in Arabic support in general on Linux [...]

I fully understand this.

Prior to my work, nobody had an idea how to do BiDi in terminals, nobody saw the whole picture. As I show in my document, everyone who thought they knew how to do it made fundamental mistakes, proving that they only saw a fraction of the story -- except for ECMA TR/53 which at least saw the big picture correctly, but that one also made big mistakes elsewhere, and is an old piece of work preceding the UBA, not suitable for straight adoptation. I believe my work is the first and only one so far that shows how BiDi can actually be done in terminals in a way that it really works. But again, it's not a magic wand solution for all the problems, it's a platform for app developers to build upon.

Funny story, perfectly rhyming with what you experienced here, and maybe pushing it a little bit further. I gained my BiDi knowledge and experience in 2009-2010 when for half a year I worked on porting the (now discontinued) iGoogle webpage to RTL. Those days Internet Explorer 6 was the market leader, IE7 was gaining some popularity, and IE8 was brand new. IE6, as we all know, was a terrible browser. But when you tried to do RTL in it, it was even magnitudes worse! IE7 was significantly better, but nowhere near perfect when it came to RTL. In IE8 I could not find a single RTL bug. (In all cases: asking the browser to use its latest rendering engine, rather than some compatibility mode.) Working around the IE6 RTL layout issues (and even crashes!) took a whole lot of development effort. IE7 caused less pain. With IE8 there was no pain at all (apart from the necessary migration and layout fixes as we asked the browser to use its new rendering engine rather than compat mode). At one point I suggested that we just add a banner asking RTL users to upgrade to IE8, saving us tons of development effort. The idea was rejected because market share of IE6 was even bigger in RTL areas than at the rest of the world. Why? Because RTL in IE6 was so bad that every webpage had to apply so many workarounds that due to these workarounds they did not show up correctly in IE7 and IE8, so users were heavily reluctant to upgrade. Having to be compatible with old, broken browsers all around the RTL world was a giant obstacle in the adoption of the new, vastly improved technology.

I can easily imagine something similar to happen in the world of RTL + terminals, too. Some apps might now look correctly in RTL in certain terminals, but not in VTE. Fixing the look in VTE might break the look in those terminals. How to convince app developers to focus on VTE? How to make them understand that VTE is the one that is good enough to satisfy the needs of all applications, whereas other terminals can only satisfy the needs of a subset of apps, therefore to pick VTE as the reference? Given that the whole topic is extremely complex, very few people understand all the aspects; and to make things worse, the BiDi recommendation was written by a guy (me) who is neither a good technical writer nor is a native English speaker, so the work surely doesn't _look_ as appealing as it should? Tough call.

So much about the "philosophical" bits for now. I'll continue (in a few days) with the technical aspects (autodetection, alignment etc.).