Arabic Transliteration, Normalizer and Amount in Words

Normalize Arabic text, transliterate Arabic to Latin or Arabizi, build a name-matching key (Mohammed / Muhammad / محمد) and write AED, SAR, QAR, KWD, BHD and OMR amounts in Arabic words. Deterministic, no web calls, no AI.

What you get

One result per text or amount: script detection, normalized text, Latin transliteration, a name key, or Arabic amount words with an optional cheque phrase. See the example below.

Use cases

• Arabic text normalization for search and deduplication (remove tashkeel, unify alef and ya, convert Arabic-Indic digits).
• Arabic transliteration of names and place names for databases and reports (a simplified romanisation, see limitations).
• Matching Arabic and Latin spellings of the same name with a shared key.
• Amount in Arabic words for invoices and cheques (فقط ... لا غير).

Details of the operations:

Clean and prepare Arabic text for search, databases, invoices and AI pipelines, without any web calls:

• Detect script, diacritics, tatweel and digit style.
• Normalize: strip tashkeel and tatweel, fold presentation forms (NFKC), optionally unify alef/ya/taa-marbuta for search matching, convert digits between Western (0-9) and Arabic-Indic (٠-٩), remove invisible direction marks.
• Transliterate Arabic to Latin (rule-based romanisation, or chat-style Arabizi with 3, 7, 5). Short vowels are only output when the text carries diacritics; unvoweled words come out consonant-heavy (e.g. "al-'rbya"). It is not a dictionary-based or machine-learning transliterator.
• Name matching key: one key for Mohammed, Muhammad, Mohamed and محمد, to match names across scripts and spellings.
• Amounts in Arabic words for AED, SAR, QAR, KWD, BHD and OMR (including fils / halalas / baisa), with an optional cheque-style phrase فقط ... لا غير.

Why use it

Arabic search and deduplication fail silently when diacritics, alef variants and Arabic-Indic digits differ. Invoicing and payroll systems in the Gulf need amounts in Arabic words. This Actor does these jobs deterministically in one cheap call per text.

Input

Field	Meaning
texts	One text per line (up to 10,000 texts, 20,000 characters each)
operations	any of detect, normalize, transliterate, name_key (default first three)
removeDiacritics, removeTatweel	normalize options, default on
unifyAlef, unifyYa, unifyTaMarbuta	aggressive folding for search keys, default off
digits	keep, western, arabic_indic
arabizi	chat-style transliteration
amounts, currency	numbers or amounts to write in words; none gives a plain whole number

Example input and output

Input (bundled test-input.json): texts مُحَمَّد بن عبد الله and الإمارات العربية المتحدة ٢٠٢٦ with operations detect, normalize, transliterate. Real output for مُحَمَّد بن عبد الله with all four operations, and the amount 1250.5 in AED:

{
  "kind": "text",
  "input": "مُحَمَّد بن عبد الله",
  "detect": { "script": "arabic", "arabic_letters": 13, "has_diacritics": true, "direction": "rtl" },
  "normalized": "محمد بن عبد الله",
  "transliterated": "muhammad bn 'bd allah",
  "name_key": "mhmd bd lh",
  "name_key_compact": "mhmdbdlh"
}
{
  "kind": "amount",
  "input": "1250.5",
  "currency": "AED",
  "words_ar": "ألف ومائتان وخمسون درهماً وخمسون فلساً",
  "words_ar_cheque": "فقط ألف ومائتان وخمسون درهماً وخمسون فلساً لا غير"
}

Limitations (read before relying on it)

• Transliteration is a simplified romanisation, not ISO 233 or ALA-LC. Without vowel marks, Arabic text has no short vowels, so محمد becomes mhmd; with full diacritics مُحَمَّد becomes muhammad. Names, loanwords and dialect spellings may differ from official passport spellings. Latin to Arabic is not supported.
• The name key is a fuzzy matching aid, not identity resolution. It drops vowels and common particles (bin, ibn, al, abu). Different names can collide; always confirm matches.
• Amounts in words follow standard Arabic number-noun agreement (singular, dual, plural, accusative tanween) in the nominative style used on invoices. Currency names: dirham/fils (AED), riyal/halala (SAR), riyal/dirham (QAR), dinar/fils (KWD, BHD), rial/baisa (OMR), with 2 or 3 minor digits per ISO 4217 (https://www.iso.org/iso-4217-currency-codes.html). Have a native speaker review the format for legal documents and cheques; banks and regulators may require their own phrasing.
• Amounts are limited to below 1,000,000,000,000 and rounded half-up at the currency's minor precision.
• Letter and diacritic classes follow the Unicode Arabic block (https://www.unicode.org/charts/PDF/U0600.pdf).

Pricing (pay per result)

Pay-per-event with Apify's built-in dataset-item event: each text or amount is one result. The live price is set in Apify Console and shown on the Store page (see Store). Planning figure in our notes: USD 2.00 per 1,000 results. The closest competitor found (a generic Unicode normaliser, no Arabic-specific features) lists from USD 0.0005 per text (USD 0.50 per 1,000); generic text-cleaning Actors list USD 0.5-3 per 1,000 (checked 21 Oct 2026, see apify/RESEARCH-2.md).

FAQ

Does it call any website or AI model? No. Everything is computed locally.

Can it transliterate Latin to Arabic? Not in this version.

Does it handle Persian digits and letters? Persian digits are read as digits; پ چ گ ڤ are romanised; other Persian-specific behaviour is not tuned.

Is my text stored? Only in your run's dataset.

Is the transliteration good enough for passports or legal names? No. It is a simplified romanisation; official spellings can differ.

Can it write amounts in Arabic words for KWD with three decimals? Yes: KWD, BHD and OMR use three minor digits, the others two.