Multilingual Website Development in the UAE: Arabic, English, RTL and UX Best Practices

Multilingual website development in the UAE usually means building one site that works equally well in Arabic and English: separate URLs per language, a content model that stores both, right-to-left layouts built with HTML direction and CSS logical properties, Arabic typography, forms, numbers and search that behave correctly, and QA run in each language. Arabic should be designed in from the start, not added as a translated copy.

Most of the effort is in internationalisation: making the codebase, CMS and components language-aware so that adding Arabic does not mean rebuilding templates. Translation is then a content workflow rather than an engineering project.

This guide covers architecture, CMS structure, translation workflow, RTL CSS, typography, forms, checkout, numbers and dates, site search, icons and imagery, and a detailed QA checklist. It deliberately keeps search optimisation brief; for keyword research, hreflang strategy and Arabic content planning, see our Arabic SEO guide for UAE businesses.

Definitions. The W3C describes internationalisation as the design and development of a product or content 'that enables easy localization for target audiences that vary in culture, region, or language', and localisation as adapting it to the language, cultural and other requirements of a specific market (W3C). For a UAE website, internationalisation is the engineering; localisation into Arabic is the content and design work that follows.

What changes between English and Arabic is more than text: reading direction, layout order, fonts and line spacing, number and date formats, how mixed-direction strings display, which icons point which way, how search matches words, and how forms validate input. Every one of these touches templates, components and content, which is why retrofitting Arabic onto an English-only build is usually slower and more expensive than planning it from the start.

UAE context. Arabic is the official language of the UAE (Constitution, Article 7), and UAE-registered ecommerce businesses must provide product information and consumer invoices in Arabic (u.ae). We found no general legal requirement for business websites to be in Arabic, so how much Arabic to publish is a commercial decision; our Arabic SEO guide sets out a tiered framework for it. The technical point is that even a partial Arabic site needs full right-to-left support in every template it uses.

For the difference between translating and localising, see ecommerce translation vs localisation. For multi-market stores in general, see multi-language ecommerce website architecture.

The answer first: use separate URLs for each language. On one domain with language subdirectories, a single codebase and CMS can serve both languages, and every page has a clear Arabic and English address.

Google 'recommends using different URLs for each language version of a page' rather than using cookies or browser settings to change the content language on one URL (Google Search Central). Cookie-based switching also breaks sharing: an Arabic speaker who sends a link on WhatsApp may send their contact the English page.

The answer first: never force visitors from one language to the other. Serve the URL requested, suggest the other language when the browser language indicates it, and let users switch to the equivalent page with one click.

Google advises: 'Avoid automatically redirecting users from one language version of a site to a different language version of a site', because such redirects 'could prevent users (and search engines) from viewing all the versions of your site.' Many people in the UAE use English-language phones but prefer Arabic content, or the reverse, so browser language is a weak signal anyway.

A note on Next.js. The Next.js App Router internationalisation guide shows sub-path routing with all routes nested under app/[lang], dictionaries loaded on the server, and locale detection from the Accept-Language header in Proxy (the file formerly called middleware). Its example redirects requests without a locale to a detected locale (Next.js documentation). Our recommendation: if you use that pattern, limit it to the bare root URL at most, never redirect between /ar/ and /en/ pages, and prefer a suggestion banner. See Next.js website development for the wider stack.

The switcher. Label each option in its own language (العربية and English), not with flags, which represent countries rather than languages. Link to the equivalent page in the other language, not to the home page. If an equivalent does not exist, say so and link to the nearest relevant page. Remember the user's explicit choice in a cookie or local storage, but use it only for suggestions, not for silent redirects.

Search is covered in depth in our Arabic SEO guide. From a development point of view, the build must support the following, generated from the content model rather than typed by hand.

Google's hreflang rules require each language version to list itself and all others, with fully qualified URLs, using ISO 639-1 language codes and optional ISO 3166-1 regions such as ar-AE and en-AE, plus x-default (Google). Annotations that are not reciprocal are ignored, which is why they should come from the same data that powers the language switcher.

The answer first: choose field-level localisation when Arabic and English pages share the same structure, and document-level localisation when the Arabic version needs its own structure, sections or publication timing. Many sites use both: field-level for products and settings, document-level for marketing pages and articles.

Sanity's documentation describes the two approaches as 'a single document with content in many languages' (field-level) and 'a unique document version for every language' (document-level) (Sanity). Contentful uses field-level locales with fallback chains, and an explicitly empty value blocks fallback (Contentful). In Strapi, 'Internationalization can be configured for each content type and/or field' (Strapi).

