Arabic-ready components, rolled out where yours break
We replace the components that keep breaking in Arabic with Ritla components, so the fixes stay fixed.
- Price
- Scoped after a scan
- Timeline
- Set by the rollout map
- Starts with
- A free scan
Some Arabic defects are not bugs in your page, they are properties of a component: a phone field that lets the browser reorder the number, a date picker that only knows left to right, an icon that points backwards in every screen that uses it. Fixing each screen by hand fixes it until the next one ships. A rollout replaces the component itself with its Ritla equivalent, built against the same checks the scanner runs, so the class of defect leaves with it. The scan decides which components earn a replacement; the ones that already pass stay yours.
This is for you if
The situations this engagement was built for.
The same Arabic defect keeps coming back on every screen that reuses a component
Your team fixes RTL issues screen by screen and the list never gets shorter
You are building new Arabic flows and want them correct from the first commit
Checkout, sign-up or payments carry revenue and cannot wait for a redesign
A screen flipped, and a screen built
The same Arabic transfer card twice: one is an English screen flipped by a stylesheet, the other is built with Ritla components. The numbered pins are the defects a rollout removes at the component, once.
- A Latin system font and a tight line height: the Arabic sits cramped, its marks clipped.
- The phone number without isolation: its digit groups reorder around the spaces.
- The check mark mirrored along with everything else. A tick has no direction.
- The forward arrow copied from English, so in Arabic it points back.
IBM Plex Sans Arabic with Arabic line heights; the phone number kept left to right inside the right-to-left form; the tick untouched; the arrow following the reading direction.
Illustrative: live HTML and CSS. Drawn from our own fixtures and public-site scans, not a client engagement.
What is in the engagement
What you get
- A baseline scan, archived, with each finding traced to the component that causes it
- A rollout map: which components to replace, which to keep, and why, ranked by how many screens each one breaks
- Ritla components installed as source in your repository, adapted to your props and your data
- A pilot on one real flow first, measured, before anything wider is touched
- Pull requests you review and merge, one component or one flow at a time
- Verification scans at every breakpoint, iterated to clean on the flows in scope
- A short handover: how the components mirror, what never mirrors, and how to extend them
What we need from you
- Repository access, or a fork we can open pull requests against
- A React codebase using Tailwind, or a decision to adopt it for the components in scope
- A staging environment where the scanner can reach the Arabic build
What this does not cover
- Components that already pass: replacing working code is churn, and the scan tells us which ones those are
- Frameworks other than React. We scope other stacks case by case rather than promise them
- Translation itself: we fix the container the Arabic sits in, not the words
How it runs
Timeline: Set by the rollout map. Every step ends with something you can see.
- Week 1
Scan and map
A full crawl, then each finding traced to the component behind it. The rollout map ranks components by how many screens they break, and the ones that already pass are left alone.
- Weeks 1 to 2
Pilot one flow
The components one real flow needs, installed and adapted to your props and data, scanned before and after. The pilot is where you decide whether the rest is worth doing.
- By scope
Roll out
The remaining components on the map, one pull request per component or per flow, so review stays small and nothing lands unseen.
- Final week
Verify and hand over
Scans at every breakpoint on the flows in scope, iterated to clean, and a short handover on what mirrors, what never does, and how to extend the components.
The checks this engagement leans on
Every finding starts as one of these, with evidence attached. Each has its own page explaining when it fires and how to fix it. Browse every check.
- R020highForced-LTR container, or a bidi override, over Arabic contentUnder a
dir="ltr"ordirection: ltrbox, mostly Arabic text starts at the wrong edge with punctuation out of order, and abidi-overridecan mirror its letters or reverse embedded numbers. - R021mediumUnisolated bidi hazards: phones, emails, Latin tokens inside Arabic textIn right-to-left text a phone number like
+966 55 123 4567displays as4567 123 55 966+unless it is isolated in<bdi>, and figures with brackets or signs can flip the same way. - R070mediumTel/email/url inputs rendered RTL (these must stay LTR)Phone, email and URL fields left right-to-left on an Arabic page: their values are left-to-right strings, so digit groups and punctuation can display out of order as users type.
- R061mediumArabic-Indic and Western digits mixed in the same contextMixing ٣ and 3 within one table, list or
fieldsetmakes figures hard to compare at a glance; numbers in running prose outside those containers are not checked. - R081mediumFlex row-reverse faking RTL instead of dir (tab order fights visual order)On a right-to-left page, a nav or list set to
flex-direction: row-reverseshows its items in reverse source order, so pressing Tab moves focus against the direction Arabic readers scan.
Scan first. Then we talk about your findings.
The scan takes about a minute and costs nothing. Your enquiry arrives with it attached, so the reply starts from evidence about your site rather than questions about it.
- Paste the URL of your Arabic page.
- See your score and top findings.
- Tell us what you need. A person replies within one working day.
Start with a scan
We would rather look before we talk. Give us the URL and we will run the same scan the homepage runs, then you can tell us what you need.
Questions about the UI rollout
How is this different from an RTL conversion?
A conversion fixes the code you have. A rollout replaces the components that cause a class of defect, so screens built later with them start correct. Many teams do a little of both, and the scan shows which one each finding needs.
Do we have to replace every component?
No. The scan decides. Components that already pass stay yours, and the rollout map is ranked by how many screens each component breaks, so the first pull request is the one that removes the most defects.
Who owns the components afterwards?
You do. They are installed as source in your repository, not loaded from a package you depend on, so your team can read and change them like any other code.
How is it priced?
Scoped after a scan. The number of components on the rollout map and the flows in scope decide the work, and we quote from those rather than from a discovery call.
Other ways we can help
- We lookArabic Readiness CertificationA pre-launch audit by people who read Arabic, ending in a certificate.See the engagement ›
- We fixArabic Readiness DeliveryWe take the product from its measured score to a clean one, and the scan is the receipt.See the engagement ›
- We lookArabic Typography & Font AuditThe layer that decides whether Arabic looks native or merely present.See the engagement ›
- We watchLocalization QA RetainerFor teams shipping continuously without an Arabic speaker on staff.See the engagement ›
- We designCustom themeYour brand as a Ritla theme: a Figma file and code on the same tokens, Arabic-first.See the engagement ›
- You deliverAgency partnersResell certification and conversion under your own brand.See the engagement ›
Find out where your Arabic stands
A free scan of one page, scored and explained in about a minute. If it tells you everything you needed, that is a good outcome too.