Compare

Four ways to find Arabic defects

No products are named here. A table of other companies' capabilities is a table of claims we cannot verify, and the question a buyer actually has is which kind of check to run. Two of the four below are not alternatives to this one: run them as well.

A bilingual tester, by hand

Somebody who reads Arabic opens the product and writes down what is wrong.

Catches

Tone, register and whether a translation is actually idiomatic
Anything that needs judgement about meaning
Defects in flows a crawler cannot reach, behind a login or a payment

Misses

Repeatability. A second pass is a second opinion, not a diff
Breadth. Every page, every width, every release is more hours
Mechanism. It finds that something looks wrong, rarely which rule and which selector

Best for: Judging whether Arabic copy is good. No tool decides that, and a scan that said otherwise would be lying.

A general accessibility scanner

An automated pass for contrast, labels, landmarks and structural accessibility.

Catches

Contrast, alternative text, form labelling, heading structure
Regressions in all of the above, on every build, for free

Misses

Direction. A page laid out left to right is not an accessibility failure and will not be reported as one
Bidirectional text. Mixed Arabic and Latin runs, neutral characters resolving the wrong way, numerals inside a right to left line
Arabic typography. A face with no Arabic coverage falls back silently and the page still passes
Untranslated strings, which are structurally perfect and semantically wrong

Best for: Accessibility, which is a different job. Run one. It is not in competition with this and every site should have both.

Localisation QA tooling

Checks over the translation pipeline: missing keys, placeholder mismatches, string length budgets.

Catches

Untranslated and stale keys before they ship
Broken interpolation and plural forms
Strings that will overflow a known budget

Misses

Everything that happens after the string reaches the page: the CSS that positions it, the font that renders it, the direction it inherits
Text that is not in the pipeline at all, which is most of a third-party widget
Whether the rendered result is readable, as opposed to whether the input was complete

Best for: Catching translation problems at the source, which is earlier and cheaper than catching them on the page. Also not in competition with this.

Ritla

this is us

Deterministic checks on the rendered Arabic page, with a screenshot, a selector and a fix for each finding.

Catches

Direction and bidi defects in the rendered result, not in the source
Physical CSS that will not mirror, per property and per selector
Arabic typography: missing coverage, silent fallback, tracking applied to a connected script
Untranslated content on a page that is otherwise Arabic
Overflow and clipping per breakpoint, because Arabic runs longer
The same defects again after a release, with a diff rather than a second opinion

Misses

Whether the Arabic is any good. It checks the rendering, never the writing
Anything behind a login, a payment step or a bot check
Design intent. An asymmetry on purpose and an asymmetry by accident look identical to a rule, which is why the declines list exists

Best for: Proving an Arabic product renders correctly, repeatably, with evidence a client or a developer can act on without a meeting.

The short answer

If you need to know whether your Arabic reads well, hire somebody who reads Arabic. If you need to know whether it renders correctly, on every page, at every width, again after the next release, and with evidence somebody can act on without a meeting, that is this. Most teams shipping Arabic seriously need both, and the scan is the cheaper half to start with because it costs nothing to try.

Run a free scan See every check