📄 Automated Generation of Arabic Verb Conjugations with Multilingual Urdu Translation: An NLP Approach

Summary

Arabic verbs inflect for tense, person, gender and number, and many forms are marked only by diacritics. This makes full conjugation tables hard to produce automatically. Urdu learners also have few computational resources that link these forms to their own language. The authors built a rule-based generator for triliteral, non-weak Classical Arabic roots. Its coverage spans four tense types: the Past Simple and the Present Simple, each in both affirmative and negative form.

The roots are frequent in the Quran and classical literature and were checked against the Quranic Arabic Corpus. Each root is matched to regex-style lexeme templates (Baab patterns). Rules then attach prefixes and suffixes and apply phonetic adjustments. A parallel module fills predefined Urdu templates that agree with the Arabic form's features.

The released dataset was reviewed by scholars of Jamia Ashrafia, Lahore. A comparison with Google Translate exposed grammatical errors by the general-purpose system. The authors present the work as the first bilingual Arabic–Urdu conjugation resource, mainly for education and religious study.

Key points

• The system covers only triliteral, non-weak roots. Weak and quadrilateral roots, dialects, Persian and Pashto are left for future work.
• The authors report 200 roots with 78 variants each, giving 14,400 entries with Urdu translations. Note that the stated numbers do not multiply out (200 × 78 = 15,600).
• Roots were taken from Quranic and Classical Arabic sources and validated with the Quranic Arabic Corpus.
• Validation combined two checks:
  • comparison with reference conjugation patterns;
  • manual review by Jamia Ashrafia scholars.
• The dataset is public on GitHub (haqnawaz99/Arabic-Urdu-Conjugation-Dataset). Future plans mention AraBERT or multilingual BERT to generalize to unseen roots.

Interesting ideas

• I1. Full inflection tables are produced exhaustively from a root plus a pattern class, so coverage is systematic rather than corpus-dependent.
• I2. The target-language phrase is chosen by the same feature bundle (person, gender, number, tense, polarity) that produced the source form, not by string mapping.
• I3. Something one language encodes in a suffix (Arabic dual) must be spelled out with extra words and reordering in the other (Urdu "those two men"). Number therefore has to be kept as meaning, not as surface form.
• I4. Negation is treated as a full dimension of the paradigm, yielding a crossed grid of feature combinations that can serve as a test suite.
• I5. Expert review of generated output is paired with a general-purpose MT baseline to show where generic systems lose grammatical detail.

For Mova

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

• I1 (tokens): generate complete English paradigms from lemma and inflection class, then diff them against the morphology lexicon to find gaps and irregular-form errors.
• I2 (back): realize text from frame features via per-feature templates, so each output word traces back to an explicit grammatical decision.
• I3 (world): store grammatical number, including "exactly two", as an entity property, so translation through the meta-world can choose morphology or periphrasis per language.
• I4 (learn): build controlled grids of polarity × tense × person sentences as negative-control evaluations, checking that frames flip polarity and nothing else.
• I5 (learn): compare Mova's explainable outputs with an LLM baseline on minimal feature contrasts, so specific failure categories become visible.