Nice work @bmartinezcalvo - I've added a few folks with area expertise to this ticket. Some initial feedback in no priority:

• Let's steer away from writing "RTL" or "LTR" in titles or headings of instructional documents. It's confusing as it is, and writing out the full word alongside a definition is far more didactic
• I wonder if we should be referencing languages in their own script (at least in parentheses) - so Hebrew for example, should be written as "עִברִית"
• We should definitely have these files reviewed by native speakers to ensure that the example designs make sense.
• How do designers access the RTL component? Will it be a variant within each component? This is a crucial workflow to consider.
• In addition to pure RTL and LTR design there are also moments in the design where something is written LTR and then there's a chunk of RTL text in the middle (for example). This is pulled from Wikipedia on Februrary 13, 2022:

This is particularly challenging for editing experiences, so we could break out a set of guidelines or principles related to that.

In T300053#7666970, @bmartinezcalvo wrote:

Hi all,

I have created this Notion where I have been documenting the most important information and rules about RTL design.

May I suggest a few edits?

Corrections

Text won't be displayed in reverse order.

I am not sure what that is trying to say. Does anyone really think that RTL languages write from the end of a word to its beginning?!

Icons without RTL versions won't be displayed on the opposite side.

This is wrong. The picture above it correctly shows that an icon (check box) is moved to the right side.

I think what should be stated instead is:

