UAE VAT invoice requirements for online stores in Dubai: what your checkout has to produce
What a VAT registered online store in the UAE must show on its tax invoices, and how the electronic invoicing rollout affects web shops.
Read the articleAn Arabic and English website in Dubai needs its own URL for each language, hreflang tags that link those URLs together, and a right to left build for the Arabic pages that goes beyond a mirrored layout. Get the structure right first, then handle direction, fonts and forms, and set up a process so one language does not fall behind the other. Skipping these steps produces a site that reads as an afterthought in Arabic, even when the translation is good.
This article covers marketing websites. It is not legal advice. Sworn or certified translation for contracts, court documents, notaries or government submissions in the UAE must be done by a translator or translation house licensed by the UAE Ministry of Justice, never by a website team.
Key points
- Put Arabic on its own URL, for example a /ar/ subdirectory, and link every English page to its Arabic equivalent with hreflang.
- Google detects a page’s language from its visible text, not from the lang attribute or the URL, so the Arabic content still has to be real.
- Right to left is a whole layout system: the html dir attribute, CSS logical properties, and explicit direction on numbers, icons and mixed Latin text.
- Arabic script needs different fonts and more line height than Latin text of the same point size to stay readable.
- A single content model with a translation status field keeps Arabic and English pages from drifting apart after launch.
URL structure for an Arabic and English website
Google’s guidance on multilingual sites sets out four ways to organise language versions: a country domain, a subdomain, a subdirectory or a URL parameter. It describes country domains as clear on geography but limited to one country and one server, subdomains as flexible but less obvious to users, and subdirectories such as example.com/ar/ as simple to set up with low maintenance. It states plainly that URL parameters such as ?lang=ar are not recommended, because they make it harder to segment content by language and give users no clear signal about what they will get. For most Dubai and UAE businesses building an Arabic and English website, a subdirectory such as /ar/ mirroring the English path structure is the practical, low maintenance choice.
The same guidance is direct about redirects: it advises against automatically sending users from one language version to another, since that can stop users and Googlebot reaching every version, and recommends a visible link or switcher instead. It also warns against adapting content by IP address, calling that approach unreliable, which matters on a Dubai website where an Arabic and an English speaking visitor share the same office network.
The URL tells Google where the Arabic page lives. It does not tell Google what language the page is written in.
That point changes how a build team should think about the whole project. Google’s documentation is explicit that it determines a page’s language algorithmically from the page’s own text, not from the lang attribute, the URL pattern or hreflang. A convincing URL structure with thin or half finished Arabic content behind it does not read as an Arabic page to Google, or to a visitor.
Hreflang and the x-default that ties the two versions together
Once the URLs exist, hreflang is the mechanism that tells Google which pages are alternate language versions of each other. Google’s documentation on localised versions describes the syntax as a language code, for example ar or en, optionally followed by a region code, so ar-AE or en-AE are valid while a region code alone, such as AE by itself, is not, which is exactly the Arabic and English pairing a Dubai website needs. Annotations can sit in the page head as link tags, in the XML sitemap, or in HTTP headers, and Google treats the three methods as equivalent.
Two mistakes cause most hreflang failures. The first is a missing return link: if the English page points to the Arabic page, the Arabic page has to point back, or Google ignores the pair. The second is applying hreflang between pages that are not genuinely equivalent, such as an Arabic homepage linked to an English service page. Build hreflang from a single list of URL pairs that both developers and content editors can check.
The x-default value has a narrower job than the language codes. Google’s documentation describes it as the page shown to a visitor whose language settings match none of the site’s versions, and says it was designed for language selector pages, so it works best pointing at a selector rather than being scattered across every page pair. On a website with only Arabic and English, many Dubai teams point x-default at the English version as the practical default.
Right to left is a layout system, not a mirror image
The starting point for a right to left build is the html element’s dir attribute. According to MDN’s documentation, dir sets an element’s base text direction, and setting dir=”rtl” on the html tag along with lang=”ar” is the standard way to mark a whole Arabic page as right to left, affecting how text, punctuation and neutral characters are ordered across the page. MDN’s own example shows exactly that pattern: dir=”rtl” and lang=”ar” on the html element, with any English fragment inside it separately marked dir=”ltr” and lang=”en”, which is the basic pattern behind every page of a Dubai Arabic and English website.
Layout code has to follow the same logic. MDN’s documentation on CSS logical properties explains that properties such as margin-left or padding-right describe a fixed physical direction, while logical properties such as margin-inline-start or padding-inline-end describe a position relative to the direction of the text. In a right to left layout, margin-inline-start automatically applies to the right edge instead of the left, with no separate stylesheet needed. Building the Arabic pages on logical properties from the start, rather than a second set of left and right overrides, is what keeps the two language versions in step as the design changes.
| What needs attention | Why a simple mirror is not enough |
|---|---|
| Directional icons | Arrows, chevrons and back or forward icons that imply movement should flip with the layout, while icons for status such as a tick or a warning should not. |
| Charts and graphs | A bar chart or progress indicator that visually implies “more is further right” reads backwards to an Arabic audience unless the axis is deliberately reversed or replaced with labelled values. |
| Numbers and phone numbers | Digits and phone numbers are written left to right even inside an Arabic sentence, so they need explicit direction markup or they can be reordered incorrectly by the browser. |
| Mixed Latin text | An English brand name, product code or email address sitting inside Arabic text needs its own direction so surrounding Arabic punctuation does not attach to the wrong side of it. |
| Forms and tables | Input order, table column order and validation message placement all need to follow the reading direction, not just the label text. |
W3C’s internationalisation guidance on inline bidirectional text describes the underlying problem directly: when a phrase in the opposite direction to its surroundings is not explicitly marked, the browser’s bidirectional algorithm can misplace or reorder neutral characters, digits and punctuation at the boundary. Its recommendation is to tightly wrap every opposite direction phrase in markup, using dir on an inline element such as a span for known text, and the bdi element, or dir=”auto”, for content whose direction is unknown in advance, such as a user’s name. W3C’s companion guidance on the Unicode bidirectional algorithm gives the concrete case of a number that should stay left to right even though it follows right to left text, isolated so the browser does not fold it into the surrounding direction.
The practical version of that advice for a Dubai website: wrap phone numbers, English proper nouns and mixed alphanumeric codes such as tracking numbers in an element with dir=”ltr” wherever they appear inside Arabic body text, rather than relying on the page’s overall direction to sort it out. A phone number that visually reverses its digits is a small bug that undermines trust in the whole page.
Arabic web fonts and line height for a bilingual website
Arabic script is not Latin text redrawn in different letterforms. Most Arabic letters connect to their neighbours and change shape depending on position in a word, and Arabic type carries vowel marks and other diacritics above and below the main letterforms. A font hinted for Latin text and used for Arabic through a generic fallback typically renders these connections poorly on a Dubai website, so the safer route for an Arabic and English build is a typeface that ships proper Arabic glyphs, matched in weight to the Latin font already chosen for the brand.
Line height is the setting that most often gets left at the English default. Because Arabic letterforms carry diacritics that sit further from the baseline than most Latin text, Arabic body copy generally needs a taller line height than the equivalent English paragraph, or diacritics from one line crowd the letters below. Set line height as a separate value for the Arabic stylesheet, checked against a full paragraph, not a single heading line.
Arabic website forms and validation
A contact or quote form is where an Arabic and English website’s shortcuts show up fastest on a Dubai build, because form fields combine text direction, numbers and validation messages in a small space. Labels and placeholder text need to sit on the correct side of their input for a right to left form, which follows automatically from building the form with logical properties rather than fixed left and right values. Phone number and email fields are usually best kept left to right even inside an otherwise right to left form, since a UAE mobile number is read left to right regardless of which language surrounds it.
Validation messages need their own Arabic copy, not a string written for the English character limit and squeezed into the Arabic layout. Arabic words are frequently longer in character count than the English original, so a message sized for an English field can wrap or get cut off in Arabic. Test the Arabic validation text on the actual layout, not as the last step before launch.
Keeping the two versions in step after launch
The build is only half the work. An Arabic and English website drifts the moment someone updates the Dubai homepage in English, changes a service description or edits an FAQ answer, and the Arabic equivalent is not touched the same day. A content model that pairs every Arabic page with its English source, and flags the pair as out of date the moment either side changes, catches this before a visitor does. A simple spreadsheet listing each URL pair and its last update date works as well as a field built into the CMS, as long as the check happens on every content change, not only at launch.
Treat new pages the same way from the start on an Arabic and English website for Dubai, rather than batching translation at the end of a project. A new English page that sits live for weeks without its Arabic equivalent is a visible sign to Arabic visitors, and to Google, that the Arabic site is the secondary version rather than a genuinely maintained one.
Where machine translation fits, and where it does not
Google’s spam policies list automatically generated content among the practices it considers scaled content abuse, and give automated translation published with little human oversight as one of the examples, a real risk for an Arabic and English website built for Dubai in a hurry. That does not rule machine translation out of a bilingual workflow: a draft can genuinely speed up a fluent Arabic writer’s work. What it rules out is publishing that draft as the finished Arabic page. Every sentence that goes live needs a fluent Arabic speaker reading it in context, on the actual right to left layout, checking tone, idiom and the technical points above, before it is treated as equivalent to the English page.
Website translation is also a different service from certified translation. Federal Decree by Law No. 22 of 2022 Regulating the Translation Profession sets up a list of translators and translation houses kept by the UAE Ministry of Justice, and its Article 3 states that no authority may carry out authentication or certification work, and no court may accept a translated document, bond or deed, unless it was produced by a translator or translation house on that list. That rule governs contracts and official paperwork, not marketing website copy. A website team can write and adapt the Arabic pages of a commercial site without being on the Ministry of Justice list, but a document for a court, a notary or a government authority needs a translator licensed by the Ministry of Justice instead.
How Digital Marketing Dubai can help
We build an Arabic and English website for Dubai businesses with the Arabic pages developed alongside the English ones from the first design review, not translated in afterwards, and we test the right to left layout and Arabic typography on real devices before handover. That work sits within our website development service, and our Arabic and English translation team writes and adapts the copy for it, working from a shared content plan rather than a raw word count. If the Arabic side of your site also needs to be found in search, our guide to Arabic SEO and keyword research covers the research behind the Arabic pages once they are live, and broader questions across both languages sit within our web services. Tell us about your site and you will receive a written fixed price proposal within 45 minutes during business hours.
