Why AI Output Uses the Wrong Numerals for Arabic Text

You asked for Arabic numerals in an Arabic document and got 2026. The model was not wrong: in English, “Arabic numerals” means exactly the digits 0–9 you are reading now. The digits you wanted have a different name.

The naming collision

This is one of the few locale bugs that is genuinely a terminology problem rather than a data problem. In English typographic and historical usage, Arabic numerals are the Western digits 0123456789 — so called because they reached Europe through Arabic mathematical texts. The digits actually used when writing Arabic in much of the Arab world are called Arabic-Indic digits, or Eastern Arabic-Indic, and are a distinct set of code points.

So a prompt that says “use Arabic numerals” is, read literally and in the register the model has most evidence for, a request for the digits it already produced. The instruction is not being ignored; it is being followed under the other meaning. Every reliable fix starts with naming the digits unambiguously, and the unambiguous names are Unicode code point ranges.

Three ranges, and which is which

• ASCII digits, U+0030–U+0039. 0123456789. In CLDR this numbering system is named latn. This is what English calls Arabic numerals.
• Arabic-Indic digits, U+0660–U+0669. ٠١٢٣٤٥٦٧٨٩. The CLDR numbering system arab. These are the digits used with Arabic in Egypt, Sudan and the Arabian Peninsula.
• Extended Arabic-Indic digits, U+06F0–U+06F9. ۰۱۲۳۴۵۶۷۸۹. The CLDR numbering system arabext. Used for Persian and Urdu. Four of the ten glyphs differ visibly from the arab set — notably four, five and six — and mixing the two sets inside one document is a real and visible error to a reader even though software will rarely complain.

The character charts are the authority here; the Unicode Consortium publishes them for the Arabic block, which contains all three of the ranges above except ASCII. If you are writing a validator, work from the code point ranges and not from a rendered sample, because several of the glyphs are visually close enough that a screenshot will not tell you which set you have.

Which region uses which

Getting the digit system right is not a single global answer for Arabic. Broadly: the Mashriq — Egypt, Sudan, the Levant, Iraq and the Gulf states — writes with Arabic-Indic digits in most printed and handwritten contexts, while the Maghreb — Morocco, Algeria, Tunisia, Libya — uses Western digits as the everyday default. CLDR encodes this: the default numbering system for ar and ar-EG is arab, while ar-MA and the other Maghreb locales default to latn.

Register matters too, and this is the part a rule table will not tell you. Even in countries that use Arabic-Indic digits in prose, technical material, invoices, software interfaces, phone numbers and anything derived from an international standard very often use Western digits. A document can legitimately contain both. If you are generating for a specific customer, the right move is to look at a document they already publish rather than to apply the country default, because the country default is a statement about newspapers and the document you are producing may not be one.

The instruction that works

Three things make the instruction reliable, and all three matter:

1. Name the code point range, not the digit system. “Write all numerals using Arabic-Indic digits in the Unicode range U+0660 to U+0669” leaves nothing to interpret. Do not say “Arabic numerals”.
2. Show the ten digits. Include the literal string ٠١٢٣٤٥٦٧٨٩ in the instruction. This is the single highest-value addition, because it removes any dependence on the model resolving a name to a glyph set, and it also pins which of the two eastern sets you mean.
3. Say what to do about exceptions. State explicitly whether version numbers, code identifiers, URLs and phone numbers should stay in Western digits. Left unsaid, the model will make an inconsistent choice within one document, and inconsistency is more noticeable to a reader than either uniform answer.

Even with all that, the durable fix is not to ask at all. Digit transliteration is a ten-entry lookup table. Generate the text with whatever digits come naturally, then map U+0030–U+0039 to U+0660–U+0669 in a post-processing pass, with an exclusion for anything inside a code span, a URL or an identifier. That pass is deterministic, testable and cannot be talked out of its behaviour by a long context, which is exactly the argument made in what to do when output ignores a language instruction.

The bidi consequence nobody expects

Switching digit systems changes how the text lays out, because the two sets have different Unicode bidirectional character classes. ASCII digits carry the class European Number (EN). Arabic-Indic digits U+0660–U+0669 carry Arabic Number (AN). Extended Arabic-Indic digits U+06F0–U+06F9 carry EN, like ASCII, despite being the eastern set — an asymmetry that surprises people every time.

The practical difference is in how a separator between digits behaves. A comma or a full stop between two AN digits is treated as part of the number under the Unicode Bidirectional Algorithm’s rules for common separators; the same character between EN digits resolves differently, and a slash between numbers is handled by a different rule again. This is why converting the digits in a date can change where the slashes land on screen without changing a single character in the logical string. If a date looks reordered after a digit swap, the string is probably fine and the rendering is doing what UAX #9 says — the reversed-numbers bug covers how to tell an actual corruption from a correct render.