Multilingual AI support: which language is your index in?

multilingual, knowledge-base, ai-support, search

Every vendor in this category says it supports 40-odd languages, and most of them are telling the truth. The sentence just hides the question that decides whether it is safe: when a customer writes in Portuguese and you have no Portuguese article, what exactly answers them? The honest answer, at every vendor we could check, is "an article in another language, translated on the way out". That path works most of the time and fails on precisely the content where failure costs money — prices, refund windows, delivery terms.

This is a breakdown of where the line runs between "handles languages" and "handles languages safely", and six questions that locate it in any vendor's documentation in about ten minutes.

The demo that always works

Ask any AI support agent a question in Spanish. It will answer in Spanish, fluently. Everyone in the room nods, and the language box gets ticked.

The demo proves the one part that was never in doubt. A modern model writes fluent Spanish; it has done since before you started evaluating. What the demo does not show is where the answer came from — and that is the entire risk. A fluent Spanish sentence built from a mistranslated English refund policy looks exactly like a fluent Spanish sentence built from your Spanish refund policy. Fluency is not evidence, and it is the only thing a demo tests.

"45 languages" is three separate features in one bullet

Vendors compress three independent capabilities into a single line. They fail differently, and they are usually built by different parts of the system.

The language of the interface. Buttons, the widget, notification emails. Static text, translated once. Nobody gets this wrong, and nobody should get credit for it.

The language of the reply. The model detects the customer's language and generates in it. This is what the demo shows, and it is essentially free — it comes with the model.

The language of the knowledge. Which articles exist, in which languages, and which of them the retrieval step is allowed to consider. This one is not free, it is not the model's doing, and it is the only one of the three that determines whether the answer is correct.

Read any vendor's multilingual page against those three and you will usually find the first two described in detail and the third mentioned in a subordinate clause.

Language-filtered retrieval, and the fallback nobody demos

Credit where due: the serious vendors do filter retrieval by language. Fin's documentation is explicit that it searches content available in the language the question was written in — French question, French articles (Fin's multilingual setup). That is the right design, and it is worth checking that your candidate does the same rather than assuming it.

The interesting part is the next sentence in that same documentation: when no relevant content exists in the customer's language, it falls back to content in your chosen fallback language and translates it. Every vendor has some version of this, because the alternative — answering "I don't have that in your language" — is worse for the metric everyone reports.

So the fallback path is not an edge case. It is the normal path for every language where your knowledge base is thinner than your customer base — which, for most teams, is every language except the one they write in.

Three things make that path worth measuring rather than trusting:

• It is invisible. The reply arrives in the customer's language either way. Nothing in the transcript says "this came from an English article I translated".
• It degrades where you are least able to notice. You spot-check the languages you read. The translation you should worry about is the one nobody on the team speaks.
• It is your liability, not the vendor's. When Air Canada's chatbot described a bereavement-fare policy the airline did not actually offer, the British Columbia Civil Resolution Tribunal held the airline responsible for everything on its website, chatbot answers included, and awarded damages (Moffatt v. Air Canada). Nothing in that reasoning depends on the answer having been in English.

None of this argues against machine translation. It argues that "we support 45 languages" and "our answers in those 45 languages are grounded in content you approved" are different claims, and only one of them is on the landing page.

What a search index actually knows about a language

Here is the part that is usually missing from the conversation, and it is worth understanding because it explains why per-language retrieval is real engineering rather than a config flag.

Full-text search does not match words. It matches stems — and stemming is language-specific. Postgres ships a separate text-search configuration per language, and running the wrong one is not a subtle degradation: the Russian word for "returns" stems to nothing useful under an English configuration, so the article you have does not come back for the question you asked. The index has to know its language at the moment a row is written.

Which forces a design decision most people never see. In our own implementation, the language lives as a regconfig column on each searchable row, and the search vector is a generated column over it:

CASE locale
  WHEN 'ru' THEN 'russian'
  ELSE 'english'
END::regconfig

That is the whole mapping, wrapped in a STABLE STRICT SQL function that the insert triggers and the search queries both call, so the two cannot drift apart. The column exists because Postgres will only accept an IMMUTABLE expression in GENERATED ALWAYS AS, and resolving a config name to its OID is a catalog lookup, which is merely STABLE. You cannot look the language up from the workspace row inside the generated expression. A column that already is a regconfig works, and it buys something useful: re-indexing a workspace that switched language costs one UPDATE of that column, because Postgres recomputes the vector and its index entry itself.

That is the whole mechanism, and it has an honest edge. A row written while the re-index is running keeps the old language, because the insert trigger reads the workspace's locale as of its own transaction. Closing that window means serialising writes against the re-index, which would block every visitor message for the length of it. We took the rare mis-stamped row over the predictable stall, and re-saving the language sweeps whatever fell in.

We are describing our own code because it is the part we can show you rather than assert. The point is general: ask your vendor what happens to the index when a workspace changes language, and whether content written before the switch is searchable after it. The answer tells you whether language is a property of their data or a filter bolted on afterwards.

Six questions that settle it

Put these to the documentation rather than to a salesperson — the same method as evaluating a vendor after an acquisition.

1. Is retrieval filtered by language, or is the index one language with translation on top? A vendor doing it properly will say so on a page, because it took work.
2. What happens when there is no article in the customer's language? You want the fallback named explicitly: which language it falls back to, and whether the answer is translated.
3. Can you see which answers came from the fallback path? A per-conversation flag, or a share in a report. If it cannot be counted, it cannot be managed.
4. Can you turn the fallback off for some content? Prices and refund terms are where you may prefer "I'll get a human" over a confident translation.
5. What happens to search when a workspace changes language? Re-indexed, or silently searching old content with the wrong stemmer.
6. Is language detected once per conversation, or per message? A customer who opens in English and switches to their own language mid-thread is common, and a per-conversation detection locks them into the first guess.

Question 3 is the one that separates vendors fastest, and it is the one you are least likely to think of during a demo.

Now ask us the same questions

We build Replium, so the same six questions apply to us, and answering them first is the only version of this that is worth reading.

Retrieval filtered by language — yes, at the index. Each searchable row carries its own text-search configuration, so a workspace's articles and conversations are stemmed and queried in that workspace's language.

How many languages — two. English and Russian. Not forty-five, and we are not going to print the bigger number and call it a roadmap: a language joins the product in the change that brings its translation.

Fallback to another language — absent, by construction. There is nothing to translate on the way out, because there is no AI agent generating replies and no model provider connected. What you get is search and a human.

Re-index on language change — yes, with the write-window caveat described above, documented in the code rather than in a brochure.

Per-message language detection — absent. The axis is the workspace's language, not the visitor's.

Interface, articles and inbox in the workspace language — shipped, in both languages.

Two of those are "absent" and one is "two, not forty-five". That is the honest shape of a product this young, and it is the reason the fallback problem does not exist for us yet rather than a claim that we solved it.

What a small vendor is worth is the other side of that table: a request reaches the people who write the code instead of a queue, and a language or a missing behaviour that matters to you is a conversation, not a roadmap item you wait a year for. If that trade fits — you need chat, an inbox and a knowledge base that searches properly in your language, and you would rather have a vendor who answers — start a workspace. It takes an email, and with no billing in the product there is nothing to cancel.

If you need an agent answering in forty-five languages this quarter, use the six questions on somebody else. That is what they are for.