The Technical Translation Quality Checklist: 25 Points Before You Sign Off

Why you need a translation quality checklist at all

A translation quality checklist exists for the same reason a pre-flight checklist exists: the failures that hurt most are the ones a competent person can miss on a tired Friday afternoon. Nobody forgets to translate chapter 3. People do forget that the German edition still shows a 120 V rating for a machine wired for 230 V, or that a safety warning moved to the wrong figure during layout.

Reviewers who rely on general impressions catch style problems. Checklists catch the other category: mechanical defects in numbers, codes, references, and formatting that read as "fine" unless you look for them deliberately. In technical content, that second category is where the liability sits.

The 25 delivery points below are the core of the list our own reviewers work from, adapted so a client-side documentation manager can run them without translation training. Around them sit three lighter phases. Skip those and the delivery check becomes an exercise in finding problems too late to fix cheaply.

Phase 1: Before translation starts

Most delivery-stage defects are planted before a translator opens the file. Five preparation items prevent the bulk of them:

• Freeze the source. Agree on a version number and stop editing it. A source that keeps changing mid-project guarantees mismatches between editions, and nobody will know which one is authoritative. Our guide on preparing technical documents for translation covers version control in detail.
• Approve a glossary first. Even 30 validated terms settle the arguments that otherwise surface at delivery. If you have no glossary, ask your vendor to extract candidate terms and have an engineer approve them. The terminology management guide explains what a useful entry looks like.
• Name the language variant in writing. Spanish for Mexico or for US crews, French for Quebec or France, Portuguese for Brazil or Portugal. "Spanish" alone is an unpriced decision someone else will make for you.
• State the style rules that matter. Formal or informal address, how to render the imperative in procedures, whether UI strings stay in English. Three lines of instruction beat three rounds of rework.
• Send editable files. A locked PDF forces reconstruction, and reconstruction introduces its own errors before translation even begins.

Phase 2: While the project runs

Two habits during production determine how clean delivery day will be. First, query management. A translator who sends questions is reading closely; a project with zero queries on 30,000 technical words deserves suspicion, not relief. Answer queries in one consolidated document, copy the engineer who knows the product, and keep the answers, because they apply to every future manual too.

Second, consistency control through the translation memory. Repeated warnings, repeated steps, and repeated captions must come out identical every time they recur. Ask your vendor how repetitions are locked and how the reviewer sees them. On our side this sits inside a broader quality assurance process with independent revision by a second linguist, but the principle holds whoever does the work.

A third habit costs nothing and prevents the expensive surprises. On any job above roughly 10,000 words, ask for the first 800 to 1,000 translated words as soon as they exist and have your in-country reviewer look at register and terminology only. Corrections applied at that point propagate through the rest of the project automatically. The same corrections requested at delivery mean touching every occurrence inside a finished layout, and paying for the layout twice.

Phase 3: The 25-point delivery checklist

Run these on the delivered target file with the source open beside it. Points 1–8 need no knowledge of the target language. A native speaker helps from point 9 onward but is only mandatory where noted.

