UI doesn't support RTL

[yasmineyoussef]

The problem is related to the UI rendering of Arabic text, not the content itself. This is related to localization strings. The interface does not properly switch to RTL layout when Arabic is used. The issue becomes more noticeable when a string contains both Arabic and English terms — the text direction gets flipped, making it harder to read. For example, if one string ends with an English term, the string will start with the English followed by the Arabic text.

[danielweck]

Hello, I have moved the issue to a "discussion" so that we can break down the problem into actionable parts (i.e. so we can assign actual development tasks in order to iteratively fix the broader problem).
Could you please provide screenshots of specific areas of the application where the text is incorrectly laid in the user interface?
Thank you very much!

[danielweck]

Thank you very much! :)
As these are "native" labels in Thorium the bugs should be easy to fix (when the strings come from publication metadata there can be problems with identifying the locale / language script).

[danielweck]

So, I tried applying the HTML dir="rtl" on the body element of the "library" and "reader" windows, and although this brings some improvements to individual displayed labels, it also destroys Thorium's layout significantly, and we actually need much more detailed guidance on how to mirror (or not) some GUI controls such as the scrollbars which become left-aligned.

In the immediate term I think that the safe / least destructive solution is to target individual paragraphs or sentences in the GUI, to make sure they are all dir="rtl" (or CSS direction: rtl). This is a one-by-one process that will take time, but I think that we might be able to apply RTL direction on a parent container of the whole popup dialog window, for example. Just high enough in the component hierarchy to work for all the labels and GUI controls (which will be reversed on the horizontal axis), but low enough in the tree to avoid disturbing other layouts in Radix and ReactAriaComponents.
Then, we need to figure-out a way to iteratively implement and test the changes. I propose a long-lived Pull Request with automatic builds with a special title, like latest-macos-arm-RTL instead of latest-macos-arm.

[danielweck]

@arthur-lemeur obviously we want to limit the impact on the existing stylesheets, but there might be changes required in the CSS that uses explicit left/right instead of start/end (logical positional values). But hopefully the flex boxes automatically do "the right thing" when mirrored with RTL (either via the dir HTML attribute or the direction CSS rule)

[danielweck]

@panaC Thorium is currently a hybrid Radix and ReactAriaComponents GUI so this will be problematic I think:

https://www.radix-ui.com/primitives/docs/utilities/direction-provider

https://react-spectrum.adobe.com/react-aria/I18nProvider.html / https://react-spectrum.adobe.com/react-aria/internationalization.html

[danielweck]

The simple addition of:

import { DirectionProvider } from "@radix-ui/react-direction";

const locale = useSelector((state: ICommonRootState) => state.i18n.locale);

<DirectionProvider dir={locale === "ar" ? "rtl" : "ltr"}>

...around <Dialog.Root> causes the following GUI disturbances:

[danielweck]

Hello, I experimented with the "piece by piece" (piecemeal) approach to apply RTL only to carefully-chosen GUI controls, instead of globally (which unfortunately destroys the GUI layout, as previously mentioned):

5182b24

Side note: the locale === "ar" check will of course be factorised in a future revision to avoid code repetition.

I only improved the "settings" popup modal dialog, but you can already test using the automatic build of Thorium for your operating system / architecture:

https://github.com/edrlab/thorium-reader/releases/

I hope that this can be a viable approach for iteratively solving the RTL problem. The tradeoff is that many changes will be required in many different places, but these changes are small snippets of code. The massive advantage is that we do not have to refactor significantly the hybrid ReactAriaComponents + Radix architecture, and the CSS stylesheets. There are pros and cons, I think we have to accept some compromise. What matters is that RTL gradually becomes a reality for Arabic users (and Hebrew, etc.).

I will now post some screenshots that show the improved GUI.

[danielweck]

[danielweck]

As you can see there are still lots of alignments and padding/margin issues, but at least the text is now readable for the most part. This is going to be an iterative process because we are looking at a tree of components, some of which are reused across the entire application (we have to carefully think about regression bugs, test everywhere nested subcomponents are used)

[danielweck]

I filed this actionable issue with concrete TODOs to move forward: #3265