Arabic localization: RTL layout, shaping, and plurals as engineering, not translation

Of all the languages a game is likely to add, Arabic is the one most likely to expose that a UI was built with only left-to-right, Latin-script assumptions baked in at the engine level. Most of the work in shipping Arabic well is not translation — it is making sure your rendering and layout systems can correctly handle a script that behaves differently at almost every level, from the direction text flows to how individual letters connect to each other.

Right-to-left layout and mirroring

Arabic is written and read right to left. This is not limited to text alignment — a correctly localized Arabic interface mirrors its entire layout: navigation flows right to left, a back button that was on the left moves to the right, progress bars fill in the opposite direction, and icons that imply directionality (an arrow pointing 'forward') need a mirrored variant. Icons that are directionally neutral — a settings gear, a trash can — do not need mirroring, and mirroring them anyway looks wrong, so this is a per-icon decision, not a blanket flip of every asset.

This is why RTL support is usually planned as a layout system feature rather than handled per screen: a UI framework that supports 'logical' start/end properties instead of hardcoded left/right can flip automatically when the active locale is RTL, while a UI built entirely from left/right positioning has to be manually reworked screen by screen.

Bidirectional text

Real Arabic text is rarely purely right-to-left in practice, because numerals and any embedded Latin-script text — a brand name, a variable inserted from English, a file extension — read left to right even inside an Arabic sentence. This mixed-direction text is called bidirectional text, and correctly ordering it on screen requires running it through the Unicode Bidirectional Algorithm, which determines the visual order of mixed-direction runs from their logical (typed) order. Getting this wrong is a common and visible bug: a sentence with an embedded English word or a number can render with the Latin substring in the wrong position, or with punctuation attached to the wrong side, if the rendering pipeline concatenates strings naively instead of respecting bidi control.

Letters change shape depending on position — cursive shaping

Arabic script is cursive: most letters connect to their neighbors, and a single letter can have up to four different visual forms depending on whether it stands alone or appears at the start, middle, or end of a connected word. This is handled automatically by any correct Arabic text-rendering stack, but it becomes a real bug source if code manipulates Arabic text at the character level the way it might safely manipulate Latin text — truncating a string with an ellipsis at a fixed character count, reversing characters for some transformation, or inserting a character in the middle of a word — because doing so can produce a sequence of glyphs that no longer connects correctly, visibly breaking the word's shape even though the underlying Unicode characters are technically unchanged.

Plural categories beyond singular and plural

Arabic's CLDR plural rules define six categories rather than the two English uses: zero, one, two, few, many, and other, distinguished by the grammatical number system of Classical and Modern Standard Arabic, which marks singular, dual (exactly two), and plural. A count of 0 items, 1 item, 2 items, 3–10 items, 11 and above, and certain fractional values can each require a distinct grammatical form. As with Russian's four categories, this means Arabic strings need a plural-aware message format with a branch per category the language uses — a hardcoded singular/plural pair simply has no place to put four of the six forms.

Font and shaping requirements

A font used for Arabic text needs actual Arabic glyph coverage plus the shaping logic — usually handled by the text-rendering engine, not the font file alone — to select the correct positional form of each letter and render the connecting strokes correctly. This shaping step, combined with bidi ordering, means Arabic text generally cannot be treated as a drop-in replacement for a Latin string in a rendering pipeline that assumes one glyph per character and a fixed left-to-right advance; verifying Arabic rendering specifically, rather than assuming it works because the font file 'has Arabic characters', is worth doing explicitly.

• Mirror layout direction and directional icons for RTL; leave direction-neutral icons unmirrored
• Use a layout system with logical start/end properties rather than hardcoded left/right where possible
• Route any string that mixes Arabic with Latin text or numerals through proper bidi handling, not naive concatenation
• Never truncate, reverse, or splice Arabic text at the raw character level
• Use a plural-aware message format with all six CLDR categories Arabic requires
• Verify Arabic shaping and glyph coverage in your actual rendering pipeline, not just in the font file