Test complete tasks in both languages, not just the appearance of two homepages. Arabic may look correct while the language switch opens a different service, a form error appears only in English or the offer's limits differ between versions. Bilingual release acceptance needs scenarios, owners and pass/fail evidence alongside visual review.
Start with commercially important journeys: understanding an offer, downloading a document, submitting an enquiry and finding branch information. Define pages, devices, browsers and languages covered, together with exclusions. Do not describe limited sampling as “testing the entire website,” or postpone Arabic review until after English has been approved.
Three complementary layers
Meaning: Are services, exclusions, dates and figures consistent? Sentences need not be literal translations, but one language must not promise what the other excludes. Review names and numbers with the factual owner, not only the designer.
Presentation: Does text, table and mixed-script direction work? W3C distinguishes document language from direction: declaring a language does not automatically set text direction. W3C direction guidance. Check phone numbers, email addresses and model codes inside Arabic sentences, not only uninterrupted Arabic paragraphs.
Behavior: Do navigation, forms, messages and downloads meet the requirements? A translated button label does not establish a correct destination. Quality Assurance connects these layers to repeatable acceptance criteria rather than a general impression that the site looks fine.
Build a realistic coverage matrix
| Scenario | Arabic | English | Evidence of success |
|---|---|---|---|
| Open a service from a direct URL | Test | Test | Correct service and complete content |
| Switch language within a service | Both directions | Both directions | Correct counterpart, not the homepage |
| Submit valid data | Test | Test | Acceptance and expected receipt |
| Omit a required field | Test | Test | Understandable feedback and correction |
| Download a file | Test | Test | Correct approved document |
| Use mobile navigation | Test | Test | No clipping or obstruction of the task |
Add cases exposing meaningful differences: a long title, table, mixed-script content, captioned image and page without a translation. Do not list devices that cannot actually be tested. Record environment, release and test method, distinguishing simulation from a physical phone.
Hypothetical example: switching language during an enquiry
Imagine a visitor opening an Arabic service page and selecting English before submitting a quote request. This is illustrative, not a LAB website test result. Requirements should define the destination, what happens to entered data and how any expected loss is communicated before it occurs.
In the first test, the switch opens the English homepage. Technically, the link works, but service context disappears. In the second, the counterpart opens but the form's service list contains old names. In the third, the success message is correct while the enquiry goes to a different team from the approved destination.
These are separate defects with different owners and retests, not one vague “translation problem.” The reviewer also checks that English does not promise a response time absent from Arabic. Authorized test data replaces real customer information. If retaining input during a language change is outside scope, the behavior must still be explicit and acceptable rather than an assumed feature.
Treat direction as component behavior
Website Design needs specifications for mixed-direction cases: back arrows, playback icons, step sequences, tables and long menus. Do not mirror every symbol merely because the surrounding page is Arabic. Check its meaning and function. Enter an Arabic name and Latin email address, then inspect their appearance in the received enquiry.
W3C's forms guidance addresses labels, instructions and notifications that help people complete tasks and correct errors. W3C forms tutorial. Review more than a red color or required-field asterisk. Users should understand what is required, what failed and how to reach the relevant control within the agreed evaluation scope.
A screenshot cannot establish these behaviors. It may show alignment but not keyboard order, an error state or what happens after submission. Use visual evidence where useful while recording the actual steps and observations needed to reproduce the result.
Verify the page relationship in the CMS
CMS Development should provide a clear way to connect counterparts, identify missing translations and avoid publishing an incorrect association. Trial a title or route change and confirm that the language switch does not retain an obsolete destination. Good copy can still sit inside a broken content relationship.
For search-specific signals, Google explains that hreflang relationships require reciprocal references between localized pages. Google's localized-page guidance. Verify implementation through SEO and AI Search Readiness, but do not treat a passing signal check as proof of translation quality or guaranteed visibility.
Report defects that can be repaired
Record URL, language, environment, reproduction steps, expected result and actual result. Attach evidence without sensitive data. Assess consequence: inability to submit an enquiry matters more than a spacing difference that does not hinder reading. Agree release blockers and explicitly accepted deferrals, then retest the repair and affected surrounding journey.
Handover should identify coverage, passes, failures, exclusions, the tested release and the authorized release decision. Do not claim universal accessibility or legal compliance from this exercise. Accessibility evaluation has its own defined scope and criteria; a release checklist is not a blanket certification.
Frequently asked questions
Is an English-only reviewer sufficient?
Not for responsible Arabic meaning and direction review. Use reviewers qualified in both languages, with a factual owner to resolve commercial meaning.
Must every page have a translation?
That is a scope decision. Untranslated pages still need an understandable language-switch behavior, rather than an invented counterpart answering a different question.
Is desktop success enough?
Not when mobile use is part of the intended experience. Test agreed devices and sizes, especially menus, fields and long text.
When should testing be repeated?
After a material repair, template change or language-relationship change, and on the final release under the plan. An old report does not establish quality for a changed version.
Before release approval
Share the important journeys, pages and approved content sources with LAB. Request bilingual acceptance connecting each finding to a task, evidence and owner, rather than a quick review of two homepage screenshots.
Sources
- W3C: HTML text direction.
- W3C: forms.
- Google: localized page versions. Reviewed 26 October 2026. These support the specific technical points, not the quality of an untested website.
