How a Technical Manual Translation Project Works: A Step-by-Step Guide

Download How a Technical Manual Translation Project Works: A Step-by-Step Guide (PDF)

Overview

This guide is written for technical authors, documentation managers, and procurement teams who are either commissioning a translation project for the first time or evaluating whether their current provider follows a sound process. It is deliberately practical. No theory, no padding.

What follows is a plain account of what happens from the moment you send source files to a translation provider to the moment you receive finished translations back. Each stage is described in terms of what happens, who does it, how long it typically takes, and what can go wrong if it is skipped or done badly.

If you have ever waited weeks for a translation only to receive something riddled with inconsistencies, or if you have ever been quoted a price with no explanation of what that price actually covers, this guide should help you understand what a well-run project looks like. It should also help you ask better questions of any provider you work with.

The process described here applies to technical manuals, instructions for use, maintenance guides, and similar structured documentation. Marketing materials, websites, and legal contracts follow different workflows and are not covered here.

Stage 1: Project Briefing

Every translation project begins with a brief. The quality of that brief determines whether translation starts on day one or after a week of clarification emails.

What you provide:

Source files in an editable format (Word, FrameMaker, InDesign, XML, structured DITA — not locked PDFs)
Target languages, including specific regional variants (Brazilian Portuguese is not European Portuguese; Simplified Chinese is not Traditional Chinese)
Context for the content — what is this document, who reads it, what product does it relate to
Any existing glossary, term list, or style guide
Previous translations of the same or similar documents
Required deadline
Desired output format

What the translation team does with it:

The project manager assesses scope by running a word count on the source files and cross-referencing against any translation memory from previous work. This tells you how much of the content is new, how much has been translated before, and how much is partially similar to previous work. The file formats are checked for compatibility with translation tools. Any potential problems — embedded images containing text, scanned content, non-standard formatting — are flagged immediately.

Why this matters:

A complete brief means the project manager can issue an accurate quote and realistic timeline straight away. An incomplete brief means emails back and forth asking for missing files, clarification on language variants, or confirmation of scope. Every day spent on clarification is a day not spent translating.

Typical duration: Same day to two working days for a quote, assuming files and instructions are complete.

Stage 2: Analysis and Setup

Once the project is confirmed, the preparatory work begins. This stage is invisible to most clients, but it is where much of the value in a professional translation process is created.

Terminology review. If you have provided a glossary or term list, the project team reviews it against the source content. If previous translations exist, key terms are extracted and checked for consistency. Where no glossary exists, one is started. This is particularly important for technical manuals, where a single component may need to be referred to by exactly the same term every time it appears — across documents, across languages, across years.

Translation memory setup. Previous translations are loaded into the translation memory system. The software analyses the new source text segment by segment and identifies matches: exact matches (identical to something translated before), fuzzy matches (similar but not identical), and new content with no previous match. On a mature project with several rounds of manual revisions, leverage from previous translations can be substantial — sometimes 40-60% of the content will not need translating from scratch.

Team assignment. Translators are matched to the project based on subject matter expertise. A translator with ten years of experience in automotive service manuals is not interchangeable with one who specialises in pharmaceutical labelling. Domain knowledge matters because a technically competent translator will not need to query every third term.

File preparation. The source files are processed through translation tools that extract translatable text while preserving formatting codes, tags, and structure. Non-translatable elements — part numbers, model codes, mathematical formulae — are locked so they cannot be accidentally altered.

Typical duration: One to two working days.

Stage 3: Translation

This is the stage people think of when they think of translation, though in practice it accounts for only part of the overall project timeline.

The translator works through the document systematically, segment by segment. For each segment, the translation memory suggests any matches from previous work. The translator reviews each suggestion and either accepts it as-is, modifies it to fit the current context, or rejects it and translates from scratch. This is not an automated process — the translator makes a deliberate decision on every segment, even those with a 100% match from memory, because context changes meaning.

New content is translated by a human linguist with relevant subject matter expertise. Technical manuals require translators who understand not just the language but the domain. A translator working on a hydraulic press maintenance manual needs to know what a pressure relief valve does, not just what the words mean individually.

Queries are inevitable on any technical project. A well-run process handles these by flagging them clearly and routing them to the client in a structured format — typically a query sheet listing the segment, the question, and any suggested resolution. The translator flags the query and moves on rather than guessing. Guessing at technical content is how safety-critical errors enter translated documentation.

For large projects — say, a 50,000-word manual going into eight languages — multiple translators may work on the same language simultaneously. When this happens, terminology is coordinated through shared glossaries and translation memories that update in real time, and a lead translator reviews the combined output for consistency of style and terminology.

Typical duration: This depends entirely on volume. For technical content, a realistic output is 2,000 to 3,000 source words per day per translator. A 10,000-word manual translated by one linguist takes roughly four to five working days. Adding translators can compress this, but coordination overhead means the relationship is not linear.

Stage 4: Review and Editing

The translated document is now reviewed by a second linguist. This is not the same person who translated it. Fresh eyes catch things that the original translator, having worked through the text closely, will inevitably miss.

