Perfectly Backwards
اقرأها بالعربية

This page is in English. It is also perfectly backwards.

Nothing about this design is broken. The type is set, the spacing is considered, the colour is deliberate. Only the direction is wrong — and that alone is enough to make it a chore to read.

That is the entire argument. Roughly 1.8 billion people who read Arabic, Hebrew, Persian or Urdu open well-built software every day and meet exactly this: something competent, pointed the wrong way.

See the tracker

You have a button for this. RTL users do not.

1.8B readers of RTL scripts 2 of 8 everyday tools have shipped it 6 years on ClickUp's most-voted language request

جمال اللغة يكمن في تفاصيلها، والـRTL ليس ترفاً، بل ضرورة والسلام PEACE

One sentence. Two scripts. The comma drifts, the Latin word lands in the wrong place, and the reader has to reassemble the meaning by hand — every single time.

Type something. Watch it come apart.

Both panels receive the identical string. The only difference is whether the directional runs are isolated.

Punctuation, digits and brackets are neutral characters. They take their direction from whatever sits next to them, which is why a full stop can end up at the start of your sentence.

What most products ship: dir is set on a container and nobody looks again.

Each run wrapped with unicode-bidi: isolate. That is the whole fix. It is a CSS declaration, not a research project.

The same message, in two chat apps

Screen recording of Microsoft Teams: as Arabic and English are typed into one message, the cursor jumps and the words reorder unpredictably.
The cursor jumps. Words reorder as you type. You cannot predict where the next character will land.
Screen recording of WhatsApp: the same mixed Arabic and English message is typed, and every character stays where the writer put it.
Same sentence, same two scripts, no drama. So it is evidently not difficult.

Who has shipped it

Status as of July 2026. Corrections and additions are welcome — open an issue on GitHub.

The tools people open every day

Highest priority
Product Category RTL support Notes Updated
ClickUp Work management Done Arabic interface available, and native RTL moved to Building Now with a public beta in July 2026 after 866 votes and six years on the request. See the story below. Jul 2026
Notion Docs & knowledge base Done Arabic interface plus RTL text direction in documents. The difference was immediate and widely noticed — it is the proof that a large editor can retrofit this. Jul 2026
Slack Team messaging Pending No RTL layout and no Arabic interface. Mixed-script messages, thread replies and canvases all reorder unpredictably. Jul 2026
Claude Desktop AI assistant Pending The model answers in fluent Arabic; the interface renders it left-to-right. Long Arabic replies, code blocks and lists are the worst affected. Jul 2026
ChatGPT Work AI assistant Pending Same pattern: strong Arabic generation, no RTL layout. Business and enterprise workspaces inherit the problem organisation-wide. Jul 2026
Discord Community & chat Pending No RTL layout. Arabic-speaking communities are among the platform's fastest growing, and they type around the bug daily. Jul 2026
Zed Code editor Pending Bidirectional text in the buffer is unreliable: Arabic strings and comments inside LTR source reorder, and cursor movement through them does not match what is on screen. Jul 2026
T3 Chat AI assistant Pending A new product, built on a modern web stack, shipping without RTL. This is the one that stings — the cost of doing it right was never lower than at the start. Jul 2026
Enterprise and ERP systems — the older backlog (4)

These were the original entries on this page. They still matter, but they are no longer where the argument is won: the everyday tools above are what a whole workforce touches hourly, and they are the ones a procurement clause can actually move.

Product Category RTL support Notes Updated
SAP ERP Enterprise resource planning Partial Arabic display is broadly fine; mixed-script data entry and BI reports are not. Apr 2025
Oracle ERP Cloud Cloud ERP Partial Financial report formatting and mixed-text documents break. Several modules have no RTL layout at all. Apr 2025
Microsoft Dynamics 365 CRM and ERP Partial Core screens are reasonable; dashboards and custom reports are not, and mixed data entry is unreliable. Apr 2025
Odoo ERP Open-source ERP Pending Limited Arabic support throughout. Reports and mixed-script documents are the biggest gap. Apr 2025

What one comment did

Evidence that this works, and the reason the page you are reading exists.

ClickUp's RTL request was opened in July 2020. It gathered 866 votes and sat there. Hundreds of Arabic- and Hebrew-speaking teams explained, over and over, that they could not use Docs, Chat, Comments or task descriptions. Nothing moved.

In February 2026, Majd Alhakeem left a comment on that thread that did something different. Instead of asking again, he handed the ClickUp team a way to feel the defect — he linked them to this site, where a left-to-right reader gets put on the wrong side of the problem for a few minutes.

I want to draw the ClickUp team's attention to an important point: RTL support (IS NOT) an aesthetic or optional feature. It is a core functional requirement for us.

