Keep these in mind
The essentials, at a glance.
Start with the customer journey
Make content and controls work together
Test the real page on a phone
Choose the journeys before counting pages
List the tasks a visitor should be able to complete: understand a service, compare products, request a quote or book a conversation. Identify which languages your actual customers use and which team can handle the resulting enquiries. Two language buttons do not automatically mean twice the audience or more sales.
Start with an inventory of essential pages and their matching versions. Include the navigation, contact details, form labels, error messages, confirmation screens and important downloadable material. A translated service page that leads into an unexplained English form is an incomplete journey.
Treat translation as an editorial decision
Agree who writes, translates and approves each version. Provide the translator with the offer, audience, brand voice and approved terminology. A literal phrase may be grammatically valid while missing the intended meaning. Business names, product labels and technical terms need consistent treatment.
For a practical pilot, choose one important service page and its enquiry form. Ask a fluent reviewer to check meaning, tone and the next step in context. Automated translation can support a workflow, but visible text still needs appropriate review before publication. Keep a short glossary and a record of approved changes.
Design for reading direction and real content
Arabic and English can require different text flow, spacing and navigation treatment. Review a layout using actual approved copy rather than assuming both versions fit the same headline box. Choose fonts with suitable character support and test line height, weight and small interface labels on a phone.
Ask the developer to handle language and direction deliberately. W3C’s language guidance explains declaring a page’s language; its direction guidance explains setting the base direction for right-to-left content. These are different responsibilities. Right-aligning a text box alone is not a complete Arabic layout implementation.
Mixed content deserves its own check: phone numbers, email addresses, product codes and prices can appear alongside Arabic text. Test the actual combinations, including punctuation and copy-and-paste behaviour. Review directional icons by meaning rather than mirroring every symbol automatically.
Make changing language predictable
A customer who switches language on a service page should, where an equivalent exists, reach that service in the other language. Avoid sending every switch back to the homepage. Use clear language names and give people control over their choice.
Decide what happens when a page has not been translated. A useful fallback should make the situation clear without disguising untranslated content as a complete alternative. Test the switch from menus, product pages, articles and the booking route, including the browser back button.
Plan the search structure with the build
If search discovery in both languages is a goal, discuss the address structure before development. Google’s multilingual-site documentation recommends separate URLs for language versions and explains the role of hreflang annotations. A visual language selector does not by itself establish separately discoverable pages.
Ask for a map of matching pages and a review of titles, descriptions, internal links and language annotations. Keep the main content and enquiry information useful in each language. Translating a list of keywords or repeating city names does not replace a readable service explanation. These technical choices support discovery; they do not guarantee a position in search.
Test the form and the handover
Test realistic entries in both languages. Can someone enter a name, choose a service, understand a validation error and see a confirmation? Does the receiving team get a readable message and know the customer’s preferred language? Check the mobile keyboard and any third-party booking or payment step separately.
- Review each essential page with a fluent reader.
- Check menus, buttons, labels, numbers and text wrapping on phones.
- Follow the enquiry route from each language version.
- Verify receipt through an agreed test procedure.
- Assign an owner to update both versions when the offer changes.
Record button clicks separately from enquiries actually received and projects booked. Do not send personal form contents into routine analytics labels. A successful test of the page layout is not proof that enquiry delivery has been tested.
What to send with your website brief
Bring your current website, priority customer journeys, required languages, existing copy, translation responsibilities and any third-party systems involved. Identify the pages that must launch together and those that can follow later. Your proposal should define content ownership, review responsibilities, delivery scope and maintenance.
Explore ABAB’s web design and development service in Dubai, discuss brand identity and design consistency, or connect the build to SEO and digital marketing priorities. If the project changes existing page addresses, our website redesign redirect checklist covers that separate planning step.
Bring both language journeys into the brief.
Book a website project conversation or send your requirements to ABAB. Start with the pages and customer tasks that matter most.
Have a project taking shape?
Explore web & ecommerce with ABAB, or bring your questions to a project conversation. We will help define the next useful step.
