Build multilingual from day one, not translated after

"We'll add Arabic later" is one of the most expensive sentences in product development. It sounds like a content task — translate some strings, ship a new locale. In practice it touches layout, data, search, typography, testing and sometimes the product itself.

For products serving the Arabic-speaking world alongside English, language is not a feature. It is architecture.

What "later" actually costs

Layout. Arabic reads right to left. A layout built with hard-coded left and right assumptions has to be reworked component by component. Icons with direction — arrows, progress indicators, back buttons — need mirroring, and some deliberately should not be mirrored. None of this is automatic.

Text length and shape. Translations differ in length, and Arabic script has different vertical metrics from Latin. Buttons clip, headings wrap badly, and carefully tuned typography suddenly looks wrong.

Data. Names, addresses and dates follow different conventions. A data model that assumed one name format, one calendar or one number system needs migrating — with real data already in it.

Search. Arabic has rich morphology and optional diacritics. Search that works for English can fail badly for Arabic unless it normalises letter forms and diacritics.

Mixed direction. Real Arabic content constantly mixes in English: product names, code, numbers, email addresses. Bidirectional text has rules, and content that ignores them renders with punctuation and numbers in the wrong places.

What "day one" looks like

Designing multilingual from the start does not mean translating everything on day one. It means making choices that keep translation cheap.

• Use logical properties. Write layout in terms of start and end, not left and right. Modern CSS supports this directly, and it makes RTL mostly free.
• Keep text out of code. Every user-facing string lives in a resource file from the first commit, even if there is only one language in it.
• Choose fonts for every script you will support. Pair typefaces that work together across scripts, rather than letting the browser fall back to whatever it has.
• Store data neutrally. Dates in a standard format, numbers as numbers, names without assumptions about structure.
• Test with real content early. A single screen with real Arabic content in week two will surface more problems than a full audit in month six.

Language can change the product

Sometimes supporting a language is not just presentation. In a learning product, the mechanics may depend on reading direction or word structure. In a marketplace, trust signals and payment expectations differ by market. Those are product decisions, and they are far easier to make before the product exists.

The takeaway

If a second language is on the roadmap, even a year out, build as if it ships next month. The cost on day one is a few conventions and some discipline. The cost of retrofitting is a rewrite you will be tempted to never finish.