I believe many people around the world are simply unaware of how broken and exhausting this experience is for RTL users. To help demonstrate this, here is a webpage specifically designed to let LTR users see and feel what we deal with.

Majd Alhakeem · 23 February 2026 · ClickUp feedback thread

Five months later the status changed. That is what awareness is for: not applause, but a status field moving from silence to Building Now.

The timeline

  1. Sella Yoffe opens “RTL Language support”, asking for text direction and paragraph justification.
  2. Perfectly Backwards publishes, built to let LTR readers experience the defect first-hand.
  3. Majd Alhakeem links the site in the ClickUp thread and reframes RTL as a functional requirement, not a preference.
  4. Status changed to “Building Now.” ClickUp opens a public beta; the thread fills with people asking to join.

Progress across the tracked everyday tools

2 shipped, 6 pending. Note which edge that bar fills from right now.

Four ways it breaks

Each of these is live on this page right now. Toggle the direction and watch them resolve.

  1. Bidirectional text and input

    The worst of the four, because it affects writing, not just reading. Cursors jump mid-word. Selections grab characters you did not point at. Full stops migrate to the start of the line. Pasted text scrambles. Every message becomes a small negotiation with the text field.

    Neutral characters — . , : ( ) 12/03 — take direction from their neighbours. Without isolation, they land wherever the algorithm leaves them.

  2. Layout that never mirrors

    Navigation belongs on the reading-start edge. Primary actions belong where the eye finishes. When a layout is written with margin-left instead of margin-inline-start, none of it moves — the structure stays pinned to a direction the reader does not have.

    The numbers down the side of this list are padded with a physical padding-left. That is the entire bug, reproduced faithfully.

  3. Icons pointing the wrong way

    Back and forward arrows, undo and redo, progress bars, sliders, chat bubble tails, send buttons. All of them carry direction. An unmirrored “next” arrow in an RTL interface is not a cosmetic slip — it is an instruction to go the wrong way.

    Forward, as this page currently renders it:

  4. Forms that read out of order

    Labels rendered after their input. Checkbox captions on the wrong side of the box. Error messages anchored to an edge the reader is not looking at. Each is small; together they make a five-field form feel like a puzzle.

    Those labels are underneath their fields, not above them. Nobody chose that; a flex-direction simply never got reconsidered.

The accessibility double standard

Companies publish accessibility statements. They fund screen-reader compatibility, keyboard navigation, focus management, contrast audits. They map their work to WCAG clause by clause and announce it in release notes. All of that is genuinely good, and it took years of advocacy to win.

The same organisations then treat right-to-left as a localisation ticket. It waits behind translation. It gets scoped as “language support”, priced as a market-entry cost, and deferred to a quarter that never arrives. Meanwhile the failure it causes is the same class of failure accessibility work exists to prevent: a person who cannot reliably operate the interface.

There is no technical distinction worth defending here. Both are about whether a human being can use the thing. One of them got a standards body, an acronym and a budget line. The other got a feedback thread and six years of votes.

The uncomfortable version: if RTL had been written into WCAG in 1999, every product in the tracker above would have shipped it a decade ago. Nothing about the engineering changed. Only the paperwork would have.

There is no excuse left, and there is one lever

The platform already solved this

  • CSS logical properties. margin-inline-start, padding-inline-end, text-align: start, inset-inline. Universally supported, not experimental.
  • The dir attribute and unicode-bidi: isolate. Wrap your directional runs. That is the mixed-text fix, in one declaration.
  • The Unicode Bidirectional Algorithm. A published standard since 1996. Every text engine you depend on already implements it; products just have to stop fighting it.
  • Component libraries. Most modern frameworks ship RTL-aware primitives. The integration cost is a fraction of what it was five years ago.
  • AI coding assistants. Converting physical properties to logical ones across a codebase is now a mechanical task an agent can do in an afternoon — which removes the last honest objection, cost.

The lever: procurement

Feature requests are optional. Contracts are not. The single most effective action available to a government body or a large enterprise in the region is to write full RTL and Arabic support into every software purchase as a non-negotiable acceptance criterion — tied to sign-off and payment, not to a roadmap promise.

The moment a vendor cannot invoice without it, RTL stops being a nice-to-have on someone's backlog and becomes a line in a delivery plan. Do that collectively, across enough buyers, and it becomes a market requirement — which is the only language a global product roadmap reliably understands.

Suggested clause. “The supplier shall deliver complete right-to-left interface mirroring and correct bidirectional text handling for reading, input, search, export and printed or generated reports. Acceptance testing shall include mixed Arabic–Latin content in every user-facing surface.”

Build products that feel native to everyone. Think RTL — and if you already do, say so publicly, because the tracker above is short and it should not be.

Pass it on

A comment in the right thread moved a six-year-old request. Yours might move the next one.

Comments