How engineering teams should test Arabic releases

An Arabic regression does not require anyone to edit Arabic copy. A shared card can gain a physical margin, authentication can drop the locale after redirect, a formatter upgrade can change digit output, or a new failure state can bypass the translation catalog.

Testing only the tickets labeled “Arabic” misses those changes. Treat Arabic as a release dimension, like browser support or authorization: every release gets a scoped pass based on what changed, backed by stable automation and a smaller set of human judgments.

Define the Arabic release contract#

A team cannot decide whether a build passes until product decisions are written down. Start with a short contract that release tests can reference.

Record:

• supported Arabic locale tags and markets;
• URL and locale-persistence behavior;
• root language and direction;
• supported browsers, devices and minimum viewport;
• numbering system, calendar, date, time, currency and unit rules;
• Arabic font files and fallback policy;
• which values remain LTR, such as phones, emails and machine identifiers;
• translation source, approval state and fallback behavior;
• keyboard and assistive-technology expectations;
• journeys that block release when they fail.

“Arabic locale” is not enough. An Emirati release and a Kuwaiti release may have different currency, fraction, copy and legal requirements even when both use Arabic. Runtime defaults are not the contract either. Locale data can change between browser versions.

Version this document with the product. A changed currency rule or supported browser should update tests in the same release, not arrive as verbal context during sign-off.

Make every change declare its Arabic risk#

Add an Arabic-impact field to pull requests or release tickets. The author should identify affected layers, not answer a vague yes-or-no question.

“No Arabic impact” needs a reason. A backend-only migration that preserves every response shape may justify it. A shared CSS variable change does not, even if the developer opened only the English route.

This field also determines who reviews the change. A formatter upgrade needs an engineer and market rule owner. New customer-facing copy needs a fluent Arabic reviewer. A focus-order change needs accessibility testing.

Choose a representative route set#

Running every test on every localized URL wastes time without guaranteeing coverage. Choose routes by interaction and component family, then add targeted routes from the release diff.

For a logistics product, a stable release set might include:

• public parcel lookup, including no-result and delayed states;
• dispatcher board with dense filters and live updates;
• shipment detail with mixed Arabic and machine identifiers;
• proof-of-delivery upload with client and server failures;
• warehouse adjustment flow with quantity and reason fields;
• invoice detail with currency, tax and print view;
• account security with session expiry and reauthentication.

Each route should justify its place. The dispatcher board covers dense geometry and live content. Proof upload covers file status, long errors and focus recovery. The invoice covers market formatting and export parity.

Keep the base set small enough to run on every candidate. Add a diff-driven set for components touched by the release. If a change modifies a shared modal, test one ordinary use, one long-content use and one failure path instead of visiting unrelated pages that happen to contain the same shell.

Build fixtures that make Arabic failures visible#

Short Arabic labels and clean numeric values allow defects to pass. Store a fixture pack with known source, expected display and owning market rule.

For the logistics release, include:

• parcel reference 6847-219-53 after an Arabic label;
• warehouse bin RACK-Z9-41;
• vehicle plate, driver email and supported phone formats;
• a three-line delivery exception;
• an address long enough to wrap inside the narrow breakpoint;
• a Kuwaiti dinar amount with three fraction digits;
• plural states for zero, one, two, few, many and other;
• a document name that begins with Arabic and another that begins with Latin text;
• loading, empty, failed, permission-denied and success data.

The numeric parcel reference has a useful shape. In Chromium 151, last checked 2026-09-24, three Western-digit groups separated by hyphens after Arabic display in reverse group order when they are not isolated. The authored 6847-219-53 therefore appears as 53-219-6847. Isolating the value keeps it intact. Firefox and Safari were not checked for the browser-specific facts in this guide, so verify the fixture in the supported matrix.

Do not turn this release guide into a bidi tutorial. The bidirectional text developer guide explains why the browser reorders mixed runs and how to mark up the boundary.

Keep fixtures immutable within a release line. If the approved Arabic error changes, update its fixture through review and note the change. Otherwise a snapshot update can silently accept a regression.

Run static and build-time gates first#

Fast gates should reject defects before the browser suite starts. The exact tools depend on the stack, but the assertions are portable.

