Short answer: A multilingual website stays maintainable when each shared fact has one source of truth, each language has a clear publishing path, language and text direction are handled as separate properties, translated pages are linked to their equivalents, and the team proves at handover that it can run a real update. Put these decisions in the original brief instead of leaving them until after the first translated page.
This guide is for businesses working across Dubai and the wider region that need a website in English, Arabic and Persian, and for the team that will run it after launch. The documentation linked below was checked on 27 October 2026.
A multilingual website is an editorial and product system. Its quality depends on how confidently a team can update all its languages after launch, as well as how the first translated page looks.
For a business working across Dubai and the wider region, English, Arabic and Persian may serve different audiences and enquiries. A maintainable implementation gives each language a clear publishing path while keeping shared information consistent. The decisions below belong in the original brief.
What should be shared, and what should be written locally?
Separate facts that should remain consistent from content that needs a local editorial decision:
- Keep consistent, from a reliable source of truth: contact details, a service's actual deliverables and approved prices.
- Write for each audience: headlines, examples, terminology and calls to action.
Build an explicit content map. For every service, show which language versions exist, who owns them and what happens when a fact changes. A shared publishing status prevents an English update from silently leaving Arabic or Persian with an outdated offer.
This does not require identical word counts or page structures. It requires equivalent clarity about what the business provides. Automated translation can support a workflow, but the final copy still needs review by someone competent in the language and subject.
How do we handle language and text direction?
Language identification and text direction solve different problems. W3C recommends declaring the document language through the HTML language attribute. It also explains using the direction attribute for documents written right to left.
For the design review, include mixed-script content: a telephone number, an email address, a price, a model name and a sentence containing English terminology. Check that these remain readable in Arabic and Persian paragraphs. Evaluate typography at real reading sizes, not only in a large hero heading.
Plan directional behaviour by component. Navigation, forms, tables, progress indicators and carousels each deserve attention. A blanket visual mirror can produce a page that appears translated while making familiar actions harder to follow.
Building right to left from the first line is an argument of its own, made in Arabic-first, not Arabic-also. This guide covers the architecture around it: content, page relationships, testing and handover.
How should translated pages relate to each other?
Maintain a clear relationship between translated pages. Google documents ways to identify alternate language or regional versions, including hreflang annotations (Google's localized-page guidance). These help describe the relationships; they do not replace good translations or guarantee a ranking.
When a visitor changes language, aim to take them to the equivalent content where it exists. If no equivalent is published, use an understandable fallback instead of pretending that a different page is a translation. Keep the URL mapping with the content model so it survives redesigns and supplier changes.
Search implementation also needs an editorial check. Confirm that titles, descriptions and visible content correspond to the language being published. Do not label an unfinished English page as Arabic simply because its navigation has been translated.
How do we test complete tasks in each language?
Review the journeys that matter to the business. Can a visitor understand the service, inspect relevant work and send an enquiry? Do validation messages, confirmation states and follow-up instructions make sense in the selected language?
Accessibility is part of this review. W3C's accessibility tutorials cover practical concerns such as page structure, images, forms and menus. Use these principles to assess labels, reading order, keyboard use and understandable feedback. An automated check can help find issues, but it should not be described as complete accessibility verification.
Include representative content lengths. A design that fits a short English label may behave differently with Arabic or Persian. Use actual copy and realistic images before approving the components.
How do we measure the experience on representative pages?
Google's Web Vitals guidance distinguishes measurable aspects of user experience. Treat performance as an observed property of the implemented pages, not a consequence of selecting a particular framework.
Agree the pages and conditions to test: a service page, a long guide, an image-heavy project and a contact journey in the supported languages. Where field data is unavailable, record that limitation and use lab measurements for diagnosis. Recheck after major content or design changes, since new media and scripts can change the experience.
What should a handover session include?
Ask the delivery team to demonstrate a routine update with the people who will operate the site. Add a translated service, change a shared contact detail, preview both directions and publish through the agreed approval process.
The handover should include account ownership, content export, deployment and recovery instructions, known limitations and a maintenance schedule. Name the person or team responsible for translations, dependency updates and incident response. Documentation is most useful when a colleague can follow it to complete a real task.
How do we start planning?
Plan a multilingual website with 4AI, with UI/UX design and SEO/GEO implementation considered alongside the content workflow from the start.
Frequently asked questions
Must every page launch in all three languages?
Prioritise the journeys your audiences need and publish complete versions. Keep the relationship between available translations clear.
Is RTL support only a visual issue?
No. It also affects text direction, component behaviour, forms and testing. Include mixed-script examples in acceptance checks.
Does hreflang make a translation rank?
It describes language or regional alternatives. Content relevance, discoverability and the implementation still matter.
