Engineering teams tend to discover the cost of careless source writing at the worst possible moment, usually a fortnight before a product ships into eleven markets. The manual is finished, the translation quote arrives, and it is three times what anyone budgeted. Nobody wrote the technical documentation badly on purpose. They simply wrote it as though English were the only language it would ever exist in.

Documentation that translates cleanly is not a stylistic preference. It is a cost centre, a compliance requirement and, for anything with moving parts or a mains cable, a safety issue. The useful part is that almost everything which makes a document translate well also makes the English version easier to read.

Short sentences are not dumbing down

The single biggest lever is sentence length. A forty word sentence with three subordinate clauses can usually be parsed by an English reader who already knows the product. Rendered into German, Japanese or Finnish it becomes a structure the translator has to unpick and rebuild, and every rebuild is an opportunity for a quiet shift in meaning.

Aim for one instruction per sentence and one idea per paragraph. Use the active voice and name the actor. An instruction such as 'press the reset button' travels intact into any language. 'The reset button should be pressed' leaves the translator guessing whether the operator, the service technician or an automated routine is meant to do it.

Say the same thing the same way

Writers are trained to vary their vocabulary. Technical writers should do the opposite. If the part is a housing, it is a housing on page four and on page ninety, never a casing, an enclosure or a shell. Synonyms that read as elegance in English read as three different components once translated, and a field engineer holding the Spanish version will order the wrong spare.

A maintained termbase solves this, and it pays for itself the first time a product family is revised. The discipline has a formal version in Simplified Technical English, developed for aerospace maintenance manuals and now used well beyond it. The full specification is published by the ASD-STE100 maintenance group and is worth reading even if you never adopt it wholesale, because the reasoning behind each rule is more useful than the rule.

Design for text that grows

German and Finnish typically run longer than English, sometimes by a third. Layouts built to fit English exactly will break, and the break usually appears as a truncated warning label or a caption that no longer sits under its figure. Leave room in tables, buttons and callouts from the start.

Screenshots and diagrams deserve the same forethought. Text baked into an image has to be recreated for every language, at real cost. Callout numbers with a separate legend in the body text cost nothing to localise, and they make the source document more accessible as a side effect.

Write once, reuse everywhere

Most manuals contain a great deal of repetition across products and versions. Structured authoring, whether in a full component content management system or simply a disciplined set of reusable topics, means each safety warning exists once and is translated once. Copy and paste means the same warning exists in nine slightly different forms, and you pay for nine translations of it.

Technical documentation that survives translation does so because someone anticipated the second language while writing the first. Property purchases abroad rarely get that benefit; the paperwork was written for domestic use. Anyone buying property abroad is therefore reading documents that were never intended for them.

This is also where translation memory earns its keep. Consistent source text produces high match rates, and high match rates lower the cost of every subsequent release. Teams that fix their source writing usually see the second release cost a fraction of the first, which is a more persuasive argument to a finance director than anything about readability.

Build in an in country review

The last safeguard is a reviewer who works in the target market and uses the product, not a head office manager who happens to speak the language. Give them a fixed window, a clear brief and a way to log changes against the source, otherwise you get rewrites of settled terminology two days before print. Agree in advance who arbitrates when the reviewer and the translator disagree, because that decision decides whether the release ships on time.

Choosing the people who do the work

Subject knowledge is not optional. A linguist who has never seen a hydraulic schematic will produce grammatical text that an engineer cannot follow, and the reviewer at the local subsidiary will send it back. Ask how the provider handles queries, because a translator who never asks a question is either working on something trivial or guessing.

Ask about terminology ownership too. The provider should maintain the termbase and hand it over on request, since it is your asset and not theirs. Comparing technical translation services on process rather than on rate per word tends to reveal quickly which firms treat documentation as engineering work. The wider case for treating it that way is set out well in this piece on the importance of professional technical translation.

None of this requires a new tool or a bigger budget. It requires the writing team to accept that they are drafting a source text rather than a finished document, and to make the small choices accordingly. The savings show up in the second language and compound in the eleventh.