Check the release artifact for:

• missing Arabic catalog keys and unintended source-language fallback;
• invalid locale metadata or route generation;
• direction-sensitive physical CSS introduced in shared components;
• Arabic font files omitted from the asset manifest;
• translated images or documents missing from the build;
• formatter configuration changed without updated market fixtures;
• release routes removed from the representative set.

Static findings need context. left is valid for a map coordinate and suspicious for a logical card action. Triage the use rather than banning the token globally. R030 reports direction-sensitive physical properties without an RTL override, which is the precise CSS finding it covers.

Fail the build for a missing required catalog or asset. A style warning can enter a review queue when its intent is unresolved, but it still needs an owner before release.

Automate document and locale persistence#

Open Arabic routes directly in a fresh session. Do not make tests visit the language picker first. Verify the URL contract, live root attributes and persistence through navigation.

// page and expect are fixtures supplied by the browser test runner.
// arabicRoutes: representative Arabic URLs owned by the release suite.
const arabicRoutes = [
  "/ar/track",
  "/ar/dispatch",
  "/ar/warehouse/adjustment",
];

for (const route of arabicRoutes) {
  await page.goto(route);

  const root = page.locator("html");
  await expect(root).toHaveAttribute("lang", /^ar(?:-|$)/);
  await expect(root).toHaveAttribute("dir", "rtl");
}

Add the product's locale transitions: refresh, internal link, authentication redirect, sign-out, browser back and a second tab if locale is expected to persist there.

R001 reports document direction that is missing, contradicted or declared only in CSS. R002 reports a missing, non-Arabic or contradictory root language. Keep those assertions separate because language and direction solve different problems.

For implementation details, use the HTML dir="rtl" guide rather than duplicating root-direction rules in release documentation.

Test the release states, not only the routes#

A route can pass in its loaded state and fail during the transition into it. Define state coverage for each representative journey.

At minimum, consider:

• loading to populated;
• empty to first record;
• valid to invalid;
• request to server failure and retry;
• authorized to expired session;
• default filters to no results;
• fallback font to loaded Arabic font;
• closed to open and back for overlays;
• locale change without a full navigation;
• narrow to wide responsive transition.

Use state builders, API fixtures or controlled test accounts rather than waiting for production data to happen. Every state should declare its expected string source, focus target, direction and geometry.

The proof-of-delivery route, for example, should cover a rejected file, interrupted upload and successful retry. The language reviewer needs the complete error and recovery path, not only the initial button label.

R071 reports untranslated form labels, validation or help text. Do not cite it for focus recovery or upload behavior; those need their own manual or automated tests.

Automate stable assertions, not aesthetic judgment#

Automation is strongest when the expectation is deterministic.

Good candidates include:

• root lang and dir;
• approved strings for critical controls and errors;
• URL and locale persistence;
• direction of known Arabic and LTR fields;
• exact formatter output for documented market fixtures;
• rendered Arabic font after assets load;
• focus target after opening, submitting and closing a surface;
• document-level horizontal overflow;
• known mixed-direction value boundaries;
• accessible names and language attributes.

Avoid tests that claim “the Arabic looks natural” or “the layout feels balanced.” Those are review judgments. Automation can compare a component to an approved visual baseline, but a passing screenshot does not establish translation quality.

For root overflow, measure after the state is complete:

// page and expect are fixtures supplied by the browser test runner.
await page.goto("/ar/dispatch");
await page.evaluate(() => document.fonts.ready);

const overflow = await page.evaluate(() => {
  const root = document.documentElement;
  return root.scrollWidth - root.clientWidth;
});

expect(overflow).toBeLessThanOrEqual(1);

This assertion covers document overflow, not an intentional inner scroller. The RTL overflow guide shows how to identify the offending box when the assertion fails. R040 reports document-level horizontal overflow.

Use visual regression for geometry#

Visual comparison can catch a shifted badge, reversed icon, missing font or label that now overlaps its action. It needs disciplined baselines.

Capture LTR and RTL variants at the same component state, data and viewport. Wait for fonts, images and stable asynchronous content. Disable nondeterministic timestamps or live positions through test fixtures rather than widening the screenshot tolerance until the difference disappears.

