A Knowledge Base in Six Languages at Once - What Drifts and How to Keep It Under Control

Whole articles do not age all at once - the details break first. A button label changes in the product, and four out of five language versions still show the old one. A screenshot shows the interface before a redesign, because it was taken once, during the first translation, and nobody went back to refresh it in every version separately. A step that disappeared from the product is still described in whatever language nobody happened to review at the last update. None of this looks serious on its own. Together it means the language version your support team reads least often quietly drifts away from what the product actually does today.

Most damage comes not from bad translations, but from nobody knowing that this particular one needs fixing. One rule helps: a change to the source version never ends with the source version - it ends with marking the linked translations as "needs review", even if the fix itself waits a week. Keeping language pairs linked (the same entry across versions tied together by one identifier) does more than tidy up the admin panel - it lets you ask directly which versions of an entry have not been updated since the source changed. Without that link, answering that question means checking every version by hand, which in practice never happens. A cosmetic change (a typo, one sentence) and a substantive one (a different step in a procedure, a different price, a renamed feature) are not the same operation - only the second one truly needs a speaker of that language to read the entry again, not just swap one word.

A few signals show up before anyone reads an entry line by line and spots the difference: The last-updated date for one language version is noticeably older than the others, even though the topic has changed since then - a sign that version fell out of the review cycle. Support tickets in one language keep coming back to the same topic more often than in others, even though the knowledge base entry formally covers it - this usually means the answer in that language no longer matches the current product, so customers write to a human anyway. Terminology drifts within a single language between entries - the same feature is called something different in an older article than in a newer one, because different people translated them at different times without a shared glossary.

One source language that the others are translated from - without a clearly marked original, every version eventually starts living its own life, because there is nothing to compare it against. A shared identifier linking versions of the same entry, so you can query the pair instead of checking each language separately. A short, living glossary of the product's key terms per language - not so everyone translates identically, but so nobody has to guess whether "ticket" means the same thing in every article in that language. Reviewing not the whole knowledge base at once, but only the entries tied to whatever just changed in the product - that is the only review that actually happens, because it stays small and specific.

Having an entry in six languages does not mean a customer gets the same quality of answer in each of them - if one version is updated weekly and the rest once a quarter, the gap in customer experience is real, even if the admin panel shows a complete set. It is also not something machine translation without review will solve - it speeds up the first version, it does not check whether that version still describes the real product six months later.

A multilingual knowledge base does not drift because someone translated it badly - it drifts because a change in one place has no way to reach the other five. Linking versions, keeping one clear source language, and reviewing only what actually changed costs less than a single support conversation with a customer who landed on an outdated answer.