Right-to-left languages: why RTL support is an engineering feature, not a translation

It is tempting to think of a right-to-left (RTL) language as just another translation target: swap the strings, ship the build. In practice, RTL support touches layout, text rendering, and input handling in ways that a translated string file cannot fix on its own. If the engineering side is not ready, the translation — however accurate — will sit inside a UI that reads backwards, breaks mid-sentence, or renders letters as disconnected fragments.

This article is an overview of what to investigate before committing to RTL support, not a complete implementation guide — the details depend heavily on your engine and text rendering stack.

Reading direction is only the starting point

Scripts like Arabic and Hebrew are written and read right to left, so body text needs to flow in that direction. That part is the obvious half of the problem. The less obvious half is that a UI built for a left-to-right reader encodes reading direction into far more than text: the eye naturally starts scanning at the leading edge of the screen, so navigation, back buttons, progress indicators, and reading order between UI elements are all oriented left-to-right by default.

Layout mirroring

For an RTL locale, players generally expect the overall UI to mirror: elements that sit on the left in an LTR layout move to the right, and vice versa. A back button that was in the top-left, a health bar anchored to one side of the screen, a menu that slides in from an edge — all of these carry a spatial meaning that should flip along with the text direction, or the interface will feel like it is fighting the language it is displaying.

This is a layout-system concern, not a string concern. It has to be designed into the UI framework — ideally with a single direction flag that flips margins, alignment, and icon orientation together — rather than solved by mirroring individual screens by hand as they come up.

Bidirectional text

Real RTL text is rarely purely RTL. Numbers are conventionally written left to right even inside an RTL sentence, and a Latin word, brand name, or code embedded in RTL text keeps its own left-to-right internal order. This mixing of directions within a single line is called bidirectional (bidi) text, and rendering it correctly requires a bidi algorithm that determines, segment by segment, which direction each run of characters flows in, while keeping the overall line direction correct.

A player-facing symptom of a broken bidi implementation is a sentence where a number or an embedded Latin term appears reversed, or sits in the wrong position relative to the surrounding RTL words, even though each individual character is rendered correctly.

Cursive shaping

Arabic script is cursive: most letters change shape depending on whether they are at the start, middle, or end of a word, or standalone, and adjacent letters connect into continuous strokes. This is not a stylistic choice — an Arabic letter rendered in isolation, disconnected from its neighbors, is visibly wrong to a reader, in the same way that a Latin letter rendered upside down would be.

Correct shaping depends on the text rendering engine, not the translation. If the font and text shaping pipeline in use do not implement Arabic contextual shaping, the text can come out looking like a string of disconnected, isolated-form letters no matter how accurate the translation is.

What to investigate before committing

None of this means RTL support is out of reach — it means it is a scoped engineering task that should be estimated honestly before a language is promised to players.

• Whether your UI framework and layout system support a mirrored (RTL) mode, and how much of the existing UI would need per-screen adjustment versus a global flip
• Whether your text rendering pipeline supports the bidi algorithm for mixed-direction text, and Arabic contextual shaping if Arabic is in scope
• Whether your font covers the target script with correct glyph forms and joining behavior
• Whether input fields, if any, correctly handle RTL typing, including mixed RTL/LTR input such as a username typed in Latin characters inside an RTL form

The takeaway

Translation and RTL engineering are two separate projects that happen to ship together. Treating RTL support as 'just another language' in the translation budget, without a corresponding engineering estimate for layout and text rendering, is the most common way RTL launches go wrong.