Arabic Is Not a Translation Layer

A bilingual product is not an English interface with Arabic text inserted later. Language changes more than the words on screen. It changes direction, hierarchy, rhythm, typography, navigation, and sometimes the order in which information makes sense.

When Arabic is postponed until the end of a project, the result may technically support RTL while still feeling like a mirrored English product. Layouts become fragile, labels are compressed, icons point in the wrong direction, and important journeys receive less attention in one language than the other.

The better approach is to treat both languages as product requirements from the beginning.

Two languages create two interfaces

English and Arabic can share one product model, one component system, and one codebase. They should not be expected to produce identical screens.

A heading that occupies one line in English may need two in Arabic. A compact English action may become a longer Arabic phrase. A dashboard that feels easy to scan from left to right needs a deliberate hierarchy when read from right to left.

This is why simple mirroring is not enough. Direction changes where the eye begins, but good hierarchy still has to be designed. Before polishing components, I ask a more useful question: what should the user notice first in each language? The answer should guide alignment, spacing, grouping, and action placement.

Begin with journeys, not translated strings

Localization often starts with a spreadsheet of labels. That is necessary, but it is too late to discover whether the underlying experience works in both languages. Start with the product journeys instead:

• How does someone find the service they need?
• What information must they understand before continuing?
• Where do they enter names, phone numbers, prices, or addresses?
• Which content may contain both Arabic and English?
• What happens when validation fails?
• Which confirmation gives the user confidence that an action succeeded?

Mapping these journeys exposes structural requirements before they become layout bugs. An Arabic-first form may still contain an English email address, a Latin product code, or a mixed-language location. The page direction can be RTL while an individual input needs LTR behavior. That distinction belongs in the product specification, not in a last-minute CSS fix.

The same principle applies to empty states, notifications, invoices, generated documents, and transactional messages. They are part of the experience even if they are not visible in the first design presentation.

Make direction a system concern

Direction should be established at the document level with the correct lang and dir values. Components should then inherit that context wherever possible. Logical CSS properties help the interface respond naturally:

• margin-inline instead of left and right margins
• padding-inline for horizontal component spacing
• inset-inline-start for positioned elements
• text-align: start rather than fixed left alignment
• directional layout primitives instead of one-off overrides

This keeps direction inside the system rather than spreading RTL patches across individual pages. Icons need judgment. A back arrow, progress arrow, or breadcrumb chevron usually follows reading direction. A play symbol, brand mark, chart, photograph, or familiar application icon usually should not be mirrored automatically.

Typography also deserves its own tokens. English and Arabic typefaces do not always share the same visual size, line height, or weight. A single numeric font value can produce two very different results. Language-aware type tokens create a more consistent hierarchy without forcing every component to carry custom exceptions.

Design components for real content

A component library can support both languages only if it is tested with realistic content. Fixed-height cards are a common failure point. They look controlled in a design file, then break when a translated heading wraps. Buttons with rigid widths can clip labels. Navigation items can collide. Decorative treatments can overlap text when the content grows.

I prefer components that tolerate expansion:

• Content-driven height
• Clear minimum sizes for interactive controls
• Flexible gaps and predictable wrapping
• Truncation only where the complete value is available elsewhere
• Layout changes at useful breakpoints, not only smaller font sizes

Real Arabic copy should enter the design process early. Placeholder text hides differences in word length, punctuation, line breaking, and visual density. Mixed-direction content needs explicit testing too. Phone numbers, email addresses, URLs, currency values, dates, and reference codes can appear inside Arabic sentences. They should remain readable without confusing punctuation or reordered characters.

Give forms, tables, and navigation special attention

These components carry more directional complexity than a normal content block. In forms, inspect label alignment, required markers, helper text, error messages, input direction, dropdown arrows, password controls, and focus order. Keyboard navigation should follow the DOM structure even when the visual layout changes direction.

For tables, decide whether the meaning of the columns follows reading direction or a familiar domain convention. Confirm how wide datasets behave on small screens. Horizontal scrolling should begin at the useful edge, headers should remain understandable, and row actions should not disappear outside the initial view.

Navigation needs the same care. Menus, breadcrumbs, pagination, drawers, and previous or next article controls all communicate direction. Their labels, icons, animation origins, and focus sequence should agree. A bilingual product feels coherent when these details behave consistently across the whole system.

Give Arabic an editorial pass

Correct translation and good product writing are different tasks. Interface copy should be concise, clear, and appropriate to the people using the product. A literal translation can be grammatically valid while sounding unnatural or carrying the wrong level of formality.

The Arabic version needs an editorial review in context. Reviewers should see the complete screen and understand the user’s goal. That makes it possible to improve terminology, shorten actions, remove ambiguity, and keep the tone consistent.

Important domain terms should be agreed early and reused. If a service, financial concept, workflow status, or permission is described differently from one screen to another, users have to relearn the product as they move through it. A small terminology list often prevents a large amount of inconsistency.

Test complete journeys in both directions

A bilingual interface is not ready because the home page looks correct in both languages. Test complete tasks:

1. Enter through a localized route.
2. Move through navigation and menus.
3. Complete a form with valid and invalid data.
4. Open a modal or drawer.
5. Read loading, empty, error, and success states.
6. View generated output such as an invoice or confirmation.
7. Change language during a realistic point in the journey.
8. Repeat the journey on a narrow screen and with a keyboard.

Use real content and long-content cases. Include mixed Arabic and English values. Check focus visibility and screen-reader language changes. Test whether the selected language survives navigation and return visits. This is where a product moves from “supports Arabic” to feeling intentionally bilingual.

A practical release checklist

Before launch, I want clear answers to these questions:

• Do both languages cover the same important journeys?
• Are lang and dir correct on every localized route?
• Are typography and spacing appropriate in both scripts?
• Do navigation, icons, drawers, and transitions respect direction?
• Can forms handle Arabic, English, and mixed-direction values?
• Are validation and system messages localized?
• Do tables and dashboards remain usable on mobile?
• Have loading, empty, error, and success states been reviewed?
• Has a fluent Arabic reviewer tested the product in context?
• Can the team update translations without changing layout code?

The goal is not to make two interfaces look mathematically identical. It is to make both feel equally clear, dependable, and complete. When language is treated as part of the product architecture, bilingual work becomes easier to maintain and much harder to break.