.png)
The request usually arrives as a market. A partner in the Gulf wants to run ticketing for a festival, or a nonprofit in the region wants the fundraising module in Arabic, and the product team has a quarter to deliver it. Someone sets the page direction to right-to-left (RTL), the layout flips, and the first demo looks close to finished. Then the question that matters comes up: is the rest a week of polish or a re-architecture nobody budgeted?
Teams usually answer in one of three ways. Some flip the direction and see what breaks. Some retrofit in place or rebuild the component layer. Some ship a limited version and add surfaces later. Each of the three can be the right call, and what decides it is a short list of things already inside the product. An audit can read all of them before a number goes to anyone. On an event platform the list also includes the transaction lifecycle at peak demand, since a ticket release or auction close pushes checkout, payment, confirmation, and ticket issuance into the same few minutes.
This is where most teams start, and it deserves its place. It takes an afternoon and gives a good read on layout debt: physical offsets, hardcoded positions, components built with the left edge in mind. It says little about everything else, because it runs on English strings and on the screens a developer thinks to open.
The better second step is one purchase, completed end to end on a phone, in the target language with real translations. The examples below follow a ticketing flow; fundraising and auction products swap in their own revenue paths, such as donation amount and receipts or bidding and results. Four areas deserve particular attention, and each one forces a choice.
The payment field. Hosted card fields render inside the payment provider's frame, so the provider's own settings control their language and direction. Stripe's embedded Elements show the split: a locale option localizes placeholders and error strings, and the direction comes from mounting the elements under an element that carries dir="rtl". Stripe's hosted Checkout page is a different product, and its supported-locale table lists Arabic for Elements only.
Coverage can differ between integration styles of the same provider. If your integration is covered in a documented way, the work is configuration plus testing on real devices. If the coverage is thin, the options are a different provider, a different integration style with the same provider, or an English card form inside a localized checkout. The last ships fastest and the first gives the best result, with a contract and fees attached. The check belongs in week one, since a provider change brings in finance and legal and takes the longest to move.
The PDF ticket. Some PDF libraries lack Arabic text shaping and print disconnected letters in reverse order. Shaping is one requirement among several: mixed Arabic and Latin text, numerals, and font embedding have to survive as well, and nobody sees a failure until someone opens a real generated ticket.
The options are a different library, rendering the ticket from HTML through a headless browser, which reuses the browser's own text shaping, or making the wallet pass or a QR link the primary ticket with the PDF as a fallback. Headless rendering is a strong option when the platform already has a reliable HTML ticket template, and it needs more infrastructure, which matters when a sale opens and thousands of tickets generate in minutes.
Whichever renderer wins, the test is a real generated ticket with representative Arabic and mixed-script content. Generating tickets asynchronously keeps the work off the checkout path during a spike. It adds queueing, retries, and a state for tickets still being issued, which the confirmation screen and email have to handle.
Identifiers and phone numbers. An order reference followed by a full stop can show the full stop on the wrong side. A phone number written with spaces can display its groups in reverse order. Browsers order bidirectional (bidi) text, meaning mixed Arabic and Latin runs, by rules that have no idea a value is an identifier.
The fix happens at display time: each identifier gets wrapped in an element with explicit left-to-right direction (dir="ltr", or <bdi> when the direction of the value is unknown). The cost depends on one thing: whether identifiers render through a shared component. If they do, it is a small change in one place. If every template formats its own, the fix touches every template, and this is the point where a retrofit starts to look like a refactor.
The bid slider and its cousins. Custom sliders, carousels, and steppers often calculate position from the left edge. The options are fixing the math, switching to a native control, or asking whether the control earns its place in any language. Preset quick-bid buttons need no position math, and flexbox mirrors their order on its own. Custom controls whose only job is decoration are the first to go.
The identifier example shows the fork. A product with shared components and physical offsets concentrated in a few places can be retrofitted in place. A product made of hundreds of one-off components faces a harder choice. The table shows where the effort tends to come from.
margin-left and left: 0Counting drivers gives a rough size and leaves out two things that matter more. Effort is the development, integration, and testing involved. Uncertainty comes from a third-party provider, an architecture question, or a product decision nobody has made. Release criticality says whether a finding blocks a revenue path or can wait. One unsupported payment integration can outweigh a dozen small layout fixes, so the audit records all three for each finding and turns them into a plan and an estimate range with a confidence level. An extract might look like this, with illustrative findings:
Teams disagree on whether to combine RTL support with a component refactor. The case for combining: a one-off codebase needs nearly every component touched for RTL anyway, and a design-system refactor touches the same components. The case against: a component-layer rebuild adds work of its own, such as designing the abstractions, changing component APIs, migrating consumers, and re-verifying existing behavior in both directions, and it ties a market launch to that risk.
With a short window, the retrofit covers the critical journey and the refactor goes on the roadmap with the RTL rules written into its spec. Where a design-system refactor is already planned and the window is long enough, folding RTL into it can reduce the total.
A small set of widely used components with localized changes points to retrofit. When several high-value journeys keep needing changes in the same foundational components, a targeted refactor of those components is worth evaluating. Hundreds of rarely used components with the same problem point to a longer job in which sequencing matters more than architecture.
The first release can leave some surfaces in English, and the organizer's workflow decides which ones. If an organizer can create events or campaigns, manage inventory, and read transaction data in English without friction, attendee-facing web and email can go first, with staff check-in and admin following.
If the organizer cannot launch or run the product without those tools in Arabic, as on a fundraising platform where organizers build the campaigns, the organizer tools belong in the first release. Venue staff might work in English or might not. Both answers come from the partner, and one email to them in week one settles most of the scope.
Three decisions shape what the audit can estimate, and engineering cannot settle any of them alone.
Mixed-language content. Organizers write event titles, descriptions, and campaign stories, often in English only, or in Arabic paragraphs that carry English artist and venue names. The interface can be fully Arabic while the content on the page is not, and the attendee page, the confirmation email, and the editor where the organizer wrote the text all have to cope with that. Three questions follow. What shows when Arabic content is missing: the English original, a machine translation labeled as such, or a prompt asking the organizer for Arabic before publishing? Does direction follow the page or each block? And does the rich text editor handle direction at all? Some editors do.
Tiptap, for example, documents a global direction setting, per-node overrides, and an auto mode that picks direction from the first strong character in each block. A custom-built editor needs that behavior built and tested. Direction per block suits organizer content, since one description can hold Arabic and English paragraphs, and page-level direction suits the interface. The fallback rule carries the commercial weight, because an English fallback keeps the event page usable and a blank field does not. The audit checks which editor the platform uses, where organizer content renders (web, email, PDF), and what happens today when a field is empty.
What mirrors. Published guidance differs, so the platform needs its own written rule. Material Design mirrors the linear passage of time and keeps clocks and media controls as they are, and Wikimedia's style guide advises against mirroring charts when it could change how the data reads.
For an event platform the contested items are organizer dashboard charts and timelines, countdowns, step indicators, and the seat map. The seat map depicts a physical room, so it keeps the venue's orientation while the controls around it mirror; a mirrored map can send a ticket holder to the wrong side of the venue. Dashboard charts depend on who reads them, and either rule is defensible. Consistency across screens matters more than which rule wins, and the rule belongs in the design system. The audit lists every directional element in the revenue paths and records the rule applied to each.
Locale conventions. Numerals, calendar, currency, and first day of the week arrive as one bundle, and defaults vary by locale. CLDR's defaults for Arabic (Saudi Arabia) are Arabic-Indic digits and the Umm al-Qura calendar, and other Arabic locales differ. Whichever combination the product picks, the formatting code sets the numbering system and calendar explicitly, since Intl.NumberFormat and Intl.DateTimeFormat both accept them and a browser default then cannot choose for the product.
The owner also decides whether to show Hijri dates alongside Gregorian ones. The typeface belongs here too: brand fonts are usually Latin-only, so Arabic text falls back to a system font that can clash with the brand, and a typeface designed for Arabic, paired by visual weight with the Latin one, is a design sign-off. The audit lists the conventions for each launch country and who validates them: a language reviewer for the translation, and someone who knows the market for currency, dates, and payment behavior.
Native-language review costs time and money, and teams rarely have unlimited amounts of either. The money path gets it first: one reviewer completing a full purchase, including a declined card and a corrected form, with license to say a label reads wrong. A language reviewer judges the translation; currency display, payment behavior, and usability need someone who knows the target market. The rest of the product gets spot checks. A direction toggle stays useful throughout development, since it exposes layout assumptions before translations land.
Two further checks protect the result over time. A lint rule that flags physical CSS properties keeps the next feature from reintroducing the problem, and visual regression tests in both directions catch what the lint rule misses. A ticket release that opens at a fixed time pushes every path above into a few minutes. A different language does not change the load profile by itself, so the load test targets what the localization does change: the checkout path, the payment integration, and the ticket generation pipeline, run against expected peak demand.
The audit is the most comparable thing to ask any partner for. A useful one contains a journey inventory covering the revenue paths and the surfaces around them, findings by journey as in the extract above, the third-party dependencies, the decisions that need an owner on the product side, an estimate range with a confidence level and the assumptions behind it, acceptance criteria for each release gate, and a staged release plan. The product team can take that document to any delivery partner, and estimates can then be compared line by line.
The audit needs four inputs from the product team: the launch countries, currencies, and payment methods; the journeys that carry revenue; the organizer workflow; and access to a staging environment. A partner who starts with these asks about them before quoting anything. Four questions bring out the difference in a first call:
Think of us as your tech guide, providing support and solutions that evolve with your product.
.png)
