Arabic support is a tender requirement, not a nice-to-have

For fleet and logistics software sold into the Gulf, Arabic support is frequently a qualification criterion rather than a differentiator. A product without it is not competing on price and features; it is not in the evaluation.

That makes Arabic a commercial decision with a technical bill attached, and the bill is routinely misjudged. Ask a development team to estimate Arabic support and you will usually get a figure based on translating the interface text. Translation is only one part of the work.

The distinction that matters most

Operational software does two things with the same string. It shows it to a person, and it makes decisions with it.

A vehicle status of "Moving" determines which colour a row is shaded, which filter it matches, which icon is drawn, and which alert rule applies — while also appearing on screen. Translate that value where it sits and every one of those decisions breaks. The vehicle is still moving; the software no longer recognises it as such.

The failure is severe precisely because it is invisible. The interface looks correct in Arabic. The filters return nothing, or the wrong thing, and the reason is not apparent from looking at the screen.

The rule to build against

Translate at the point of display. Never at the point of comparison, and never in data sent to a server. The value on the wire stays exactly as the backend issued it; a mapping layer converts it to Arabic only at the moment it is drawn.

This is worth stating as an explicit engineering rule rather than a convention, because it can be violated in a single line by a developer who does not know the rule exists — and the resulting defect can invert the behaviour of a control while leaving the interface looking entirely correct.

Numerals, and why reports come back empty

Arabic locale settings in common date libraries rewrite digits into Arabic-Indic form. The date 2026-08-21 becomes ٢٠٢٦-٠٨-٢١.

Shown to a user, that is correct behaviour. Sent to an API as a query parameter, it is not a date the server can parse. And because such requests typically return an empty result rather than raising an error, the defect reaches production and presents as reports that inexplicably return no data — for Arabic users only.

The structural fix is to separate machine-facing from human-facing date handling at the architecture level: one function that always formats for the wire, another that formats for the reader, and a check that fails the build when a raw call slips in. Doing this retrospectively across an existing codebase typically means auditing several hundred call sites.

Layout that mirrors by rule

Right-to-left is not a stylesheet applied over an English layout. Every rule specifying a left or right position — margins, padding, text alignment, borders, absolute positioning — must become direction-relative, so the interface mirrors as a matter of course rather than screen by screen.

Two things must deliberately not mirror:

• Map canvases and chart axes. Time-series plots are read left to right in Arabic contexts as elsewhere; mirroring them produces an interface that is technically right-to-left and practically unusable.

• Mixed Latin content inside Arabic text. Plate numbers, IMEI identifiers, coordinates and measurements need directional isolation, or the bidirectional algorithm reorders them — a speed of 154,320 km rendering as km 154,320, which can make an identifier or measurement ambiguous.

Documents are their own project

Arabic script is cursive: letters change shape depending on their position within a word. Some PDF generation libraries require explicit shaping and font configuration. Arabic text passed to one without an embedded, correctly-configured font renders as disconnected, reversed characters — legible to nobody.

Each export path needs separate work and separate visual verification: PDF needs the embedded font and column-order reversal; spreadsheets need right-to-left sheet orientation; CSV needs a byte-order mark or Arabic opens as mojibake in Excel; print needs its own direction handling because the print document does not always inherit the page's.

It is also worth knowing that several widely-circulated technical fixes for Arabic in PDF actively make output worse in current library versions. This is an area to establish by testing against the specific versions in use, not by following the top search result.

Language is also a plural problem

Arabic has six plural categories — zero, one, two, few, many and other — where English has two. Any interface string containing a count needs proper plural handling rather than string concatenation, or it reads as machine output to a native speaker. "3 مركبات" and "11 مركبة" take different forms, and getting this wrong is one of the fastest ways to signal that a product was translated rather than localised.

Budget the review, not just the translation

The component most often cut is native linguistic review, because machine translation produces Arabic that looks plausible to a non-speaker. It is also the component your users judge the product on. Fleet and telematics vocabulary is specialised, terminology should be agreed as a glossary with the client rather than chosen by a translator in isolation, and consistency across a thousand strings does not happen by accident.

The engineering makes the product capable of Arabic. The review makes it credible in Arabic. Both are required, and only one of them is optional in most quotes you will receive.

Questions or a correction? Contact the 2M team. Examples explain a method; results depend on your operation and configuration.