Download Technical Documentation Translation: A Best Practice Guide (PDF)
Introduction
Most translation problems do not originate during translation. They originate earlier — in how the source documentation is written, how the project is briefed, and how the review process is managed. By the time a translator opens your file, the quality ceiling has already been set.
This is not to say that translation quality is irrelevant. It plainly is. But the variables that determine whether a technical translation project goes smoothly or becomes an exercise in damage limitation are largely within the client’s control. The source content, the file preparation, the briefing, the terminology management, the review process — these are the levers that move the needle.
This guide covers the practices that consistently produce better results. It follows the full arc of a technical translation project, from preparing source documentation through to managing ongoing multilingual documentation programmes. None of what follows is theoretical. It is based on what we have observed across thousands of technical translation projects over more than twenty years.
Some of it will seem obvious. It often does in hindsight. But we continue to see the same avoidable problems on project after project, from organisations of all sizes and levels of sophistication. The gap between knowing what good practice looks like and actually implementing it remains wide.
If you are a technical author, documentation manager, or anyone responsible for producing multilingual technical content, this guide is written for you. It is intended to be practical and specific. Where a recommendation is made, the reasoning behind it is explained. Where a common mistake is identified, the consequences are described. The aim is to give you a reference you can return to at each stage of the translation process.
2. Writing for Translation
The quality of a translation is bounded by the quality of the source. A perfectly executed translation of a poorly written source document produces a perfectly executed poor document in another language. This is not a failure of translation. It is an inheritance.
Use consistent terminology. The same component should have the same name every time it appears. If you call it a “housing” on page four, do not call it a “casing” on page twelve and an “enclosure” on page twenty-three. Each variant becomes a separate term in the target language. What should be one consistent translation becomes three, and the reader is left wondering whether these are different parts. A simple terminology list maintained during authoring prevents this entirely.
Write clear, unambiguous sentences. Avoid idiomatic expressions, cultural references, and humour that will not translate. “This unit packs a punch” means nothing to a translator working into Japanese. “This unit delivers high output relative to its size” is clear in any language. Technical documentation is not the place for creative writing. Precision is the objective.
Keep sentences reasonably short. Long compound sentences with multiple subordinate clauses are harder to translate accurately. They are also harder for end-users to parse in any language. If a sentence contains more than one main idea, it is usually better as two sentences. This is not about dumbing down. It is about clarity.
Use controlled language where possible. Particularly for safety-critical content — warnings, cautions, procedural instructions — standardised sentence structures translate more consistently and reduce the risk of ambiguity. Controlled language specifications such as ASD-STE100 exist for precisely this reason. Even an informal set of writing rules applied consistently across your documentation will improve translation outcomes.
Avoid embedding text in images. Text in screenshots, diagrams, and illustrations creates additional translation and desktop publishing work. Every image with embedded text must be recreated for every language. Where possible, use numbered callouts that reference a translatable legend. This is faster, cheaper, and produces cleaner results.
Be explicit about measurements and units. “Standard voltage” means different things in different markets. Specify 230V AC, 50Hz. “Normal operating temperature” is meaningless without a range. Translators should not have to guess what you mean, and neither should your readers.
Minimise cultural assumptions. Instructions that assume familiarity with UK or US conventions may confuse international readers even when the translation itself is accurate. References to specific regulatory frameworks, trade practices, or measurement conventions that are not universal should be explained or adapted.
Complete the document before sending for translation. Translating draft content that subsequently changes generates rework across every target language. If you are translating into eight languages and make a late change to twenty paragraphs, you have just created one hundred and sixty paragraphs of rework. Finalise the source first. Translate once.
3. Preparing Source Files
File preparation is unglamorous work that has an outsized effect on translation cost, speed, and output quality. Getting it right is straightforward. Getting it wrong creates problems that ripple through the entire project.
Provide editable source files, not locked PDFs. Word, InDesign, FrameMaker, XML, HTML, DITA — whatever your authoring environment produces. Editable files can be processed through translation tools, which means the translator works with the text while the formatting is preserved automatically. Locked PDFs must be manually recreated, which is slower, more expensive, and more error-prone. If you only have a PDF, say so upfront so the translation provider can plan accordingly.
Use styles and formatting consistently. Consistent heading styles, body text formatting, and table structures help translation tools parse the document correctly. If your Heading 2 is sometimes a style and sometimes manually formatted bold text, the translation tool may not recognise it as a heading. The result is formatting inconsistencies in the translated output that require manual correction.
Separate text from layout where possible. Content management approaches and structured authoring environments that separate text from presentation — XML, DITA, component content management systems — make translation significantly more efficient. The text is extracted, translated, and reinserted. Layout is handled separately. This is the direction the industry has been moving for years, and for good reason.
Tag non-translatable content. Product codes, part numbers, model numbers, brand names, international standards references (ISO, IEC, EN), chemical formulae, and software commands should not be translated. Clearly identifying these elements prevents unnecessary translation, avoids errors, and ensures they remain in their original form. A simple list is sufficient. Better still, tag them in the source files.
Provide reference images at full resolution. If the document contains images with embedded text that needs translating, provide the editable source files — Illustrator, Photoshop, Visio, or whatever was used to create them. Without editable sources, the desktop publishing team must recreate graphics from scratch, which is time-consuming and rarely pixel-perfect.
Include style guide or formatting specifications. If the output needs to meet specific corporate standards, regulatory formatting requirements, or publication specifications, document these upfront. Assumptions about output requirements are the source of a remarkable number of late-stage revisions.
4. Briefing Your Translation Partner
A translation brief is not a purchase order. The more context you provide, the better the translation will be. Translators are not mind-readers, and even the best ones cannot compensate for missing information.
Provide context, not just files. What is this document? Who reads it? What should they be able to do after reading it? Where will it be used — in a factory, a hospital, a retail setting? Is it a standalone document or part of a larger set? Context shapes translation decisions. A term that is appropriate in a user manual may be wrong in a marketing brochure, even if the source word is the same.
Specify target languages precisely. “Brazilian Portuguese” is not the same as “European Portuguese.” “Simplified Chinese” is not the same as “Traditional Chinese.” “Latin American Spanish” may need further specification depending on the target market. Ambiguity here leads to rework. Be precise.
Share your glossary. Even an informal spreadsheet listing key terms with preferred translations is enormously valuable. This is, without exaggeration, the single most useful thing you can provide alongside the source files. If you do not have a glossary, say so — the translation provider can help you build one. But if you have any existing terminology preferences, share them.
Provide previous translations. Earlier versions of the same document, related documents, translations from other providers — all of these are useful. They build translation memory, establish terminology, and give translators reference points. Even imperfect previous translations are better than nothing.
Identify terms that should not be translated. Brand names, product names, proprietary terminology, international standards references, software interface terms that remain in English — list them. Do not assume the translator will know. A product called “SmartFlow” should probably remain “SmartFlow” in all languages, but that is not obvious unless you say so.
State output format requirements. Do you need the translation in the same format as the source? A print-ready PDF? A bilingual document? Specific file naming conventions? These details matter and are best addressed at the start, not discovered at delivery.
Name one contact person. Translators will have questions. They should know who to ask and be confident of a timely response. A single named contact is far more effective than a committee. Questions that take three days to answer through a chain of approvals delay the project and sometimes result in the translator guessing instead.
Set realistic deadlines. Technical translation of complex content takes time. A realistic rate for specialist technical content is 2,000 to 2,500 words per day per language. A 10,000-word document translated into six languages does not take one day. Unrealistic deadlines force compromises — additional translators who may not know your terminology, reduced quality checks, or both.
5. Translation Memory and Terminology Management
Translation memory and terminology management are the mechanisms through which translation quality improves and costs reduce over time. Understanding how they work is essential for anyone managing a multilingual documentation programme.
What translation memory is. A translation memory is a database of previously translated segments — typically sentences or sentence-like units. Each entry pairs the source text with its approved translation. When a new document is processed, the translation tool compares each segment against the database. Where it finds an exact or close match, it proposes the previous translation. The translator then accepts it as-is, modifies it to fit the new context, or retranslates entirely.
Why it matters. Translation memory delivers three benefits simultaneously. First, consistency: the same source text produces the same translation every time, which matters enormously for technical content where terminology must be uniform. Second, cost reduction: content that has been translated before does not need to be translated again from scratch, and most translation providers reflect this in their pricing. Third, speed: less genuinely new content means faster turnaround.
How it compounds. The value of translation memory is cumulative. The first project builds the foundation. The second project leverages everything that was translated on the first. By the fifth or sixth project, a substantial percentage of content may match previous translations — particularly if your documentation follows consistent structures and uses consistent terminology. By the tenth project, translation memory leverage of 40 to 60 percent is not unusual for well-managed documentation sets. Costs reduce, turnaround shortens, and consistency improves with every project.
Terminology databases. A terminology database — sometimes called a termbase — goes a step further than translation memory. It is a maintained glossary of approved terms in all target languages, often with definitions, context notes, and usage guidance. While translation memory works at the sentence level, terminology management works at the word and phrase level. It ensures that regulated terms, product names, safety-critical vocabulary, and technical terminology are translated consistently across all documents, all projects, and all translators.
Who owns the translation memory. This is a point worth being clear about. The translation memory built from your projects is your asset, not the translation provider’s. It was created from your content, funded by your investment, and its value accrues to your documentation programme. Ensure your contract explicitly provides for ownership of, and access to, your translation memory and terminology databases. If you ever need to change providers, you should be able to take these assets with you. Any provider who resists this is not one you should work with.
What happens without it. Without translation memory and terminology management, every project starts from scratch. Different translators make different terminology choices. The same source sentence receives different translations in different documents. Costs never reduce because there are no leverageable assets. Inconsistency accumulates across your documentation set, and your readers notice — even if they cannot articulate exactly what is wrong.
6. Managing the Review Process
In-country review is where many otherwise well-managed translation projects encounter difficulty. The problem is rarely the concept of review. It is the execution.
Define the purpose of review. Review verifies that the translation is accurate and appropriate for the intended audience and use. It is not an invitation to rewrite the text according to personal preference. This distinction matters and should be communicated clearly to reviewers before they begin. A reviewer who rewrites accurate translations because they would have phrased things differently is not adding value. They are adding cost and delay.
Use qualified reviewers. The ideal reviewer is a native speaker of the target language with subject matter knowledge. A bilingual engineer who works with the product is far more valuable than a linguist who does not understand the technical content. Conversely — and this is important — an intermediate-level speaker with no technical background is worse than no reviewer at all. Poor reviewers introduce errors that were not present in the original translation. If you do not have access to a qualified reviewer for a given language, it is better to rely on the translation provider’s quality processes.
Provide clear feedback guidelines. Distinguish between errors (factual inaccuracies, mistranslations, omissions — these must be corrected) and preferences (alternative phrasing that is equally correct — these should be discussed, not imposed). Require tracked changes with explanations. Consolidate feedback through one reviewer per language. Multiple reviewers with conflicting preferences create confusion and delay that benefits nobody.
Feed review outcomes back into the process. This is where review becomes genuinely valuable beyond the immediate project. Confirmed terminology goes into the glossary. Approved translations update the translation memory. Reviewer preferences are recorded for future reference. Over successive projects, the translation increasingly reflects your organisation’s preferred style and terminology. Review effort decreases because there is less to correct. This feedback loop is the mechanism through which translation quality improves over time — but only if the outcomes are captured systematically.
Set review timelines and stick to them. Delayed review delays the project and every downstream activity that depends on it — desktop publishing, final approval, printing, distribution. Build review time into the project schedule from the outset and hold reviewers to agreed deadlines. A two-week review window that stretches to six weeks is a planning failure, not a translation problem.
7. Managing Ongoing Programmes
Single translation projects are one thing. Managing a multilingual documentation programme over months and years is quite another. The organisations that do this well share several characteristics.
Treat translation as part of the document lifecycle. Translation is not an afterthought to be bolted on after the documentation is complete. It is a stage in the documentation process, as integral as authoring, review, and publication. When translation is planned from the outset, source documents are written with translation in mind, schedules accommodate translation timelines, and budgets reflect the true cost of multilingual documentation.
Maintain a document inventory. What documents exist? In which languages? At which revision level? Without a clear inventory, version mismatches accumulate silently. The English manual is at revision 4, the French translation is at revision 2, and nobody is entirely sure about the German. In regulated industries, this is a compliance risk. In any industry, it is a quality problem.
Trigger translation updates automatically. When a source document is revised, the translation update should be triggered as part of the revision process — not discovered weeks later when someone notices the discrepancy. If your document management system supports workflow automation, use it. If it does not, build manual triggers into your revision procedures.
Build a long-term translation partnership. Consistency, terminology knowledge, subject matter familiarity, and process efficiency all improve with continuity. A translation provider who has worked with your documentation for two years knows your products, your terminology, your formatting requirements, and your reviewers’ preferences. Switching providers resets all of this. The new provider starts from scratch — learning your terminology, building new translation memories, understanding your processes. There may be good reasons to change providers, but the cost of doing so is higher than most organisations anticipate.
Budget for translation in the documentation plan. If you know the documentation will need translating, budget for it when you plan the documentation — not as a separate, unexpected cost that appears after the English version is complete. Late budget surprises lead to corners being cut, deadlines being compressed, or languages being dropped. None of these outcomes serves the end-user.
Track translation memory leverage. Monitor the percentage of content matching previous translations across successive projects. This figure should increase over time as the translation memory grows. If it does not, something is wrong — either the source documentation is too variable, the translation memory is not being maintained properly, or the content is genuinely new each time. Investigating a flat or declining leverage rate often reveals process improvements that benefit both the documentation and translation programmes.
8. Key Takeaways
- Write source documentation with translation in mind: consistent terminology, clear sentences, no embedded text in images, explicit measurements, and finalised content before translation begins.
- Provide editable source files with consistent formatting, and clearly identify content that should not be translated.
- Brief your translation partner thoroughly: context, precise language specifications, glossaries, previous translations, format requirements, a single contact, and realistic deadlines.
- Build and maintain translation memory and terminology databases as long-term assets — and ensure you own them.
- Define the review process clearly: qualified reviewers, clear feedback guidelines, and systematic capture of review outcomes for future projects.
- Treat translation as an integral part of the document lifecycle, not an afterthought.
- Maintain a document inventory, trigger translation updates as part of the revision process, and track translation memory leverage over time.
- Invest in a long-term translation partnership — consistency, knowledge, and efficiency compound with continuity.
About Bubbles Translation Services
We have been translating technical documentation since 2003. If you would like to discuss how to improve your technical translation process, or if you have a project you would like to talk through, we are here to help.
Email: info@bubblestranslation.com
Phone: 0870 777 7750
Web: bubblestranslation.com
Bubbles Translation Services — Technical documentation translation expertise since 2003.
