Building for users who do not write in one language

The input you will actually receive

A support box in India does not receive Hindi or English. It receives this:

bhai order kal aana tha, still nahi aaya. cancel karna hai, refund kab milega?

Roman-script Hindi with English words, no diacritics, spelled however the user types. Then the next message is in Devanagari, and the one after that is Tamil, and one is Bengali written in Roman script with an English product name in the middle.

This is normal for most of the world. If your prompt says respond in the user’s language, you have not specified anything, because there are two languages and one script and no clean answer to what “their language” is.

Four decisions to make explicitly

1. Which script do you reply in? The safest default is: reply in the script the user wrote in. Somebody who typed Roman-script Hindi may not read Devanagari comfortably: script and language are independent, and getting this wrong makes your reply unreadable to the person who wrote to you. State it as a rule:

Reply in the same language and the same script as the user’s most recent message. If they wrote Hindi in Roman letters, reply in Hindi in Roman letters.

2. What happens to product terms and legal text? Order IDs, product names, statutory notices and policy phrases usually should not be translated. Say so, and give an example, because a model asked to reply in Hindi will cheerfully translate your product name and your refund policy’s legal wording.

**3. Which language does the retrieval run in?** Your documentation is probably in English. A Hindi query against an English index will retrieve badly unless you either use a multilingual embedding model or translate the query first. This is usually the real cause when a multilingual assistant is bad in one language: not generation, retrieval.

4. What language are the internal steps in? Keep classification labels, tool arguments and JSON keys in English. Only the user-facing text is translated. A category field that comes back as बिलिंग will not match your enum and your code will fall through to a default nobody tested.

Quality is not uniform, and you must measure per language

Every multilingual model is best in English and degrades unevenly. The degradation is not a single number: it varies by task and by language, and it is worst where training data is thinnest.

What this means practically: an aggregate quality score across all languages is a lie. If 80 per cent of your traffic is English at 95 per cent quality and 20 per cent is Tamil at 60 per cent, your headline number is 88 and your Tamil users are having a bad time invisibly.

So your evaluation set is stratified. Twenty cases per language you actually serve, scored separately, reported separately. That is the only way the Tamil number can move, because a number nobody computes cannot be improved.

And it costs more, as the first module showed: the same conversation in Devanagari or Tamil script consumes two to four times the tokens. Budget per language, not per user.

Techniques that help, in order of value

Examples in the target language. Two examples of good Hinglish replies do more than any instruction about tone in Hinglish. Write them with a native speaker; do not have the model generate them and assume they are idiomatic.

Translate the query for retrieval, keep the answer in the user’s language. Cheap, and it fixes the most common failure.

Do not translate your prompt. Instructions in English generally work at least as well as instructions in the target language, because the model’s instruction-following was trained predominantly in English. Instructions in English, output in the target language, is a normal and effective combination.

Beware transliteration round-trips. Converting Roman Hindi to Devanagari, processing, and converting back loses information: names in particular. Prefer working with what the user sent.

Say what you do not support

If your assistant is poor in a language, the honest option is to detect it and route to a human or say plainly that support in that language is limited. That is more respectful than confident, subtly wrong Tamil.

The test is straightforward. Take twenty real messages in each language, have a fluent speaker read the replies, and ask one question: would you be happy receiving this from a company? If the answer is no for a language, you do not support that language yet, whatever the model’s marketing page claims about the number it supports.