Why translation QA isn't enough for Arabic products

A translator can approve every Arabic string and users can still receive a broken product. The return number inside the approved confirmation may display backward. The payment error may never load the Arabic catalog. The correct button label may clip because the component has a fixed width. An English accessible name may remain on an icon whose visible text was translated.

Translation QA did not fail in those cases. It answered a narrower question: is the target text accurate, consistent and suitable in the context available to the reviewer? Users encounter that text after routing, interpolation, bidi layout, font selection, CSS, formatting and interaction have all changed it.

Arabic products need translation QA, but they also need product QA around it. The useful boundary is simple: translation review approves language; product testing proves that the approved language reaches every state and still works when rendered.

A reviewed string is not a rendered state#

Translation systems organize content as keys, source strings and target strings. Products render routes, components and state transitions. The mapping between them is not one to one.

One approved string may appear in a toast, dialog and inline error, each with different width and accessible markup. One dialog may combine a translated title, a server-supplied message, an interpolated order ID and a component default. A catalog can be complete while the runtime result is not.

This distinction explains several common false passes:

The remedy is not to expand the translator's job until it includes browser debugging. Keep language review focused, then add in-context, technical and interaction testing around it.

Some strings never reach translation review#

The most direct gap is content that bypasses the translation pipeline. It often lives outside the happy path:

• validation created in a form library;
• a payment or identity error returned by a service;
• empty, loading and offline states;
• a component's default placeholder or tooltip;
• image alt text and icon aria-label values;
• a CMS entry with no Arabic variant;
• an email, receipt or downloadable document produced by another service;
• a title, meta description or social card assembled separately from body content.

Page-by-page review rarely finds all of these because the missing strings depend on state. Test the product task and force each branch. For checkout, that means empty cart, unavailable item, invalid promotion, payment rejection, timeout, confirmation and receipt. For search, include loading, no results, malformed query, network error and retry.

R011 reports untranslated interactive labels such as buttons, navigation links, menu items and tabs. R012 reports untranslated placeholders, alternatives, titles, accessible labels and button values. R010 covers broader visible Latin-script body text above its thresholds.

Do not classify every Latin token as a gap. Emails, URLs, product models, legal entity names and approved brands may intentionally remain Latin. The team needs a narrow allowlist or content rule that distinguishes intentional terms from fallback copy. Excluding a whole component because it contains one brand name can hide an English error in the same region.

A useful bug report identifies the source: catalog key, server response, CMS field, component default or metadata generator. "English on Arabic page" is a symptom. The source determines who can fix it.

Fragmented messages force the wrong grammar#

Translation QA cannot produce natural Arabic from a message split into fragments whose order is fixed in code.

Problem

const message = t("delivery.prefix") + date + t("delivery.suffix");

The translator sees two disconnected fragments and cannot move the date relative to the complete sentence. Adding spaces to either fragment creates more ambiguity, especially when punctuation or direction changes.

Better

const message = t("delivery.message", { deliveryDate: date });

Keep the complete thought in one message and give variables meaningful names. The translator can then place deliveryDate where Arabic requires it. Include context about what the date represents and where the message appears.

Plural logic has the same problem. English-style count === 1 branching does not model Arabic plural behavior. The localization runtime should select categories from locale data, and fixtures should exercise every category it can return for the supported Arabic locale. Engineering can test category selection and placeholder integrity. An Arabic reviewer approves the grammar in each resolved message.

Test variables with hostile values, not only a short name. Use a long Arabic name, a Latin name, a date, a return number that starts with digits and a value that ends in punctuation. Confirm that every variable appears exactly once and is not escaped as visible markup.

Avoid asking translators to edit raw HTML unless the localization system explicitly supports safe structured placeholders. Reordered tags, unsafe interpolation and markup that cannot move with the sentence are application concerns disguised as copy.

Correct words can still have the wrong direction#

Direction is a document and markup property, not a translation property. lang="ar" identifies the language and does not make the document right to left; the HTML dir attribute does that, and a CSS direction: rtl is no substitute, because :dir(rtl) does not match it. RTL testing: the complete guide covers those checks. R001 reports an Arabic page whose root direction is missing or LTR, while R002 covers a missing or contradictory root language.

Translation review also sees a string outside the context it will be rendered in, and usually with a friendlier value in its placeholder than production supplies. The browser resolves the finished sentence with the Unicode Bidirectional Algorithm, where digits and punctuation take their direction from what surrounds them.

