Arabic-First AI Interfaces: What Breaks in RTL and How to Fix It

Translation Is the Easy Part

Teams shipping into the Gulf usually budget for translation and assume the rest is a stylesheet change. Then the product reaches an Arabic-speaking reviewer and a list of odd, hard-to-describe problems comes back: a product name printed backwards, a full stop floating at the wrong end of a sentence, a chat response that jumps around while it streams.

None of those are translation errors. They are what happens when text that reads right-to-left shares a line with text that reads left-to-right, which in a technology product is constantly — because .NET, C#, Azure and SharePoint stay in Latin script inside Arabic sentences. That is correct practice in Arabic technical writing, and it is also the source of most of the bugs.

The Bidirectional Text Trap

Unicode resolves the direction of every character when it lays out a line. Letters are strongly directional. Punctuation is not — characters like a full stop, a hash or a slash are neutral, and a neutral character takes its direction from whatever surrounds it.

That rule produces a specific, repeatable failure. In an Arabic sentence, ".NET" can render with its leading dot pushed to the far side, and "C#" can render with the hash on the wrong side of the C. The text in your database is perfectly correct; only the display is wrong, which is why it survives code review and reaches production.

The fix is to wrap each Latin run in an isolate — U+2066 and U+2069 — or to mark the element so the browser treats its direction independently. Two practical warnings from doing this at scale:

• Isolate whole runs, not individual words. Two adjacent Latin words each isolated separately will be laid out right-to-left relative to each other, so "ASP.NET Core" comes out as "Core ASP.NET". • Keep the characters out of anything that is not display text. They are invisible but real. In a form value they travel into the email you receive; in structured data they reach search engines; in a URL they break the link.

Streaming Output Makes It Worse

A model streaming tokens into an Arabic interface creates a problem a static page never has. The direction of a neutral character depends on what comes after it — and during streaming, what comes after it has not arrived yet.

The visible result is text that re-flows as it arrives: punctuation jumping from one end of the line to the other, a partially rendered product name reversing itself and then correcting. It reads as a broken product even though the final state is right.

Mitigations that work in practice:

• Render streamed content inside an element whose direction is fixed rather than inferred, so each fragment cannot re-resolve the whole line. • Buffer to a sentence or clause boundary before painting, rather than per token. The latency cost is small and the improvement in perceived quality is large. • Apply the isolate treatment to the accumulated text, not to each chunk as it arrives.

Arabic Retrieval Is Not English Retrieval

If your assistant answers from Arabic documents, expect retrieval quality to be the limiting factor, and expect the causes to be unfamiliar.

• Orthographic variation. Alef appears in several forms, hamza placement varies, and the same word is commonly written more than one way. Without normalisation, a search for one spelling misses documents using another. • Diacritics. Usually absent from body text, occasionally present, and they change tokenisation. • Rich morphology. A single Arabic root generates many surface forms. Stemming that works for English underperforms badly here. • Dialect against Modern Standard Arabic. Your corpus is almost certainly MSA. Your users may well ask in Gulf dialect. The vocabulary gap is real. • Mixed-script content. Arabic documents full of Latin product names need an index that handles both, which is another argument for hybrid keyword-and-vector search rather than vector similarity alone.

Test with questions written the way your users actually write, including dialect and inconsistent spelling. An evaluation set translated from English will flatter your system and tell you nothing.

Mirroring the Interface Properly

Layout mirroring is mostly mechanical, and the exceptions are what catch teams out.

Mirror the flow: navigation, columns, sidebars, alignment and the direction of any arrow that indicates forward or back. CSS logical properties handle most of this if you use them from the start; retrofitting them into a mature stylesheet is a long job.

Do not mirror everything. Numbers stay left-to-right. Media player controls follow the timeline, not the language. Logos and brand marks stay as they are. Charts usually keep their conventional orientation, though the axis labels move.

One detail worth deciding deliberately: a language switcher that mirrors with the page moves the control to the opposite side when the user changes language, which is exactly when they are least able to find it. Pinning it to a fixed order is usually kinder.

Test It the Way It Will Fail

Visual inspection is unreliable for bidirectional text, because the failure is a subtle position swap and reviewers who do not read Arabic cannot see it. Screenshots and transcriptions are worse — both can present the logical order rather than the visual one, which hides the bug.

What works is measuring glyph positions directly. Ask the browser where each character actually rendered, and assert that the dot in ".NET" sits to the left of the N. Then validate the test against a deliberately broken sample, so you know the check can fail.

We built exactly that harness for our own Arabic site. It found 181 mis-ordered product names across 50 pages that a visual review had passed, and a further set of invisible control characters that had leaked into structured data where no one would ever have looked.

Two closing points for anyone planning an Arabic AI product. A native reviewer is not optional; no amount of tooling substitutes for someone who reads the language telling you the register is wrong. And Arabic support is not a launch task — it changes your retrieval design, your evaluation set and your component library, so decide early.