1. Numbers match the source. Compare every figure: quantities, tolerances, pressures, model numbers. QA tools diff digits automatically; by hand, scan tables and specification lists first. Typical error: two transposed digits in a torque spec.
2. Units are converted, or deliberately not. Check that psi/bar, °F/°C, and inch/mm follow the agreed policy on every occurrence. Typical error: a value converted in chapter 2 but left imperial in chapter 7.
3. Decimal and thousands separators follow the target locale. 1,500 means one and a half thousand in Houston and one and a half in Hamburg. Spot-check every table. Typical error: separators converted in text but not in imported tables.
4. Hazard codes are untouched. H- and P-statements, GHS pictogram references, and risk codes are standardized text with fixed official wording per language. Verify codes against the source and wording against the regulatory phrase list. Typical error: a paraphrased P-statement that no longer matches the official text.
5. Part numbers, references, and codes stay in the source form. Item codes, drawing numbers, and standards designations (ASTM A106, DIN 912) must survive verbatim. Typical error: an overzealous find-and-replace altering a part number that contained a translated word.
6. Tags and placeholders are intact. In files from XLIFF, JSON, or CAT workflows, {0}, %s, and formatting tags must appear once each, unbroken. Typical error: a placeholder deleted because it "looked like clutter."
7. Nothing is left untranslated. Scan for source-language sentences, especially in text boxes, callouts, and chart labels that sit outside the main flow. Typical error: an untranslated warning inside a graphic.
8. The document is complete. Compare section counts, table counts, and appendices against the source. Typical error: a final appendix dropped when the file was split between translators.
9. Terminology matches the approved glossary. Search five or six critical terms and confirm the approved rendering appears everywhere, with no rogue synonyms. Typical error: two translators, two different words for the same valve.
10. Repeated segments are identical. Pick a recurring caution and search for it. Every instance should match to the character. Typical error: three near-identical phrasings of the same lockout warning.
11. Headings match the table of contents. Compare wording between chapter titles and TOC entries. Typical error: a heading edited after the TOC was generated.
12. The TOC and index are regenerated, with live page numbers. Text expansion shifts pagination, so a copied TOC lies. Typical error: TOC pointing to the source document's page numbers.
13. Cross-references resolve. "See section 4.2" must point at the section it named in the source, and hyperlinks must open. Typical error: dead links after files were renamed for the target language.
14. Figure captions and callouts sit with the right figures. Layout reflow separates captions from images more often than anyone expects. Typical error: captions for figures 12 and 13 swapped.
15. Text inside images is handled. Screenshots, diagrams, and labels either carry translated text or a numbered legend, per the agreed approach. Typical error: a wiring diagram delivered with source-language labels and no legend.
16. Tables have not overflowed. Longer target text pushes cell content out of view or onto stray pages. Page through every table. Typical error: a truncated final column that still looks complete.
17. Line breaks and hyphenation follow target-language rules. Bad breaks in warnings can change reading order. Typical error: English hyphenation rules applied to German compounds.
18. Punctuation and typography match the target locale. Quotation marks, ordinals, list punctuation, and required spaces before French punctuation. Typical error: English quotation marks throughout a French manual.
19. The language variant is consistent. One document should not mix Iberian and Latin American Spanish. A native reviewer scans vocabulary and address forms. Typical error: tú and usted alternating between chapters.
20. Dates, times, and phone formats are localized. 03/04/2026 is March 4 in the US and April 3 in most target markets; write dates unambiguously. Typical error: a maintenance interval misread because of date order.
21. Safety warnings use the target market's signal conventions. Danger, warning, and caution levels must map to the target standard's severity wording, consistently. Typical error: WARNING and CAUTION collapsed into one word, flattening severity. This check needs a native speaker.
22. Headers, footers, and page furniture are translated. Running titles, revision blocks, "Page X of Y," and watermark text hide from every reviewer who only reads body text. Typical error: a source-language DRAFT watermark in the released file.
23. Fonts render the target script. Missing glyphs become empty boxes, and some fonts silently substitute. Check accented characters, CJK text, and anything in bold-italic. Typical error: tofu squares in a Chinese header nobody opened.
24. Deliverables match the order. File formats, naming convention, one file per language, plus the certificate of accuracy if requested. Typical error: a print PDF delivered where the contract said editable InDesign package.
25. The final PDF is proofed as a PDF. Export, then page through the actual deliverable, because errors appear at export that never showed in the working file. Typical error: an approved layout whose exported PDF dropped a font.

Sort what you find before you send it back

A completed pass usually produces a mixed list: two wrong numbers, eleven comma preferences, a table that overflows, and one term an engineer dislikes. Sending all of it back as a single undifferentiated list wastes a revision cycle and buries the item that actually matters. Sort your findings into three classes before the email goes out.

Class	What belongs here	Who fixes it	Cost of shipping it
Defect	Wrong number or unit, missing warning, altered hazard code, omitted section, broken placeholder	The vendor, at no charge, under the correction warranty	Safety, warranty, or audit exposure
Deviation	A term that departs from the approved glossary, inconsistent repeated strings, wrong language variant	The vendor, with the termbase updated so it stays fixed	Engineers stop trusting the document
Preference	A synonym your reviewer likes better, sentence order, house style that was never written down	You, by adding the rule to the style guide for next time	Mild irritation, nothing more

The distinction protects both sides. Defects and deviations belong to the vendor and should come back corrected quickly, with the memory and termbase updated so the fix survives the next revision. Preferences are legitimate, but they are new instructions rather than errors, and treating them as errors turns an acceptance review into a negotiation. Reviewers in a market office who have never been told the difference default to rewriting, which is why a first project with a new subsidiary often generates several hundred comments and the third generates a dozen.

One rule is worth printing on the review form itself: every finding needs a location and a proposed fix. "Chapter 6 sounds odd" cannot be actioned by anyone. "Page 63, step 4: use the glossary term for disconnect" can be applied in seconds and verified in seconds.

Phase 4: After delivery

The checklist only compounds in value if findings flow back. Log every defect with its category (number, terminology, layout, omission) and its phase of origin. A wrong unit traced to an ambiguous source sentence is a Phase 1 fix, not a translator problem. Send field feedback from operators and in-country staff to your vendor so the translation memory and termbase get corrected; otherwise the same defect returns in the next revision, at 100% match, wearing a mark of confidence.

When errors cluster in style or terminology rather than mechanics, that usually points to review depth rather than translation quality, and a dedicated technical editing and proofreading pass is the cheaper remedy. And if you are checking a long-lived document such as an operator manual, remember that revisions inherit defects: a checklist finding fixed only in the PDF will resurface from the memory. That pattern shows up constantly in user manual translation, where v3 quietly republishes a v1 mistake.

One honest note on scope. This list verifies the translation you received. It cannot verify that the source was correct, and a good reviewer will occasionally hand you a query that says the original is wrong. Treat those as free engineering review. If you would rather have all four phases run for you, with a second linguist and tool-based QA already built in, request a quote and mention which checks matter most for your document.