Whichever platform you choose, check that the admin interface handles Arabic input properly, with right-to-left fields and previews; that editors can see which fields are untranslated; that slugs can be set per language; and that publishing one language does not silently publish the other with fallback text.

For platform selection more broadly, see how to choose a CMS and headless vs traditional CMS.

The answer first: pick one source of truth, translate through a repeatable workflow with a glossary and translation memory, have fluent reviewers approve every change, and release both languages together.

Source of truth. Usually English is authored first and Arabic follows, but for Arabic-first audiences the reverse can be better. Whichever it is, record the source version each translation was based on, so editors can see when the Arabic is out of date.

Glossary and translation memory. A glossary fixes approved Arabic terms for products, services, legal phrases and the brand name. Translation memory reuses approved sentences across pages and keeps terminology consistent. Both matter more in Arabic than in many languages because several valid terms often exist for the same thing.

Fluent review. Machine translation can draft; a fluent Arabic reviewer approves. Google's spam policies list automated translation used to produce many pages 'where little value is provided to users' as an example of scaled content abuse (Google). Review should cover meaning, tone, terminology, layout in context and metadata.

UI strings. Keep interface text (buttons, labels, errors, emails, notifications) in resource files or a translation system, never in components. Use message formats that handle plurals properly: Arabic has more plural categories than English, which simple 'one or many' logic gets wrong.

Release. Treat Arabic as a release target, with its own QA sign-off. A change to an English page that has an Arabic twin should not ship until the Arabic is updated, or the change is explicitly marked as English-only.

The answer first: set lang and dir on the html element, write layout CSS with logical properties, and use the :dir() selector only for the few exceptions.

The W3C advises adding dir="rtl" to the html element 'any time the overall document direction is right-to-left' and says 'Never use CSS to apply the base direction', because markup keeps working when CSS does not load (W3C). It also says to always declare the language on the html element, and not to use a meta element with http-equiv set to Content-Language. Language and direction are separate attributes: do not infer one from the other in code.

Logical properties describe layout by flow rather than physical side. MDN describes the module as controlling layout 'through logical rather than physical direction and dimension mappings' (MDN). margin-inline-start is the left margin in English and the right margin in Arabic, so one stylesheet works for both. Flexbox and grid already follow the writing direction.

The :dir() pseudo-class matches the direction the browser computes, including inherited and dir="auto" values, unlike an attribute selector such as [dir=rtl]. MDN lists it as baseline widely available since December 2023 (MDN). Use it for genuine exceptions, such as flipping a directional icon.

The answer first: whenever text of unknown or opposite direction is inserted into a sentence, isolate it. Use dir="auto" on inputs and blocks of user content, and the bdi element for inline inserted values such as names, product names and order references.

The Unicode bidirectional algorithm treats Arabic letters as strongly right to left, spaces and punctuation as neutral, and digits as weakly directional; the order of runs depends on the base direction (W3C). That is why '+971' in an Arabic sentence can appear as '971+', and why an English product name followed by a number can display in a confusing order.

The W3C recommends dir="auto" for user input and inserted text whose direction is unknown, and the bdi element to isolate inline text. Mark English phrases inside Arabic text with lang="en" so screen readers and fonts handle them correctly.

The answer first: design every component for content that is longer or shorter than the English, and test the Arabic version at every breakpoint.

Arabic text can run longer or shorter than English, depending on the content and the translator, and Arabic fonts often need more vertical space. Components that fit English exactly (navigation bars, buttons, tabs, cards with fixed heights, table headers) are where Arabic layouts break first.

Our recommendations. Avoid fixed widths and heights on text containers. Let buttons grow and wrap. Check the mobile navigation in Arabic, since long labels often force a different menu pattern. Mirror the overall layout (logo, navigation and sidebars move to the right), but do not mirror content that has its own direction, such as charts with time axes, maps and video. Test on real devices; our mobile-friendly website guide covers the general approach.

The answer first: choose an Arabic typeface designed for screens that pairs with your Latin face, load only the subsets and weights you use, and give Arabic text enough line height for its ascenders, descenders and any diacritics.

Many Google Fonts families offer an Arabic subset; in our check of the Google Fonts API in October 2026, Noto Naskh Arabic, Noto Kufi Arabic, Noto Sans Arabic, IBM Plex Sans Arabic, Cairo, Tajawal, Almarai, Readex Pro, Amiri and Changa all returned an Arabic subset. Some families cover both Arabic and Latin, which helps mixed-language text look consistent.

Performance. Self-host or preload the Arabic font only on Arabic pages, limit weights to those you use, and use font-display settings that avoid invisible text. A heavy Arabic font that blocks rendering hurts Largest Contentful Paint for exactly the visitors you built the Arabic pages for. Google's 'good' thresholds are LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less; see website performance optimisation.

