Building bilingual products from day one

Designing for multiple languages is not an afterthought — it is a foundational decision that shapes your architecture, UI, and content strategy.

Adding Arabic to a product that was built English-first is not a translation task. It is re-engineering. Teams that postpone the decision pay for it twice: once in the code, and once in a user experience that comes out distorted.

Why "we'll add Arabic later" fails

The problem is not the strings. The problem is that right-to-left flips many assumptions buried in your design and code: margins, directional icons, table column order, chart direction, dropdown positioning, even horizontal scroll logic. When those assumptions are built LTR-only, RTL support becomes a chain of fragile exceptions that breaks with every new feature.

Seven decisions to settle on day one

1) Keep strings out of the code: every user-facing string lives in translation files — including error messages, confirmation button labels and transactional emails. Hardcoded text is the single most common reason English words show up inside an Arabic interface.

2) Use CSS logical properties: write margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, and inset-inline instead of left/right. Modern browsers mirror these automatically based on document direction, which removes the need for a separate Arabic stylesheet.

3) Set dir and lang at the document level: the html element carries dir=rtl and lang=ar on the Arabic version, dir=ltr and lang=en on the English one. This is not cosmetic — screen readers and search engines depend on it.

4) Pick a real Arabic typeface: Latin fonts contain no Arabic glyphs, and falling back to a system font means a different look on every device. Choose an Arabic face designed for interfaces, and tune line-height separately, because Arabic needs more vertical breathing room than Latin.

5) Numbers, dates and currency: decide early whether you render Eastern Arabic numerals or Western ones, and how currency and dates are formatted per locale. Use the standard Intl API instead of hand-rolled formatting.

6) URLs and routing: put the locale in the path, such as /ar/services and /en/services, and emit hreflang tags for each version. This stops the two versions from competing for the same keyword in search.

7) Bilingual data in the database: every user-facing field needs both language variants from the first table design. Adding a second column later is far cheaper than rewriting every query and every admin screen.

A ten-minute test

Switch the language on every page and look for four things: an untranslated string, an element still left-aligned inside an Arabic page, an arrow icon pointing the wrong way, and a number or date formatted for the wrong locale. Those four catch most localisation defects before a client sees them.

What we have learned

At Vexxa we build every project assuming it will run in both languages from the first screen. The extra cost up front is small. The cost of retrofitting it after launch is often equivalent to rebuilding the interface.

If you have an existing product and are considering adding Arabic, or you are building something new and want it bilingual from the start, get in touch and we will review your current architecture with you.