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 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.). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2002290 Title: Poor Arabic rendering in VTE Status in gnome-terminal package in Ubuntu: Fix Released Status in vte2.91 package in Ubuntu: New Bug description: VTE has a number of issues when it comes to rendering Arabic letters in the terminal, which could affect a number of languages (Arabic, Urdu, Persian... etc). Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed with spaces between its letters, making readability hard and sometimes not possible. Sometimes the letters are crushed together very closely making reading impossible too. Bug 2: If a non-Arabic text and an Arabic text are displayed together in the same line, then the entire line will be missed up and you won't be able to understand what is being said. Both of these bugs can be seen from the image I attached. I reported both of these bugs together because it's unlikely they can be fixed separately, probably they are related to each other. Problem can be seen in any VTE-based terminal. Here I am using GNOME Terminal 3.44.0 on Ubuntu 22.04, but it can be seen in any Ubuntu version and in any terminal version as well (it has been there since forever). I reported the bug here instead of upstream because that's what they said at the page: https://wiki.gnome.org/Apps/Terminal/ReportingBugs, but this bug is not related to Ubuntu only; it happens on all Linux distributions. Happy to provide any information you need, or any do tests or experiments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2002290/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