Not all icons have an RTL version, and for those that do, it is not always a mirror image of the LTR version. Icons, appear in the same "relative" position in RTL as in LTR; i.e. an icon that is at the beginning of a sentence (to its left) in LTR view will still be at the beginning of the translated sentence (which is to its //right//) in RTL view.

And the image with the flipped musical note icon can be used as a bad example of flipping an image to make an RTL version of it.

Zip code numbers will never be mirrored

Well, no numbers are ever mirrored. No text is ever mirrored for that matter. I think there is a misunderstanding here that RTL is a "mirroring" phenomenon. It is not.

Additions

I would suggest adding that "elements of sentences that are language specific, such as punctuation, should not be hard-coded, so that they can be handled by proper i18n code". Finding untranslatable periods and semicolons in designs is something I have experienced a lot.

• Let's steer away from writing "RTL" or "LTR" in titles or headings of instructional documents. It's confusing as it is, and writing out the full word alongside a definition is far more didactic
• I wonder if we should be referencing languages in their own script (at least in parentheses) - so Hebrew for example, should be written as "עִברִית"
• We should definitely have these files reviewed by native speakers to ensure that the example designs make sense.
• How do designers access the RTL component? Will it be a variant within each component? This is a crucial workflow to consider.
• In addition to pure RTL and LTR design there are also moments in the design where something is written LTR and then there's a chunk of RTL text in the middle (for example). This is pulled from Wikipedia on Februrary 13, 2022:

@iamjessklein updated Figma design and Notion page with the following corrections:

1. Added "Right to left (RTL)" to all titles to clarify what the abbreviation means.
2. Added Hebrew and Arabic in parentheses in their own scripts.
3. I agree, some native speakers should review all these examples. I'm going to look for native speakers in our Staff language skills.
4. The idea is to have all of our components available for both LTR and RTL layouts, so we should add an RTL variant to all of our components (we also have our icons with RTL variants). I think it's the best way to fully work our system for RTL.
5. I have added the use case for text with LTR and RTL both in Notion and Figma.

@Huji thank you for your feedback, I answer you below:

I am not sure what that is trying to say. Does anyone really think that RTL languages write from the end of a word to its beginning?!

About text. It's true that this sentence seemed confusing, for this reason I have updated the image and text for "Text and icons" section. I know it's logical that the text should be written in the correct direction of the language, but this are a basic rule that needs to be explained (for example, if you don't use a specific plugin the design tools write the RTL texts in the reverse order, so it's important to pay attention on this).

Icons without RTL versions won't be displayed on the opposite side.

About icons, I removed the description of the icons from here as the icons have their own section and this section will be for Text only.

Zip code numbers will never be mirrored

About numbers, some numbers can be mirrored. For example, units and measurements can be mirrored but phone and zip codes never be mirrored. For this reason it's important explain when a design can mirror numbers and when not.

I would suggest adding that "elements of sentences that are language specific, such as punctuation, should not be hard-coded, so that they can be handled by proper i18n code". Finding untranslatable periods and semicolons in designs is something I have experienced a lot.

Could you send us a link or screenshot with these examples? We will study them to know how include them in this documentation.

In T300053#7710188, @bmartinezcalvo wrote:

@Huji thank you for your feedback, I answer you below:

I am not sure what that is trying to say. Does anyone really think that RTL languages write from the end of a word to its beginning?!

About text. It's true that this sentence seemed confusing, for this reason I have updated the image and text for "Text and icons" section. I know it's logical that the text should be written in the correct direction of the language, but this are a basic rule that needs to be explained (for example, if you don't use a specific plugin the design tools write the RTL texts in the reverse order, so it's important to pay attention on this).

Thanks for the clarification. It makes a lot more sense now. The "text in reverse order" issue is a known bug. I remember years ago many pieces of Software (e.g. Adobe Photoshop) had that issue too. Good to call it out as you did in the revised version.

Zip code numbers will never be mirrored

About numbers, some numbers can be mirrored. For example, units and measurements can be mirrored but phone and zip codes never be mirrored. For this reason it's important explain when a design can mirror numbers and when not.

What do you mean by "units and measures can be mirrored"? Do you mean that the unit itself (like the "cm" in "12 cm") will be on the left side in an RTL language? That is of course true, but "cm" is not a number. The numeric part (like 12) will still be an LTR string. In all RTL languages I know of, the actual number (string of digits) is always LTR. If I am missing the point, please educate me.

I would suggest adding that "elements of sentences that are language specific, such as punctuation, should not be hard-coded, so that they can be handled by proper i18n code". Finding untranslatable periods and semicolons in designs is something I have experienced a lot.

Could you send us a link or screenshot with these examples? We will study them to know how include them in this documentation.

Actually, the example you have for Zip code is a good one already. The comma character ("," in English and "،" in Arabic) should not be hard-coded and isn't in this case. Perhaps you can create a "don't" example for it too, where you use the English comma in both cases.

+1 to this comment T300053#7670925 from @TheDJ about providing guidance on how to show mixed RTL and LTR content in a particular UI setting. Besides the examples from the Android app when you have multiple languages selected, another example would be wikidata items where it is very common to see translations of the item on all languages shown in one table:

One edge case icon exception that comes to mind that doesn't strictly adhere to RTL/LTR rules is that the "?" question mark icon uses LTR in Hebrew.

In T300053#7711431, @RHo wrote:

One edge case icon exception that comes to mind that doesn't strictly adhere to RTL/LTR rules is that the "?" question mark icon uses LTR in Hebrew.

That is what I had in mind when I proposed "Not all icons have an RTL version, and for those that do, it is not always a mirror image of the LTR version."

@Huji In the early stages of Codex we've already initialized a clearer presentation of these language specific icons open for critique.

@Volker_E nice work.

You did not specify where such critique should be provided, so I will write some immediate reactions here, but am happy to move it wherever you deem appropriate.

• Overall, they make sense.
• Notable to me was that certain icons were aligned with right-handedness (e.g. the magnifying glass in both LTR and RTL version of cdxIconArticlesSearch is drawn such that a right-handed person would hold it). No objections, just expressing my first impression.
• Not sure why these icons are flipped in RTL:
  • cdxIconBrowser: most RTL users still use an LTR language for their OS, which means their window buttons will not be flipped; this implies otherwise
  • cdxIconEditUndo and cdxIconUndo: same argument; besides, even if you change your OS language to an RTL one, typically, software that has undo buttons doesn't flip it. Perhaps further investigation is warented on whether the arrow direction for undo should be flipped or not, based on common practice in other i18n'ed software.
  • cdxIconImageAdd and cdxIconImageLock: I see no benefit in flipping them (but no harm either)
• For cdxIconListNumbered, should consider having a language-specific icon for 'fa' (and perhaps 'ar'). In Persian, we don't use Western Arabic Numerals (1,2,3) for lists or in text; we use Eastern Arabic Numerals (۱,۲,۳) instead. In Arabic, from what I have seen online, numbers in text are either in Eastern or Western Arabic Numerals but numbers for lists (<ul>) elements are mostly in Western Arabic Numerals. In published (paper) media, however, I have seen broader use of Eastern Arabic Numerals, including in lists.
• As for cdxIconItalic for 'fa', see T301157
• cdxIconSignature could be debated; the cursive form used for signature here makes sense in Latin-script languages but not in RTL languages. I don't have a better recommendation though, and certainly none that works both ways.
• cdxIconStrikethrough and cdxIconUnderline: may be worth being designed in a language specific manner, similar to bold and italics icons are.

Icons and RTL are one of my favorite topics of philosophical musings that lead to practical visual decisions -- but they're usually really complicated, as the discussion here demonstrates.

In T300053#7713452, @Huji wrote:

@Volker_E nice work.

You did not specify where such critique should be provided, so I will write some immediate reactions here, but am happy to move it wherever you deem appropriate.

• Overall, they make sense.
• Notable to me was that certain icons were aligned with right-handedness (e.g. the magnifying glass in both LTR and RTL version of cdxIconArticlesSearch is drawn such that a right-handed person would hold it). No objections, just expressing my first impression.

This is also true for the editing icon (the pencil) and the checkmark icon and -- my personal favorite 'flipped-but-should-it?' icon -- the 'loudspeaker' icon. If I remember correctly, many of those were flipped for design clarity (they follow the "start" or "direction of the text" as leads, rather than strictly because they "need" to be in RTL.

There are a bunch of icons that are also more culture or context-dependent, when deciding to flip. For example -- a calendar. Calendars are all over the place in RTL; some are right-to-left (following the names of months/days) but some (even in RTL languages) are still LTR, following the numbering of the days. I have a speaker deck for a talk I gave a little while ago with some examples of this, where it's clear there is no real standard in the language. Technically speaking, a calendar would be correct whether it's displayed LTR or RTL in many RTL languages, although some cultures prefer one over the other more (less language dependent, more context/culture dependent)

This is mostly an observation about how fascinating some of those choices are, and a general observation that some of those choices are for visual/design appeal. For example, from my understanding, the reason that the magnifying glass is flipped in RTL isn't so much that it's held in reverse in RTL (that is hand-dependent as you point out) -- but rather that visually we want the magnifying glass to lean towards the beginning of the text -- which means leaning one way in LTR, and the other in RTL.

I leave those design decisions for the design considerations, but figuring out which icons shoudl or shouldn't flip is definitely one of the harder problems of supporting RTL interfaces, and tends to be entirely non standard online.

• Not sure why these icons are flipped in RTL:
  • cdxIconBrowser: most RTL users still use an LTR language for their OS, which means their window buttons will not be flipped; this implies otherwise

I tend to semi-agree on this; while it's true that many users use LTR operating system with some minimal translation (meaning the browser is still LTR) that's (a) not true for all, and tends to be not true for less tech-savvy ones, as far as I could tell, and (b) technically speaking not the "proper" RTL browser, so I think it's perfectly reasonable to swap the browser icon, since RTL would mean it's flipped, and makes it very clear we're not just thinking about flipping of the text direction, but of the "mental model" of the user (expecting menu/buttons/logo/etc on the other side)

• cdxIconEditUndo and cdxIconUndo: same argument; besides, even if you change your OS language to an RTL one, typically, software that has undo buttons doesn't flip it. Perhaps further investigation is warented on whether the arrow direction for undo should be flipped or not, based on common practice in other i18n'ed software.

Oh, gosh, I have a whole lecture about this -- the undo and redo buttons are probably one of my favorite lecture-tools to demonstrate the brain-busting property of supporting RTL languages visually :)

The undo and redo buttons are in fact flipped twice in interfaces; the undo button points towards "backwards" -- in LTR, that's towards the left, but in RTL, that's towards the right. What makes this usually brain-imploding is the fact that when you do have an RTL interface, the two buttons [ undo | redo ] are flipped inside themselves ([ redo | undo ]) which essentially means that they LOOK (as a pair) exactly the same as the LTR version, except each of them does the reverse.

This is brain-imploding if you spend time thinking about it, but examining editing interfaces out there -- that appears to be the standard, and what RTL users tend to expect without necessarily noticing. We do recommend adding popup/title text to all buttons, though, to make sure people know which is which (in all buttons, including undo/redo)

It's also technically speaking "correct" ('go back' / 'go forward' with both of those terms flipping in RTL) and the convention online seems to follow that in the vast majority of interfaces. Those that don't follow tend to make it look really off with the arrows suddenly pointing towards one another, which feels a lot less standard.

• cdxIconImageAdd and cdxIconImageLock: I see no benefit in flipping them (but no harm either)

No opinion on that one.

• For cdxIconListNumbered, should consider having a language-specific icon for 'fa' (and perhaps 'ar'). In Persian, we don't use Western Arabic Numerals (1,2,3) for lists or in text; we use Eastern Arabic Numerals (۱,۲,۳) instead. In Arabic, from what I have seen online, numbers in text are either in Eastern or Western Arabic Numerals but numbers for lists (<ul>) elements are mostly in Western Arabic Numerals. In published (paper) media, however, I have seen broader use of Eastern Arabic Numerals, including in lists.

Yes, +1000 to this, let's try to have proper variants for eastern arabic numerals; I believe there are several other languages that do the same, though there might be slight variations with arabic, since iirc, some locales use western arabic and some eastern ones, so I'm not sure if it'll be completely possible to cover all options - but there are definitely standardized ones.

A small anecdote (which I hope OpenOffice fixed, but I'm not sure) -- open office flipped the numbered lists icon as-is... meaning you ended up with a "number on the right and lines on the left" but also with the numerals 1, 2, and 3 mirrored. It appears some apps forget to double-check their flipping rules ;)

• As for cdxIconItalic for 'fa', see T301157
• cdxIconSignature could be debated; the cursive form used for signature here makes sense in Latin-script languages but not in RTL languages. I don't have a better recommendation though, and certainly none that works both ways.

Yea, I think the same, I think it probably works either way? I'm not 100% sure.

• cdxIconStrikethrough and cdxIconUnderline: may be worth being designed in a language specific manner, similar to bold and italics icons are.

Good point on that one.

In T300053#7712183, @Huji wrote:

In T300053#7711431, @RHo wrote:

One edge case icon exception that comes to mind that doesn't strictly adhere to RTL/LTR rules is that the "?" question mark icon uses LTR in Hebrew.

That is what I had in mind when I proposed "Not all icons have an RTL version, and for those that do, it is not always a mirror image of the LTR version."

@Huji @RHo question mark has the RTL variant because we use it in Arabic (although we don't use it in Hebrew), so the RTL variant is needed but we should keep attention in when to use this icon (that is more about how to use some RTL icons in each language and not about the RTL variant).

Anyway, I have added the question mark use cases to explain that we can use the RTL variant for Arabic but not for Hebrew.

In T300053#7714306, @bmartinezcalvo wrote:

In T300053#7712183, @Huji wrote:

In T300053#7711431, @RHo wrote:

One edge case icon exception that comes to mind that doesn't strictly adhere to RTL/LTR rules is that the "?" question mark icon uses LTR in Hebrew.

That is what I had in mind when I proposed "Not all icons have an RTL version, and for those that do, it is not always a mirror image of the LTR version."

@Huji @RHo question mark has the RTL variant because we use it in Arabic (although we don't use it in Hebrew), so the RTL variant is needed but we should keep attention in when to use this icon (that is more about how to use some RTL icons in each language and not about the RTL variant).

Thanks @bmartinezcalvo, speaking for my reason for bringing up the question mark example, it was intended to firstly suggest including this consideration in our icon design guidelines which in hindsight I didn't clearly express. The second reason was to see if there was a more overt way to categorise such edge case icons have different applications by language and not straightforwardly "RTL" vs "LTR", so it is good to see @Volker_E linking to how this is done in Codex by appending the specific language variant (helpHE, helpYI,helpRTL), and am looking forward to these variants being added to the Figma icon components too.

Thanks @bmartinezcalvo, speaking for my reason for bringing up the question mark example, it was intended to firstly suggest including this consideration in our icon design guidelines which in hindsight I didn't clearly express. The second reason was to see if there was a more overt way to categorise such edge case icons have different applications by language and not straightforwardly "RTL" vs "LTR", so it is good to see @Volker_E linking to how this is done in Codex by appending the specific language variant (helpHE, helpYI,helpRTL), and am looking forward to these variants being added to the Figma icon components too.

@RHo ince we avoid in our icon system Figma file repeating icon variants that are visually the same, we can add an icon description for those icons with specific uses (like this question mark), so that designers can read about the use of the icon when they use it.

In T300053#7713535, @Mooeypoo wrote:

In T300053#7713452, @Huji wrote:

• For cdxIconListNumbered, should consider having a language-specific icon for 'fa' (and perhaps 'ar'). In Persian, we don't use Western Arabic Numerals (1,2,3) for lists or in text; we use Eastern Arabic Numerals (۱,۲,۳) instead. In Arabic, from what I have seen online, numbers in text are either in Eastern or Western Arabic Numerals but numbers for lists (<ul>) elements are mostly in Western Arabic Numerals. In published (paper) media, however, I have seen broader use of Eastern Arabic Numerals, including in lists.

Yes, +1000 to this, let's try to have proper variants for eastern arabic numerals; I believe there are several other languages that do the same, though there might be slight variations with arabic, since iirc, some locales use western arabic and some eastern ones, so I'm not sure if it'll be completely possible to cover all options - but there are definitely standardized ones.

There's a relevant list of examples (as of 2016) at https://www.mediawiki.org/wiki/Talk:Localisation#Languages_that_use_non-arabic_numerals_in_their_ToC and a search-link for more at https://www.mediawiki.org/wiki/Manual:$wgTranslateNumerals which might help with this item?

In T300053#7714306, @bmartinezcalvo wrote:

In T300053#7712183, @Huji wrote:

In T300053#7711431, @RHo wrote:

One edge case icon exception that comes to mind that doesn't strictly adhere to RTL/LTR rules is that the "?" question mark icon uses LTR in Hebrew.

That is what I had in mind when I proposed "Not all icons have an RTL version, and for those that do, it is not always a mirror image of the LTR version."

@Huji @RHo question mark has the RTL variant because we use it in Arabic (although we don't use it in Hebrew), so the RTL variant is needed but we should keep attention in when to use this icon (that is more about how to use some RTL icons in each language and not about the RTL variant).

Anyway, I have added the question mark use cases to explain that we can use the RTL variant for Arabic but not for Hebrew.

Well, Arabic and Persian.

This figma file is absolutely incredible. For years we've been working on RTL support on the Wikimedia projects with some learnings and insights that were very rarely properly coalesced into a proper document with guidance and decisions, so having one being worked on not only as decisions for the specific Codex library, but as more widespread visual guidance is extremely helpful!

I have some (minor) comments about the Figma file that I hope are helpful:

Phone numbers

Numbers in general are a doozy for multiple reasons that may make things a bit complex in the example you gave:

1. Western vs Eastern Arabic numerals -- Western numerals are always LTR'ed and Eastern are RTL'ed, so watch out that you'd need to align them differently if you expect either of those numerals.
2. Parentheses (and spaces) are a nightmare; in RTL, the ( on your keyboard actually renders ) when you're on an RTL input (it's "open" parenthesis rather than "left" parenthesis... and is the cause of many a-brain-melts when supporting RTL).
3. Specifically phone numbers can be an annoyance because you may have an international prefix (+1 or such) which means the + sign can move to the other side of the number if the number is RTL'ed, which is another annoyance.

The general advice that we tend to follow in RTL/LTR for number fields --

1. Use them only for numbers (try not to have users type symbols in them)
2. Always LTR the field if it's Western Arabic numerals, and always RTL the field if it's Eastern Arabic numerals. The cases where that might be an exception are very very rare; for the most part, western arabic numerals are written LTR even in RTL, so "sticking" that input to LTR (you can align-right if you want, but use dir=ltr) is usually the best.

As an aside, this is also a good advice for things like an email field which is 99.9999% of the cases written in ascii/LTR so the recommendation is to have an email input "stuck" to dir=ltr. Otherwise, you start writing foo and when you type @ it jumps around until you type the rest of the domain.

This flipping can also happen with fields that are mixed numerals/letters which leads me to the next point --

Zip code example

In the zip code example, you show an input that has a mix of numbers and letters -- 08014, Barcelona. When mixing numbers and letters in RTL, this can go completely off the rails with where the cursor goes and the letters go, depending on whether you type in RTL language, Western or Eastern numerals, or have any sort of LTR character in there.

As an example, we encounter this a lot with currency. Some apps as you to add, in a single input, a price with currency (example - 123 USD) which can get tricky when you flip RTL/LTR with different values.

What we usually recommend in these cases is to always try to separate numerals and letters/language in inputs -- make 2 inputs (one dedicated to the number, one dedicated to the language/letters) rather than mixed, to avoid a lot of potentially super jarring typing (and rendering) experiences.

Images example

I was a bit confused with the example about the "don't" in the images on the right-hand corner. After zooming in, I understand that this is about not flipping the image itself -- but it first appeared as if the recommendation is not to align the images on the right, which is what dropdowns should do. Maybe clarify that part?

Iconography

As I mentioned in a previous comment, this is one of my fav topics because there are a lot of icons that are completely inconsistent basically everywhere you look online, which makes a lot of this guidance a bit tricky. I think the guidance you have is good.

One detail I'd maybe add to that piece is that there are several exceptions to the general "flip or not flip" rule; icons are complicated. I have a few examples of this in slides 81-90 in a talk I gave a few years ago at the Unicode conference. TL;DR -- some icons aren't as clearly consistent on flipping, but also some icons are okay to flip if that's what your "design eye" is going for (example -- icons that represent "the beginning" of a sentence like the loud-speaker or the pencil or, in some cases, the checkmarks) -- You don't have to flip them in RTL, but it might actually be a visual choice to do so.

Mirrored elements

A few minor questions about the mirrored elements in the middle --

1. The [phone number] [dropdown] has the text flipped but not the positions of the elements flipped in RTL -- is that on purpose? (I would expect to see [dropdown] [phone number] in RTL, but it's not "wrong" per say either way)
2. Same with the [zip code] [country] -- is it supposed to stay this order, or flip to be [country] [zip code] (as it usually does, in reverse order for RTL) ?

This is awesome. Thank you for all this work!!

Can you provide some clarity/examples about what you mean when you say numbers with Eastern Arabic nuemrals are RTL'ed?

In T300053#7766024, @Huji wrote:

Can you provide some clarity/examples about what you mean when you say numbers with Eastern Arabic nuemrals are RTL'ed?

Yes, sorry, I was mostly thinking about Mathematical notation and arrangement and the difference between using western arabic and eastern arabic notation; the numbers CAN be read from right-to-left (though my understanding is that that is not always the case)

I was hoping to make the case that even directionality can be a bit tricky in numbers/digits within RTL languages, especially when we take into account some languages use the western arabic numerals and some the eastern arabic numerals that can (and often do) have different behaviors between them.

That said, I am much less personally-familiar with the Eastern arabic numerals, and am only familiar with the impact they have on HTML inputs, so I apologize if I may have over-generalized or confused any principles here. My goal was to warn against some fo the variations that exist so we don't automatically assume behavior that limits digits in certain languages.

Another example for what I was trying to demonstrate is the "flipping" of the expected location of the negative sign

LTR (and RTL with western arabic numerals): -3
RTL (with eastern arabic numerals): ٣−

There seem to be some notable differences in the expectations of Eastern Arabic vs Western Arabic notation/rendering that impacts inputs, especially web inputs.

In T300053#7765926, @Mooeypoo wrote:

This figma file is absolutely incredible. For years we've been working on RTL support on the Wikimedia projects with some learnings and insights that were very rarely properly coalesced into a proper document with guidance and decisions, so having one being worked on not only as decisions for the specific Codex library, but as more widespread visual guidance is extremely helpful!

I have some (minor) comments about the Figma file that I hope are helpful:

@Mooeypoo thank you for your great and useful feedback, I have update the Figma file with the following:

• Info added about Western Arabic and Eastern Arabic numbers.
• Added the prefix example you commented.
• Added zip example separating zip code and city (as you commented).
• Example of images updated with a single image to be more clear.
• Added some new icons examples (your slides examples were great!)
• About parentheses example, I haven't added nothing because I would need a visual real example to understand it and add it as example.

Thank you so much for your feedbacks!

In T300053#7767004, @bmartinezcalvo wrote:

@Mooeypoo thank you for your great and useful feedback, I have update the Figma file with the following:

Sweet!

• Info added about Western Arabic and Eastern Arabic numbers.
• Added the prefix example you commented.

Small correction -- the +1 field should remain +1 in RTL (not 1+) since it's using Western arabic numerals.

(edit/addition) -- the fields should remain the LTR order, too [prefix] [number] IF you use western arabic numerals (I am not 100% sure about the eastern arabic numerals on phone numbers with prefixes, though). You would USUALLY flip inputs, but in this specific case, you're separating the prefix for ease (see below) but the number is still "left to right" including the prefix, so the order in this case should remain the same and not flipped.

Western arabic numerals generally do "mathematical operations" in Left-to-Right manner (for the most part; don't let me start on things like ranges...) -- so +1 still has the + on the left of the number. The problem I was sharing before is that if the number input is aligned RTL, then when you type + and then the number, the input RENDERS the + as going to the wrong side (annoyingly) so separation of the prefixes is better, like you've displayed.

• Added zip example separating zip code and city (as you commented).
• Example of images updated with a single image to be more clear.
• Added some new icons examples (your slides examples were great!)
• About parentheses example, I haven't added nothing because I would need a visual real example to understand it and add it as example.

All the above is excellent, thank you!

So, supporting RTL on the web is exciting but also potentially brain-exploding; I was trying to be careful how much excited-details I share here (I can talk about this for hours, I'm sure it's evident ;) BUT since you've asked for examples to understand it better, I have a few you can look at:

1. RTL.WTF is a visual example I made to demonstrate to primarily-LTR-reading-folk what RTL experience feels like online. It also has an introduction to Unicode's RTL support and its ups-and-downs in this article. (NOTE: Do not feel bad if your brain gets confused; there's a "flip this to LTR" button on the bottom you can use to at least read the article properly after experiencing the jarring misalignment ;)
2. This is a video of a talk I gave a few years ago about supporting RTL and its many brain-twisters. If you watch the entire thing it may shed light on some of the problems I mentioned regarding the typing and rendering "jumpiness", but you can also skip to timestamp 24:11 where I specifically demonstrate the issue of Parentheses (of all kinds, including the issue of typing <HTML> elements in RTL -- a cry-worthy affair ;)

Tiny note on the video lectures -- there are a few corrections that browsers have implemented since them (specifically, a correction to properly render parentheses of an LTR name in an RTL context) but that does not extend to inputs (only the HTML visual render). And... there are some other minor corrections done over the years, but the gist of things remain the same, so I hope it's helpful if you want to delve in a bit to what is actually happening.

Do let me know if there are more questions, I would love to continue supporting this effort -- and thank you for the thoughtful work on this!

Great collection so far. :)
To get this under the umbrella of the Design Style Guide, design team has originally outlined an idea of an “Internationalization” section underneath the “Accessibility” one T300655. Aligning with our overarching goals of support in design team and Codex.
Bidirectionality is just one, a large one, piece of Internationalization.

I'd propose to proceed in finding and sharing general rules for Internationalization design in overview page, that can be expanded in the other DSG sections. At the same time letting the article contain a large segment on bidirectionality. Certain design specifications are also expanded on in component or guidelines pages, like icon guidelines.

That sounds logical to me @Volker_E

@Mooeypoo - would you feel comfortable if we linked the resources that you shared here to the documentation directly in some form? I am thinking they could be good as supplementary reading materials.

In T300053#7771932, @iamjessklein wrote:

That sounds logical to me @Volker_E

@Mooeypoo - would you feel comfortable if we linked the resources that you shared here to the documentation directly in some form? I am thinking they could be good as supplementary reading materials.

What if we include them here in the left introduction?

Feel free to share those wherever you deem fit :)

I'd also add this wonderful resource that has a lot of examples on how to style RTL text and elements on the screen: https://rtlstyling.com/posts/rtl-styling

In T300053#7774204, @Mooeypoo wrote:

Feel free to share those wherever you deem fit :)

I'd also add this wonderful resource that has a lot of examples on how to style RTL text and elements on the screen: https://rtlstyling.com/posts/rtl-styling

Thank you @Mooeypoo, I've added it too :)

might it be useful to add math symbols/icons under the 'Acceptance criteria (or Done)' section?

In T300053#8622164, @AAlhazwani-WMF wrote:

might it be useful to add math symbols/icons under the 'Acceptance criteria (or Done)' section?

Done! We can document this use case with the final version of your icon in T329383#8621562

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

[design/codex@main] docs: include bidirectionality guidelines

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

Change #1028510 merged by jenkins-bot:

[design/codex@main] docs: include bidirectionality guidelines

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

Change #1032095 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] Update Codex from 1.5.0 to 1.6.0

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

Change #1032095 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from 1.5.0 to 1.6.0

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