Choose baselines around component families and high-risk journeys. A full-page image for every route creates review noise; a focused capture of the dispatch filters at narrow width makes a spacing regression obvious.

Review changes by relationship:

• logical start and end placement;
• text and action overlap;
• clipping after wrapping;
• directional icon meaning;
• rendered Arabic font and line height;
• fixed and sticky element position;
• content available at both horizontal edges.

An intentional visual update should change both the implementation and approved baseline in the same review. “Update snapshots” is not a diagnosis.

Exercise mixed values by component type#

Arabic pages contain identifiers, emails, phones, SKUs and document names. Do not repeat one token across every test and assume the bidi problem is covered.

For shipment detail, test the numeric-leading parcel reference and the Latin-leading warehouse bin. The first exposes a missing isolation boundary; the second should remain intact by its character shape. In the driver contact component, use the phone formats approved by the market and product.

The phone numbers in RTL interfaces guide covers display, links, fields and Arabic-Indic digit groups. Link the component test to that contract instead of rebuilding its cases in the release suite.

R021 reports unisolated bidi hazards such as phones, emails and Latin tokens inside Arabic text. A passing report does not prove that every business identifier preserves its group order, so keep explicit fixtures for product-specific references.

Compare visual display with logical value. Copying returns authored order even when a value displays incorrectly in the measured browser, so a clipboard assertion cannot replace the visual check.

Freeze market formatting expectations#

Store examples for every supported Arabic market. Include date, time, currency, decimal, percentage, unit and plural behavior. The expected output comes from the product contract, not whatever the current runtime returns.

For the Kuwaiti invoice route, include an amount whose third decimal digit is nonzero. Intl.NumberFormat formats KWD with three fraction digits in the checked runtime because the currency is divided into 1,000 fils. Assert the formatter's resolvedOptions().maximumFractionDigits as well as the visible output if that setting is a business requirement.

Arabic plural selection needs all categories. In Chromium 151, Intl.PluralRules("ar") reported zero, one, two, few, many and other; counts 0, 1, 2, 3, 11 and 100 selected them in that order. Use product-owned messages for all branches and send them through fluent review.

R060 reports English month or day names and MM/DD/YYYY dates in Arabic text. R061 reports Arabic-Indic and Western digits mixed in the same context. Cite each finding only for the format named in its description; market preference still needs the written contract.

When a browser or formatting dependency changes, run these fixtures before approving snapshot updates. A new default may be standards-conforming and still violate the product decision.

Test fonts as a release dependency#

Arabic font coverage is part of the build, not a design-only concern. Test the final production bundle with the same font URLs, cache headers and content-security policy used at release.

In DevTools or automation, capture the font that actually rendered for representative Arabic text after document.fonts.ready. Compare fallback and loaded states at the narrow viewport. Different metrics can introduce wrapping, clipping or layout shift.

R050 reports Arabic text falling back past the declared font family when measured, declared or when a webfont failed to load. The release test should preserve the network or rendering evidence that identifies which condition occurred.

Also inspect typography utilities changed by the release. R051 reports letter spacing applied to Arabic text, which breaks the connected script. A visual baseline helps reveal the damage, but the computed declaration is stronger evidence for the fix.

Do not shorten an approved translation to compensate for a missing font or fixed container. Repair the asset or layout layer that owns the constraint.

Run keyboard and accessibility journeys#

Complete the blocking journeys without a pointer. Test menu and dialog entry, data entry, invalid submission, retry, dismissal and focus return.

Record DOM order, visual order and focus sequence for controls whose layout changed. A component can look mirrored while keyboard navigation follows a disconnected path. R081 reports row-reverse used to fake RTL when tab order fights visual order; it does not cover every focus-order defect, so test the journey directly.

Inspect the accessibility tree for names, roles, descriptions and language. A visible Arabic label does not prove that an icon button's accessible name was translated. R012 reports untranslated attribute text such as aria-label, placeholders, alternatives, titles and button values.

Spoken Arabic needs human review with the supported assistive technology. Automation can establish that lang is present and names exist; it cannot approve pronunciation, wording or comprehension.

Give fluent reviewers a focused language pass#

