📄 Translating Names and Technical Terms in Arabic Text

Summary

The paper addresses back-transliteration from Arabic to English. Given a foreign name or loanword written phonetically in Arabic script, the goal is to recover its original Roman spelling, for example turning "bytr strymz" back into Peter Streams. Arabic makes this hard in several ways. Short vowels are not written, several English consonants merge into one Arabic letter (P/B become b, F/V become f), and nothing in the script marks a word as borrowed. The authors adapt the Japanese noisy-channel cascade of Knight and Graehl (1997). They keep its English-only models, a word-sequence model and a pronunciation model, and add a single new model that maps English phonemes directly to Arabic letters, skipping hidden Arabic pronunciation. The models are weighted finite-state machines combined by composition. The new model is trained with EM on a small hand-built name list, and English sounds may produce no Arabic letters at all. The system works inside an Arabic-to-English MT engine and produces reasonable candidates. Most of the paper is careful error analysis, which matters because borrowed names are the main source of words missing from bilingual dictionaries.

Key points

• The architecture reuses P(w) and P(e|w) from Knight and Graehl (1997) and adds one new model, P(a|e), from English phonemes to Arabic writing. The usual pair of a phoneme model plus an orthography model was dropped because Arabic pronunciations are unobservable.
• Training data is a hand-made dictionary of about 150 words. English pronunciations come from the CMU Pronouncing Dictionary, and parameters are learned with EM. The EM is modified so an English sound can map to an empty Arabic output.
• Models are WFSA/WFSTs composed in the style of Pereira and Riley (1997). The best English candidates are read off the resulting lattice by graph search.
• The final D of names like Edward and Raymond is often dropped in Arabic. Allowing D to vanish anywhere produced wrong outputs such as Friedman for Freeman, so deletion was limited to word-final position by extending the transducer. Even that rule overgenerates (Alfred for Oliver), and the authors suggest a narrower post-consonant condition.
• The error analysis traces several failures to specific causes:
  • Training-data quirks, such as the German-style Koch giving CH→x weight 0.5, and Frederick causing a spurious R→y mapping.
  • Arabic that follows English spelling rather than sound, as in James and Graham.
  • English stress, which was found to correlate weakly with where Arabic places long vowels.

Interesting ideas

• I1. Collapse two unobservable stages into one direct mapping when no data exists for the hidden middle layer, instead of inventing it.
• I2. Build the system to be deliberately brittle, so that failing to find any good candidate becomes a useful signal that the input probably is not a transliteration.
• I3. Allow a learned mapping to delete material, but only in contexts licensed by an explicit positional constraint (word-final D), encoded directly in the transducer shape.
• I4. Trace each systematic error back to the specific training item that skewed a probability, as with Koch and Frederick.
• I5. Chain small generative models (writing, pronunciation, script, noise) and invert the chain with Bayes' rule, so each stage stays separately inspectable.

For Mova

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

• I1 (back): When generating or translating through the meta-world, skip any intermediate representation that has no annotated data and learn the visible-to-visible mapping directly.
• I2 (answer): A reader that refuses low-confidence analyses can flag "this may not be a name or entity" rather than forcing an answer, which keeps the explanation honest.
• I3 (tokens): Morphology and normalization rules for clipped or elided forms can permit empty outputs only in stated positions, so learned deletion stays explainable and does not overgenerate.
• I4 (learn): When self-induced repair rules or silver data shift a weight, record which examples caused it, so a bad rule can be explained and removed.
• I5 (tokens): Recovering misspelled or OCR-garbled English words could use a similar cascade of a word model, a spelling-variation model and a noise model, with each step's contribution visible.