Line height and alignment. We found no official numeric standard for Arabic line height, so test with real content rather than copying a Latin value. The Dubai Design System, a government design system, recommends one typeface for Arabic and English, cites WCAG 1.4.12 text spacing (line height at least 1.5 times the font size) and reserves right alignment for Arabic text (Dubai Design System). Avoid letter-spacing on Arabic, which breaks the joined script, and avoid all-caps styles that have no Arabic equivalent.

The answer first: mirror icons that express direction or progress; leave everything else alone.

Material Design's bidirectionality guidance says the most important icons to mirror are back and forward buttons, that progress fills right to left in RTL, and that time is shown right to left in RTL layouts; it says not to mirror icons without direction, clocks, media playback controls or numbers (Material Design). Mozilla's RTL guidelines add checkmarks, product logos, icons containing text or numbers and the order of size dimensions to the do-not-mirror list (Mozilla).

Images. Do not put text inside images; it cannot be translated, searched or read by screen readers. Where an image implies direction (a person looking towards the content, a before-and-after sequence), consider a mirrored or alternative image for Arabic pages, but never mirror photos containing text, logos or recognisable places.

The answer first: every part of a form, including placeholders, help text, validation messages and confirmation emails, must exist in Arabic, and inputs for numbers, emails and IDs must behave predictably in a right-to-left page.

Labels and messages. Translate labels, help text and every validation message; untranslated errors are one of the most common Arabic bugs because they live in code rather than the CMS. Keep labels visible rather than relying on placeholders, which our accessibility guide explains in more depth.

Phone numbers. Default the country code to +971 for UAE audiences, accept spaces and leading zeros, store numbers in a normalised international format, and render them with dir="ltr" so they are not reordered. Accept both Western and Arabic-Indic digits on input and normalise them before validation.

Emirates ID and other identifiers. Ask for Emirates ID only when you genuinely need it, and treat it as personal data under the PDPL. Accept it with or without separators, validate against the format your verification provider documents, and render it left to right. Where identity verification is required, UAE PASS offers authentication to private organisations with a valid UAE trade licence (UAE PASS documentation).

Mixed input. Use dir="auto" on free-text fields so that English typed into an Arabic form displays correctly, and set inputmode and autocomplete attributes so mobile keyboards show the right layout.

Navigation. Mirror the order of navigation items and breadcrumbs. Keep the language switcher in the same place in both languages so users can find their way back. Localise mega-menus, search suggestions and footers as components, so their links stay in the current language.

Checkout. UAE addresses rarely fit Western templates; many customers describe location by area, building, landmark or map pin rather than postcode. Offer an emirate selector, area and building fields, and an optional map pin, all labelled in Arabic on Arabic pages. Payment method names and logos stay as their brands show them. Order confirmation, invoice and delivery messages must follow the order language; for UAE-registered ecommerce, consumer invoices must be in Arabic (other languages optional). See UAE ecommerce checkout optimisation.

Currency. Format AED prices with a locale-aware formatter rather than string concatenation. In our Node.js tests, Intl.NumberFormat with ar-AE and currency AED placed the Arabic currency abbreviation after the number with Latin digits; with en-AE it produces the English 'AED' form. Choose one presentation per language and apply it everywhere, including emails and receipts.

The answer first: do not rely on locale defaults for digits, calendars or separators. Decide the presentation for each language and encode it in your formatting functions.

Digits. The W3C's Arabic layout requirements note that European digits are used in western Arabic-speaking countries such as Algeria and Morocco, and Arabic-Indic digits in eastern ones such as Egypt, Saudi Arabia and Iraq; the UAE is not named (W3C alreq). In our tests with Node.js 22.20 (ICU 77.1, CLDR 47), ar-AE formatted 1234567.89 as 1,234,567.89 with Latin digits by default, while ar-SA and ar-EG used Arabic-Indic digits. Defaults depend on the CLDR data shipped in each browser and runtime, so set the numbering system with the -u-nu-latn or -u-nu-arab extension if your design depends on it.

Dates. Gregorian dates are the norm for most commercial content. Show Hijri dates where the context calls for them, for example around religious occasions, and only after confirming the expected calendar variant with the client. The JavaScript Intl API accepts a calendar through the locale's -u-ca- extension. In the same tests, ar-AE formatted 8 October 2026 with the Arabic month name and Latin digits.

Consistency. Use the same formatting functions on the server and the client, so server-rendered and hydrated pages do not show different digits.

