Comment 33 for bug 2002290

Revision history for this message
M.Hanny Sabbagh (mhsabbagh) wrote (last edit ):

@Egmont:

Thank you for the valuable feedback.

First I would like to ask you to forgive me if some of my words are not clear or vague; I am not a native English speaker so it is a little bit hard when I write long responses like this. I hope I am correctly delivering my ideas to you and others.

I just would like to confirm again that my proposal is related to changing the default text behavior in VTE *only for Arabic/RTL-based languages*. Languages like Arabic, Persian, Urdu, Hebrew... etc and only these. Other users of English, French, Italian and other languages do not need to endure this change (because they do not need autodetection or RTL text).

Hence, we are talking about a change that would not affect 95% of the user base.

I understand your concern and that we may still need to do further testing. And I will work on providing more test cases for various applications. Still, I wholeheartedly believe that any Arabic/RTL user would be quite happy with this proposed change because it makes the RTL text rendering so much better regardless of the application, terminal emulator or Linux distribution used. (I will provide more of these examples).

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, and the interface text for "nano" should be translated too, which ultimately should result in a much better UX for Arabic users. That is, the entire command line interface be translated to Arabic and supportive of RTL text. Everything from Python/C/Rush syntax errors or outputs, all the way up to tools like apt, nano, vi or emacs. This is a very long journey and it may take many years until we reach that point.

However, in order to get there, we need to start somewhere. One of the main reasons perhaps why no Arabic users provided feedback all these years is that Arabic or RTL support needs a huge investment in terms of effort to make it feasible for the end user. And so far no one stepped up to do that effort. We need efforts in both the fields of translation + RTL support to make this happen. Sadly, we are missing on both.

I believe if we succeed in supporting RTL applications in the terminal and fixing the bugs we are currently facing, then this could open the door for a wide range of CLI-based computing for RTL languages speakers. We could have command line tools that fully support these languages (even RTL TUIs!), instead of just English as we have today. We could finally print correctly formatted Python error messages in Arabic instead of being afraid to translate it; because we know it wouldn't render correctly in the LTR terminal.

I want to add a few additional reasons on why feedback is small regarding your work on RTL:

- I honestly didn't hear about it although I am invested in Linux and open source software for 13 years in the Arabic Linux communities. I was surprised to know that RTL support is already there in VTE. I think that I came across a social media post once that talks about it in 2020, but because of Coronavirus and how all of our lives were missed up, I just couldn't give it enough attention at that time.
- The political factor is also important. I don't want to talk about politics here of course, but currently, all RTL-speaking nations are in chaos; the middle east is full of wars and issues (Arabic), and the people of Iran (Persian) have their issues too. Afghanistan/Pakistan both have their problems as well with the recent events (Urdu), Israel (Hebrew)... And so on. In such circumstances, the interest in open source software or Linux, yet in terminal-based applications, or even more in bugs related to text rendering (RTL) in the terminal, would be quite small and considered to be luxurious for most people. The open source userbase from these countries in general is already small, so it's rare to find someone capable of following these topics and providing further feedback. I am writing this reply to you from Turkey, where 40K people were killed last week in the earthquake that happened (also in Syria). So overall, nothing is stable in these lands, including the land itself.
- 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, so they just give up on the whole thing and decide to use English everywhere, although it is not their main language. (For such users btw, our proposal does not affect them).
- I would like to repeat the fact that the Arabic/RTL-based languages user base is quite small; I rarely see someone using Linux here (other than developers). Most people use Windows or macOS just like everywhere. However, if we wanted to promote Linux more in these communities, then we need to make sure that there are no blocking bugs or issues related to Arabic with open source software. And the terminal/VTE is one of the most important areas for this.

I have provided attached images that show the outputs of "cat" and "nano" with autodetect/LTR modes. I can clearly say that no Arabic user would ever consider using any Arabic terminal application at all if the mode is set to LTR. Mainly because you can not even comprehend how the text is read if you are trying to read it in LTR.

A small thing to also perhaps think about: Most terminal emulators start in 80x24 size (columns and rows), so the space difference while using autodetect will not be an issue even when there are some lines that start with a non-RTL text (e.g some untranslated strings like in "apt").

I will provide more examples in the future (few days!), but this is just what I had to say and provide currently in my limited time.

Thank you again Egmont for the help and feedback! I am already spreading the word about VTE and the BiDi support in it in our local Linux communities, and many of my developers friends are considering to use it in their CLI applications.