Problem

<p dir="rtl">رقم طلب الإرجاع 5521-02</p>

Suppose the translation tool previewed this message with the sample value RMA-5521, which starts with letters and displays exactly as written after Arabic text. Production return numbers start with digits, and measured in Chromium 151, 5521-02 displays as 02-5521 after the same label. The Arabic was approved and correct; the preview value hid the failure.

Better

<p dir="rtl">رقم طلب الإرجاع <bdi>5521-02</bdi></p>

<bdi> isolates the value whatever it starts with, taking its direction from the value's own content; a value with no letters, like this one, resolves left to right. Use dir="ltr" when the product knows the value is left to right. The W3C inline bidi guidance recommends tightly wrapping an opposite-direction phrase rather than allowing it to influence adjacent text, and the wrapper belongs around the value alone: one that also holds the Arabic label takes its direction from the label. Review placeholders with production-shaped values: digits first, letters first, and the longest real value. R021 reports unisolated phones, emails and Latin tokens inside Arabic text.

Correct copy can break component geometry#

A translator should not have to shorten an accurate label until it fits a component built around English. That turns a layout defect into a language compromise.

Arabic changes more than string length. Connected glyphs, font metrics and line breaks affect width and height. A server error may be longer than any catalog preview. An icon floated to a physical side stays on that side when the layout becomes RTL, and the message then starts next to empty space.

Direction-relative placement should use CSS logical properties:

Problem

.alert-icon {
  float: left;
  margin-right: 0.75rem;
}

In the Arabic alert the warning icon stays at the left, at the end of the first line rather than beside its first word, and its gap faces the wrong way.

Better when the icon belongs at inline start

.alert-icon {
  float: inline-start;
  margin-inline-end: 0.75rem;
}

The icon now leads the message in both languages. R031 reports physical floats in an RTL context without an override.

The example only applies when the relationship is logical. Physical properties remain right for physical meaning, such as a compass or media timeline.

Run approved Arabic content at the minimum supported viewport, intermediate wrap points, wide layouts and 200 percent zoom. Open menus, dialogs, toasts and validation summaries. Wait for web fonts and API data, then compare element bounding boxes with their containers and the viewport.

Do not hide the result with page-level overflow-x: hidden. Find the element that escapes and fix its sizing or positioning. R040, R041, R042 and R043 report document overflow, text overlap, clipping and fixed-width containers exceeded by Arabic content.

Translation previews and pseudo-localization are useful pressure tests, and a right-to-left pseudo-locale exercises direction before any Arabic exists. Neither reproduces Arabic shaping, the fallback fonts Arabic triggers, or the values the product puts inside Arabic sentences. The final Arabic strings still need to run in the actual component.

Font and typography failures are invisible in a catalog#

A translation system stores characters. It does not choose the browser's rendered font or show whether Arabic letters remain connected under the product's CSS.

A declared web font may include Latin glyphs but no Arabic. The browser then falls through to another family only for Arabic characters, producing different widths, baselines and line height in the same label. Inspect the rendered font in DevTools after fonts load. R050 reports measured fallback or a declared stack that names no Arabic-capable family.

Latin display treatments can damage Arabic. Positive letter spacing may separate connected letters. Uppercase styling has no equivalent transformation for Arabic script, and synthetic italics may not match the approved Arabic type system. R051, R054 and R055 report these inherited styles.

Test headings, buttons, body copy, numbers and mixed-language labels. Look for disconnected shapes, missing marks, uneven baselines, changed wrapping and clipping. The correct fix is an Arabic-capable font stack and script-appropriate typography, not a shorter translation.

Line height and component height interact. Multi-line errors are better fixtures than isolated labels because they reveal clipped marks, overlapping lines and fixed-height controls. R052 and R053 cover cramped line height and undersized Arabic body text.

A translated value can still use the wrong format#

Translating a currency name is not the same as formatting a price for the market, and the shortcut that skips the formatter is easy to approve in review:

Problem

const label = `${amount} ${t("currency.sar")}`;

The translator approves the Arabic abbreviation for riyals and the string passes review. The number beside it is whatever amount happens to be: no digit system, no grouping, no decimal rule, and nothing that orders the two parts for the locale.

Better

