Change #1120196 had a related patch set uploaded (by Bmartinezcalvo; author: Bmartinezcalvo):

[design/codex@main] docs: fix RTL issues in Bidirectionality guidelines

https://gerrit.wikimedia.org/r/1120196

@bmartinezcalvo Am I correct, that your patch is only covering parts of above acceptance criteria?

@Aaharoni-WMF The patch is testable at https://1120196--wikimedia-codex.netlify.app/style-guide/bidirectionality.html

Also, it would be helpful for many folks to orient, why the diacritics aren't needed?

In T386621#10562136, @Volker_E wrote:

Also, it would be helpful for many folks to orient, why the diacritics aren't needed?

TLDR: They are simply not written most of the time.

For learning more than you ever wanted to know about the usage of diacritics in modern Hebrew, you can read this article, which yours truly wrote a few years for a peer-reviewed encyclopedia a few years ago.

The patch is testable at https://1120196--wikimedia-codex.netlify.app/style-guide/bidirectionality.html

Thanks! Some comments:

1. I am slightly uncomfortable about using the term "mirror" for text fields. The verb "mirror" is good for describing what is done to graphics, such as icons that are horizontally flipped. Setting the direction of a text field, however, is not quite the same—its text direction changes, but it is not fully mirrored visually. If everyone else is certain that it will be convenient for designers who use these instructions, then feel free to keep using "mirror". But if you don't mind, consider changing "mirror" to something "define an opposite text direction" when talking about text fields.
2. About "Do mirror: [...] Alignment of text in RTL languages": Does this line make it clear to designers and developers who will use it that in HTML and CSS, direction (ltr/rtl) is distinct from alignment (left/right)? Setting direction also sets default alignment, but not the other way around: setting alignment does not define the correct direction. And occasionally they have to be defined explicitly and separately (e.g., ltr direction, but right alignment and vice versa).
3. In "Don’t mirror: [...] Phone numbers and ZIP codes", I recommend making it more general. For example: "Fields that fully consist of numbers, such as phone numbers and postal codes".
4. Same for "URLs and email addresses": it's better to write something like "Technical names that are always written in left to right scripts, such as email addresses".
5. I'm not sure if "Currency symbols" should be mentioned at all, because their usage may be different with every currency. If they are mentioned, there should be an example.
6. In the "URL and email addresses" section, both Hebrew screenshot have wrong labels. "Email" must be "דואר אלקטרוני" and "Website" must be "אתר".
7. In the "URL and email addresses" section, the "Don't" screenshot has an email address written in random Hebrew letters. This is irrelevant: it's better to write the same email address as in the "Do" screenshot, but aligned to the right. It will be a better demonstration of the undesirable behavior because email addresses are never written in non-Latin letters anyway.

¹ "ZIP code" is a United States term.

Instead of mirroring, we could use "directional mirroring".

For ZIP codes: I also suggest expanding it to postal codes. I also wonder if there are any countries that use an alphanumeric postal code with RTL language (like Canada and the UK do with LTR). I don't know of any, but thought I should raise it, in case an example exists, in which case we would want to change @Amire80 's suggestion from "consists of numbers" to "alphanumeric" or something like that.

For #4, I don't agree with Amire80's suggestion. What third example of such "technical names" exists that is neither a URL nor an email address? I thing calling them out specifically is better than a general statement.

Finally, I get that Arabic and Hebrew are two of the most commonly used RTL languages, but I suggest we also include an example in Persian and Urdu, as other commonly used RTL langauge. FCOL, the number of people whose primary language is Persian or Urdu is nearly 10-fold that of Hebrew.

In T386621#10595810, @Huji wrote:

For #4, I don't agree with Amire80's suggestion. What third example of such "technical names" exists that is neither a URL nor an email address?

Email addresses are probably the most common example by far, but there are other kinds of small pieces of code. In the MediaWiki world in particular, these can be API action and parameter names (in the API sandbox), parser functions, and configuration variables. In particular, the names of the latter two begin with # and $, and these characters "jump" to the wrong side of the word if explicit direction is not set.

Finally, I get that Arabic and Hebrew are two of the most commonly used RTL languages, but I suggest we also include an example in Persian and Urdu, as other commonly used RTL langauge. FCOL, the number of people whose primary language is Persian or Urdu is nearly 10-fold that of Hebrew.

I agree!

Change #1120196 merged by jenkins-bot:

[design/codex@main] docs: fix RTL issues in bidirectionality guidelines

https://gerrit.wikimedia.org/r/1120196

In T386621#10596343, @Amire80 wrote:

In T386621#10595810, @Huji wrote:

For #4, I don't agree with Amire80's suggestion. What third example of such "technical names" exists that is neither a URL nor an email address?

Email addresses are probably the most common example by far, but there are other kinds of small pieces of code. In the MediaWiki world in particular, these can be API action and parameter names (in the API sandbox), parser functions, and configuration variables. In particular, the names of the latter two begin with # and $, and these characters "jump" to the wrong side of the word if explicit direction is not set.

Fair point. And you inspired me to add a few more: API tokens (alphanumeric), credit card numbers (if they contain space between groups of four digits, they can be incorrectly displayed in RTL), timestamps (especially when including colon or other similar characters), and TOTP tokens (which in my opinion should be both LTR and left-aligned).

As we would like to keep the issues tackled per sprint in scope, and I agree with a number of questions/comments shared, I've opened another task T387807: docs, i18n: Further refine “Bidirectionality” guidelines.
Also the postal code amendment made it into this patch/this spring.

Change #1124526 had a related patch set uploaded (by LWatson; author: LWatson):

[mediawiki/core@master] Update Codex from v1.20.2 to v1.20.3

https://gerrit.wikimedia.org/r/1124526

Test wiki created on Patch demo by LWatson-WMF using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/1f500859d0/wiki/Main Page

Change #1124526 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.20.2 to v1.20.3

https://gerrit.wikimedia.org/r/1124526

Test wiki on Patch demo by LWatson-WMF using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/1f500859d0/w/