I've managed translation into roughly 28 languages across very different products: surveying and GNSS machine-control systems at Leica Geosystems, and manufacturing execution software since. The products, audiences, and review processes couldn't be more different. What carries over between them is almost never about the languages themselves — it's about everything upstream of translation.
Source content is the real bottleneck
The most expensive translation mistakes I've seen were never translation mistakes. They were ambiguities in the source English that got faithfully translated into 28 different ambiguities. A sentence with an unclear antecedent doesn't get clarified by translation — it gets multiplied. Tightening the source content before it goes out is the single highest-leverage thing a documentation team can do for a multilingual program, and it's also the easiest step to skip when deadlines are tight.
Terminology before translation
Locking down terminology in the source language, before sending anything to translators, prevents the most common and most visible inconsistency: the same product feature described with three different terms across three different manuals, then translated into three different terms in every target language. A shared, maintained glossary sounds like overhead until you've had to explain to a customer why their manual uses a different name for a button than the UI does.
Picking the right process for the team
At Leica Geosystems, translation supported a hardware product line with long release cycles — there was room for a more traditional, batch-oriented translation process. In a software context with continuous releases, that same process would create a permanent backlog. The right setup depends less on the number of languages and more on how fast the source content changes; a process built for quarterly hardware manuals will buckle under weekly software releases, and a process built for continuous localization is overkill for content that barely changes.
What scales and what doesn't
Headcount doesn't scale linearly with language count — process does. The difference between managing translation into 5 languages and 28 isn't more people doing the same thing 28 times; it's whether terminology management, source-content review, and file handling are consistent enough that adding a language is a configuration change rather than a new project.