const label = new Intl.NumberFormat("ar-SA", {
  style: "currency",
  currency: "SAR",
  numberingSystem: "latn",
}).format(amount);

The formatter supplies the symbol, the digits, the separators and their order, and numberingSystem records the product's digit decision, which current locale data would otherwise answer with Arabic-Indic digits for ar-SA. That is one possible product decision, not a universal Arabic convention, and product and market owners need to approve the rule.

Test a day above 12, month names, time-zone boundaries, decimals, thousands, negative values, zero and percentages. Compare the same value in UI, email, export and receipt. Different services often call different formatters.

Keep the formatter's output intact when it goes into a message: it carries locale spacing and direction marks that a hand-assembled string loses.

R060, R061, R062, R063 and R064 report common date, digit, currency, percent or unit, and punctuation inconsistencies.

Form behavior begins after the label is translated#

A form can have accurate Arabic labels and still be difficult to operate, and some of the problems appear before anyone types. A search box that may receive either language is a natural place for dir="auto":

<input type="search" dir="auto" placeholder="ابحث عن منتج">

Once someone types, the field takes its direction from the first letter. Empty, it has no letter to decide from, so it is left to right, and its Arabic placeholder sits against the left edge of a right-to-left page. The placeholder's translation is correct; its position is not. Leave dir off for fields that mostly receive Arabic, so they inherit right to left; keep dir="auto" where both languages are equally likely; and review the empty state as well as the filled one.

Machine formats are the opposite case. Email, URL and text fields inherit the page's direction unless they set dir="ltr", and only type="tel" is left to right by default.

Test editing, not only appearance. Type and paste real values, move the caret through punctuation, select a middle range, delete and correct the value. Check prefix and suffix icons, clear buttons and focus rings. R070 reports telephone, email and URL inputs rendered RTL. R023 reports text inputs rendered LTR where Arabic input is expected.

Validation exposes another boundary. The browser's own messages ignore the page's lang, so an Arabic form opened in an English browser still shows English bubbles. If the product requires Arabic validation, provide localized application messages and test their field association. R071 reports untranslated form labels, validation and help text.

Check that selects with Arabic options render right to left (R072), and check their expanded state and keyboard behavior by hand. Test identity-field autocomplete tokens rather than removing them to work around styling; R073 covers missing ones.

Translation review cannot verify interaction order#

A translator reviews content, not the relationship between visual order and DOM order. CSS can mirror controls while the keyboard continues through the original document sequence.

The WCAG focus-order guidance requires an order that preserves meaning and operation. It does not require focus to trace every row mechanically from right to left. It does require a search field and its action, or a step sequence, to remain understandable.

Test the critical journey without a pointer. Tab through navigation and forms, use arrow keys inside composite controls, submit invalid data, open and close dialogs, and confirm focus remains visible. Avoid positive tabindex as a repair for visual reordering. It creates a separate order that becomes fragile when the interface changes.

Also inspect the accessibility tree. Visible Arabic copy does not guarantee an Arabic accessible name. A tooltip or aria-label may come from a different key, and an intentional foreign-language phrase may need a lang attribute for correct pronunciation. R080 reports foreign-language runs without a language annotation; R012 covers untranslated attribute text.

In-context review helps, but it is not the whole answer#

Showing translators screenshots or a live preview is valuable. It reveals component purpose, nearby labels, variable placement and available space. It can catch a mistranslated verb or copy that assumes the wrong state.

It still cannot replace technical testing. A preview may not expose a real server failure, narrow viewport, font-loading delay, keyboard path or dynamically loaded phone number. It may render the target string without the production formatter or markup.

Use in-context language review for what humans judge well:

• meaning, grammar, tone and terminology;
• whether a foreign term should be translated or marked as another language;
• plural phrasing and variable placement;
• market suitability and legal wording;
• whether the complete message reads naturally.

Use engineering and QA for deterministic facts:

• the correct key resolves in every state;
• placeholders and plural branches are complete;
• the live document has the intended language and direction;
• mixed values preserve the expected order;
• text fits under the intended font at supported widths;
• formatters use approved locale options;
• fields, focus and accessible names work.

Neither side is secondary. They certify different properties of the same state.

A clean translation review can still produce a broken checkout#

Consider a checkout whose Arabic catalog has been fully reviewed. The cart, address, payment and confirmation strings are accurate. Terminology is consistent. Variables and punctuation are present in the resources. Translation QA signs off.

