An AI writing in Arabic: what breaks in your interface

A shop in Bab Ezzouar puts its catalogue into Arabic. A model writes the descriptions, they are clean, and nobody on the team reads a word out of place. On the first customer’s phone, the price line starts from the wrong side, the delivery date shows a day that does not exist, and the brand name has pushed the whole title the other way round.

The text is right. What broke is the screen. An artificial intelligence system produces Arabic that does not have the properties of the text your developers were looking at the day they designed the page: it mixes scripts, it writes its digits in Latin characters, and it adds none of the invisible marks a bidirectional layout uses to decide.

This article names the eight places it breaks, in the order you will meet them, and gives the one-hour check that finds all of them. It does not re-argue that an Arabic interface is not a mirrored French one: that is the prerequisite, it is covered elsewhere, and everything below happens even once it has been respected.

A price, a phone number, a percentage, a quantity: those values read left to right in every language, Arabic included. Dropped as they are into a right-to-left sentence they sit correctly most of the time, and move to the wrong place the moment a sign accompanies them.

The case that breaks is the attached sign: a minus in front of a number, a percent behind it, a currency, a change arrow. The sign is directionally neutral, so it takes the direction of its surroundings, and it ends up on the opposite side from the one it should occupy. A fall renders as a rise with its sign trailing at the end of the line.

The answer is one rule and one trap. The rule: isolate the value in a bidirectional isolation element forced left-to-right, never the whole sentence. The trap: putting that direction on the block rather than on the value also recomputes the block’s alignment, which was inherited, and pushes the figure against the wrong edge of the section.

We fixed exactly that in four places on one site — a proof bar, an offers grid, a featured result and the footer — and every one of them had been written by somebody who knew figures must be isolated. Knowing the rule is not enough if you apply it one level too high.

The usual way to handle two scripts is to stack the fonts: the Latin font first, an Arabic font behind it, and the browser walks down the stack character by character until it finds a face that can draw the glyph. That is what we did, and it is wrong.

The reason is that a modern webfont often ships with a local fallback face, adjusted to occupy the same space. That fallback sometimes has enough Arabic coverage to intercept the character before the Arabic font is reached. The browser finds a face that accepts the glyph, it stops there, and the bold is then manufactured by geometric distortion rather than drawn.

To the eye this gives slightly thickened Arabic with clogged joins, which nobody describes as a bug. It is nevertheless the difference between a page that looks finished and one that looks approximate, and on a phone screen it shows on every heading. We measured the case, tried the stack, and replaced the whole stack under Arabic direction.

Two practical consequences. A professional Arabic font often stops at a normal bold: asking for a weight heavier than it contains restarts the geometric manufacture. And an Arabic sentence inserted into a French page does not inherit the right stack, because the stack is chosen on the document’s direction: it is the element itself that has to carry its language.

Card titles, table columns and breadcrumbs truncate. In Latin, a cut inside a word leaves a readable fragment followed by an ellipsis. In Arabic the cut falls between two joined letters and breaks the join: the letter left on screen changes shape, because its shape depended on the letter after it.

The fragment produced is not an abbreviated Arabic word, it is a run of glyphs that reads badly, and a reader does not reconstruct the original as easily as in Latin. The ellipsis itself is neutral: it lands on whichever side the sentence’s direction gives it, and if that direction was resolved wrongly further up, it appears at the beginning.

What to take from this is not to ban truncation, but to make it visible to the people who sign off the page. A product card whose title comes from a model will receive longer titles than a copywriter used to write, because a model has no screen constraint in mind.

The useful constraint is given at writing time: a maximum length asked of the model, checked in characters rather than in words — Arabic writes the same content 25 to 30 % shorter, so a word count says nothing about the space taken.

We do three things on this subject. We run the check above on your screen, with you there, and we leave you the list. We correct what belongs to the stylesheet and the template — direction, isolation of values, fonts, letter-spacing, line width — and we write the drafting instruction the model will receive. We then wire in a control that refuses text carrying a Latin punctuation mark in an Arabic field.

We refuse to have the Arabic corrected by the model that produced it. It is the proposal that comes up most often and it does not hold: the system has no representation of your screen, it does not know that a line flipped, and it will produce a different variant with nobody knowing which of the two went live.

We do not take on editorial proofreading of the produced Arabic either. Style, register and accuracy are a trade of their own, they are handled with texts reread by somebody who genuinely writes in that language, and a technical supplier claiming to judge both will cost you the quality of one of them.

What you can do without us is most of the work: the six points show to the naked eye, and the fourth — copying a reference and searching for it — needs nothing but your own search field. If they all pass, your problem is elsewhere, and the next question is rather the one the vocabulary these systems do not know raises.