UI guides from right to left?

Question

I am looking for RTL support for my own user interface infrastructure (for a desktop application), and I am wondering: are there any recommendations on how to change the visualization of the widget?

I am looking for a list of things like:

• flag labels are located to the left of the flag and are aligned to the right
• toolbar buttons move from right to left
• vertical sliders are located on the left.
• window decoration
• ...

Answer 1

Typically, the layout should be mirrored , which is horizontally upside down. In addition to the controls that you already mentioned, obviously, switches, combined fields (aka drop-down menus), backs (or up and down, depending on terminology) should be mirrored. Window or window control panels that minimize, maximize and close buttons should be on the opposite side. The same goes for the window title.
You also need to change the order of the buttons, so if you have [OK] [Cancel] [Help], in RTL languages ​​it will be [Help] [Cancel] [OK]. Icons in pop-up messages should be on the other side.

You might want to find out how Microsoft implemented RTL support in its MFC infrastructure: they just changed the coordinates, so 0.0 indicates the upper right corner of the screen and the x coordinates increase as you move from the left side. This has some side effect observed in splitter management - it works exactly as you would expect (dragging it to the left side increases the left side of the window).

Returning to the controls: Obviously, left-justified text fields in LTR languages ​​should be right-aligned in RTL languages, etc.

What is definitely less obvious, some bitmaps must also be flipped. What particularly surprised me is the question mark icon (the one that usually appears with a confirmation dialog or help button) should be flipped if Localization is in Arabic, Urdu or Persian, for the Reverse Question Mark (⸮) is what they use. I am not sure about Hebrew.

Please keep in mind that some bitmap images must be localized for cultural reasons (for example, some may not be appropriate). In addition, it is more or less necessary to use the so-called Eastern Arabic numerals when localizing into Arabic (and similar languages), but it is not a good idea to use them for Hebrew. As you can imagine, if you have interesting images for marker points (containing numbers), and the application (or framework) needs to be translated into Arabic, these images should be at least localizable (which is being replaced).