The estimate for adding a right-to-left language is usually built on a wrong assumption: that the layout mirrors and the work is translation. Setting the direction takes an afternoon. Everything listed below is the rest of it.
<html dir="rtl" lang="ar">
Icons that carry direction
A back arrow points the way you came from, and in RTL that is the other way. So does a next arrow, a breadcrumb chevron, an undo icon, a send icon and the play triangle on a video.
But not all of them. A clock still runs clockwise. A checkmark is still a checkmark. A logo is never mirrored. There is no rule that separates these; someone has to look at every icon and decide, which is why it gets missed in estimates.
Anything that moves
Carousels, drawers, toasts, accordions and page transitions all have a direction baked into them, usually as a hard-coded transform. A drawer that slides in from the right is correct in one direction and wrong in the other. So is a toast that animates from the corner, and a carousel whose arrows now point at the wrong slides.
Logical CSS properties handle most static layout automatically, and are worth adopting even on a single-language site. They do not help with transforms, which is where the work is.
margin-inline-start: 1rem; /* flips automatically */ padding-inline-end: 2rem; /* flips automatically */ transform: translateX(-100%) /* does not. you handle this */
Numbers, dates and mixed content
Numbers stay left-to-right inside right-to-left text. A phone number, a price, a product code and an English brand name in an Arabic sentence all read in the other direction, and browsers get the boundary wrong often enough that you will see mangled output in the wild.
The bidirectional algorithm handles most cases. The ones it does not tend to be exactly the ones you care about: prices next to currency symbols, model numbers, addresses.
Typography
- Arabic and Urdu scripts need more vertical space than Latin at the same nominal size. Fixed-height buttons and single-line labels overflow.
- Most Latin webfonts have no Arabic coverage, so you are pairing two typefaces and matching their optical sizes by eye.
- Urdu is usually set in Nastaliq, which is a different writing style from the Naskh used for Arabic. A font that handles Arabic beautifully can look wrong for Urdu.
- Letter-spacing on connected scripts breaks the connections between letters. It is not a stylistic choice there; it is a bug.
Third-party components
Your own components can be fixed. The payment form, the review widget, the chat bubble, the map, the date picker and the cookie banner belong to somebody else, and they will render left-to-right in the middle of your right-to-left page.
Audit these before quoting, not after. Discovering mid-build that the checkout provider has no RTL support is a scope change, and an awkward conversation you can avoid by spending an hour up front.
Content that is not text
Screenshots with English UI in them. Diagrams that read left to right. Videos with burnt-in subtitles. Marketing images with text baked into the pixels. Each one needs a second version, and image production is usually owned by a different team than the one doing the build.
How to scope it honestly
- 01Audit every third-party component for RTL support first. This is the item that changes the estimate.
- 02Count icons that carry direction, and animations with a hard-coded axis. Both are per-item work.
- 03Confirm who produces translated images and video, and by when. This is usually the thing that slips.
- 04Get a native reader to review before launch. Machine translation passes a spellcheck and still reads as foreign.
Done properly it is a genuine differentiator, because most studios have never shipped one and quote it as a translation job. Done as an afterthought, it produces a site that technically displays the language and visibly was not built for it.
Working on something like this?
We build websites, stores and custom applications, and we will tell you honestly if the thing you are describing does not need one.