The running journey can still fail at several handoffs.

The cart loads an approved message into the wrong box#

The empty-cart message was reviewed in isolation. In production it appears inside a card with a fixed height inherited from the English design. At a narrow viewport, the Arabic message wraps to a second line and the recovery link overlaps it.

The translation is not too long. The container is too rigid. Reproduce the state with the approved copy, inspect its bounding box, remove the fixed height and let content determine the card size. Add the real empty-state string to the component fixture at the minimum supported width.

The address form translates labels but not editing behavior#

The address, phone and email labels are correct. The whole form inherits RTL, so the email input does too. The user enters characters at an unexpected edge and caret movement around punctuation becomes difficult.

This defect does not exist in the catalog. The field contains inherently LTR data and needs a deliberate direction even though its label remains Arabic. Test typing, pasting, selection and correction with a real address, phone and email. Keep Arabic prose fields RTL.

The payment service bypasses the catalog#

The client-side card errors were reviewed. A rejected payment returns a message from a service, and the component renders it directly. The happy path and local validation look fully translated, but the actual rejection appears in English.

The fix belongs at the content boundary: map service error codes to localized product messages or localize the producing service according to the architecture. Do not ask translators to review a string they cannot access or ask CSS to hide the message. Add a deterministic rejected-payment fixture to the Arabic journey.

The total is translated but formatted for another market#

The word for the currency is accurate, yet the formatter receives the wrong currency code or relies on a generic default. Digits, separators and symbol placement do not match the approved market rule.

Translation QA can approve the currency name but cannot infer the numeric value or runtime formatter options from the string alone. Test the formatter with zero, decimals, thousands and negative values. Compare the checkout, email and receipt, since each may be produced by a different service.

The confirmation shows the card ending in the wrong order#

The approved confirmation says which card was charged, and the API supplies the masked value **** 4242 correctly. In the Arabic sentence the unisolated value displays as 4242 ****, so the digits a customer checks against their card sit where the mask should be.

The translator preserved the placeholder, and the backend preserved the data. The markup failed to isolate it. Wrap the dynamic value in <bdi> or an explicit left-to-right boundary, and assert the displayed order: a test that asserts only the API value will miss the defect.

The receipt passes visually but remains inaccessible#

The download button shows approved Arabic text. Its icon-only compact variant uses an old English aria-label, and keyboard focus reaches it after controls that appear later in the visual task.

Neither issue appears in the visible translation screenshot. Inspect the accessibility tree, use the journey without a pointer and test both responsive variants. Route the label to the localization owner and the focus sequence to the component owner.

The pattern across these failures is consistent:

This is why the correct next step after translation approval is not another spreadsheet review. It is an in-product journey that forces real states, values, widths, fonts, services and interactions. The checkout becomes releasable when every handoff has evidence, not when the catalog alone is complete.

Build a process around the gap#

Start with one critical Arabic journey, such as checkout, account creation or order lookup. List its initial, loading, empty, invalid, failed and success states. Create fixtures with approved Arabic copy, a return number, a Latin product name, phone, email, date and price.

Then layer the review:

1. Catalog checks: Missing keys, placeholder parity, plural branch coverage and stale resources.
2. Runtime checks: Locale persistence, server messages, metadata and attribute text.
3. Direction checks: Root dir, bidi isolation, logical CSS, field direction and focus order.
4. Content-pressure checks: Real Arabic strings, loaded fonts, narrow widths, zoom and dynamic surfaces.
5. Market checks: Numbering system, calendar, dates, currency, units and address conventions.
6. Language review: Meaning, tone, terminology and resolved plural messages in context.
7. Regression evidence: Focused automated tests and reviewed visual fixtures at the owning layer.

Automate stable invariants, but do not automate away judgment. A test can confirm that every branch returns a non-empty Arabic string. It cannot decide whether the phrasing is natural. A screenshot can detect geometry changes. It cannot prove that copied account data remains correct.

A Ritla scan checks the layer translation review never sees: every check runs against the rendered page, from untranslated attribute text to values that lost their isolation. Use a finding to reproduce the exact product state and route the defect to its owning layer. The RTL testing checklist for Arabic websites covers the same ground in one pass on release day.

Translation QA remains necessary. The change is to stop treating it as the final gate. A string is finished only after it reaches the right state, survives the browser, fits the component, follows the market rule and remains operable.