I've tested Section Translation on sx.wmflabs.org on January 13, 2021, and found several RTL issues.
To test, I set the wiki UI language to Hebrew, and translated the section "Use" from the English Wikipedia article [[ASCII]] to Hebrew.
Most of the issues happen because content in the source language (English) is not explicitly marked as English and LTR with `lang` and `dir` HTML attributes. The `lang` and `dir` attributes for elements in both the source and the target language must always be set explicitly to ensure correct text direction (`dir`) and font selection (`lang`).
The text direction for every language code is available using ULS JavaScript API functions. I'm a bit less sure about CX3, which uses JavaScript somewhat differently from most other things on the MediaWiki platform, but on usual MediaWiki pages, a language's direction can be obtained by running something like `$.uls.data.getDir( 'he' )`.
In all the cases that I list below, adding `lang="en" dir="rtl"` to relevant elements using the browser's DOM inspector made the display correct and no further HTML or CSS was needed. This is different from many other MediaWiki components, where developers sometimes need to also add `class="mw-content-ltr"` or make some CSSJanus adjustments.
Here are the cases:
Section selector:
[ ] Foreign section title (`<h5>` elements under `<ul class="sx-section-selector__sections-list">`)
Section comparator:
[ ] Article title (`<h4 class="sx-content-comparator-header__article-title">`)
[ ] Section title (`<h2 class="sx-content-comparator-header__section-title">`)
[ ] Section title (`<div "class="sx-content-comparator__content-header-title">`)
[ ] Section content (`<section class="sx-content-comparator__source-content">`)
Translation view:
[ ] Article and section title: `<div class="sx-sentence-selector__section-header">` (and `<a>` and `<h2>` under it; the direction can probably be applied to the top `<div>`)
[ ] Source content at the top on the gray background: `<div class="sx-sentence-selector__section-contents">`
[ ] Target editing area (VisualEditor component; see details below)
The target editing area is perhaps the most complicated thing to explain and to get right (I did a little video meeting with @ngkountas to discuss it). In CX1 and CX2, the logic is as follows:
* The `lang` and `dir` attributes of the target language are applied to all the paragraphs in the target column.
* If the source and the target language have the same direction (e.g. English and Spanish), the defaults are:
** To fill the target paragraph with machine translation if it's available.
** To fill the target paragraph with the source text if it's not available. (The user can change this default.)
* If the source and the target language have different direction (e.g. English and Arabic), the defaults are:
** If **machine translation is available** for this language pair, fill the paragraph with machine translation.
** If **machine translation is NOT available** for this language pair, **start with an empty paragraph**.
The user can change all the above defaults. It means that when translating to a language without MT and choosing to pre-fill the paragraph with the source text, the source text will appear with the direction of the target language. It's not great, but I cannot think of any better solution than starting with an empty paragraph by default. Unless someone comes with something smarter, I recommend choosing the same logic for CX3.
Other issues:
[ ] Very minor: The blue checkmark button at the top before publishing doesn't need flipping for RTL. The same icon can be used for LTR and RTL.
[ ] In Firefox on Android, the web app is completely broken in RTL, although it works well if my UI language is English. The first step of choosing the section shows a mostly blank screen. In Chrome on Android it works as well as on the desktop, and in Firefox on desktop it's mostly good, too. Screenshot:
{F33997801}
[ ] The guidance wizard that appears after reviewing the sections and before starting the actual translation has some significant display issues. I experienced them on the desktop (Firefox and Chrome on macOS), in both desktop mode and mobile responsive mode, and also on Chrome on Android. The gray background is in the wrong location on the first screen, and in an even more wrong location in the second screen. Here's a screenshot:
{F33997778}
Thanks :)