📄 Botta: An Arabic Dialect Chatbot

Summary

Arabic is poorly served by conversational agents, and its spoken dialects even more so. Dialects have no standard spelling, heavy inflection and ambiguity, and their own conversational formulas. The authors build BOTTA, which they describe as the earliest chatbot able to hold a conversation in a dialect of Arabic. It has a friendly young female persona, speaks Cairene Egyptian Arabic, and recognizes greetings from several other dialects. The authors chose not to learn from corpora, because mixing many speakers' voices would make the persona incoherent. Instead they hand-author the bot in AIML on the Pandorabots platform, partly adapting resources from the English bot Rosie. The knowledge base has three parts:

• AIML category files (greetings, biography)
• set files (countries, dialect-specific month names, offensive words, dialect cues)
• map files (nation2capital, word2proverb, name2gender)

User input is orthographically normalized before pattern matching. An informal trial with three native speakers found the bot entertaining and authentically Egyptian, though sometimes repetitive. The database files are released publicly as a starting base for future Arabic botmasters.

Key points

• BOTTA 1.0 is built in AIML, hosted on Pandorabots (BotID dana33/botta), with database files distributed via the CAMeL lab resources page.
• Input normalization has three rules, partly drawn from CODA: Alif-Maqsura→Ya, Ta-Marbuta→Ha, and Alif-Hamza forms→bare Alif. Citing Eskander et al. (2013), these cover 85.1% of spelling errors in spontaneous typing, and Alif-Hamza errors alone account for 38.5%.
• Gendered responses rely on guessingthegender.aiml. It looks up the user's name in names.set and then in name2gender.map, confirms the guess with the user, and asks directly if the name is unknown.
• Preliminary evaluation used three native speakers (two Egyptian, one Levantine). They praised authenticity and entertainment value but noted repetition and out-of-context remarks.
• Planned work includes corpus-based learning and morphological analysis of input with Egyptian Arabic tools (Pasha et al., 2014) for lemma-based matching. Call Home Egyptian was considered, but its speakers are acquaintances of varied age and gender, which does not match the persona.

Interesting ideas

• I1. Normalize noisy input only for matching while leaving generated output in natural spelling, so robustness does not degrade output quality.
• I2. Idiomatic exchanges like Arabic's modified echo greetings (a greeting answered with a related but different phrase) cannot come from translating another language's bot; they need language-specific pairing tables.
• I3. Infer a hidden attribute (user gender) from a name lexicon, confirm it, and fall back to asking when the name is missing. This is a three-step guess, verify, and defer policy.
• I4. The authors avoided multi-author conversational data because pooled sources would blend inconsistent perspectives into one voice.
• I5. Evaluators were not told the bot's purpose and were asked to guess it, a cheap blind check of whether the system's behaviour conveys its intended role.

For Mova

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

• I1 (tokens): Keep a separate matching key (case, spelling-variant, contraction-normalized) next to each token's surface form, so lexicon lookup tolerates noise while the original text stays available for explanation and generation.
• I2 (frames): Store conventional adjacency pairs (greeting/reply, thanks/acknowledgement) as an explicit lexicalized table in the speech-act layer, rather than deriving them compositionally.
• I3 (world): Assign entity gender from name lists with an explicit "unknown" state instead of a forced default, so pronoun coreference can report that it lacks evidence rather than guessing silently.
• I4 (learn): When building silver data from heterogeneous treebanks or LLM teachers, track provenance and check annotation-convention consistency, so training does not average incompatible styles.
• I5 (answer): Have judges infer what a reader's answer was meant to establish without seeing the question type, to test whether explanations are self-evidently on target.