One source, six languages: building a multilingual AI assistant without chaos

A customer begins in Slovak, a colleague continues in Czech and an international visitor asks in German. They are asking about the same product, date or policy. They expect the same fact, expressed naturally in their own language.

This is where many multilingual AI projects fail: a company builds one knowledge base, adds automatic translation and assumes the job is done. The result can be correct German with a price from the wrong market, a Polish answer linking to an English policy, or six copies of a document with only one kept current.

Multilingual does not mean six chatbots. It means one system of facts with six high-quality ways to explain them.

Separate facts from language first

A maintainable system has three layers:

1. Shared facts: product ID, stock status, order number, technical parameter or internal location ID.
2. Localized values: name, description, instructions, terms, service explanation and link label.
3. Regional rules: currency, tax, price, availability, delivery method, legal notice and date format.

A laptop model number can be identical in every language. A warranty explanation needs localization, while its price may vary by market. Mixing these layers into one text field turns every update into a manual review of every translation.

Seven decisions that keep answers consistent

1. Name supported languages explicitly

Web standards use BCP 47 language tags such as sk, cs, en, de, hu and pl, with regional variants such as de-AT where justified. RFC 5646 recommends adding specificity only when it conveys a useful distinction.

2. Distinguish interface, question and source language

An English browser setting does not mean the customer will write in English. The language of the buttons, the current message and the retrieved document are three separate signals. Reply in the question’s language when supported; otherwise use a transparent fallback and offer a switch. Do not silently invent a translation of an unapproved legal or price statement.

3. Retrieve in the same language first

A Hungarian question should search Hungarian sources or language-neutral data first. Only a defined fallback should reach another language. Language filtering belongs in retrieval, not merely in the model’s final instruction. Translating the wrong source still produces the wrong answer.

4. Maintain one brand and terminology glossary

Decide what remains untranslated, what has an approved equivalent and what needs explanation. A short glossary mapping “source term → approved term per language → forbidden variants” is more useful than a long generic prompt. It can cover municipal department names and forms, or e-commerce categories, materials and product names.

5. Localize numbers, dates and plurals

Word translation is not enough. Amounts, dates and a phrase such as “2 business days” differ in notation and grammar. Unicode CLDR defines plural categories because rules vary substantially between English, Czech, Polish and Hungarian. Let the application’s localization layer guarantee currency, units and formatting; the model should explain meaning.

6. Give each web language its own URL

Google recommends separate URLs for language versions, hreflang links and a visible language switcher. Automatic redirects based on an assumed language can prevent users and crawlers from reaching alternatives. A stable language URL also gives a knowledge source an identity and lets citations lead to content the visitor understands.

7. Test meaning, not just grammar

Create a small regression set of real questions for each supported language. Verify price, currency, tax, opening hours, time zone, delivery, availability, exact document names, the language of links, missing-translation behavior and handoff to a human operator. Do not only translate one test question: different markets describe the same need differently.

A safe fallback when translation is missing

The worst fallback is invisible. A visitor receives fluent Polish freely translated from an outdated English document and has no way to know that an approved Polish version does not exist.

1. Find an approved source in the question’s language.
2. If it is missing, use only an allowed shared fact or a clearly identified fallback.
3. For sensitive information, disclose the missing localization and offer the original or a human operator.

An automatically translated general description may be acceptable. Contract terms, health information, an official procedure or a final price require an approved language version.

Updating six languages without six incidents

A source change must expose which translations are current, waiting for review or temporarily unavailable. Do not publish a new price in one language while leaving the old price active in the other five.

1. Change the shared fact or primary source.
2. Mark affected translations as outdated.
3. Update and review localized versions.
4. Publish related changes together.
5. Run regression questions in every language.

For products, price and stock should come from live structured data while descriptions can move at a slower pace. That reduces translation volume and the risk of stale commercial answers.

Where Informio fits

Informio supports Slovak, Czech, English, German, Hungarian and Polish interfaces. An assistant can use a fixed language or automatic mode. Website and XML sources can carry language information so retrieval prefers content matching the current locale while preserving tenant and source restrictions.

The main value is not automatic translation. It is controlled sources, visibility into unanswered questions and the ability to test whether the assistant communicates the same facts in every language. Start with your two most important languages and ten real questions. Add another language only after facts, links and fallback behavior are consistent.

Sources and further reading

• IETF RFC 5646: language tags
• W3C: language tags in HTML and XML
• Google Search Central: managing multilingual and multi-regional sites
• Unicode CLDR: plural rules