Building a Multilingual Chatbot That Handles Romanized Text
Real users mix languages and scripts — Nepali in Devanagari and in Latin letters, Hinglish, English with local words. How to route, retrieve, parse dates and reply in the right script, with lessons from a production assistant.
A multilingual chatbot that handles romanized text needs four things beyond "the model speaks many languages": test inputs written the way people actually type (Nepali or Hindi in Latin letters, mixed with English), a rule that replies come back in the same language and script as the question, retrieval that doesn't depend on English keywords alone, and deterministic handling of everyday words that carry meaning — dates like bholi (tomorrow) — rather than leaving them to the model. Normalize Unicode before matching, and evaluate every change on mixed-language cases.
How people really write
In LetRelay's user base, a single morning's messages to the assistant can include:
- Plain English: "what's on my plate today?"
- Nepali in Devanagari: "मेरो आजको काम के छ?"
- Romanized Nepali: "aaja mero kaam ke cha?"
- Code-switched English and Nepali: "bholi ko meeting cancel gardinu"
- Hinglish (Hindi and English mixed, usually in Latin letters): "kal ki leave approve karo"
Code-switching — alternating between languages within a conversation or a sentence — is normal in multilingual communities, and romanized typing is common because it's faster on a standard keyboard. A chatbot tested only on English and "proper" Nepali will fail on most of these.
Problem 1: replying in the wrong language or script
Large models are multilingual, but they don't reliably choose the right output language. We saw an English question about a user's own data answered in Korean. We also saw romanized Nepali questions answered in Devanagari, which many users read more slowly than Latin letters.
The fix was an explicit rule in the answer prompt:
Reply in the SAME language and script as the user's question: English gets English; a romanized message (e.g. Roman Nepali or Hinglish) gets the same romanized style in Latin letters. Never switch to another language or script.
Plus lowering the model's reasoning effort for short data answers, which made output steadier. Test it: include questions in each language and script in your evaluation set, and check the reply's script — a simple character-range check distinguishes Latin, Devanagari and other scripts.
Problem 2: routing mixed-language messages
The router decides what a message is asking for (a how-to question, a data lookup, an action). Two things made it work across languages:
- Examples in the prompt in romanized Nepali and code-switched forms, not just English.
- Evaluation cases in those forms. LetRelay's 51-case router evaluation includes romanized Nepali; a routing change ships only if all 51 pass.
Small models handle this well once they've seen examples. The routing design is covered in intent routing with small LLMs.
Problem 3: dates and other meaning-carrying words
"bholi ko meeting" means "tomorrow's meeting". If the date is resolved by the model, it may guess, and date errors are the worst kind — they look right. LetRelay's date parser, which is deterministic and unit-tested, recognizes the everyday romanized Nepali words alongside English:
| Word | Meaning |
|---|---|
| aaja / aaj / aja | today |
| bholi / voli | tomorrow |
| parsi | the day after tomorrow |
| hijo | yesterday |
It also tolerates common misspellings of English words ("tmrw", "tomorow"). The model identifies that a message contains a date phrase; code resolves it in the user's timezone; the confirmation card shows the concrete date. See timezone bugs in web apps for the timezone side.
Apply the same principle to other small, high-value vocabularies in your domain: statuses, priorities, leave types. A short list of local words mapped in code beats hoping the model infers them.
Problem 4: retrieval across languages
If your help content is in English and questions arrive in romanized Nepali, keyword search finds little: "kasari admin banaune?" shares no words with "Users, admins, invites & ownership". Options that help:
- Embeddings from a multilingual model map questions and content in different languages close together. LetRelay's guide retrieval combines keyword matching with embedding similarity.
- Synonyms and transliterations in your search keywords for the most important terms — add the romanized words people actually use to the relevant pages.
- Real questions as anchors: store actual user phrasings, in whatever language they came, alongside each help page.
Measure retrieval per language; aggregate accuracy can hide a language that almost never finds the right page. The retrieval design is in RAG for internal documentation.
Problem 5: text normalization
Before matching text, normalize it:
- Unicode normalization. The same visible character can be encoded in different ways; Unicode Standard Annex #15 defines normalization forms (NFC, NFKC) that make them comparable. Normalize both stored and incoming text.
- Unusual spaces and dashes. Models and phones produce non-breaking spaces and non-breaking hyphens. A test expecting "follow-up" failed against an answer containing a non-breaking hyphen until we normalized them.
- Case folding for Latin script, and Unicode-aware character classes (
\p{L},\p{N}) instead of[a-z], so Devanagari isn't stripped out as "punctuation".
Problem 6: fallbacks in the user's language
When the AI is unavailable, the fallback message should still make sense to the person. A fixed English sentence is acceptable if your users read English, but consider short, pre-written translations for the fallback notices in your main languages — they're static text, so they cost nothing to serve. The fallback design is in AI that degrades gracefully.
A worked example
A message arrives: "bholi ko meeting Priya sanga 3 baje rakhdinu" — roughly, "set up a meeting with Priya tomorrow at 3".
- Normalize the text (Unicode form, spaces, case).
- Route: the small router model, having seen similar examples, returns a structured "request a meeting" action with the person ("Priya") and the date phrase ("bholi").
- Resolve in code: "bholi" → tomorrow's date in the user's timezone; "Priya" → the one Priya in the organization, or a pick-list if there are two. "3 baje" is honest about its limits: the parser understands "at 3" (a bare 1–7 is read as afternoon, working hours) but doesn't know "baje" yet, so the time comes back empty rather than guessed.
- Confirmation card shows the meeting with Priya on tomorrow's date, with the start time left for the person to set before confirming.
- Reply text around the card comes back in romanized Nepali, matching the question.
Nothing in that chain requires the model to be good at Nepali date arithmetic or name lookup; it only has to recognize what kind of request this is. And when the code doesn't understand a word, the card makes the gap visible instead of hiding a guess — which is also how you find the next word to add ("baje" is now on our list). The confirmation pattern is in AI agent actions with human confirmation.
Testing checklist
- Questions in every language and script your users write, including romanized and code-switched
- Reply script matches question script
- Routing accuracy per language
- Retrieval top-1 / top-3 per language
- Date words and domain vocabulary resolved by tested code
- Unicode normalization before matching and in test assertions
FAQ
What is romanized text?
Text in a language normally written in another script, typed with Latin letters — for example Nepali or Hindi written as "bholi" or "kal" instead of in Devanagari.
How do I make a chatbot reply in the user's language?
Add an explicit instruction to reply in the same language and script as the question, and test it with mixed-language cases; models don't choose reliably on their own.
Should a chatbot translate everything to English first?
Not necessarily. Translation adds a step and can lose meaning in code-switched text. Multilingual models plus multilingual retrieval and a same-script reply rule often work better.
How should dates in other languages be handled?
With a deterministic parser that knows the everyday date words your users type, resolved in their timezone, and shown for confirmation before any action.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
LLM Tool Calling for Internal Assistants: Design Choices
How to give an internal AI assistant tools — reading workspace data with the user's permissions, formatting results for the model, native function calling vs a routing step, limits on how many tools run, and answers that stay inside the data.
Stop Your Product Chatbot from Hallucinating Features
A help chatbot that invents buttons, settings and features is worse than no chatbot. How we fixed ours — a feature registry checked against the real UI, retrieval that finds the right page, strict grounding rules, link guards and must-not-include evals.
Caching LLM Responses Safely: What to Cache and What Never To
Caching LLM answers saves tokens and latency — and can leak one user's data to another if done carelessly. A safe design: cache only answers that are identical for everyone, key on normalized question plus content version, expire, and lock the cache down.