When commissioning an Arabic version of an existing app, ask for behavior and content specifications alongside layouts. The proposal should explain navigation changes, mixed-direction data, Arabic copy ownership and the boundary between design and implementation. A file containing a flipped version of every screen can still leave the hardest decisions to developers during construction.
Start with a consequential journey, such as adding an address and submitting an order, rather than a screen count. Record entry points, interruptions, messages and shared components. Agree the target platform and versions with engineering: a rule written for an embedded web interface is not automatically an implementation specification for a native app.
Separate three kinds of decision
Layout direction. Where does a list begin? How does someone recognise a return to the previous step? Which item deserves prominence? Avoid a blanket “mirror everything” instruction. Record a rule for each direction-sensitive component and review its meaning with engineering and an Arabic reviewer.
Content direction. An Arabic address can include a Latin building name; an order identifier can combine letters, numbers and punctuation. Preserve the value, reading order and copy behavior rather than rearranging the data to fit the page. For HTML, W3C explains that declaring a language does not automatically establish text direction. This is web guidance, not evidence of every mobile platform’s behavior. W3C structural text direction.
Task behavior. Switching language while editing an address raises different questions from button alignment. Does the draft survive? Does the person return to the same place? Is a submission pending? Specify the intended outcome, then verify feasibility instead of turning every design preference into a technical promise.
Mobile App Design can define these decisions within the agreed app scope. If the task sequence itself is confusing, use User Experience Design to resolve the flow before redrawing screens.
Worked hypothetical: an address and an order code
Consider a delivery app displaying an Arabic neighbourhood name, “Cedar B”, apartment 12, order code DL-2048 and a map pin. This is an illustrative scenario, not a completed LAB engagement or a performance claim.
The team makes three separate decisions. The order code must preserve its sequence when displayed and copied. The long mixed-language address is checked across single-line and multiline presentations, including punctuation. The map is not treated as an image that needs flipping: engineering reviews the meaning and actual behavior of the provider’s controls. A readable address confirmation accompanies location selection so the customer can understand what will reach the delivery team.
The language-switch test begins with an edited, unsaved address. The specification records the before and after states. If preserving the draft is feasible, that becomes an explicit requirement. If the current architecture requires reloading, the team evaluates a way to protect the entry or explain the limitation. The trade-off must not disappear behind a generic “Arabic support” line item.
Test content includes a short Arabic name, a long mixed address, a code pasted from a message and an empty delivery-instructions field. Each has an observable expected result: the full content remains available, the copied value matches, an error identifies the correct field and a brand name does not acquire an unapproved translation.
For the map, the designer supplies a decision record rather than an unsupported platform assertion. The developer confirms which controls are supplied by the provider, which are custom and what can be altered safely. An unresolved provider limitation stays visible in the handoff.
Ask for a reviewable handoff
The package should work at both component and journey level:
- A direction register explaining what changes, what stays fixed and why, including exceptions.
- Approved Arabic and English copy for in-scope loading, error, help and notification states.
- Short, long and mixed-content examples instead of decorative placeholder text.
- Language-switch and interruption behavior, including whether entries survive or are intentionally discarded.
- Open implementation questions, each with an owner and a resolution point before final design approval.
User Interface Design can turn these rules into reusable screens and states. Acceptance of a design file is different from acceptance of the implemented app. Where construction is included, establish a separate implementation review through Software Quality Assurance.
Compare proposals on the same unit of scope
One supplier may offer “twenty Arabic screens”; another may scope one journey with its components, messages and exceptions. Their prices are not comparable until the work units match. Ask both to specify journeys, states, copy sources, third-party coverage, review rounds and whether they check the finished implementation or only deliver designs.
For acceptance, choose tasks that can expose the decisions. Can a reviewer enter the mixed address, correct it, copy the order code and return after switching language without an unexplained change? Can the developer identify the current approved behavior without consulting an old chat? These questions are more useful than whether every screen visually matches its English counterpart.
Common purchasing mistakes include approving Arabic only at the end, assigning review to someone unfamiliar with the product, or pursuing visual symmetry at the expense of important information. A single successful screenshot also does not establish behavior with an open keyboard, enlarged text or a return from an external screen. Include those circumstances where relevant, without claiming coverage that was never performed.
Frequently asked questions
Can we start from the existing English design?
Yes, if the files, components and rules can be inspected and changed. Review the Arabic journey as a complete task, not just a text substitution and alignment exercise.
Should order identifiers and brand names be translated?
Do not change identifiers or approved names automatically. The content owner decides what is translated; the design and engineering team specifies safe display and copying inside Arabic text.
Who approves icon direction?
The designer, engineer and Arabic reviewer should agree based on meaning, context and platform. A general list is insufficient when a custom component behaves differently.
Does RTL design include accessibility testing?
Not automatically. Accessibility requirements can inform design, but testing with specified assistive technologies requires its own scope, skills and evidence. It is not a guarantee for every user.
To begin, bring one real journey, representative mixed content and the platform list. These inputs produce a more actionable brief than asking for an “identical Arabic version”.
Source
- W3C: Structural markup and right-to-left text in HTML, reviewed 26 October 2026; a web-specific reference, not a native-platform guarantee.