📄 Machine Transliteration of Names in Arabic Texts

Summary

Arabic news text often contains foreign and Arabic personal names. Translating these names into English is hard because Arabic script usually leaves out short vowels and maps several English sounds onto one letter, so a single written form can match many romanizations. Al-Onaizan and Knight frame Arabic→English name transliteration as probabilistic decoding with cascades of weighted finite-state machines. They compare two approaches. The first is the established phonetic route, which passes through English pronunciations taken from a pronunciation dictionary. The second is a new spelling-based route that links English letter sequences directly to Arabic letters. The spelling model learns from fairly small lists of name pairs, which are easier to collect than phoneme-aligned data. It also handles names that the phonetic route cannot pronounce. The authors test both models and their combination on names grouped by origin, using exact-match scoring and human judgments, and compare the system with human translators. The spelling-based model beats the phonetic one by a clear margin. This matters for cross-lingual search and named-entity translation, where names make up much of the vocabulary not found in dictionaries.

Key points

• Transliteration is built as a generative noisy-channel model: candidate English words are scored by an English model times a channel model, and both are implemented as weighted finite-state transducers.
• Phonetic-based model: English spelling → English sound sequence (via a pronunciation dictionary) → Arabic letters. It struggles with names that are missing from that dictionary or are not English in origin.
• Spelling-based model: English letter sequences map directly to Arabic characters, with probabilities learned from name-pair lists. It needs no phonetic alignment.
• Test names are split by origin (Arabic, English, other), because each model's success depends strongly on where a name comes from.
• Evaluation uses two views: exact string match against a reference, and human judgment of whether an output is acceptable. System output is also compared directly with human translators.

Interesting ideas

• I1. Swapping a pivot layer (pronunciation) for direct surface-to-surface mapping can raise both coverage and accuracy when the pivot resource is incomplete.
• I2. Using a cascade of small, separately trained weighted transducers keeps each step inspectable and lets you combine or replace parts independently.
• I3. Reporting results by name origin shows where a model really fails, which a single overall score would hide.
• I4. Scoring with both strict exact match and lenient human-acceptability judgments separates real errors from harmless spelling variation.
• I5. Comparing the system with human translators gives an interpretable upper reference instead of treating the gold list as perfect.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (tokens): unknown proper nouns and foreign words could get lemma and morphology guesses from letter-level patterns learned from examples, instead of failing when a word is not in the lexicon.
• I2 (learn): repair rules and normalizers could be kept as composable weighted stages with logged scores, so every rewrite in silver data can be traced to one stage.
• I3 (learn): evaluation sets should be split by provenance (fable, school test, news, foreign names) so regressions in one subgroup are not averaged away.
• I4 (answer): answers naming entities could be graded with an exact key and an alias-tolerant key, so that "Mohammed" versus "Muhammad" is not counted as a reasoning error.
• I5 (world): when linking entity names to Wikidata, a small human-matched sample could calibrate how much name variation is acceptable before merging two entities.