A multilingual chatbot does not need a separate bot for each language. A grounded assistant searches one knowledge base and replies in whatever language the shopper wrote in, which turns a translation project into a much smaller decision: what genuinely needs a local version, and what can stay in one language. For most small stores selling across borders, that is the difference between weeks of work and an afternoon.
How one knowledge base serves many languages
The assistant searches your pages, products and policies for every question, then writes an answer from what it finds, the method described in Lewis et al., 2020. Because the answer is composed rather than looked up as a fixed string, the language of the reply can differ from the language of the source. A shopper writing in Spanish gets a Spanish answer built from your English returns page. That works well for facts, which is most of what stores are asked, and less well for tone, which is where the remaining work sits.
What to translate and what to leave
| Content | Translate? | Why |
|---|---|---|
| Product names and specifications | Leave | Model numbers and measurements travel; a translated model name breaks search |
| Shipping costs and times per country | Leave, but split by destination | The facts differ by country, not by language |
| Returns policy | Translate if the terms differ by market | Consumer rights vary; one policy cannot cover several legal regimes |
| Widget interface labels | Translate | The greeting and buttons set the first impression |
| Legal pages and consent wording | Translate | Comprehension matters legally, not just commercially |
| Marketing copy and brand voice | Translate if the market matters | Machine tone is acceptable for facts, weaker for persuasion |
The pattern: translate what is legally or emotionally load-bearing, leave what is factual. A shipping table in English still produces a correct Italian answer about the cost to Milan.
Where machine answers need care
- Formality. Several languages distinguish formal and informal address, and the wrong choice reads as rude or oddly familiar. Set the tone you want in the assistant's instructions and have a native speaker check a sample.
- Units and formats. Sizes, dates and currencies vary by market. Put the numbers in your content in a form that travels, and state the unit explicitly.
- Legal phrasing. A translated summary of a right is not the right. Link the local policy page rather than paraphrasing law.
- Product terms of art. Materials and technical words sometimes have a settled local term that a general translation misses.
- Right-to-left layouts. Check the widget renders correctly, not just that the words are right.
Testing a language you do not speak
- Ask your five most common questions in the language, using wording a customer would use rather than a textbook sentence.
- Check the facts against your policy. Numbers, days and currencies are verifiable without speaking the language.
- Have one native speaker read five replies for tone and formality. This is a one-off, not an ongoing cost.
- Test a handover and confirm the agent can see which language the conversation was in, so the reply matches.
- Test a decline, so you know the assistant says "I don't have that" clearly in that language too.
The scoring approach is the same as the monolingual one in how to test AI chatbot accuracy.
The mistake that costs the most
The expensive error is maintaining parallel content per language and letting the copies drift. A store translates its returns page into four languages, changes the window from fourteen days to thirty, updates the English page, and forgets the rest. Now the assistant answers thirty days in English and fourteen in German, both confidently, because both are in its knowledge base. Duplicated facts are worse than untranslated ones: an untranslated fact still produces a correct answer in any language, while a stale translation produces a wrong one. Where a page genuinely must exist per market because the terms differ, keep the differing numbers in exactly one place per market and review them together whenever anything changes.
Agents who do not speak the language
Handover is where multilingual support usually breaks. The assistant answers in Portuguese, the conversation escalates, and an English-speaking agent replies in English to someone who may not read it. Two practical arrangements work: reply in your language with a short apology and let the customer use their own translation, or keep escalations in that language to specific hours when someone can handle them. Either is better than pretending. The handover should carry the conversation language along with the transcript and order reference, as covered in chatbot human handover.
What this does for search and for trust
Multilingual chat and multilingual pages are different projects. Chat serves the customer who already found you; localised pages are how more of them arrive. If a market matters commercially, translate the pages for it properly, and let chat cover the long tail of languages where a full localisation is not worth it. Google's guidance on localized versions of pages covers the site side; the chat side needs no equivalent setup. In our own conversation data across real stores, conversations arrive from dozens of countries, which is the practical argument for letting the assistant handle languages you have not localised for; the figures and method are in our ecommerce chatbot statistics.
Which languages will actually arrive
Stores are often surprised by the list. Visitors write in the language they think in, not the language of the site, so an English-language store shipping to Europe sees questions in German, Dutch, Spanish and Polish long before it localises for any of them. The practical move is to look at your analytics for visitor countries, pick the three that generate the most sessions, and run the five-question test in those. The rest of the long tail takes care of itself, and the assistant answering a Finnish question correctly costs nothing extra on a flat plan. If one of those three turns into a serious market, that is the moment to localise the pages properly rather than leaning on chat alone.
Setting it up
Write the content well in your main language first, using a heading per question, as described in how to write a chatbot knowledge base. Translate the widget labels and the legally load-bearing pages. Set the tone you want in the assistant's instructions. Then run the five-question test per language. Vatdi replies in the customer's language on every plan, with the widget labels editable per store, and the allowances are on the pricing page; the wider sequence is in the AI chatbot implementation guide.
Frequently asked questions
Do I need a separate chatbot for each language?
No. A grounded assistant answers in the language of the question using the same knowledge base, so one setup serves many languages. Separate bots per language belong to the flow-builder era, where every path had to be drawn and therefore redrawn for each market.
Does my knowledge base have to be translated?
Not for factual content. A shipping table or returns page in one language still produces correct answers in others. Translate what is legally load-bearing, such as policies that differ by market and consent wording, plus the widget labels that set the first impression.
How good are the translations?
Good enough for facts, which is most store questions, and weaker for tone and persuasion. The reliable check is to verify the numbers yourself and have a native speaker read a handful of replies once per language. That one review catches formality problems that no amount of testing in your own language will.
What happens when the conversation reaches a human?
The handover should carry the conversation language so the agent knows what they are looking at. If nobody on the team speaks it, say so plainly and reply in your language, or restrict escalations in that language to hours when someone can help. Silence is the outcome customers remember.
Can it handle languages I do not sell in?
It will answer whatever language a visitor writes in, which is usually an advantage: a shopper from a market you have not localised for still gets their delivery question answered. If you would rather not serve a market at all, say so in the content, and the assistant will say so too.
Does multilingual chat help my search rankings?
Not directly, because chat is not indexed. Localised pages are what bring international visitors in; chat is what keeps them from leaving once they arrive. Treat them as two projects, and use chat to cover the languages where full localisation is not yet worth the cost.
