Preparing Technical Documentation for Translation

Translation

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.

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: Partial retranslation. 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.

Version misalignment. 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.

Translation memory pollution. 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.

The practical instruction is simple: 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.

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.

File formats that work well for translation: Microsoft Word (.docx) Microsoft Excel (.xlsx) — for structured content, terminology, or UI strings Microsoft PowerPoint (.pptx) Adobe InDesign (.indd or .idml) — with exported .idml for translation XML and HTML files XLIFF, SDLXLIFF, and other standard localization formats Plain text files with clear structure

File formats that create problems: PDF (especially scanned PDFs) Image files (JPG, PNG, TIFF) containing text Locked or password-protected files Files with embedded text in graphics If 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.

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.

Before sending documentation for translation, review it for: Inconsistent component names. Does "pressure valve," "pressure relief valve," "PRV," and "the valve" all refer to the same component? Pick one and use it throughout.

Inconsistent process descriptions. Does "press," "click," "tap," "activate," and "select" all describe the same action in your UI documentation? Choose the preferred term and apply it consistently. Inconsistent abbreviations. 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.

Mixed register. 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.

If you do not already have a terminology glossary for your product or system, create one before sending your documentation for translation. A glossary of 50 to 100 key terms takes a few hours to compile and saves many times that cost in translation inconsistencies, revision cycles, and corrections.

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.

A basic glossary contains: The source-language term (preferred form) A definition or description of what the term refers to Any approved translations in target languages you work in regularly Notes on usage — for example, "always capitalize," "abbreviate as X after first use," "do not translate — use English term in all languages"

A more complete glossary adds: Deprecated terms (terms that should not be used, with the preferred alternative) Product names and brand terms (with instructions on whether to translate or retain in source language)

Regulatory terms (with the specific regulatory framework they belong to) Abbreviations and their expansions 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.

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.

Common ambiguity types in technical documentation: Pronoun reference. "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.

Vague quantifiers. "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.

Compound nouns without hyphens. English compound nouns like "pressure relief valve bracket" are ambiguous about their internal structure — 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 — "pressure-relief-valve bracket" — removes the ambiguity.

Culturally specific references. Examples, analogies, or references that depend on knowledge specific to one culture may not translate meaningfully. Replace with neutral examples wherever possible.

Safety-critical instructions. Any instruction that affects safety must be unambiguous. If there is any doubt about whether a safety-critical instruction could be misunderstood, resolve it before translation — not after.

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.

Options for managing text in graphics: Externalize text from graphics. 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.

Provide source files for graphics. 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.

Provide font files. 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.

Allow layout adjustment time. Text length changes significantly in translation — German and

Finnish text is typically 30–40% longer than English; Chinese and Japanese text is often shorter.

Graphic layouts that are tight in English may need adjustment in translation. Build this into your schedule.

If you have worked with a translation provider previously, you may have a translation memory — a database of previously translated content from your documentation.

Before starting a new translation project, ask your provider: What translation memory do we have for this content? Knowing the volume of existing approved content allows more accurate project scoping and cost estimation.

What is the match rate for this new version against the existing TM? A high match rate — meaning most of the new content has been translated in previous versions — significantly reduces cost and turnaround time.

Has the existing TM been validated against the current terminology? If your terminology has changed since the TM was built — if components have been renamed, processes redescribed, or 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. This is the standard interchange format that any professional translation tool can import. Your translation history belongs to you and should be transferable.

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.

Documentation practices that reduce the cost of translation updates: Use a content management system or version control. 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.

Mark changes clearly. 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.

Maintain consistent structure. 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.

Segment updates by content type. 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.

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.

Useful contextual materials: Product samples, physical components, or access to the equipment being documented Video walkthroughs of procedures described in the manual Access to the software or interface being documented Previous versions of the same document in any language Competitor documentation for the same type of product (useful for terminology benchmarking)

Contact details for a subject-matter expert who can answer technical questions during translation Even a brief product overview — one page explaining what the product does, who uses it, and in what context — materially improves the quality of translation for a translator who is encountering your product for the first time.

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 of those changes 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.

Before translation begins, agree on: Who will review the translation, and what are they reviewing for? 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. What counts as an error, and what counts as a preference? A translation error — a mistranslation, an omission, a terminology deviation from the agreed glossary — is a quality failure that the provider should correct. A stylistic preference — a different but equally valid word choice — is not. Mixing these in feedback creates confusion and disputes.

What is the process for submitting feedback? 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.

What is the timeline for review and corrections? 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.

Summary: The Preparation Checklist Before sending technical documentation for translation: Source text is finalized — no further changes expected Source files are in editable format (not PDF or image) Terminology is consistent throughout the source text A terminology glossary has been prepared and will be provided Ambiguities have been identified and resolved Graphics with embedded text have been handled — source files or externalized labels provided Existing translation memory has been reviewed for relevance and accuracy Update management approach has been agreed Contextual materials — product overview, SME contact, reference documents — have been gathered

Review process, feedback format, and correction timeline have been agreed in advance 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.