Second linguist review. The reviewer reads the translation against the source text, checking for accuracy, completeness, and natural readability in the target language. This is not proofreading in the sense of scanning for typographical errors, though those are caught too. The reviewer is asking: does this read as though it was originally written in this language? Is the terminology consistent throughout? Has anything been omitted or misinterpreted?

Technical accuracy check. Measurements, tolerances, part numbers, torque values, safety warnings, and regulatory references are checked against the source one by one. A missing decimal point in a torque specification or a transposed digit in a part number can have real consequences. This stage exists specifically to catch those errors.

Terminology consistency. The reviewer checks that the agreed glossary has been followed throughout. In a long document, it is easy for a translator to use two different terms for the same component — both technically correct, but inconsistent. The reviewer identifies and resolves these.

Discrepancy resolution. Where the reviewer disagrees with a translation choice, the two linguists discuss and agree on the correct rendering. In cases where neither is certain — typically where the source text is itself ambiguous — the query is escalated to the client.

Typical duration: Roughly 50-70% of the time taken for translation. For a document that took four days to translate, expect two to three days for review and editing.

Stage 5: Formatting and Delivery

Translated text rarely drops neatly back into the original layout. This stage deals with the practical reality that different languages take up different amounts of space, read in different directions, and use different typographic conventions.

Desktop publishing (DTP). If the source document was created in InDesign, FrameMaker, or a similar layout tool, the translated text needs to be flowed back into the original template. This is skilled work — it requires someone who understands both the software and the typographic conventions of the target language.

Text expansion and contraction. Translated text is almost never the same length as the source. German and French translations of English source text typically run 15-25% longer. Finnish can be 30% longer. Chinese and Japanese often run shorter. This means tables may need reformatting, text boxes may overflow, and page breaks will shift. Each of these needs manual adjustment.

Right-to-left and complex scripts. Arabic and Hebrew read right to left, which means the entire page layout may need to be mirrored — columns, diagrams, flow charts, and navigation elements all reverse. Chinese, Japanese, and Korean use character-based scripts that require specific fonts and may need different line spacing. These are not cosmetic adjustments; they affect whether the document is usable.

Final format checks. Page breaks, image references, cross-references, figure numbering, headers, footers, and the table of contents are all checked. Hyperlinks are tested. Any index entries are verified. The document is compared against the source layout page by page to confirm nothing has been missed.

Delivery. The finished files are delivered in whatever format was agreed at the briefing stage — the same editable format as the source, a print-ready PDF, a bilingual document for internal review, or multiple formats if required.

Typical duration: One to three working days, depending on the complexity of the layout and the number of languages.

Stage 6: After Delivery

The project does not end at delivery. What happens next determines how smoothly future projects run.

Client review period. Most organisations have an internal review process where subject matter experts or in-country staff check the translation. This is sensible and encouraged. To be effective, feedback should be routed through a single named contact person rather than collected piecemeal from multiple reviewers with conflicting preferences.

Corrections and revisions. Any corrections identified during client review are processed and incorporated. Where the client disagrees with a translation choice, the reasons are discussed — sometimes the client’s preference is a house style choice, sometimes it is a genuine error, and sometimes the original translation was correct and the reviewer is mistaken. A good provider will explain the rationale rather than simply accepting every change without question.

Translation memory update. Once the final text is approved, the translation memory is updated with the confirmed versions. This is critical. It means that the next time similar content is translated, the approved terminology and phrasing are suggested automatically. Over successive projects, the proportion of new content decreases and leverage from memory increases. This is how translation costs reduce over time on recurring work.

Glossary update. Any new terms agreed during the project are added to the shared glossary and circulated.

What to Prepare Before You Start

The following will help your project start promptly and run without unnecessary delays:

Source files in editable format — Word, InDesign, FrameMaker, XML, DITA. Not scanned PDFs, not locked documents, not screenshots of text.
Complete content — no sections marked “TBC” or pending final engineering review. Translating a document that changes during the project means translating it twice.
Target language list with specific variants — e.g. Brazilian Portuguese, not just “Portuguese”; Simplified Chinese for mainland China, Traditional Chinese for Taiwan.
Any existing glossary or term list — even an informal one is better than none.
Previous translations of similar content — earlier versions of the same manual, related product documentation, anything that might provide useful translation memory leverage.
A named contact person who can answer technical queries promptly.
A realistic deadline — if you need it in five days, say so at the start, not on day four.

Typical Timeline

The following is an indicative timeline for a 10,000-word technical manual translated into three languages:

Day	Activity
Day 1	Brief received, quote issued
Day 2	Analysis and setup
Days 3-6	Translation
Days 7-8	Review and editing
Day 9	Formatting
Day 10	Delivery

This assumes complete source files, a clean brief, and no major technical queries. More languages add time for coordination and formatting, but the relationship is not a simple multiplication — much of the analysis, setup, and project management work is done once regardless of the number of target languages.

For context: a 10,000-word manual into ten languages on the same timeline would likely need twelve to fourteen working days rather than one hundred.