Arabic RTL websites nearly always follow the same sequence. The site is designed in English, built in English, and two weeks before launch somebody asks about the Arabic version. A developer sets the text direction to right to left, the layout mirrors, and what ships has broken line breaks, English buttons, phone numbers reading backwards and a headline in a font that was never meant to carry Arabic. It is the most common quality failure on Egyptian websites and it is entirely a planning problem.
In Arabic RTL websites, direction is the cheap part
Setting the document direction takes minutes. Writing a stylesheet that was ready for it takes discipline. Use logical properties: margin inline start rather than margin left, padding inline end rather than padding right, inset rather than hard coded left and right offsets. A stylesheet built that way flips itself and needs almost no direction specific overrides, which means the Arabic site does not drift away from the English one every time somebody ships a change.
Then decide what must not flip. Back and forward arrows, breadcrumbs, progress bars and carousel controls all mirror. Logos, media player controls and icons that depict a real object do not. Phone numbers, prices, product codes, email addresses and Latin brand names stay left to right inside Arabic text, and unless they are isolated properly the browser reorders the characters around them in ways that look like a typo and are in fact the bidirectional algorithm behaving exactly as specified. Test with real mixed content, because these bugs never appear in placeholder text.
Arabic type is not Latin type at a different size
Arabic has no capital letters to create rhythm, sits differently on the baseline, and carries detail above and below the line. Set at the same size and line height as your English copy it reads as a gray wall that people skip. We generally move up a step in size and out to roughly 1.8 in line height, then check the result on a cheap Android screen rather than on a laptop.
Three rules save most projects. Never apply letter spacing to Arabic, because the script is connected and spacing it apart breaks the joins. Never fake bold or italic, because Arabic has neither and the browser will smear the glyphs. And keep body copy at regular weight, since light cuts disappear on low density screens. Cairo, Tajawal, Almarai and Noto Kufi all pair sensibly with common Latin faces if you match apparent weight rather than the number on the label. Subset the font file as well. Arabic families ship large, and an unsubsetted webfont is often the heaviest single asset on the page.
Two languages, two first class experiences
Arabic copy is not English copy translated. It is shorter in characters, wider on the line, different in headline rhythm, and a call to action that sounds confident in English often lands as either blunt or oddly formal in Arabic. Brief a writer. Let the layout absorb text that will never be the same length twice, especially in navigation and buttons.
Structurally, give each language a real URL path, an ar segment and an en segment, with hreflang tags pointing at each other so both get indexed. A cookie based switch that serves two languages from one address gives a search engine one page and hides half your content. Put the language switch where people expect it in the header, and make it keep the reader on the same page rather than dumping them on the homepage. In the content system, treat the two versions as parallel entries with their own titles, meta descriptions and images, not as a field bolted onto the English record.
Planned from day one, proper bilingual delivery adds perhaps fifteen percent to a build. Retrofitted after launch it costs two or three times that. Which is why it is a scoping decision on the first call for every project our website and app development team takes on.