Run structural automation before the language review so the reviewer is not spending the session reporting overflow or missing assets.

Provide:

• release notes and changed source strings;
• screenshots or a build for every changed state;
• market, audience and tone guidance;
• source key, English source and Arabic translation;
• character or layout constraints;
• explicit questions for disputed messages;
• known technical issues that could distort the review.

Ask whether the message is accurate, natural, consistent and appropriate for the task. Include error and recovery states, not only successful journeys.

Teams without an Arabic-speaking tester can still run the deterministic pass. The guide to QA without speaking Arabic defines the boundary between observable evidence and language judgment.

Treat reviewer changes as versioned product decisions. Update the catalog, glossary and test fixture together. A correction left only in a screenshot comment will be rediscovered in the next release.

Test a production-like candidate#

Development mode can hide failures caused by bundling, caching, route generation and asset delivery. Run the release candidate through the same delivery path users will receive.

Verify:

• server response includes the correct root metadata before client code;
• Arabic chunks and catalogs load from the release origin;
• font files return successfully and render;
• cache invalidation does not mix old strings with new code;
• deep links work without prior locale state;
• redirects preserve locale;
• print, export and notification surfaces use the same approved formats;
• monitoring can distinguish Arabic-route failures.

Test with a clean profile as well as an upgraded profile carrying an older locale selection and cached assets. The release needs both first-visit and returning-user evidence.

If a rollout uses flags, test each supported flag combination that changes Arabic UI. A hidden branch can still ship untranslated code and become visible later without another deploy.

Triage by user impact, not finding count#

A release is not safer because it has fewer logged issues. One changed parcel reference can have more impact than several minor spacing differences.

Block release when:

• a critical Arabic journey cannot complete;
• the locale or base direction is lost;
• a price, identifier or date changes meaning;
• a required action or message is unreachable;
• a critical error is untranslated or misleading;
• keyboard or assistive-technology users cannot operate the task;
• the production artifact lacks required Arabic fonts or catalogs.

Lower-impact visual inconsistencies can ship only under the team's risk policy, with an owner, documented impact and retest date. “Arabic issue” is not a useful severity. Name the affected task and failure.

Keep expected differences out of the defect queue. A physical map, approved Latin brand or market-specific digit choice may be correct. Link the acceptance decision so it is not reopened each release.

Define release evidence and ownership#

A sign-off should say what passed, not only who clicked approve.

Attach the build identifier, locale, market, browser, viewport, route set and fixture version. Note exclusions explicitly. “Arabic passed” is weak if print export, a supported browser or the failed-upload state was not tested.

Keep findings reproducible: route, state, input, expected result, actual result and supporting DOM or screenshot evidence. Record the first transition where the failure appears.

Scale the routine for hotfixes#

A hotfix may not allow the full candidate suite, but it still needs an Arabic risk decision.

Run:

• the fixed path in Arabic and the primary LTR locale;
• shared components touched by the patch;
• locale persistence if routing or authentication changed;
• the exact failure and recovery state;
• a root direction, translation and overflow smoke pass;
• any formatter, font or catalog fixture affected by the diff.

Do not skip Arabic because the patch contains no translation files. The code path, shared style or response state may still be localized.

After release, run the broader suite if the emergency process deferred it. Record that follow-up as part of the hotfix, not as an optional cleanup task.

Turn escaped defects into permanent coverage#

For every Arabic regression that reaches users, ask which layer failed to prevent it:

• Was the product rule undocumented?
• Did the representative route set omit the component?
• Was the state unavailable in test data?
• Did automation assert the wrong output?
• Did the visual baseline use short content?
• Was fluent review too early or too narrow?
• Did the production artifact differ from the candidate?

Add the smallest fixture or assertion that would have caught the defect. Do not respond by running every test everywhere. Improve the risk map and representative set.

Ritla can scan a release candidate for concrete Arabic failures such as physical CSS R030, untranslated validation R071 and document overflow R040. Run the free scan on the candidate URL, then route each finding into the same owner, severity and evidence process as the rest of the release.

For the organizational layer above this routine, read Arabic product QA for product and engineering teams. For a final public-site launch pass, use How to test an Arabic website before launch.