Arabic and English Platforms: What to Get Right Early

If your customers read Arabic and English, your platform has to work properly in both. Not "translated later". Not "Arabic version coming soon". Both, from the first release.

Many teams underestimate this. They build in English, add Arabic at the end, and find that half the screens break when the layout flips to right-to-left (RTL). Fixing it late is slow and expensive.

This guide is for owners and CTOs planning a platform for users in the Gulf, North Africa or anywhere Arabic and English sit side by side. It covers the decisions to make before design starts, a technical checklist you can hold a partner to, how to test, and the questions to ask before you hire. It draws on bilingual platforms we have built.

Why bilingual is harder than it looks

Translating text is the easy part. The hard parts are:

• Layout direction. Arabic reads right to left. Navigation, icons, progress bars, tables and form layouts all need to mirror.

• Mixed text. Arabic sentences often contain English product names, numbers, emails and URLs. Without care, punctuation jumps to the wrong side and numbers display in the wrong order.

• Content, not just interface. Courses, product descriptions, event pages and emails all need two versions, managed by real people in an admin panel.

• Documents. Invoices, certificates and other PDFs must render Arabic correctly, with joined letters and the right direction.

• Search and SEO. Each language needs its own URLs and metadata.

Decide which language leads

Before design starts, decide which language is primary. It sounds minor, but it shapes the whole project.

Marafiq, a training platform for facilities-management professionals in Riyadh, is Arabic-first. Arabic is the default experience, and English is the second language.

On GrowFast, a startup accelerator platform, traffic between Arabic and English is close to even. Both languages had to be treated as equals, from programs and applications to events and jobs.

Knowing this early tells designers which layout to start from, tells content teams which language to write first, and tells developers which direction to test by default.

The technical checklist

This is the checklist we work from. If a partner cannot explain how they handle each point, treat it as a warning sign.

Layout and styling

• Set dir="rtl" and lang="ar" on the <html> element, not on individual blocks. The browser then lays out text, tables and form controls in the right direction.

• Use logical CSS properties such as margin-inline-start and text-align: start instead of left and right, so one stylesheet works in both directions. Tailwind has matching utilities (ms-4, pe-2) and rtl: variants for the exceptions.

• Mirror directional icons such as arrows, chevrons and "back" buttons. Do not mirror logos, media controls, checkmarks or charts with a time axis unless your users expect it.

• Pick an Arabic typeface designed to pair with your Latin one, and test it at small sizes. Arabic usually needs a larger font size and line height to read comfortably.

• Never apply letter-spacing to Arabic text. It breaks the joins between letters.

Mixed-direction text and forms

• Add dir="auto" to free-text inputs, comments and user-generated content, so each entry takes the direction of its own first strong character.

• Keep email, URL, phone and code fields left-to-right, even on Arabic pages.

• Wrap user names and other embedded values in <bdi>, so an English name inside an Arabic sentence does not scramble the punctuation around it.

Numbers, dates and currencies

• Decide between Western digits (0–9) and Eastern Arabic digits (٠–٩) for each market, and apply that choice everywhere. Locale-aware formatters choose a digit system by default, and the default may not match what your users expect, so set it explicitly.

• Accept both digit systems in inputs such as phone numbers and amounts, and convert them before validation. Many users on Arabic keyboards type Eastern Arabic digits.

• Format dates and currencies per locale, and decide whether you need the Hijri calendar anywhere, for example on booking or event dates.

Content and data

• Store translatable fields per language in the database, so editors can manage both versions in the admin panel.

• Decide what happens when a translation is missing: hide the item, show the other language, or block publishing.

• Plan search for both scripts. Arabic search usually needs normalization, for example treating the different forms of alef as the same letter.

URLs and SEO

• Give each language its own URL prefix, such as /en/ and /ar/.

• Add hreflang tags, including an x-default, so search engines know which pages are translations of each other.

• Write separate titles and descriptions for each language. Do not machine-translate metadata and forget it.

Payments

• Offer the payment methods your market uses. Marafiq offers card payments through Stripe and buy-now-pay-later through Tamara, which is common in Saudi Arabia. GrowFast accepts Stripe and Alipay.

• Translate checkout pages, receipts and payment emails fully. This is where trust matters most.

Emails and PDFs

• Send emails in the user's chosen language. Set dir and align attributes on the email's HTML and table elements, because many email clients ignore logical CSS properties. Test in the clients your users actually use.

• Not every PDF library shapes Arabic letters or handles right-to-left text correctly. Choose one that does, embed an Arabic font, and test with real names that mix scripts. Marafiq generates its completion certificates, with a serial number and a QR code for public verification, through a PDF engine with Arabic support.

When you need more than two languages

Omraty, an Umrah and travel booking platform we built (not yet launched), supports five languages: Arabic, English, French, Russian and Turkish, with RTL for Arabic and prices in the visitor's currency.

The work you do for two languages pays off here. A platform built with proper translation storage and logical layout can take a third language mostly as a content task, not an engineering one.

Common mistakes

How to test a bilingual platform

RTL bugs are easy to miss because developers often work in English all day. A few habits catch most of them:

• Demo in both languages. Every weekly demo should show at least one new screen in Arabic.

• Write automated tests per locale. Feature tests can load key pages in each language and check the text, the dir attribute and the URLs. They also catch strings that were never translated.

• Use real content, not placeholder text. Arabic and English versions of the same label differ in length. Buttons, menus and table headers that look fine with sample text can break with real copy.

• Test on phones. Many users in the region browse mostly on mobile, and overflow and wrapping problems show up there first.

• Ask native speakers to use it. Before launch, have a few people who read Arabic daily go through sign-up, checkout and the main flows. They will spot wording and layout issues that a checklist will not.

What to ask a software partner

We wrote a general guide on what to ask a software agency. For bilingual platforms, add these questions:

1. Can you show me a live platform you built in Arabic and English?

2. Does your team read Arabic, or will someone outside the team check it?

3. How do editors manage content in both languages in the admin panel?

4. How do you handle RTL in PDFs and emails?

5. Which digit system will you use, and how will forms accept the other one?

6. Which local payment methods have you integrated?

Our team works in English, French and Arabic, which helps when reviewing content and layouts in each language.

How to start

The cheapest moment to get bilingual right is before design starts. Our Discovery sprint takes one to two weeks and costs $1.5k to $4k. It covers workshops, a feature specification, the architecture and a clickable prototype, and ends with a fixed estimate. For a bilingual platform, ask to see the prototype in both languages, so layout problems are found before any production code is written. The fee is credited in full if the build starts within 60 days.

Planning a platform for Arabic and English users? Book a consultation to talk through your project, or request a quote.