Multilingual Desktop Publishing: What Happens to Your Documents After Translation
Multilingual desktop publishing is the work that turns translated text back into finished documents: typesetting each language in the original layout, fitting longer or shorter text, handling other scripts, fonts and line-break rules, and checking every page before print or publication. DEMA Solutions does this in the source files, so each revision costs less and your translation memory stays clean.
Who this guide is for
This article is for the people who sign off manuals, catalogues, labels and leaflets in fifteen or twenty languages: technical documentation managers, technical writers, localisation managers and the quality teams behind them, usually at manufacturers of complex equipment whose documents are built in InDesign, FrameMaker, Word or an XML publishing chain.
It picks up where translation ends. Preparing files before translation, such as converting a PDF or a legacy layout into something translatable, is a separate job, covered in our guide to preparing files before translation. Here the question is what happens once the translated text comes back, and how to make that step predictable, checkable and cheaper on every revision.
What multilingual DTP actually involves
Multilingual DTP is not graphic design. A designer creates a layout; a DTP specialist makes that layout work in another language without changing what the document says or how it is meant to be used. The job is part typesetting, part engineering and part proofreading, and it sits between the translator and the printer or web team.
In practice, desktop publishing translation means importing the approved translation into the original files, reflowing text, applying the right language settings and fonts, adjusting tables and callouts, rebuilding cross-references and indexes, and exporting the outputs you need. Each step can fail in ways a reader notices at once: a warning split across two pages, a German compound broken in the wrong place, a part number wrapped onto two lines.
The most important decision is where the work happens. Layout handled in the native source files can be updated and reused for years; layout patched into a PDF starts from zero at every revision. That choice drives cost far more than the hourly rate, as we explain below.
Text expansion and contraction
Translations rarely occupy the same space as the source. Text from English into German, Finnish, French or Italian usually runs longer, sometimes much longer in short strings such as table headings, button labels and callouts, where a single English word can become a long compound or a phrase. Chinese, Japanese and Korean take fewer characters, but often need more line height and generous spacing to stay legible. The effect is never uniform: a paragraph may grow modestly while a two-word label doubles.
Good multilingual typesetting absorbs this without changing the document. The tools are well known: frames that grow with their content, paragraph and character styles instead of manual formatting, controlled adjustments to tracking and word spacing within agreed limits, and, where the design allows, small changes to column widths or image sizes. What a DTP specialist should never do is shrink the type in one language until it is no longer comfortable to read, or cut text to make it fit. In safety and regulatory content, legibility is a requirement, not a preference.
The best protection starts upstream: layouts with room to grow and no text burned into images cost far less to localise, so involve your DTP supplier when you redesign a template.
Fonts and scripts: Latin, Cyrillic, Greek, CJK and right-to-left
A font that works perfectly in English may not contain the characters a target language needs. Central European languages need diacritics such as Polish ł and ą or Czech ř and ů; Romanian needs ș and ț with a comma below, not a cedilla; Bulgarian, Russian, Serbian and Ukrainian need Cyrillic; Greek needs its own alphabet and accents. When a glyph is missing, layout software substitutes another font or shows an empty box, and the error is easy to miss on screen if nobody reading the page knows the language.
Corporate fonts are also licensed, and the licence must allow PDF embedding. For scripts your brand font does not cover, choose a matching companion family once, have it approved and record it so every language uses the same choice.
Chinese, Japanese and Korean bring different rules. Lines can break almost anywhere, but certain characters may not start or end a line; punctuation is full width; emphasis is not done with italics; vertical spacing differs. Right-to-left languages such as Arabic and Hebrew go further: the whole page is mirrored, with text, columns, tables and often the reading order of images reversed, while numbers, part codes and embedded Latin words still run left to right inside the right-to-left text. Arabic letters change shape according to their position in a word, so text pasted into a layout engine that does not support the script falls apart into unconnected letters. Handling these languages needs a correctly configured layout environment and someone who can read the result.
Line breaks, hyphenation and typographic rules per language
Every language has its own conventions, and layout software applies them only if each paragraph is tagged with the correct language. Hyphenation dictionaries differ: German compounds must break at meaningful points, Dutch and Scandinavian languages have their own rules, and some languages are better left unhyphenated in headings and warnings. French typography puts a non-breaking space before colons, semicolons, question and exclamation marks; Spanish opens questions and exclamations with inverted marks; quotation marks change from language to language. In Greek, words set in capitals normally lose their accents, and in Turkish the capital of i is İ, so an automatic “all caps” style can produce wrong text if it is not language aware. Thai has no spaces between words, so line breaks depend on a dictionary rather than on spacing.
A manual that ignores these rules looks foreign to its users and, in safety content, is harder to read. Machine checks miss these errors and a native linguist sees them at a glance, which is why the final review has to happen on the laid-out pages.
Tables, callouts and technical illustrations
Technical documents are dense with elements that do not reflow gracefully. Spare parts tables with narrow columns, technical data sheets, wiring and pneumatic diagrams, exploded views with numbered callouts and screenshots of the machine interface all carry text that must stay aligned with the graphics around it.
Tables need column widths that survive longer headings without breaking part numbers or units across lines. Callouts are best kept as live text in the layout or in editable vector files; text flattened into images has to be recreated by hand in every language and often drifts from the body text. For interface screenshots, decide whether to show the translated interface or the original with translated captions, matching how the machine is delivered in that market, and apply the choice in every manual.
Units, decimal separators and number formats deserve their own check. A torque value or a tolerance that loses a decimal place in layout is far more serious than a typographic flaw.
Safety signs and warnings
Warnings are where layout and liability meet. Safety messages in technical documentation usually follow a fixed structure: a signal word, a hazard symbol, a description of the hazard, its consequence and how to avoid it. Graphical symbols commonly follow ISO 7010, and the ISO 3864 series sets the principles for safety colours and sign design. The translated version must keep that structure intact: the signal word in the correct, consistent term for each language, the symbol beside the right text, the warning on the same page as the step it relates to, never orphaned after a page break.
For machinery, the instructions and the safety information they contain must be supplied in the language or languages required by the Member State where the machine is placed on the market or put into service, a principle the Machinery Regulation (EU) 2023/1230 keeps when it applies from 20 January 2027. Our article on what the Machinery Regulation requires for translated instructions covers the detail. For layout teams, the practical point is simple: safety content should be built from approved, consistently translated building blocks, and a DTP specialist should never edit the wording of a warning to make it fit.
Page count changes, cross-references and indexes
When text grows, pages move. A manual that is 200 pages in Italian may need extra pages in German, and everything that refers to page numbers moves with it: the table of contents, “refer to page” references, figure and table numbering, running headers and footers, and the index. If cross-references were typed as plain text in the source, every one of them has to be found and corrected by hand in every language. If they were built as live references, the layout software updates them, and the DTP check becomes a verification rather than a repair.
Print adds constraints: a saddle-stitched booklet needs a page count in multiples of four, and some manuals have a page count fixed by the printer or the packaging, so blank pages, spacing or different page counts per language must be agreed in advance.
Indexes are a small but telling detail. Terms must match the body text and be sorted by each language’s rules: in Swedish, å, ä and ö come at the end of the alphabet, and Cyrillic and Greek indexes follow their own alphabets. An index in English order in a Swedish manual shows that nobody checked.
Regulatory layouts: labels, leaflets and packaging
Some documents have fixed space and layout rules set by regulation. Medical device labels and instructions must be legible and comprehensible to the intended user, as our guide to EU MDR labeling requirements explains. Chemical hazard labels under the CLP Regulation have minimum sizes for the label and its pictograms. Multilingual labels and package leaflets for several countries must carry all required languages in a fixed area, which often means careful negotiation between text length, type size and the number of languages per panel.
The order of languages, the minimum type size, the position of symbols and the fields that must never change, such as lot numbers, UDI carriers or dates, belong in a layout specification applied to every language, so nobody solves a space problem by quietly shrinking the Hungarian panel.
Multilingual QA: linguist checks in layout
Layout quality can only be checked on the finished pages, so a sound process has two reviews after typesetting.
The first is a technical check by the DTP team: every page compared with the source for missing or overset text, fonts, images, styles, cross-references, numbering and units, and the outputs tested against the print or digital specification. The second is a qualified linguist reading the laid-out pages in context, which is where wrong hyphenation, truncated table cells, misplaced captions and orphaned warnings are caught.
Corrections made at this stage must go back into the translation memory, not only into the layout. If a linguist fixes a sentence directly in the InDesign file and the memory is not updated, the next revision will bring the old, uncorrected sentence back, and someone will pay to fix it again. Our article on checking a supplier’s quality before you hire them lists the questions to ask about this step.
Why layout in the source files keeps your memory clean and cuts revision costs
This is the part of multilingual DTP that procurement rarely sees and that matters most over a document’s life. Your translation memory reuses approved sentences at every revision, but only if those sentences are clean and complete.
Layout shortcuts break this. Forced line breaks, manual hyphens and extra spaces inserted to make text fit end up inside the translated segments, so the next time the same sentence appears it no longer matches exactly. Text split across separate frames or table cells becomes fragments that a translator has to translate without context. Changes made only in the layout or in a PDF never reach the memory at all. Each of these problems reduces reuse at the next revision, and lower reuse means paying again for text you have already approved. That is why owning your translation memory, and keeping it clean, matters as much as the translation itself.
Handled properly, the arithmetic works in your favour. As an illustrative example: if a revision changes ten pages of a two-hundred-page manual published in twenty languages, the translation work should cover only the changed text, reused from memory everywhere else, and the layout work should be ten pages in twenty languages, not two hundred. That is only possible when each language exists as a maintained source file, not as a PDF to be rebuilt. Our guide to what drives the cost of technical manual translation looks at the other factors in that equation.
Print and digital outputs
Most technical documents now have several outputs from one source: a print-ready PDF for the printer, a lighter PDF for download or a documentation portal, and sometimes files for distributors who print locally. Print PDFs need embedded fonts, images at print resolution and the colour settings agreed with your printer. Digital PDFs benefit from bookmarks, working links, searchable text and accessibility tagging with the correct language set. Agree these specifications once, in writing, so the twentieth language is produced exactly like the first. Where accessibility is part of that specification, our guide on how to make a PDF accessible explains what PDF/UA expects beyond a single export setting.
Managing versions across 20 or more languages
The real difficulty of multilingual desktop publishing is not one manual in one language; it is dozens of documents in twenty languages, each with its own revision history. Without discipline, language versions drift: one market receives an update, another does not, and nobody can say with confidence which German edition matches which Italian source.
A few habits keep this under control: every language carries the source’s revision identifier and date and is released with it; deliveries include packaged source files, not only PDFs; file names follow one convention. Terminology and style decisions should live in shared references, which is why keeping terminology consistent across suppliers and a translation style guide that covers layout conventions, such as how warnings, units and interface terms are written, both pay off in DTP as much as in translation.
A step-by-step multilingual DTP workflow
The steps are simple; what matters is that none of them is skipped.
Agree outputs and rules first. Confirm languages, outputs per language, fonts for other scripts, the treatment of interface screenshots and any regulatory layout constraints. An hour here saves days at the end.
Import and typeset. The approved translation flows from a clean memory into the original files, each paragraph gets the correct language setting, and the DTP specialist resolves expansion, tables, callouts and script settings while keeping warnings with their steps.
Rebuild navigation and check. Cross-references, contents, numbering and the index are updated, then every page is checked technically against the source and the agreed output specification.
Review in layout and close the loop. A qualified linguist reads the finished pages; corrections go into both the layout and the translation memory. You then receive print and digital outputs plus packaged source files, all with the same revision identifier.
What to ask a DTP supplier
A few direct questions help. Do you work in our native source files, and will you return them packaged with fonts and links? How do you handle scripts and right-to-left languages, and who checks the result? Do linguists review the final pages, and are their corrections written back into our translation memory? How do you keep forced line breaks and manual formatting out of the translated segments? How do you price a revision that only changes some pages? The answers tell you quickly whether the supplier treats layout as part of a controlled process or as a one-off finishing job. Our broader guide to choosing a technical translation company covers the questions to ask about the translation side.
How DEMA Solutions handles multilingual desktop publishing
Our in-house DTP team works on your native files, whether they come from InDesign, FrameMaker, Illustrator, Word, PowerPoint or other layout and graphics formats, and returns them packaged and ready for the next update. Where only a PDF exists, the same team can make it editable first, as described in our file preparation guide. Because our DTP specialists work alongside our translators, they understand how translation memories are built and keep layout fixes out of the translated segments.
Translation follows an ISO 17100 certified process in which a second qualified linguist revises every translation, and linguists check the finished pages in layout before delivery. Corrections from that check are written back into your translation memory, so the next edition starts from the corrected text. Your memories and glossaries belong to you and are delivered in portable formats (TMX and TBX). Our teams in Italy, Serbia and Spain cover the full workflow, and details of the review process are on our quality process page. You can find the full scope of our desktop publishing services, including the formats we work with, on the service page.
Where TUBE fits
For manufacturers whose manuals and catalogues change with every product update, TUBE keeps the language side of each edition under your control. Your glossary and translation memory control machine translation, every approved translation goes into a memory you own and can export, and leverage reporting shows how much of each update comes from text you have already approved.
Frequently asked questions
It is the work of producing finished documents in several languages from translated text: typesetting each language in the original layout, adapting it to text expansion, scripts, fonts and language rules, rebuilding navigation such as cross-references and indexes, and checking the final pages before print or publication.
Because translations rarely take the same space as the source, other languages have their own line-break, hyphenation and punctuation rules, and some scripts run right to left or need different fonts. Without layout work, text overflows, warnings separate from their steps and pages become hard to read.
Source files, packaged with their fonts and linked images, whenever you have them. A PDF can be converted, but working in the native files is faster, more accurate and keeps every language maintainable for future revisions.
Not on its own. Language models and machine translation work on text; they do not reflow a layout, apply language-specific typography, rebuild indexes or check that a warning stays with its step. They can support translation, but the finished pages still need a DTP specialist and a linguist to check them.
A DTP specialist for technical issues such as missing text, fonts and numbering, and a qualified linguist who reads the finished pages in context.
Because the next revision is translated from the memory, not from the PDF. A correction made only in the layout disappears at the next update, and the same error has to be found and fixed again.
As the outputs you need, print and digital, plus packaged source files for each language, all carrying the same revision identifier as the source so every market works from the same edition.
Get every language ready for print and publication
If you publish manuals, catalogues, labels or leaflets in many languages and want each revision to cost less than the last, send us a sample document and your language list. We will review your files and show you how we would typeset, check and maintain them across every language.
Experience seamless translation
with our top-notch DTP solutions
Download our detailed guides to see how we optimize your files for accurate, hassle-free translations, regardless of format or complexity.
