A customer completes an Arabic form, receives an English error message and forwards a screenshot to an employee whose dashboard uses a third name for the same status. Every individual screen may look finished. The journey still leaves people translating the product to one another.
Consider a hypothetical business serving customers in Saudi Arabia, with an Arabic-speaking sales team and developers in Egypt working mainly with English technical documentation. This is a design scenario, not a claim about a particular client. It shows why a bilingual workflow needs shared meanings and deliberate language choices before visual polish can finish the job.
Agree on the meaning before choosing the words
Start with a short vocabulary of business states and actions. If a request says “under review,” identify who is reviewing it and whether the customer needs to do anything. The Arabic wording should express the same situation without copying an English phrase that sounds vague in context.
I would store a stable internal identifier for the state, then associate the appropriate customer and employee labels with it. A wording improvement should not require changing the business record itself. Customer copy may be simpler than the operational label, provided both point to the same agreed meaning.
For our example, “بانتظار مستند منك” is more actionable than “قيد المعالجة” when the customer actually has to upload something. The improvement comes from understanding the state, not from selecting a more impressive translation.
Decide what the language choice controls
The current page language, the customer’s communication preference and an employee’s dashboard language can differ. Treating them as one setting creates questions the product cannot answer clearly.
Suppose a customer opens an English page because a colleague shared its link, then completes the form in Arabic. Which language should the confirmation use? I would define a clear default, let the customer change the communication preference where appropriate, and persist that choice independently of the link they followed.
Also decide what a language switch preserves. In this example, switching should not unexpectedly discard an unfinished form. If a particular step cannot preserve entered data, tell the person before they lose it. The language control is part of the workflow and needs its own acceptance example.
Keep reference codes readable and usable
An Arabic paragraph may contain an email address, an English company name and a reference such as SA-2048-A. Check the displayed order, surrounding punctuation and what the customer gets when copying the reference.
The W3C recommends direction-aware markup around opposite-direction phrases and dir="auto" or bdi for inserted text whose direction is unknown. These mechanisms help isolate mixed-direction content. W3C guidance on bidirectional text.
In the hypothetical form, I would provide a dedicated copy action for the reference and test a pasted Arabic name beside it. Correctness includes the email, the printable view and the employee dashboard, because people carry identifiers between all three.
Write validation for the actual correction
“Invalid input” does not explain whether a phone number needs a country code, whether spaces are allowed, or whether a field expects a business name in a particular script. Define the accepted value first; then write a message that helps somebody provide it.
For Saudi and Egyptian phone inputs, test the supported local and international forms explicitly rather than assuming one shared length. If the system normalizes accepted formats, confirm the stored value still represents the number the person intended. Avoid changing a person’s name or an official reference merely to make an English-only rule pass.
The same care applies to dates and money. State the currency, make ambiguous dates readable and distinguish the time shown to a customer from the operational deadline. These are product decisions to settle with the business, not formatting defaults to inherit accidentally.
Test a handoff across languages
I would finish by asking two people to follow the same sample request: one as an Arabic-speaking customer and the other through the employee interface. Can they identify the same request, understand its current state and agree on the next action without translating unexplained labels themselves?
Test at least one correction, one interrupted submission and one language switch. Record the expected wording and behaviour together so that later content edits do not quietly weaken the interaction.
A bilingual product is ready when people can complete and coordinate the work in either language. My OVZA case study shows the customer and operational connections that inform how I think about these design questions.
Frequently asked questions
Is an Arabic interface only a translation task?
No. Review text direction, mixed-language references, forms, notifications and operational handover in both languages.
Which language should be tested first?
Test the language and real scenarios your users rely on, then verify that the other language completes the same journey. Do not treat either version as an untested copy.