2026 and ٢٠٢٦ are the same year. Newspapers
use one, government forms often use the other, and most writers mix them without thinking
about it. If you produce Arabic voice-over, that choice turns out to matter more than
anything else on the page.
The test
Fifteen Arabic sentences, each written three ways. Same words, same punctuation, same length. The only thing that changes is how the number is typed:
في عام ٢٠٢٦ ارتفعت نسبة المشاركة
في عام ألفين وستة وعشرين ارتفعت نسبة المشاركة
Forty-five utterances per engine. Synthesise, transcribe, and ask one narrow question: could a listener recover the number? Not whether the voice is pleasant — whether the figure survived. The categories are the ones that appear in real work: years, percentages, currency, times, dates, phone numbers, decimals, large counts.
The result
| Numeral form | Fish Audio | Apple Majed |
|---|---|---|
| Western 2026 | 73% | 80% |
| Arabic-Indic ٢٠٢٦ | 7% | 80% |
| Spelled out | 73% | 53% |
Apple scores the same on both digit forms, because it converts the numeral before speaking. The other engine drops from 73% to 7% on identical sentences.
And the failures are not near-misses. ٢٠٢٦ in a date came back as تخاناتر. The time ٢:٤٥ came back as انفافس اسم مفاعس. That is not a mispronounced number; it is noise where a number should be.
Why this matters more than it sounds
Nobody notices, because TTS demos do not contain numbers. You audition a voice on a paragraph of prose, it sounds excellent, and you ship it. The failure only appears in the deliverable — a price, a date, a phone number, a percentage in an awareness film — and by then it is in front of a client.
The fix is one line: normalise every numeral to Western digits before synthesis. What is worth knowing is that you have to know to do it.
A second thing, found by accident
While testing prosody I noticed the same engine sounds mechanical — word by word, evenly spaced — on plain Arabic. Written Arabic omits short vowels, so the engine has to guess how each word is voiced, and when it is unsure it retreats to a flat read.
Add tashkeel and it stops guessing. The same sentence runs 7.8 seconds undiacritized and 10.6 seconds diacritized: it is phrasing rather than marching. A native Emirati speaker, given three takes blind, chose the diacritized one.
Two rules for Arabic TTS, and both cost nothing:
Western digits. Diacritics.
Honesty about the numbers
The absolute percentages understate both engines. The measurement chain is TTS → transcription → a number parser, and an error anywhere gets charged to the voice. Three rounds of fixes to my own scorer moved the Western scores from 47% to 73–80% without a single audio file changing — most of the early “failure” was my harness, not the engines. One of those bugs was silently punishing Apple for speaking dates ordinally, which is correct Arabic.
The 7% versus 80% gap is the robust finding. Transcription noise cannot manufacture that, and the Arabic-Indic transcripts are visibly gibberish rather than approximations. Still open: only two engines, and no full human listening pass yet — every judgement so far is a transcriber’s, not an ear’s.
Reproduce it
The sentence set, the scorer and the results are published as ArNum-TTS on Hugging Face. The audio is not — the free tiers used carry no redistribution rights, and regenerating it takes a minute anyway, which makes the benchmark reproducible instead of frozen.
python build_set.py python run_bench.py --engine fish python run_bench.py --engine apple
If you work in Arabic audio, run it against your engine. I would like to know which others get ٢٠٢٦ right.
Part two: The Arabic fix everyone recommends is now the thing breaking your Arabic.