The Expensive Part of Multilingual DTP Isn't Only the Translation

A finished English layout existed in InDesign — a short quick-start guide, set cleanly, with a type hierarchy and a grid. It needed to exist in Japanese and German as well. The translations were already done. What remained was the part that actually takes the time: getting each language back into the layout.

That last step is easy to underestimate. It sounds like typing, or pasting. In practice it is where multilingual production quietly goes wrong, and the reason is worth stating plainly.

What Is Fixed, and What Varies

A multilingual document has a fixed part and a variable part. The design — the frames, the styles, the master pages — is fixed. The language is the variable. The job is to hold the first constant while changing the second.

Done by hand, that distinction collapses. Each language becomes a fresh layout task: select the text, replace it, then re-check every frame by eye. The design that was supposed to stay constant is now being re-touched three times, five times, once per language — and every touch is a chance to move something that was meant to stay put.

So the useful question is the same one I keep returning to in production work: which part is the source, and which part is derived? Here the layout is the source. Each language is a rendering of it. The text content is the only thing that should change.

Two Failures That Ship When You Reflow by Eye

Translating is the easy part precisely because a translation is just different words. The trouble is that the different words have two other properties the layout cares about.

The first is length. German runs longer than English — often much longer. The same sentence that fit a narrow column in English now overflows its frame. On screen the overflow is a small red +; in a shipped PDF it is simply missing text. Nobody decided to cut the sentence. It fell off the end of a frame that no one re-measured.

The second is script. Japanese set in a Latin font renders as tofu — the empty boxes □□□ that appear when the font has no glyph for the character. The text is correct; the font just cannot draw it.

Both of these are detectable properties of the swap, not matters of judgment. A frame either overflows or it does not. A font either has the glyphs or it does not. Which means they belong to the tool, checked at the moment the text is swapped — not to a human doing a final visual pass and hoping to catch them.

Swap the Content, Keep the Container

The approach that follows from this is a keyed swap. Every translatable frame carries a label — a key — and the translation table is keyed the same way:

key, en, ja, de
title, Quick Start Guide, クイックスタートガイド, Kurzanleitung zur Inbetriebnahme
intro, Thank you for ..., 本製品をお選び..., Vielen Dank, dass Sie ...

The script matches each frame to its key, replaces the text inside it, and re-applies that frame's paragraph style to the swapped text. The master pages and the paragraph-style definitions stay exactly as they were — they were never the variable. Where a language needs a different font — Japanese — the script applies it as a local override on the swapped text, leaving the style definition itself unchanged. This is the same shape as a TMS round-trip — extract, translate, reimport — done directly against the document.

And because the swap is the moment the new text meets the old frame, it is the right moment to check the two failures:

Overset is caught and reported. Every frame where the translated text no longer fits is written to a report, by language and by key. The overflow that a by-eye reflow ships becomes a line you read before you deliver.
A CJK font is applied automatically. For Japanese, the script finds an installed CJK font and applies it as a local override on the swapped text — the paragraph style itself is left as defined. If no CJK font is installed, that is flagged in the report rather than exported as broken output: a missing font is a note to fix, not a file you send.

The design — frames, master pages, and the style definitions — survives; the content is replaced, and for Japanese the font is overridden on that swapped text.

Two Ways to Run It

The same engine reads two ways, and which one you lead with depends on where the content lives.

One CSV in, every language out. Hand it a table (key, en, ja, de, …) and it lays out and saves each language as a finished document, plus the report. One data file in, a set of print-ready PDFs out.
On your own document, in place. Open your branded InDesign file, point the script at a language, and it swaps that layout where it stands — preserving your design. This is the real localization job: here is our brochure, we need it in five languages.

Where This Has Limits

Worth knowing before you lean on it:

Right-to-left is out of scope here. Arabic and Urdu need bidirectional layout handling that this proof does not attempt.
The swap is whole-frame, and it does not preserve inline formatting. Each keyed frame is replaced with plain text from the table, so local emphasis — a bold word, a character style on a single term, or several different paragraph styles inside one frame — does not survive the swap. A frame comes back in one paragraph style, with | adding further paragraphs in that same style. That is what keeps the behavior predictable, and it fits structured, one-field-per-frame content — a label, a spec line, a short guide — better than richly formatted running text. For the latter, an inline-aware swap that replaces phrases inside a run is the right next step.
Input is a CSV for now. Word and xlsx import are a natural next step, not part of this proof.
Terminology is a separate layer. Making the translation fit is this tool's job; making it use the approved terms is a different check. I keep that in a companion, a glossary/terminology checker, run on the copy before reflow.

None of these are blockers. They are the edges of a deliberately small proof, and knowing them up front is part of the point.

The Structural Takeaway

The layout is the source; each language is a rendering of it. Once you treat it that way — swap only the content, keep the container, and let the tool check the fit and the font at swap time — reflowing a document into another language stops being a fresh manual job and becomes a repeatable step. The translation was always the easy part. The value is in everything that has to happen after the words are ready.