Arabic speech to text for business, read from the docs

Somebody wants to transcribe customer calls, or index a few hundred hours of recorded meetings, or route voice notes into a ticketing system. They search for Arabic speech to text, find a demo that works on a clear sentence of Modern Standard Arabic, and conclude the problem is solved. Then they feed it an Egyptian sales call with two people talking over each other and half the product names in English, and the output is unusable.

The gap between those two experiences is documented, in public, by the vendors themselves. It is just documented in support tables rather than in marketing pages, and those tables are the honest version.

Arabic is not one language to a speech model

Both major cloud vendors treat Arabic as a set of country locales rather than a single language. That is not a technicality. A model trained on Gulf speech handles Moroccan Darija badly, and the vendors acknowledge this by shipping separate locale codes and separate levels of support behind each one.

Which means the first decision is not which vendor. It is which locale your speakers actually use, because that determines what you are allowed to turn on.

What Google documents

Google's Speech-to-Text supported languages page lists Arabic locales for Algeria, Bahrain, Egypt, Iraq, Israel, Jordan, Kuwait, Lebanon, Mauritania, Morocco, Oman, Qatar, Saudi Arabia, the State of Palestine, Syria, Tunisia, the UAE and Yemen, plus a pseudo-accent entry used for testing.

The interesting part is not the breadth, it is the unevenness. Most of those locales offer the chirp_3 model in the eu and us regions and the older long and short models globally. Egypt is the exception that proves the point: ar-EG is the only Arabic locale on that page with chirp and chirp_2 available, and they are tied to asia-southeast1 and europe-west4 specifically. Syria, by contrast, appears with chirp_3 only and no long or short models at all.

The page also carries a warning worth repeating to any developer about to guess a code: use only the language codes in the table, because other codes are not maintained by Google and can cause breaking changes. There is no generic "ar" that quietly does the right thing.

What Microsoft documents

Microsoft's Azure AI Speech language support page lists eighteen Arabic locales for speech to text and states plainly that language support varies by functionality. Every one of the eighteen supports real-time transcription, batch transcription and fast transcription. After that the table thins out fast.

Multilingual post-stream refinement is listed for three Arabic locales only: Bahrain, Egypt and Saudi Arabia. Azure's LLM-based speech transcription is listed for the same three. For custom speech, every base model accepts plain-text customisation, but structured text customisation is available only for ar-EG and ar-SA, and ar-SA alone also lists output format and phrase list support.

Azure also lists ar-LY for Libya, which did not appear in the Google table we read. Small difference, large consequence if Libya is your market.

The two lists side by side

What this means if you are buying

Three practical consequences fall out of those tables, and none of them appears in a sales demo.

• The good features cluster on three locales. Egypt, Saudi Arabia and Bahrain get the capable models and the richer customisation on both platforms. If your callers are Moroccan, Sudanese or Libyan, you are on the base model and your pilot should be designed to find out whether that is good enough.
• Model availability is a hosting constraint. Google's better Egyptian Arabic models are pinned to specific regions, which is a problem if a customer or a regulator requires processing to stay somewhere else. That is the same constraint that shows up in data residency requirements and who sets them, and it is worth resolving before anyone writes code.
• Pick the locale, not the language. Sending Gulf speech to an Egyptian locale, or either to a generic code, is the most common self-inflicted accuracy problem, and it is free to fix.

What neither vendor publishes

Neither page publishes a word error rate. Not per locale, not per model, not for any Arabic variety. That is the number a buyer actually wants, and the absence is consistent across both vendors, so treat any supplier quoting you an Arabic accuracy percentage as quoting their own test set rather than a published benchmark.

The second undocumented thing is code switching. Business Arabic in Cairo and the Gulf mixes English product names, English numbers and whole English clauses into Arabic sentences, and neither support page says what happens to accuracy when it does. Azure's LLM transcription detects languages automatically and makes the locale field optional, which suggests the problem is being worked on, but inferring performance from a configuration note would be guessing.

This is the same shape as every other applied AI question we write about here. The capability is real, the documentation describes its edges honestly, and the only way to know whether it clears your bar is to measure it on your own material, which is the argument in measuring the return on AI automation honestly.

How to test it in a week

A pilot that answers the question costs a few days and does not need a vendor's help.

• Collect twenty to thirty real recordings, deliberately including the worst audio you have: speakerphone, background noise, two people interrupting.
• Transcribe each one with the correct locale, then with a neighbouring locale, and compare. The difference tells you how much the locale choice is worth before you spend anything on tuning.
• Score on what matters rather than on overall accuracy. Names, numbers, product names and amounts. A transcript that gets the sentiment right and the figure wrong is worse than useless in an operations workflow.
• Test the customisation path on the platform you prefer, because that is where the recoverable accuracy lives, and on Azure it is restricted by locale.
• Hand ten transcripts to the person who will actually use them and ask whether they would trust them unread. The answer is usually no at first, which is a scoping finding and not a failure.

What you do with the output is a separate build. Transcription that feeds a summary has the failure modes described in AI meeting notes and what they are actually good at, and transcription that feeds extraction into a system of record has the ones in AI document processing and where it still needs a person. Both are worth reading before the transcription itself is treated as the project.

One more thing about the most common use case. Most people asking for Arabic call transcription want to know what customers actually said in sales conversations. Transcribing a bad discovery call just gives you a readable bad call, so the question set is the real lever, and BDG Labs has a solid version of it in the eight discovery questions that decide a deal.

Honest limits

Both support pages are longer than we could read in full. Google's runs to roughly 140,000 characters and Azure's to roughly 170,000, and our read of each was truncated. The locale and feature lists above are accurate for the part we read and should be treated as indicative rather than exhaustive. Check the live page for your locale before you commit to a platform.

No accuracy claims, in either direction. We have not told you that Arabic transcription is good enough for your use case or that it is not, because we have no benchmark to offer and neither does the vendor. The test plan above exists because the published documentation genuinely cannot answer it.

Google Distributed Cloud is a different product. A separate Google page lists Levantine, Maghrebi and Peninsular Gulf Arabic variants, which looks like exactly what a dialect-heavy business wants, but it belongs to the Distributed Cloud offering rather than the public Speech-to-Text service. We have not evaluated it and have not assumed the variants are available in the service described above.