June 15, 2003
Five shifts are reshaping how manufacturers localize content, and none of them is a new technology in isolation. Together they change where the quality checkpoints sit.
The old model for machine translation was post-editing: produce a rough version first, then have a linguist tidy it. The problem with that model is anchoring — the editor works inside the machine's choices, and awkward phrasing slips through. The more common approach now is to move machine translation forward, using it for drafting and lookup while a person judges what to keep. Looking up how a term is conventionally rendered in the target language, for instance, is much faster than asking a translator to guess from memory.
What actually changes when you move the step forward is the location of the quality checkpoint. Reviewers used to check whether the translation read well; now they also have to check whether terminology is correct, whether the machine has damaged data structures, and whether units and regulatory wording are right. The responsibility has not shrunk — it has shifted from correcting typos to exercising judgement.
Where the time genuinely comes from is in joining things up: terminology base, translation memory and machine translation working together can give a several-fold speed-up on repetitive content. The precondition is that the termbase exists first. Without a governed termbase, the efficiency gain is cancelled out by the consistency loss.
The spread of structured authoring is the most concrete change of recent years. Manufacturers write a product instruction, safety specification or certification statement once as modules, then publish it per market. The benefit is not only cost — just as important is that two language versions can no longer disagree, which in regulated documents is a serious defect.
Making this work means splitting content into reusable units: a technical parameter, a warning sentence, an installation note, each independent and numbered. It sounds like document engineering, but it decides whether later localization is multiplication or addition.
Many teams underestimate the workload here. Restructuring content scattered across dozens of Word documents is a real upfront investment, but once it is built the marginal cost of each additional language keeps falling. That calculation has to be made over three years, not one quarter.
More and more devices ship with voice prompts and online support, and this content follows a different logic from documentation. Documentation has to be accurate; voice and chat interfaces have to consider tone, level of formality and whether the response pattern is culturally acceptable. Japanese and German users expect different degrees of politeness for the same meaning, and a literal translation can read as abrupt or even rude.
The difficulty is that this is not static text — it is part of interaction design. Rewording may require changing the flow: some markets expect confirmation before an action, others the reverse. A localization team given only a list of strings cannot make that judgement.
In practice this should be reviewed together with interface design, not handed to translation after the interface is frozen. Changing a flow is far more expensive than changing a string.
Safety and compliance files increasingly diverge by market. The same product is subject to different requirements in the EU, North America and Southeast Asia — format, section structure and disclosure depth all differ — and the versions must not be mixed. This means localization is not only language conversion; it has to carry version control and approval records: which version goes to which market, who approved it, and when.
Which means documents have to be tied to product versions. If the product changes one parameter, the corresponding safety sections must be updated in every language. Watching for this manually does not scale; it needs process and tooling.
For manufacturers, the cheapest approach is to fix the version-management rules at project start rather than patching them after a problem. Remediating after the fact routinely costs ten times what following the rules would have.
Carbon footprint data, material declarations and sustainability statements used to appear in a handful of customer questionnaires. Now regulators and procurement teams in more and more markets ask for them. Their characteristics are that the numbers are sensitive, the definitions are not yet harmonised, and the ground keeps moving — written one way this year, a different standard next year.
Treating this as routine localization content means having a single data source, someone maintaining the definitions, and version records. Numbers scattered across departmental spreadsheets will never reconcile no matter how many times they are translated.
All five trends point at the same thing: localization is moving from project to continuous operation. The single-translation-delivery mindset no longer fits. Whoever gets content, terminology and version control in place first finds each additional language is only a matter of quantity; whoever skips it re-accumulates the deviation with every new language.
We handled a Vietnamese manual for a power tool maker. The first round was technically clean and the engineers approved it. The second round went to the local distributor, who said the register was too formal — workers did not read "always disconnect the power supply first" as an instruction; "unplug it first" was what the shop floor actually said. The third round restructured the sequence, because literacy levels on that line varied widely enough that every safety warning originally carried in text had to become an illustration with a short phrase under it.
The third version was about a quarter shorter than the first and the complaints about unreadable instructions dropped noticeably afterwards. The lesson is that localisation stopped being a translation step a long time ago. Content design, choice of reviewer and choice of carrier all determine whether the document gets read. When we assess a localisation project, we do not start from the number of languages requested; we start from the question of who the document finally lands on.
The five points above all sound right, but on a budget sheet only one item must come first: the glossary. Without it, every other trend is discounted — machine translation cannot guarantee consistency, structured writing reuses the same concept under several names, and voice and UI localisation each translate independently. The glossary is the foundation on which every efficiency gain rests.
The second spend is reviewer selection. Most teams have translation self-check or peer review, which is the right direction but the wrong level. What works is involving local people who know the target market, especially for instructions and safety warnings that directly affect use. That investment usually costs less than adding a language and pays off more directly.
Conversely, the least worthwhile spend is full coverage. Do the high-value documents well first — the operating instructions, service manuals and interface prompts customers use every day — where translation ROI is highest. Annual-report-scale documents can wait. When the budget is limited, sequence matters more than volume.
Tell us your project scenario and requirements, and we will match the right solution and provide a quote within 24 hours.
Get a Free Quote