Translation coverage is the share of the source file's actual content that reached the translated output, and it is a different question from accuracy. A file can be graded excellent on every sentence it produced and still be missing speaker notes, a text box, a hidden worksheet or a header — because those objects were never extracted for translation in the first place. Coverage is checked by reconciling object-level counts between source and target, not by reading the translation.
This is the failure mode nobody scores. Reviewers compare what is in front of them; they do not compare it against what should have been in front of them. As of September 2026, every major automatic metric, and most human review workflows, share the same blind spot: they evaluate the segments that exist and say nothing about the segments that never arrived.
Coverage Is a Separate Question From Quality
Quality frameworks do name this. The MQM error typology places Omission under Accuracy and defines it as content present in the source that is missing in the target — a paragraph in the original with no counterpart in the translation. So the category exists.
The problem is procedural, not definitional. An MQM scorecard is applied to a set of segments, and a segment that was never created cannot be scored. If the extractor skipped a slide's notes pane, the reviewer receives a job containing no notes, marks the slides they were given, and returns a clean sheet. The omission is invisible at exactly the point it was supposed to be caught.
That is why coverage needs its own check, run before linguistic review rather than inside it. Two documents, two counts, one comparison. Everything below is a way of making that comparison specific enough to be useful.
Where Text Hides in an Office File
Open a DOCX, XLSX or PPTX and you are looking at a ZIP container of XML parts, structured by ECMA-376, the Office Open XML standard. The visible body is one part among many. Text also lives in:
PowerPoint: the notes slide, the slide master and layouts, grouped shapes, SmartArt data, chart titles and axis labels, hidden slides, and any text frame sitting behind an image.
Word: headers and footers, footnotes and endnotes, text boxes, comments and tracked-change balloons, content controls, captions, alt text, and index or TOC entry fields.
Excel: hidden sheets and hidden rows, cell comments and notes, chart labels, data-validation prompts and error messages, custom number formats containing literal words, and defined names.
PDF: annotations, form field values and their tooltips, bookmarks, and the tag tree that PDF/UA uses for structure.
Each of these is a separate code path in an extractor. Support for one implies nothing about support for the next. A tool can handle Word footnotes perfectly and silently ignore text boxes, because they are different parts of the package read by different code.
Why Extraction Is Where Content Disappears
It helps to separate the three stages of a document translation job, because only one of them is about language.
Extraction walks the file and pulls out translatable strings. Translation converts those strings. Reconstruction writes them back into the original structure. A model that mistranslates a clause produces a visible error a reviewer can catch. An extractor that never reaches the notes pane produces no error at all — it produces silence, and silence passes review.
This is also why the omission is stable rather than random. If a tool does not read grouped shapes, it will miss them in every deck, every time, in the same way. The defect is a property of the tool, not of the document — which means a single well-built test file characterises the behaviour once and predicts it thereafter. Coverage is a format-engineering problem, not a model-quality one: the strings an engine never sees cannot be scored by any metric applied to it.
The Count Reconciliation That Catches Most of It
The cheapest useful check is a structural diff. Take the source and the target, count the same things in both, and look at the difference. In practice:
Object | Expected relationship |
|---|---|
Slides / pages / sheets | Identical count |
Text frames per slide | Identical count |
Notes slides containing text | Identical count |
Footnotes and endnotes | Identical count |
Header and footer parts | Identical count |
Comments | Identical count |
Non-empty cells per sheet | Identical count |
Characters per object | Ratio inside the expansion band for the language pair |
Counts are exact; character volumes are not. Translated text expands or contracts predictably by language pair, so a per-object character ratio should sit inside a band rather than hit a number. What you are hunting is an object whose ratio is near zero or exactly 1.00 — near zero means the content vanished, and exactly 1.00 across a whole object usually means the source string was copied through untranslated.
Run this per object, never per file. A document-level character total will absorb a missing notes pane without moving enough to notice, which is precisely how these defects survive to the client.
What a Count Check Will Not Catch
Reconciliation has real limits, and it is worth being honest about them.
It cannot see text baked into a raster image. A diagram exported as PNG and dropped into a deck carries no extractable string, so source and target agree perfectly and both are wrong. That is an OCR question, and OCR accuracy varies sharply by document condition, so it needs handling as its own stage.
It cannot see content the source file was already hiding from you. White text on a white background is not flagged as hidden by Word's Document Inspector, which only detects content explicitly formatted as hidden. The same gap matters when translating a redacted PDF, where a burned-in black box and a removed text layer behave very differently.
And it cannot judge whether a partially translated object is acceptable. A table where nine cells translated and one did not will show a plausible character ratio. Only a per-cell comparison finds that, which is why the granularity of the check matters as much as the check itself.
Building a Canary File
The most efficient way to characterise a tool is to build one small document that contains every object you care about, once each, with a distinctive marker string in each — then translate it and read the output.
A good canary deck runs to three or four slides and includes a notes pane, a grouped shape, a SmartArt block, a chart with a title and axis labels, a hidden slide, a text frame behind an image, and one master-level element. The Word equivalent covers a header, a footer, a footnote, a text box, a comment, a tracked insertion and a caption. The Excel equivalent covers a hidden sheet, a cell comment, a chart label, a data-validation prompt and a custom number format containing a word.
Then translate into a language whose script you can distinguish at a glance — Greek, Japanese or Arabic all work — and look for anything still in the source script. It needs no linguist, and it produces a permanent, reusable statement about what a tool does and does not read. Re-run it after any vendor version change.
The Coverage Questions Worth Asking a Vendor
Procurement questionnaires ask about languages, formats, security and price. They rarely ask what is actually read inside a supported format, which is where the variance lives.
Four questions separate implementations quickly. Which objects inside each supported format are extracted, enumerated rather than summarised as "full support"? Is there an output that reports what was extracted, so coverage can be verified without opening the file? What happens to an object the pipeline cannot process — is it passed through untouched, dropped, or flagged? And is the same answer true through the API as through the web interface, since pipelines and interactive uploads are frequently different code paths?
"Supports PPTX" is not an answer to any of these. The American Translators Association's review guidance makes the same point from the reviewer's side: text hides in tables and text boxes and behind graphics, and the reviewer remains responsible for it either way.
Where Coverage Failures Actually Cost Money
The consequence is rarely embarrassment about a stray English word. It is that the missing content was load-bearing.
A regulatory submission whose footnotes carry the qualifications on every claim in the body. A financial statement where the notes — not the statements — hold the accounting policies. A supply agreement whose liability cap sits in a schedule that arrived as a separate header part. A training deck where the speaker notes are the actual course content and the slides are just headings. In each case the visible page reads perfectly and the substance is gone.
There is also a rework cost that compounds quietly. When an object is missed, somebody translates it by hand and pastes it back — which reintroduces the manual reformatting step the automation was bought to remove, and routes the document through a person who was not in the original workflow. The saving evaporates in the correction.
Related Reading
Does Translating PowerPoint Break Speaker Notes and Animations?
Does Translating a Document Break Headers, Footers and Page Numbers?
Translate Document Footnotes and Endnotes While Keeping Formatting
Sources and Further Reading
MQM error typology — the Omission error type under Accuracy — the standard definition of content present in the source and missing in the target.
ECMA-376, Office Open XML file formats — the specification describing how DOCX, XLSX and PPTX split content across separate package parts.
Microsoft Support: customize a slide master — how master- and layout-level text sits outside individual slides.
Microsoft Support: Inspect Document — including the limitation that it only detects content explicitly formatted as hidden.
PDF Association: ISO 14289 (PDF/UA) — the structure and tagging layer that carries content a visual read of a PDF will not surface.
American Translators Association: How to Review a Translation — reviewer-side guidance on text hidden in tables, text boxes and behind graphics.
r/powerpoint — "How do you translate a PowerPoint deck without losing the formatting?" — a practitioner thread showing people discovering deck-level objects were skipped only after delivery.
Check coverage on your own files. Bluente translates DOCX, XLSX, PPTX and PDF across 120+ languages and reconstructs the original structure rather than rebuilding it — so run your canary file through it and see what comes back. Start with BluTranslate, or talk to the team about coverage reporting on an API pipeline.
Last reviewed 17 September 2026. Written by the Bluente document engineering team, who build and test the extraction and reconstruction pipeline described above. We update these guides when the underlying standards, regulations or file formats change.