The answer first: Arabic site search needs an Arabic analyser with normalisation, or customers who type a common variant will see no results.

Apache Lucene's ArabicNormalizer, which Elasticsearch and OpenSearch use, folds hamza forms of alef to bare alef, taa marbuta to haa and alef maksura to yaa, and removes diacritics and tatweel (Apache Lucene). Elasticsearch's built-in Arabic analyser chains lowercase, decimal digit, Arabic stop-word, Arabic normalisation and Arabic stemming filters (Elastic).

Our recommendations. Index Arabic and English fields with their own analysers. Add synonyms for product terms that have several common Arabic names. Accept Arabic-Indic digits in queries. Return results from both languages' product data where a user searches in Latin script on an Arabic page, for example a brand name. Review zero-result Arabic queries monthly; see ecommerce site search for the wider practice.

Metadata. Store titles, descriptions, Open Graph text and og:locale as localised fields, and fail the build or flag in the CMS when an Arabic page has English metadata. Strategy for what to write in them lives in our Arabic SEO guide.

Structured data. Generate JSON-LD from the localised content, so Arabic pages carry Arabic names, descriptions and URLs, and set inLanguage where the type supports it. Google's guidelines require structured data to be a true representation of the visible page content (Google). Untranslated schema on an Arabic page is a common silent bug, because nobody sees it.

Analytics. Send page language as its own dimension or content group, separate from browser language. Name events in one language (usually English) for consistent reporting, but record the page language as a parameter. Tag CRM leads with the form language. Our guide to AI-search-ready UAE websites covers the server-rendering and content structure that help both search engines and AI systems read each language version.

These scenarios are hypothetical and show how the choices combine. They are not client projects.

Translated text breaking layouts. Fixed-width buttons, tabs and cards overflow or truncate in Arabic.

Base direction set in CSS. The page reverts to left to right when styles fail, and direction-aware components misbehave.

Physical CSS properties. margin-left and left-aligned text create dozens of RTL overrides that drift out of sync.

Mixed-language metadata. Arabic body with English title, description or Open Graph text.

Incorrect hreflang. Missing return links, invalid codes such as AE alone, or hreflang pointing to redirected URLs.

Duplicate pages. Arabic URLs that fall back to English content, or two live slugs for one page.

RTL bugs. Mirrored logos and play buttons, unmirrored arrows, scrambled phone numbers and prices.

Untranslated structured data. English JSON-LD on Arabic pages.

Hard-coded English UI strings. Error messages, empty states, emails and PDFs left in English.

Poor Arabic search. No normalisation, so common spelling variants return nothing.

Auto-redirects by browser language. Users and crawlers cannot reach the version they want.

Placeholder Arabic in QA. Lorem-ipsum-style or machine text hides real length and bidi problems.

Run this checklist on every template, in both languages, on desktop and real mobile devices. It complements the SEO checklist in our Arabic SEO guide and the accessibility checks in accessible UI/UX design.

Bilingual builds go wrong when Arabic is treated as a late translation task. When comparing partners, ask to see right-to-left work in production, how they structure content for two languages, who reviews Arabic copy, and how they test bidirectional text. Our guides to choosing a web development company in Dubai and web development in Abu Dhabi include scorecards you can use, and GEO for UAE businesses covers how AI search reads each language version.

Google: Managing multi-regional and multilingual sites; hreflang documentation; Spam policies; Structured data guidelines; Core Web Vitals.

Standards and references: W3C, structural markup and right-to-left text; W3C, language declarations; W3C, Unicode bidi basics; W3C, localisation vs internationalisation; W3C Arabic and Persian layout requirements; MDN, CSS logical properties; MDN, :dir(); MDN, Intl.NumberFormat; Material Design bidirectionality; Mozilla RTL guidelines; Dubai Design System typography; Apache Lucene ArabicNormalizer; Elasticsearch language analysers.

Platforms: Shopify languages; Shopify Markets SEO; Shopify Arabic auto-translation; WPML URL options; Sanity localisation; Strapi internationalisation; Contentful locales; Next.js internationalisation.

UAE: UAE Constitution, Constitute Project; u.ae consumer protection; UAE PASS documentation. Number and date outputs were tested in Node.js 22.20 (ICU 77.1, CLDR 47) and may differ in other runtimes. This guide is not legal advice.

A good bilingual website in the UAE is built bilingual: separate URLs per language, a content model that holds both, direction set in HTML and layout written in logical CSS, Arabic typography, forms, numbers and search that work as Arabic speakers expect, and QA that treats Arabic as a first-class release. Get those foundations right and adding or updating Arabic content becomes routine editorial work rather than a rebuild.