Our Translation Quality Assurance Process

What Quality Assurance Actually Controls on a Technical File

Ask five agencies what their quality assurance covers and most describe reading the text a second time. Our definition is narrower. Each pass has one declared target, one name attached to it, and a gate to clear before the file advances. Verifying terms against a locked termbase is a different cognitive task from matching figures to the source, and asking one person to do both in the same read is how mistakes survive.

Technical documents fail in predictable places: numbers, units, tolerances, cross-references, hazard statement codes, part numbers, callout labels tied to a figure that sits three pages away. The prose can read beautifully while a torque value is off by a factor of ten. Sequencing the checks so each one has a single target is the whole design of what follows.

The Seven Checkpoints in Our Translation Quality Assurance Chain

The table below is our production checklist, simplified for reading. Each row names what is being controlled and what has to be true before the file passes to the next hand.

Checkpoint	What is controlled	Gate before the file moves on
1. File analysis and preparation	Scope, segmentation, non-editable text, source defects	Every string extractable, word count agreed
2. Termbase and glossary build	Key terms, do-not-translate items, approved variants	Term list validated, or review declined in writing
3. Translation by a native specialist	Meaning, register, target-language convention, safety phrasing	Every open query closed
4. Independent revision	Accuracy against source, omissions, term compliance	Second linguist signs the bilingual file
5. Tooled QA checks	Digits, units, tags, spacing, inconsistent segment pairs	Each flag fixed or logged as a false positive
6. Layout and format inspection	Pagination, tables, figure callouts, contents list, expansion	Target renders the way the source renders
7. Release	Deliverable set, file naming, memory and termbase update	Package matched against the order

Checkpoint one is the least glamorous and saves the most time. A scanned PDF with text baked into images, a Word file where half the headings are manual bold rather than styles, a spreadsheet stuffed with plant abbreviations nobody outside that plant has seen: all of it surfaces before a translator opens the file. Anything ambiguous in the original travels back to you with the analysis.

Checkpoint two decides consistency for the whole project, often for the account. Terms are extracted from the source, matched against material you already own, and written into a termbase with a definition, a context sentence and a field for rejected alternatives. Our terminology management work makes the reviser's job objective: a term either matches the entry or it does not, and nobody argues about taste at nine in the evening.

Checkpoint five is where software takes over. Xbench and Verifika run rule sets rather than judgment, flagging digits that changed between source and target, tags dropped from a segment, doubled spaces, identical source segments rendered two different ways, and terms used against the termbase entry. Perhaps a third of what they raise is noise, and a human clears each flag by hand. The value sits in the two thirds that are real.

Checkpoint six is where text expansion shows itself. German typically runs 25–35% longer than English, so a two-line warning becomes four lines that push a table cell past its border or drive a callout into a drawing element. Files with no page layout, such as spreadsheets covering the technical document types we handle or software string tables, get a structural pass for broken references and truncated fields.

How We Follow the ISO 17100 Translation Process

ISO 17100 is the international standard for translation services. It sets requirements a buyer can verify: who is allowed to work on a file, which steps the service must include, and what records survive the project. Techniwords follows ISO 17100 as its production framework. We are not audited against it by a certification body, and we say so plainly, because a vague quality badge is easy to print and hard to check.

On competence, the standard describes qualifying routes: a degree in translation, a degree in another field plus documented professional experience, or a longer stretch of documented experience alone. Most of the linguists who handle your files arrive through the second and third routes, with engineering degrees or years on a plant floor behind them. Each keeps a competence file holding diplomas, certifications, sector history, and the revision record of recent projects.

On process, the standard requires that somebody other than the translator compare target against source. That is the part certain vendors quietly price as an option. For us it is the default, staffed by revisers who also translate in the same field, the same pool our editing and proofreading service draws on when a client brings in an existing translation for repair. On traceability, we retain the source, the delivered target, the term decisions, the query record and the reviser's identity for every project, and any of it can be produced on request.

Why an Independent Reviser Catches What Self-Review Misses

A translator who has spent two days inside a maintenance manual stops reading the words on the page and starts reading the sentence they meant to write. No amount of professionalism removes that limit. Re-reading your own work after a night's sleep helps a little; it does not come close to a second pair of trained eyes.

The reviser arrives with none of that history. Same sector, same language pair, different head, working segment by segment with source and target side by side. What they find falls into recognizable categories:

• A negation dropped from a warning, so "do not energize the panel" becomes an instruction to energize it.
• A modal softened in transit, where "must" arrives as "should" and a mandatory step reads as advice.
• A term that drifted between chapter 2 and chapter 9 because the file was translated across a weekend.
• An ambiguous source sentence resolved the wrong way, plausible on its own and wrong against the diagram.
• A unit converted where it should have stayed put, or left alone where the target market expects metric.

Revisers also catch defects already present in your original: a step numbered twice, a figure reference pointing at nothing, an obsolete part number carried forward from an earlier revision. Those come back as a separate note rather than being silently corrected, because your English master needs the same fix and only your team can approve it.

When Something Reaches You Anyway

Sometimes it does. A process that pretends otherwise is selling confidence rather than describing itself. What matters is the next 48 hours:

1. You send the file with the passages marked, or simply describe the problem in an email.
2. We correct the confirmed items and return the file, same or next business day for a short document.
3. The project manager traces where it entered the chain: source ambiguity, a missing term entry, a reviser oversight, or a file-handling step that dropped content.
4. The fix goes into the memory and the term entry, so the next project on that account inherits it.
5. If assignment was the cause, the linguist profile for that account changes and the reason is recorded.

Preferences get handled differently. If your engineer wants "housing" where we used "casing" and both readings are defensible, that is a terminology decision rather than a defect. It goes into the termbase, applies across the account from then on, and skips the analysis above. Keeping the two categories apart stops a correction log turning into an argument.

Memory and Termbase: Consistency Between Projects, Not Only Inside One

Consistency within a single document is a solved problem for any competent linguist. The hard case is the operator manual translated in 2023, revised in 2026 by a different person, sitting alongside a training deck and a set of machine labels that all have to say the same thing. Our translation memory work keeps every approved segment pair retrievable, so a sentence you validated three years ago comes back identical instead of being rewritten.

The termbase does the same job at word level and carries the reasoning: why this rendering was chosen, which alternative was rejected, who approved it and when. Both assets belong to the client and are handed over in standard formats whenever asked. Where a passage carries regulatory or clinical weight, we add back translation and reconciliation on those sections alone, so your reviewers read the target meaning in English without paying for it across a whole manual.

The Quality Numbers We Watch Internally

We do not publish a defects-per-thousand-words figure. Any vendor quoting one is grading its own homework with its own rubric, and the number tells you nothing you can verify. What we track internally is more mundane and more honest.

We watch how heavily revisers edit each translator, because a change rate climbing on a given pair is an early signal worth a conversation before a client notices anything. We count client-reported items per quarter and, more to the point, whether the same cause repeats. We measure how long a correction takes to close. And we log how often a project needs a second corrective round, rare enough that each instance gets read by two senior people. Trend beats absolute value here. To see where these controls sit in the wider timeline, the full project workflow lays out the client-facing stages, and you can ask us to price a document set whenever you are ready.