Why Preparation Determines Quality
Most organizations treat translation as something that happens to their documentation - they write it, finish it, and send it to a translation provider. The quality of the preparation determines the quality of the result as much as the quality of the translator.
Technical documentation presents specific challenges that general business content does not. It contains specialist terminology that must be consistent across hundreds of pages and multiple language versions. It is often structured - tables, numbered procedures, embedded warnings, cross-references - in ways that affect how it can be processed. It may exist in file formats that require technical handling before translation begins. And it is frequently updated, which means the translation must be maintainable over time, not just accurate on first delivery.
Organizations that prepare their technical documentation thoughtfully before sending it for translation receive better output, faster, at lower cost - and with fewer surprises. This guide explains how to do that.
Finalize the Source Text Before Sending
The single most expensive thing you can do in a translation project is change the source document after translation has begun.
Every change to the source after translation starts creates one of three problems:
The changed sections must be retranslated, and their surrounding context reviewed for consistency. Depending on the change, this can affect far more content than the changed passage itself - particularly where the changed content contains terminology that appears throughout the document.
If the source changes mid-project and the change is not communicated clearly, the translation may be completed against an outdated version - producing a delivered translation that does not match the final source.
If changed source content is translated before the change is noticed, the incorrect translation may be stored in the translation memory and applied to subsequent projects.
Do not send documentation for translation until it is final. If your internal review process is not complete, wait - the cost of a mid-project source change is almost always greater than the cost of the short delay.
If changes are unavoidable - for example, because regulatory requirements change during a translation project - communicate every change immediately, in a tracked or clearly marked version, and ask your translation provider to confirm the impact before proceeding.
Provide Source Files in Editable Format
Translation tools work with editable files - files in which the text can be extracted, translated, and reintegrated programmatically. A PDF is not an editable file. An image of a document is not an editable file. A scanned page is not an editable file.
When you send a PDF instead of a Word document, or a scanned manual instead of the InDesign source, you create additional work - and additional cost - before translation can begin. The text must be extracted, reformatted, and prepared before a translator can work with it. The output quality is lower because the automated consistency tools that work on structured files cannot function on reconstructed text.
.docx.xlsx - structured content, terminology, UI strings.pptx.indd / .idml - with exported IDML for translationXLIFF, SDLXLIFF and other standard localization formatsPDF - especially scanned PDFsJPG, PNG, TIFF) containing textIf your documentation exists only in PDF because it originated as a PDF, inform your translation provider upfront. The additional preparation work - PDF text extraction, formatting reconstruction - can be assessed and priced before the project begins.
Use Consistent Terminology in Your Source Text
Translators translate what they read. If your source text uses five different terms to describe the same component, the translation will introduce five different terms into the target language - and none of them will correspond to an agreed standard.
Terminology inconsistency in the source is the most common single cause of terminology inconsistency in the translation. It is also the most preventable.
Do these all refer to the same component? Pick one and use it throughout.
If these all describe the same action in your UI documentation, choose the preferred term and apply it consistently.
If you introduce an abbreviation, define it at first use and use it consistently thereafter. An abbreviation that appears without definition cannot be translated reliably.
If your documentation shifts between formal and informal register - sometimes addressing the reader as "you" and sometimes using passive constructions that avoid addressing the reader - the translator must make a choice at every shift point. Make the choice in the source and apply it consistently.
Build and Share a Terminology Glossary
A terminology glossary is a list of the key terms in your documentation with their approved translations - or, at minimum, their approved source-language forms and definitions.
Your translation provider will use this glossary as the foundation of the project-specific terminology database applied throughout translation. The more complete the glossary you provide, the more consistent the terminology in the output.
If you do not have a glossary, a professional translation provider can build one from your existing documentation during project preparation - but this takes time and adds cost. Building it yourself, once, is a better investment.
Identify and Resolve Ambiguities Before Translation
Technical documentation contains implicit knowledge. The engineer who wrote a procedure knows what "the unit" refers to because they designed it. The translator does not.
Ambiguities that are harmless in a single-language context become translation problems - and potentially safety problems - in multilingual documentation.
"Connect the module to the base unit. Ensure it is properly grounded before proceeding."
Does "it" refer to the module or the base unit? In English the ambiguity may be obvious from context. In translation into a language with grammatical gender, the translator must choose - and may choose wrong.
"Tighten securely." · "Allow sufficient time." · "Use an appropriate tool."
These are not translatable because they do not specify what they mean. Replace with specific values wherever possible.
pressure relief valve bracket
pressure-relief-valve bracket
Is it a "bracket for a pressure-relief valve" or a "pressure-relief-valve bracket"? Translators into German, for example, must resolve this ambiguity because German compounds are written differently. Hyphenating your English compounds removes it.
Examples, analogies, or references that depend on knowledge specific to one culture may not translate meaningfully. Replace with neutral examples wherever possible.
Handle Graphics and Text-in-Images Carefully
Technical documentation frequently contains graphics with embedded text - labels, callouts, legends, diagram annotations. Text embedded in images is not translatable by standard translation tools. It must be extracted, translated separately, and re-embedded into the image - a process that requires additional skill, tool support, and time.
Rather than embedding text labels directly in images, reference a separate table of label translations. This is the most efficient approach for documentation that will be maintained and updated over time.
If text is embedded in illustrations produced in a vector graphics application (Illustrator, CorelDRAW, AutoCAD), provide the source files rather than exported images. Text can then be edited directly in the source.
If your documentation uses custom or specialist fonts, provide them to your translation provider. A translated document that defaults to a system font because the original font is unavailable will not match the source formatting.
Understand What Your Translation Memory Contains
If you have worked with a translation provider previously, you may have a translation memory - a database of previously translated content from your documentation.
Knowing the volume of existing approved content allows more accurate project scoping and cost estimation.
A high match rate - meaning most of the new content has been translated in previous versions - significantly reduces cost and turnaround time.
If your terminology has changed since the TM was built - components renamed, processes redescribed, regulatory language updated - the TM may contain outdated translations that need review rather than automatic reuse.
If you are changing translation providers, request an export of your translation memory in TMX format - the standard interchange format any professional translation tool can import. Your translation history belongs to you and should be transferable.
Plan for Updates from the Start
Technical documentation is never finished. Products are updated, regulations change, components are renamed, procedures are revised. Every update to a technical manual is a translation project - and how you manage documentation updates determines how expensive those subsequent translation projects will be.
Knowing exactly what changed between version 2.3 and version 2.4 of a manual allows a translation provider to translate only the changed content - not the entire document again.
Provide new or updated content in tracked changes or clearly marked sections. A provider who must compare two document versions manually to identify changes will charge accordingly.
Documents that maintain a consistent structure across versions allow translation memories to align efficiently. Documents that are restructured with each update lose much of the efficiency benefit of TM reuse.
Safety warnings, technical specifications, and instructional procedures change for different reasons at different frequencies. If your documentation structure separates these content types, updates to one type can be processed independently.
Provide Context Your Translator Cannot See
A translator working on a technical document sees the text. They do not see the product. They cannot touch the component, run the software, or walk the production line. Any context you can provide that connects the text to the physical or digital reality it describes improves translation quality.
Agree on a Review Process Before Delivery
The most common source of post-delivery disputes in technical translation is a mismatch between the reviewer's expectations and what was agreed at the outset.
Your internal technical reviewers - engineers, product managers, regulatory affairs specialists - will review the translated documentation with domain knowledge that the translator does not have. They will find things they want to change. Some will be corrections of genuine translation errors. Others will be stylistic preferences that differ from but are not inferior to the translator's choices. Others still will be changes to the source content that the reviewer has decided to make retroactively.
A regulatory affairs specialist reviewing for compliance terminology is doing a different job from a product manager reviewing for brand consistency. Both are valid - but they should be defined in advance.
A mistranslation, an omission, a terminology deviation from the agreed glossary.
A different but equally valid word choice.
Mixing these in feedback creates confusion and disputes.
Feedback delivered in a single, clearly organized document is much more efficiently processed than feedback scattered across email threads, tracked changes in multiple file versions, and verbal comments.
Build review time into the project schedule at the outset. A rushed review process produces either missed errors or excessive revision requests - neither of which serves you well.
The Preparation Checklist
Before sending technical documentation for translation:
The time invested in preparation is recovered many times over in translation quality, project speed, and reduced revision cycles.
Working With Business Team Translations on Technical Documentation
Business Team Translations translates technical documentation across manufacturing, engineering, medical devices, energy, automotive, electronics, and other specialist sectors. Our translators have professional technical backgrounds in the relevant domains - they understand what they are translating, not just the language it is written in.
We assist clients with terminology glossary development, translation memory management, file format preparation, and structured update workflows for ongoing documentation programs.
Ready to translate your technical documentation?
Send us your files and we will prepare a detailed proposal.