One knowledge base, seven languages: what breaks in upkeep
Keeping review cycles in sync across languages, separating binding answers from market-specific ones, and deciding what applies when the source and the question are in different languages.
Martin Semmele
Key takeaways
- The expensive part is not the translation but the window between the change in the original and the last language brought up to date.
- Answers fall into three classes: word-for-word identical, equivalent in substance with local evidence, and deliberately market-specific. Without classification everything gets treated alike, and therefore wrongly.
- One review cycle per language does not hold the languages together. The cycle has to hang off the original and raise an obligation in every language.
- If the source exists only in German and someone asks in Polish, the honest answer points at the German version rather than making a quietly translated claim.
The gap nobody records
The mistake does not happen while translating. It happens on the Tuesday when somebody changes the German version of an article, and on the Wednesday, the Thursday and through the three weeks afterwards, during which six other languages still carry the old statement. In that window the knowledge base is not incomplete but contradictory: it holds two different answers to the same question, and which one a customer gets is decided by their language.
As long as people read the articles, this barely shows. The moment an agent answers out of the same base, it becomes an operational problem. The agent does not know the difference between a current and an outdated version; both are sourced material to it. It cites the Polish version with the same confidence it cites the German one.
Most teams record this gap nowhere. There is a list of open translations, but no list of statements that currently differ between languages. The first step is therefore unspectacular: every change to the original opens a visible item per language that stays open until it has been brought up to date. Not as a ticket in the translation tool, but as a state on the article itself.
How a knowledge base has to be cut in the first place so an agent can work with it is covered in building a knowledge base for AI support. This article takes that as given and asks only what happens when the same base exists in seven languages.
Three classes of answer
The most common wrong decision is to treat all content alike. But a price and a worked example have nothing in common: with one, every deviation is a defect; with the other, deviation is the point. Put both through the same translation process and you get either rigid examples or drifting prices.
It helps to break the stock into three classes once and record the class on the article.
| Class | What belongs in it | Rule on change |
|---|---|---|
| Word-for-word | Prices, deadlines, cancellation terms, security and availability commitments, legal texts | No language goes live before all of them do. A change locks the article in every language. |
| Equivalent in substance | Procedures, definitions, troubleshooting, response times | Change the original, bring the languages up to date. Evidence and examples may be local. |
| Market-specific | Payment methods, support hours, contact routes, regulatory notices | Deliberately different. The reconciliation checks presence, not sameness. |
The first class is the smallest and the only one where a release freeze is justified. It is also the one where precision is not negotiable: under the European directive on unfair terms, standard contract terms have to be drafted in plain, intelligible language, and ambiguities are interpreted in favour of the consumer1. A version that promises something different in one language than in another is therefore not merely untidily maintained.
The third class is regularly overlooked, because it looks like a translation error. When the Italian version names different payment methods than the German one, that is not a defect but correct. A reconciliation that enforces sameness breaks these articles.
Review cycles that hold the languages together
The usual setup gives every language its own rhythm: German is reviewed quarterly, the other languages whenever somebody has time. The result is predictable. After two quarters each language describes a different state of the product, and nobody can say which of them is the valid one.
A cycle that carries hangs off the original, not off the language. It has three properties:
- 01The review of the original is the trigger. If nothing changes during the pass, that confirms every language along with it; if something changes, it opens an item in every language.
- 02The review of the translation is a separate step with a separate person. ISO 17100 requires exactly that: revision by a second person who checks the translation against the original, as an obligatory part of the standard rather than an add-on service2.
- 03The state is visible on the article, not in a table beside it. Whoever opens the Polish version sees which version of the original it was last checked against.
The third point decides whether the first two are worth anything. A review date with no reference to a version of the original says only when somebody looked, not whether they saw the current state. As long as that reference is missing, every statement about how current a language is remains a guess.
For small stocks a single column is enough for this. The effort does not arise from keeping the list anyway, but from working it off.
When the source and the question are in different languages
The case is more common than expected: a customer writes in Portuguese, but the dependable answer exists only in the German version, because the Portuguese one has not been brought up to date yet. How this gets solved technically is covered in multilingual AI support. What matters here is the decision that comes before it, and that one is not technical: what is the agent allowed to do in this situation?
That the question is hard at all shows in the effort that goes into measuring it. The MIRACL dataset tests retrieval across 18 languages with 77,000 queries and relevance judgments made by native speakers — an order of magnitude nobody spends on a solved problem3.
In practice three answers are possible, and only one of them holds up against the house rule that there is an answer with a source, or none at all:
- Translate quietly. The agent finds the German source, translates it while answering and names it as the reference. The customer gets a pointer to a text they cannot read, and a wording nobody has checked. For class one this is not defensible.
- Find nothing. The agent searches only the Portuguese stock, finds nothing and hands over to a human. Honest, but expensive, and unnecessary when a maintained German answer exists.
- Search across languages and name the origin. The agent answers in Portuguese, points at the German version and says that the source is in German.
The third answer is the only one that answers the question without blurring the origin. It does require the agent to know the language of its source and be able to name it — a field on the document, not an inference from the text.
For class one there is an exception: where a binding statement does not exist in a checked form in the customer's language, no answer is given and the case is handed over. A translated deadline is a new deadline.
What this costs in operation
The honest part at the end: this governance makes the knowledge base slower. Changing an article in the first class means collecting seven approvals before anything goes live. That is the price of a price being the same in seven languages.
The counter-calculation is manageable. The number of articles that genuinely belong in the first class sits in the low tens in most stocks. Everything else may lag, as long as the backlog is visible. Whoever does not separate the classes pays the price of the first class for the entire stock — and therefore does not keep it up.
Two things pay off regardless of size. First, a named responsible person per language; without one the backlog decays into a shared task and therefore nobody's task. Second, the rule that an article's class is decided when it is created and not at the first conflict. What the public structure for this looks like is covered in building a Help Centre.
At ComLayer the Help Centre, the inbox and the agent sit on the same knowledge layer, so the language of a source and its review state are maintained in one place instead of drifting apart across three tools.
Frequently asked questions
Which content has to be word-for-word identical in every language?
Everything a customer can hold you to: prices, deadlines, cancellation and contract terms, and commitments on security and availability. For this class, no language goes live before all of them have been checked.
What may differ between the languages?
Payment methods, support hours, contact routes and examples. These differences are intended and are not translation errors. A reconciliation should check here whether a statement is present, not whether it is identical.
How often should a multilingual knowledge base be reviewed?
What matters is not the interval but the trigger: the review hangs off the original, and every change there opens an item in every language. A fixed rhythm per language lets the versions drift apart.
What does the agent do when the source exists only in another language?
It answers in the language of the question, points at the version that exists and says which language it is in. For binding statements the case is handed to a human instead, because a translated deadline would be a new deadline.
Is machine translation enough for the knowledge base?
For content that only has to be equivalent in substance it is a usable first draft that then gets checked. For word-for-word content it is not enough: ISO 17100 treats revision by a second person as an obligatory step, and that is exactly the step an unchecked machine output is missing.