📄 A Simple but Effective Approach to Improve Arabizi-to-English Statistical Machine Translation

Summary

Arabic user-generated content is often typed in Arabizi, an informal romanization that mixes Latin letters and digits. A system trained on conventional Arabic-English data sees nearly all such tokens as out-of-vocabulary, and the lack of any standard spelling makes hand-written rules unreliable. The authors propose a lightweight pipeline that requires no expert or native-speaker knowledge. It first converts Arabizi into Arabic script, then passes the result to an ordinary phrase-based SMT system. The pipeline has four stages:

• Generate many candidate spellings from a public character table.
• Discard candidates absent from a large Arabic vocabulary.
• Pick among the survivors using sentence context and an Arabic language model.
• Favour options attested in a small, manually transliterated NIST tritext.

Adding these attested word pairs roughly halves the word-level transliteration error. End-to-end translation quality approaches what human transliteration of the input achieves. The authors also release the software and a crawled Arabizi-English bitext of about 10K sentence pairs, which is valuable because Arabizi resources are scarce.

Key points

• Resources used:
  • Candidate generation relies on a public Wikipedia Arabizi-Arabic character table with uniform weights.
  • Decoding follows the phrase-based SMT setup with distortion limit 0 (monotone) and a 5-gram Arabic character LM.
• Main SMT bitext: 1.75M sentence pairs and 52.9M Arabic tokens, about 70% news and 30% informal genres. It also supplies a 200K-word Arabic vocabulary used for filtering.
• Disambiguation: srilm-disambig with a 3-gram Arabic word LM selects among the remaining 5–10 candidates per word.
• Error rates: on two held-out test sets built from 1,788 items of the NIST tritext (LDC2013E125), word-level transliteration error falls from about 46–51% to about 26–28% once Arabizi-Arabic word pairs are added.
• Released data: a web-crawled Arabizi-English bitext of roughly 10K sentence pairs and 180K Arabizi tokens, taken from news comments and translated professionally.

Interesting ideas

• I1. Character-level script conversion is treated as monotone phrase-based translation, so off-the-shelf decoders can handle segmentation ambiguity (one versus two letters per symbol).
• I2. Generation deliberately over-produces candidates, and filtering keeps only words the downstream model actually knows, since any other output would be useless anyway.
• I3. Mappings are allowed to drop vowels so that expressive elongations like "henaaa" can still reach the real word.
• I4. Words that cannot be converted are left untouched rather than forced into a wrong form, which accidentally handles code-switched English correctly.
• I5. The authors compare against human-transliterated input as an upper bound, and they notice that a halved intermediate error rate barely moves BLEU.

For Mova

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

• I1 (tokens): a small monotone character decoder could normalize noisy input such as leetspeak or phonetic misspellings into dictionary forms before tagging, with every mapping step traceable.
• I2 (tokens): spelling-repair or lemma candidates could be pruned against the lexicon the tagger and morphology were trained on, keeping repairs aligned with model coverage.
• I3 (tokens): an explicit rule collapsing repeated letters ("sooo", "noooo") before lemma lookup would let emphatic informal text reach correct lemmas.
• I4 (tokens): when a normalizer has no confident candidate, passing the original token through avoids injecting errors that would propagate into the UD tree.
• I5 (learn): evaluation should also feed gold-preprocessed input through the same pipeline and measure downstream answer quality, not only intermediate error, to see whether a preprocessing gain truly matters.