Chatbot

Multilingual Chatbot That Replies in the Customer's Language

A chatbot with no language limitation recognises the language each customer writes in and answers in that language, from a single knowledge base. This guide covers how detection behaves in a live chat, why a translation layer is not the same thing, and the four preparations that make a rarer language such as Azerbaijani work as well as English.

A multilingual chatbot is a bot that recognises the language of every incoming message and answers in that same language, without asking the customer to choose a language first. One bot, one knowledge base, one inbox — not a separate bot for every market. The real test is not English or Spanish; it is a less common language such as Azerbaijani, where a translated answer can be grammatically acceptable and still commercially wrong.

This guide explains how language detection behaves in a live conversation, what you have to prepare so a rarer language performs as well as English, and where translation-based setups quietly fail.

What "no language limitation" actually means

Many chatbot descriptions say "supports 100 languages". That sentence usually hides a list: the vendor has prepared interface strings and canned replies for a fixed set of languages, and everything outside that list falls back to English. A chatbot that replies in the customer's language works the other way round — there is no list at all.

• The customer writes in whatever language they normally use. No menu, no flag icon, no "press 2 for English".
• The bot answers in the same language, using your own content as the source of the answer.
• If the customer switches language mid-conversation — a common habit in mixed-language markets — the bot follows without losing the thread.
• The knowledge base stays single. You do not maintain three parallel copies of your catalogue.
• When a human operator takes over, the conversation history is already in front of them, and they can reply in the language they are comfortable with.

On the NERO platform this is the default behaviour: language detection is not a paid add-on and not a setting you have to remember to switch on.

Translation layer versus a genuinely multilingual answer

There are two engineering routes to a bot that speaks more than one language, and they produce different outcomes. Route one: the bot thinks in English, then a translation step converts the answer. Route two: the model generates the answer directly in the target language, from source content written in that language.

Aspect	Translation layer	Native multilingual answer
How the reply is produced	Written in one language, then converted	Generated directly in the customer's language
Product and brand names	Often translated by mistake	Kept exactly as written in your knowledge base
Tone of voice	Flattened — polite forms and formality levels get lost	Controlled by a written tone instruction per language
Local terminology	Dictionary word, not the word your customers use	Whatever term appears in your own documents
Mixed-language messages	Confuses the detector, answer language flips	Handled as one message, answered in the dominant language
Typical failure	Sentence is correct but sounds foreign	Missing content, which the failed-answer log exposes
Adding a new language	New translation pipeline and review cycle	Add source content in that language

The second failure mode is much easier to fix. A missing answer is visible and can be added to the knowledge base in minutes; a subtly foreign-sounding reply is invisible in reports and only shows up as customers who stop replying.

How language detection works in a live conversation

Detection happens per conversation, not per account. The bot reads the incoming message, identifies the language, and carries that choice forward until the customer changes it. Three practical details matter.

First, very short messages are ambiguous. A single word like "salam", "ok" or a phone number carries almost no signal. A well-built bot keeps the language of the previous turn instead of guessing again on every message.

Second, transliteration is common. Many customers write their own language using the Latin alphabet, or mix in English words for technical terms. The bot should treat this as the same language rather than switching to English because two English words appeared.

Third, the greeting matters. If your automatic first message is English-only, you have already told the customer which language to use, and you will never see the true language distribution of your audience. A neutral opening — short, in your primary market language — gives a cleaner signal.

Making a rarer language work: four things to prepare

Large models are strong in widely written languages and weaker in low-resource ones. You cannot change the model, but you can change what the model has to work with. For Azerbaijani, and for any language with a small share of public text, four preparations do most of the work.

1. Knowledge base written in that language

This is the single biggest factor. If your catalogue, delivery terms and service descriptions exist in Azerbaijani, the bot quotes real sentences instead of reconstructing them. Uploading an English document and hoping for a good Azerbaijani answer is the most common cause of stiff, unnatural replies. The knowledge base holds up to one million tokens, so there is room for the full source text in more than one language.

2. A written tone instruction

Tone is not automatic. Decide in advance whether the bot addresses customers formally or informally, how long answers should be, whether it uses emoji, and which words are never translated — brand names, model codes, service names. Write this down as an instruction, one per language if the norms differ. Formality rules are not the same across languages, and a single global instruction produces a bot that is too casual in one market and too stiff in another.

3. A test set of real questions

Before go-live, collect thirty to fifty questions your team actually receives, in the target language, including badly typed ones, questions with no diacritics, and voice-message transcriptions. Run them through the bot and read the answers. This takes an afternoon and finds more problems than a month of guessing.

4. A failed-answer log

A bot is never finished on day one. Every question the bot could not answer, or answered from the wrong section, should be recorded. The log becomes your content backlog: each entry is either a missing paragraph in the knowledge base or an unclear tone instruction. Teams that review this log weekly for the first month end up with a bot that stops surprising them.

Channel differences worth knowing

• WhatsApp — connects through the official Cloud API or by QR. Language handling is identical either way; the difference is in how the number is registered.
• Instagram DM — short messages and voice notes are frequent, so the "keep the previous language" rule matters more here than anywhere else.
• Facebook Messenger — profile language is not a reliable signal. Many people keep the interface in English and write in their own language.
• Website chat — the widget is generated inside the panel and added with one code snippet. If your site is multilingual, the page language is a useful hint, but the message itself should still decide.

All four channels land in one inbox, so your team does not need a language-specific operator per channel. Roles and permissions decide who sees what.

Common mistakes

• Building the knowledge base only in English and expecting equal quality everywhere.
• Asking the customer to select a language as the first step — it adds friction and most people abandon menus.
• Translating brand and product names. Leave them untouched and say so in the tone instruction.
• Skipping the test set because "the demo answered correctly".
• Never reading the failed-answer log, then concluding that the bot does not work.
• Copying an English tone into a market where a more formal register is expected.

When you do NOT need a multilingual chatbot

If effectively all of your enquiries arrive in one language and you have no plan to sell abroad, multilingual capability is not the feature to evaluate on. Look at response speed, catalogue handling and handover to a human instead. Two more honest cases: if your answers depend on live stock and order status, the integration with your database matters far more than language coverage; and if your problem is that nobody answers the phone, an AI voice agent is closer to the real issue. It is also fair to say that a language you receive one message a month in does not justify preparing a full content set — let the bot answer from the general knowledge base and route those conversations to a person.

How this is set up in practice

Bots are configured inside the panel itself — no external automation tool, no separate server and no additional workflow subscription for a standard sales or support bot. In practice the sequence is: connect the channel, upload the knowledge base in each language you serve, write the tone instruction, run the test set, publish, then review the failed-answer log. Once your content is ready, a standard chatbot is built and handed over in about an hour.

You can see the full product list on Products, the service scope on Services, and package details on Pricing. Background on the company, including verified figures, is in the English company profile.

Next step

Tell us which languages your customers actually write in and which questions repeat most often, and we will tell you what content you need to prepare first. The initial conversation is free and there is no obligation.

Contact page · Message us on WhatsApp · Platform: app.aimedia.az · Phone: +994 50 250 00 74