There are two ways to serve IT support in another language: translate the knowledge base, or translate the reply. They cost different amounts, fail in different places, and most teams pick one by accident rather than deciding.
TL;DR
- Translating the reply is cheap, instant and unauditable. Translating the base is slower, costlier and reviewable.
- You do not have to choose globally. Decide per content type, because most IT content is safe either way.
- Translate the base for the twelve articles that cover most of your volume. Translate replies for everything else.
- A translated base goes stale. The second-language version is always the one nobody updates after a change.
- Internal system and tool names should not be translated at all, and a glossary fixes this in an afternoon.
- Never translate 400 articles to find out whether it works. Translate twelve and measure.
The two strategies, plainly
Translating the reply means keeping one set of documentation, usually in English, and having the tool or the agent render the answer into the requester’s language at the moment of response. Nothing is pre-translated. Setup is near zero.
Translating the base means maintaining your articles in each supported language, so the answer is retrieved from material written for that population rather than converted on the fly. Setup is real work and so is the upkeep.
The difference that matters is not quality of language. Both produce fluent output. The difference is whether anybody can later check what somebody was told and trace it to a source.
Where translating the reply fails
Three specific places, and none of them is grammar.
Internal names. Your VPN client, your asset tool, your ticketing system and your device naming convention will be cheerfully rendered into descriptive phrases that match nothing the user can search for. This is harmless once and corrosive across a hundred tickets, because it teaches people the translated answer is an approximation.
Steps with exact strings. IT instructions are full of literal values: menu labels, settings names, error text. A translation layer with no instruction to leave those alone will translate the thing the user is supposed to click, which makes the instruction impossible to follow.
No audit trail. When the answer is generated per conversation, there is no reviewable artefact. You cannot sample the translated content for accuracy because it does not exist until somebody asks.
Where translating the base fails
Almost entirely on staleness, and it is predictable. The first translation happens during a project when everybody is paying attention. The fourth happens eighteen months later during a software migration when nobody is.
A translated article that is wrong is worse than no article, because it is specific, confident and findable. A user following translated instructions for a tool you replaced last quarter will file a ticket, and the ticket will be harder to resolve than the original question.
The second failure is scope creep. Teams start by translating twelve articles and end up with a commitment to 300, because nobody drew a line and every request to add one more sounds reasonable.
A worked example
A company with 210 staff across four countries decided to translate its IT knowledge base. The base had 340 articles. Somebody sensibly asked which ones were actually used, and the answer was that 18 articles accounted for roughly three quarters of all views.
They translated those 18 into two languages, left the rest in English, and put a document-trained assistant in front of the whole base so that anything outside the 18 got a translated reply from the English source. Total content work was under three days.
Then they did the step that made it last: a review date on each of the 18, owned by one named person, checked when any tool in the stack changed. Two years on, 16 of the 18 are still current, which is a considerably better outcome than a fully translated base would have achieved.
How to decide, cheaply
What to do:
- Pull article view counts and find the set that covers roughly three quarters of traffic. It is usually between twelve and twenty.
- Translate only that set, into only the languages your headcount actually justifies.
- Build a glossary of internal system and tool names, and mark them as never translated.
- Mark literal UI strings and error text so the translation layer leaves them alone.
- Put a named owner and a review date on each translated article.
- Leave everything else in one language and let the tool translate replies from it.
The glossary is the highest-return item on that list and takes about an afternoon. Twenty to forty entries covering every system name, tool name and internal convention, with the instruction to leave them in their original form.
What the tools do with each strategy
The capability that matters is whether the tool answers from your own documents, because only then can a wrong answer be traced to an article and corrected. Figures below were read from each vendor’s own pricing page on 5 and 7 October 2026.
| Matram | Document-trained | $29, $69, $199 per month flat | 95+ languages |
| SiteGPT | Document-trained | $468 and $948 billed yearly | 95+ languages |
| Chatling | Document-trained, free tier | Free plan available | 80+ in one place, over 85 in another |
| Crisp | Broader support platform | Free, $45, $95, $295 per month | No count published |
| Zendesk | Broader support platform | $55 plus $50 per agent per month | No count published |
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It has no free tier, answers rather than actioning tickets, and is not an ITSM platform. Chatling’s free tier is the cheapest way to test whether reply translation is good enough on your content before committing to anything. All eight are in our multilingual IT support comparison.
Final thoughts
This is not a choice between two strategies. It is a split, and the split follows your view counts. A small set of articles carries most of your traffic and deserves proper translation with an owner and a review date. Everything else is better served by reply translation from a single maintained source, because a stale translated article is worse than an English one.
Do the glossary first regardless of which way you lean. Internal names and literal UI strings are the failures users notice immediately, they are the cheapest to fix, and fixing them improves both strategies at once.
Frequently asked questions
Should we translate our IT knowledge base or let the tool translate answers?
Both, split by usage rather than choosing globally. Pull your article view counts and you will usually find that twelve to twenty articles account for around three quarters of all traffic, and those are worth translating properly with a named owner and a review date. Leave the long tail in one language and let the tool translate replies from it, because a stale translated article is worse than an English one that is current.
What should never be translated in IT support content?
Internal system and tool names, your device naming conventions, literal menu labels, settings names and error message text. These are the failures users notice immediately, because an instruction telling somebody to click a button whose label has been translated is impossible to follow, and a system name rendered descriptively matches nothing in your search. A glossary of twenty to forty entries marked as never translated fixes all of it in about an afternoon.
How do translated knowledge base articles go stale?
Predictably, and always in the same direction. The first translation happens during a project with attention and budget, and then a tool gets replaced or a process changes and the English article is updated while the other language versions are not, because nothing breaks when they fall behind. The remedy is a named owner and a visible review date on each translated article, plus a trigger rule that any change to a tool in your stack prompts a check.
Is reply translation accurate enough for technical instructions?
For prose it generally is, and for step-by-step instructions containing exact strings it frequently is not, which is the specific weakness to plan around. The engine has no way of knowing that a quoted menu label is something the user must match character for character rather than a phrase to render naturally. Mark those strings explicitly so the translation layer leaves them intact, and test a handful of your most procedural articles before relying on it.
How many articles should we actually translate?
Start from view counts rather than from the structure of your base, and translate the set that covers roughly three quarters of traffic, which is typically between twelve and twenty articles. Translating more sounds thorough and creates a maintenance commitment that quietly becomes unsustainable, and the long tail of rarely-read articles is exactly where staleness goes unnoticed. Draw the line explicitly and write it down, or scope creep will take you from twelve to three hundred one reasonable request at a time.
Why does it matter whether the tool answers from our own documents?
Because it determines whether a wrong answer is fixable. A tool that retrieves from your documentation and can show which article it used turns any problem into a content edit you can make and verify, while a tool generating from general knowledge will keep producing its own phrasing regardless of what you change. It also makes sampling possible, since you can check whether the answer follows from the source rather than only whether the language reads well.
