Comparing InDesign Files After Translation: What to Check

A document goes out for translation as an InDesign file and comes back as an InDesign file. In between it went through a translation workflow: exported to IDML (InDesign's interchange format, a ZIP of XML files), split into segments, translated, reassembled. The question that follows is simple to ask and harder to answer than it looks: is everything still there?

In the forum threads I reviewed, two answers recur. Export both versions to PDF and use Acrobat's comparison. Or switch on Track Changes before the edits happen. Each does what it says. Neither, on its own, answers the structural question, and the reason tells you what the check has to look at instead.

What "compare" means after translation

When you compare two versions of a same-language document, you are looking for edits: a sentence changed here, a paragraph deleted there. The text is mostly identical, and the differences are the signal.

After translation, text differences are expected. What you actually want to know is whether the structure the translation was poured back into still matches the one you sent out. Concretely, six things:

Are all the stories still there, and does each still contain text? (A story is a continuous flow of text; it can run through several linked text frames.)
Do the tables still have the same number of rows and columns?
Does each story still have the same number of footnotes?
Does each story still have the same number of anchored objects — figures, callouts, inline frames?
Are the paragraph styles that were in use in the source still in use in the target, and vice versa?
Is any of the text not different — a paragraph, a footnote, a table cell that still reads in the source language?

None of these is about how well the translation reads. They are about whether the container survived the round trip, which is a separate check from linguistic review.

PDF comparison, Track Changes, CAT comparison, and direct IDML inspection each reveal different evidence and leave different structural questions unresolved.

What a PDF comparison shows

Acrobat's Compare Files compares the rendered appearance and the extracted text of two PDFs. Run it on a source PDF and a translated PDF and the report will be dominated by the text differences you already expect, and layout changes from text expansion add to them. The six questions above are not what the report is organized around, and a missing footnote is one difference among many.

There is also a quieter limit. Overset text is not included in the exported PDF. A PDF comparison therefore does not inspect that text.

What Track Changes shows

InDesign's Track Changes records edits made inside InDesign after it is switched on. It answers "what did the editor change in this file". It does not record what happened to the text while it was outside InDesign, and switching it on after the file comes back records only what you do next.

What the CAT tool shows

A third route that experienced operators use: load both files into the CAT tool and let the translation memory find segments that are identical between source and target. This is useful for question 6, untranslated text, and it works at the segment level.

What appears in the extracted bilingual data depends on the filter settings. Footnotes, for example, can be excluded. In the XLIFF (a bilingual data format used in translation workflows) generated by the Okapi round trip I tested, I found Story, Cell and Footnote tokens, but no occurrences of TextFrame, Table, Row, ParagraphStyle or Self=. That observation applies to that output; it does not establish what every CAT tool or every XLIFF file can represent.

Before you start: which two files

Identify the source version you sent out and the returned version you want to check. Record whether the returned IDML was subsequently opened in InDesign and exported to IDML again — for example, after layout fixes.

This matters because of what happened to object identity in my tests. InDesign assigns every object an internal ID. In the three documents I tested through Okapi, those IDs survived the translation round trip; when the returned IDML was then opened in InDesign and exported to IDML again, the IDs I had recorded were no longer present. In the same tests, labels I had added to the objects myself before export survived both stages.

Whatever the state of your files, the rule for the check is the same: for each item, record whether you could establish which object in the target corresponds to which object in the source. If you could not, mark that item as could not be compared.

A checklist you can run by hand

Record the outcome for each object or check performed, not one result for the whole document. Three outcomes: matched for a value you checked and found equal; differed for a difference you established; could not be compared when you could not establish the correspondence or complete the check. Keep the third separate from a clean result.

The practical way to do this without a tool is to read the IDML directly. An IDML file is a ZIP archive: copy it, rename the copy to .zip, and extract it. Inside, the Stories/ folder holds one XML file per story, named after the story's internal ID (for example Story_u195.xml). The checks below involve reading these XML files in a text editor with find-in-files. They cover values you can inspect directly; where the correspondence between objects or the counting unit is unclear, record could not be compared. The search strings match the formatting of the IDML pair I inspected; check the element formatting in your own files before relying on search counts.

Stories. Compare the list of file names in Stories/ between the two archives. In the Okapi pair I inspected before any re-export, all eight story file names matched, and I used them to pair the stories in that test; do not assume the same for another workflow. After a re-export, the story IDs I had recorded were no longer present in my three tests, so the file names had changed as well. If you cannot establish the correspondence, record the stories as could not be compared. Record a file name present on only one side as a difference in the file list; it does not by itself establish that a story was lost. For each story you can pair, inspect the text inside its <Content> elements. If the source contains text and the target contains none, record a difference. The presence of a <Content> element alone is not a check that the story contains text; in my sample, an emptied story still had the elements, with nothing inside them.
Tables. In each paired story, find each <Table element. Its attributes HeaderRowCount, BodyRowCount, FooterRowCount and ColumnCount give the counts. Compare them only after establishing which table in the target is the counterpart; do not use the order of appearance alone as proof, since one missing table shifts everything after it. Record tables present on one side only separately, and tables you cannot pair as could not be compared.
Footnotes. In each paired story, count the <Footnote elements and compare.
Anchored objects. In each paired story, count the <AnchoredObjectSetting elements and compare. Each anchored or inline object carries one of these elements; in my sample, a story with one anchored frame in the source and two in the target showed one and two of them. I have not tested a file with an anchored group, so if your file contains one and the count is unclear, record this check as could not be compared.
Paragraph styles. Across all story files in each archive, collect the distinct values of AppliedParagraphStyle="…". These are the styles actually applied, as opposed to the styles merely defined in the document. Note any value present on one side only.
Untranslated text. This is a spot check, not a comparison, and the three outcomes above do not apply to it. Choose a few source-language strings you have confirmed were meant to be translated, and search for them in the target's story files. Record the strings searched and any candidates found; a hit is a candidate to check in context, and no hits do not establish that the file contains no untranslated text. Where I automate this check, I apply a word-count threshold; text below that threshold is outside the check, including any untranslated text it may contain, and the method does not work for languages without word spaces.

These checks cover counts, style use and a spot check for untranslated text. They do not establish that every footnote or anchored object is still attached at the same place in the text; that requires a finer comparison than counts. If you need that, treat items 3 and 4 as a first pass, not a conclusion.

I am developing a tool for comparing the structure of two IDML files. Its report distinguishes items it compared from items it could not compare. The current trial and the testing request are in a separate post.

After translation, text differences alone do not tell you whether the document's structure survived. The review also needs to cover stories, tables, footnotes, anchors, styles, and possible untranslated text.