The problem is the second year
A multilingual programme almost always starts well. There is budget, there is attention, and the five versions get delivered together. Everybody is satisfied.
The problem arises at the first change. A procedure changes, and the Dutch version gets updated because it sits closest to home. The Polish version follows a month later, the Romanian does not, and the Turkish turns out on enquiry to have been translated by an agency worker who no longer works there.
From that moment you no longer have five languages but five different trainings. And the people who get the divergent version are precisely the ones least able to check whether what they are learning still holds.
Where it drifts apart
Three things cause practically all the drift.
Text in the imagery. When on-screen text is burned into an image or a video, changing it means producing it again. At five languages that is five times, and so it does not happen.
Separate files per language. When each language is its own source file, there is no single place where the divergence is visible. Somebody has to track it by hand, and that is exactly the task that disappears first when things get busy.
No owner per language. The Dutch version always has an owner. The other four often do not. There is somebody who translated it once, and that is a different thing from somebody who is responsible.
Designing for maintenance
The choices that prevent this are made at the start. Repairing it afterwards means, in practice, building it again.
Separate text from imagery. Imagery without burned-in text, with a separate text layer. Adding or changing a language is then a text job, not a production.
Work with one source and language variants. One structure in which the language versions hang off each element, so a change at the source makes visible which languages are behind. This is the most important of the five choices.
Use visual instruction where you can. Whatever you can say in an image does not need translating. That lowers the maintenance load structurally and raises comprehensibility as well.
Fix the terminology. A glossary per language holding the technical terms and the brand-specific words. Without that list, every translator picks their own word for the same component.
Appoint somebody per language to check. Not to translate, to check. Somebody from your own organisation who knows the installation and speaks the language. One round of half an hour per change is enough, and the difference in quality is considerable.
What AI does and does not solve here
Machine translation has become considerably better in recent years, and for this kind of material that is noticeable. But it moves the problem more than it solves it.
What it does do: make language six cost practically the same as language two and, more importantly, keep terminology consistent across a whole set. That last part used to be the real bottleneck, not the translating itself.
What it does not do: judge whether the translated instruction matches the installation. A model translates “valve” correctly and does not know that you call that component something else on site, or that the target language has a term that gets confused with another system. That is what the human review round is for, and it stays necessary.
The practical conclusion: stop letting translation costs decide how many languages you train in. Let the availability of reviewers decide it. That is the scarce factor now, and it is a factor you can organise.
Multilingual delivery is a design choice you make early, alongside a few others. Which ones those are is in the guide on setting up or renewing a corporate academy. The application is under multilingual onboarding, the production side under AI-assisted development.