Localising Technical Training

Localisation budgets are usually built around word count. The failures are mostly not in the words.

What actually breaks

Terminology that does not match the market's tooling. A course teaching a term that does not appear on the diagnostic equipment the technician actually uses creates confusion at exactly the moment it matters. The reference point is the tool and the service documentation in that market, not the source language.

Regulatory divergence. Safety requirements, refrigerant handling, high-voltage qualification, waste disposal and environmental rules differ. A procedure that is correct in one market may be non-compliant in another, and this is the most serious category because the course is teaching something wrong.

Vehicle specification. The same model differs between markets: emissions systems, driver assistance content, market-specific equipment, sometimes fundamental drivetrain differences. A course illustrating a component the market does not have is not a translation problem.

Units and formats. Torque, pressure, temperature, distance, dates, decimal separators. Automated conversion produces numbers of implausible precision — a torque value of 47.4515 newton metres tells the technician something about the process rather than about the fastener.

Text in images and video. Screenshots of the diagnostic tool, labelled diagrams, on-screen callouts, and anything with text baked into it. This is the item most often discovered late, because it was not counted as text.

Recorded voice. Re-recording rather than subtitling, if the original was narrated. See voice-over.

Text expansion. Some languages run substantially longer than English, and layouts built to the source break. Right-to-left languages break them structurally.

Assessment items. Questions translate; their difficulty does not necessarily survive. A distractor that is plausible in one language may be obviously wrong in another, and the item stops discriminating. See assessments that predict performance.

Examples and scenarios. Vehicle names, customer names, currency, road conditions, seasons. A scenario about a vehicle that does not exist in the market undermines credibility for no benefit.

Designing so localisation is cheap

Decided at build time, and it determines the cost of every subsequent language.

Separate text from graphics. Callouts as overlay text rather than baked into the image. This single decision accounts for a large share of localisation cost.

Avoid text in video. Where it is needed, use overlays that can be replaced.

Build layouts that tolerate expansion, and test with a long language early.

Keep a terminology glossary from the start, agreed with each market. Retrofitting consistent terminology across an existing library is expensive and it is the most common quality complaint.

Modularise by market variation. If a section differs by market, make it a separate module rather than a variant of the whole course. Then one market's regulatory change does not require reissuing everything.

Version the source properly. See updating courseware when the product changes.

And do not use automated conversion for values. Have units handled deliberately, with sensible precision.

The review that matters

A technical review in-market, by a working technician, not only a linguistic review by a translator.

The translator checks the language. The technician checks whether the procedure is correct, the terminology matches the tools, and the vehicle is the one they see. These are different reviews and only one of them is usually budgeted.

Give the reviewer the criteria. "Does this read well" produces style comments; "does this match the service documentation, the tools and the regulations here" produces the findings you need.

Feed corrections back to the source where the issue is not language-specific. A terminology error found in the German version is frequently present in all of them.

Keeping versions in step

The problem that grows with the library.

One course in eight languages is eight things to maintain. A product change requires eight updates, and without a mechanism the versions drift — a network ends up with one language two revisions behind and nobody knows which.

Manage them as versions of one course, not as separate courses. The platform should be able to tell you which language versions are current against the source. See choosing an LMS.

Track currency explicitly, and publish it. A dealer should be able to see that their language version corresponds to source revision 4.

And decide the policy for a lagging version: withdraw it, or serve it with a notice. Serving an outdated procedure silently is the worst option and it is the default one.

Budgeting realistically

Translation is a minor line. Technical review, graphic rework, re-recording, assessment revalidation and layout adjustment are the substantial ones.

The first language costs the most, because it exposes everything that was not built for localisation. Budget the first one as a project and the rest as production.

Maintenance is ongoing, not a one-off. A library of a hundred courses in eight languages has a permanent maintenance cost that is frequently not in anyone's budget.

The short version

Terminology must match the market's tools and documentation, not the source language.

Regulatory and specification divergence is the serious category — the course may be teaching something that is wrong there.

Text baked into images and video is the cost discovered late. Separating text from graphics at build time is the highest-return decision.

Have a working technician in-market review it, not only a translator.

And manage eight languages as versions of one course, or a network ends up serving procedures two revisions old without knowing which.

For open guidance on language, locale and international web content, consult W3C Internationalization resources.