Multilingual DTP Checklist for Agency Project Managers

A brochure can pass translation review and still arrive at the printer with clipped headings, a missing font, or an Arabic phone number that reads in the wrong order. The project manager’s job is to make sure the handoff covers more than the words.

A multilingual DTP checklist is a practical set of checks for preparing source files, managing localized layouts, and approving final PDFs. DTP means desktop publishing: arranging text and images in a designed document, then preparing the file for digital or print delivery. Localization adapts that document for a particular language and locale, including its writing direction, dates, numbers, and layout needs.

The checklist below follows a project from intake through final approval. It gives you a way to assign responsibilities, spot risks early, and tell whether a file is ready for the next person in the workflow.

What a multilingual DTP handoff needs¶

A DTP handoff is the package of files, instructions, and decisions that lets a designer work without guessing. A well-prepared handoff identifies the editable source, the intended output, and the person responsible for each approval.

Start with the InDesign package or other agreed editable source, not only a PDF. Include linked images and graphics, any placed documents, and the fonts or font details needed to open the layout correctly. State whether fonts can be transferred or whether the team must use approved alternatives. Font licensing can limit what a supplier may embed, share, or install, so settle that question before production rather than after a missing-font warning appears.

Add a reference PDF or approved visual sample so the DTP specialist can compare the original design with the working file. Identify which elements must remain fixed, such as a logo, legal line, product image, or callout. Note where the design can change to make room for translation. A layout that treats every line break as sacred can force tiny text or awkward spacing in a language whose wording takes more room.

Write down the locale for every deliverable. “French” or “Arabic” alone may not answer what the team needs to know about language variant, regional formatting, or reading direction. Include any client-specific terminology, approved spellings, and instructions for dates, currencies, units, and sorting. Unicode’s UTS #35 locale-data standard, version 48.2 dated 2026-03-03, describes locale data for identifiers, dates, numbers, units, time zones, collation, and plural rules. Its guidance supports a practical handoff rule: record the locale and platform assumptions instead of expecting every application to format or sort content the same way.

A useful handoff also states who checks what. The translator or reviewer approves language and terminology; the DTP specialist checks composition and layout; the project manager checks that files, locales, and approvals match the brief; and the print provider confirms production specifications. One person can hold more than one role, but the review tasks still need named owners.

Handoff checklist

• Editable source file, packaged links, and reference PDF are present.
• Target languages and locales are named precisely enough for formatting decisions.
• Font requirements, licensing constraints, and approved substitutions are documented.
• Text that must remain unchanged is identified, including names, codes, URLs, and legal copy.
• Layout flexibility, priority elements, and known space constraints are clear.
• Date, number, unit, and currency conventions are recorded for each locale.
• The required output format and printer specifications are available.
• Linguistic, layout, and final-production approvals have assigned owners.

A typical failure starts with a brief that says only “make the French version match the English PDF.” The DTP specialist receives a flattened reference instead of an editable file, has no source for a missing image, and discovers that the client expects the exact same line breaks. The problem isn’t a lack of design skill; the handoff hasn’t defined what “match” means or which source files are authoritative.

The practical distinction is between visual reference and production source. A PDF can show what the approved page should look like, but it may not contain the paragraphs, styles, or linked assets needed to edit the design efficiently. Keep both the reference and the editable source in the handoff, and label which one controls content, layout, and output.

Prepare the source file before localization¶

Source-file preparation is the point where a project manager can prevent avoidable layout work. A clean file gives the localization team a stable structure and makes it easier to distinguish a translation problem from an inherited design problem.

Open the working file and check that it contains the expected pages, layers, parent pages, and links. Confirm that the supplied version matches the approved reference. If a client sends several files with similar names, ask which is current and record that choice in the brief. A designer shouldn’t have to infer whether “final,” “final-new,” or “final-approved” is the actual source.

Run InDesign Preflight before handing off the file. Adobe describes the Preflight panel as a way to flag issues such as missing fonts, modified links, overset text, and low-resolution images. The panel can group problems by category and take the user to affected content. Treat it as a working-file check, not a box to tick only at final export.

Resolve or document existing issues. A source file that already has overset copy or a modified link can create confusion when the localized version changes. If the issue is intentional, mark it and say what the DTP specialist should do. If it isn’t intentional, correct it before the first target layout so nobody has to guess whether the error came from localization.

Check text frames and styles, too. Look for hard-coded line breaks, manual spacing, inconsistent paragraph styles, and text placed in a way that makes normal editing difficult. Keep content editable wherever possible. Text split into many small frames may look fine in the source language but can make reflow and proofreading awkward after translation.

Make a separate note for assets with text inside them. A product image, chart, screenshot, or diagram may contain labels that aren’t in the main text flow. List those items and say whether they need translation, recreation, or approval as-is. Ask for the original graphic when available; editing text embedded in a flattened image is a different task from editing a normal text frame.

Finally, set a baseline for what counts as a clean source. Record the preflight status, list accepted exceptions, and retain the approved reference PDF. That baseline gives the team a comparison point later. Without it, an inherited missing link can be mistaken for a new localization defect, or a genuinely new problem can be dismissed as “already in the file.”

For an InDesign localization handoff, the minimum useful package is therefore more than an IDML file. It includes the editable source, placed assets, font instructions, a reference, locale requirements, and a record of unresolved issues. A translation-ready InDesign file is one whose structure and dependencies are clear enough for another person to work on it without rebuilding the project from clues.

Manage text expansion, locale data, and review¶

Translated copy may occupy a different amount of space than the source, and a good workflow plans for that change instead of treating every overset frame as a surprise. The final layout is shaped by both the translation and the design choices around it.

Don’t rely on a single expansion percentage as a universal rule. The dossier doesn’t provide a fixed value that applies across languages and layouts. Instead, identify the areas where space is tight: navigation labels, buttons, narrow columns, tables, captions, and text placed over images. Ask the translation team to flag terms that can’t be shortened without changing meaning, and ask the designer to identify where a line break or frame change is acceptable.

Build review around complete strings and their context. A short button label may have several plausible translations, but only one may fit the available space and make sense beside its icon. A heading can wrap differently after translation, shifting the content below it. A table can break when one localized cell becomes longer than the others. Reviewers need to see the target text in the layout, not only in a text export.

Keep locale-specific formatting deliberate. Unicode’s UTS #35, version 48.2 dated 2026-03-03, describes locale data for items such as dates, numbers, units, and collation. The standard says language-neutral data should be stored and communicated, then formatted for the client’s locale. Where the workflow allows, keep an underlying value separate from its display format. That makes it easier to check whether a date or quantity was changed by the content owner or merely presented according to a locale convention.

Record the platform assumptions as well. Locale data can vary across systems and applications, and differences can produce inconsistent results, including sorting differences. A list of product names that sorts one way in a desktop layout may not follow the expected order after export or processing elsewhere. Include the locale and application assumptions in the brief, then verify the final ordering in the actual output.

Plural handling needs a similar context-first approach. The CLDR plural-rules specification, consulted in 2026, defines the categories zero, one, two, few, many, and other. “Other” is required, and some languages may use only that category. Those categories describe phrase changes triggered by a numeric placeholder; they don’t map neatly to the English singular-versus-plural split.

For a localized layout, the project manager should ask for the full string and its representative values, not just a translated noun ending. Test the numbers that appear in the product or publication, including fractional values when they’re relevant. A label such as “items remaining” may need a different complete phrase as the count changes. CLDR’s minimal-pair method supports checking number/string cases that differ only where the value forces a grammatical change.

How should project teams check dates, numbers, and plurals?¶

Treat values and presentation as separate review questions. First confirm the underlying date, number, or quantity against the approved source; then check whether the localized presentation follows the agreed locale. For pluralized strings, review complete phrases with representative values rather than checking only the noun.

A practical review table can keep these decisions visible:

The table is a project control, not a replacement for linguistic review. The translator checks whether the phrasing is natural; the DTP reviewer checks whether the approved phrasing fits and renders clearly; the project manager makes sure both checks happened against the same version.

Internal project documentation can make this easier. For example, a team may reuse a locale-aware localization workflow as a model for recording locale assumptions across channels, or compare its handoff roles with translation agency project management systems. Keep the DTP brief specific to the actual layout, though. A general workflow doesn’t replace printer instructions, approved terminology, or file-level checks.

Check RTL and mixed-direction layouts visually¶

Right-to-left layout quality assurance needs a separate visual pass because a page can contain both right-to-left and left-to-right text. Arabic and Hebrew content may include digits, Latin product names, phone numbers, codes, and URLs, each of which can affect how a line appears.

Unicode’s Bidirectional Algorithm, UAX #9, states that text is stored in logical order. Display order is handled separately. In other words, the character sequence in the file and the way a reader sees it on screen are related, but they’re not the same thing.

“The Unicode Standard prescribes a memory representation order known as logical order.”

• Unicode Standard Annex #9

For the project manager, the practical consequence is simple: don’t manually reverse or rearrange source characters to make a line look right. Review the rendered result and, when needed, the extracted text. Manual character reordering can damage the underlying text even if a particular preview appears correct.

A line written mainly in an RTL script can still be bidirectional as soon as it contains left-to-right digits or embedded Latin text. Unicode notes that digits written left to right inside RTL text make the text bidirectional, and the same issue arises with Latin words. Include phone numbers, product codes, URLs, and mixed-script labels in the visual test set rather than reviewing only paragraphs made up of one script.

For InDesign files, check the paragraph direction and the relevant composer. Adobe’s Arabic and Hebrew setup guidance describes World-Ready composers for Middle Eastern and other complex-script composition, including RTL and bidirectional text. Confirm the installed application setup and the required composer for the project, then inspect the actual output instead of assuming that selecting a language alone fixes direction and shaping.

Look at punctuation and boundaries with special care. Parentheses, quotation marks, slashes, hyphens, and adjacent numbers can appear in an unexpected visual sequence when direction changes inside a line. Check whether a URL remains readable, whether an opening and closing bracket surround the intended text, and whether a product code still matches the approved source. Pay special attention to account numbers and other sensitive identifiers, since Unicode identifies security concerns associated with bidirectional text.

Unicode also distinguishes directional isolates from embeddings. Isolates keep characters inside them from affecting ordering outside, and the standard encourages isolates over embeddings in new documents when target platforms support them. Don’t insert directional controls as a visual patch without understanding how the receiving application handles them. Record the relevant platform assumptions and check that any formatting controls survive the complete production path.

“Whenever right-to-left scripts, for example, use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text, even in the same script.”

• Unicode Standard Annex #9

That explanation points to a useful QA technique: create a small, representative test page before flowing all the content. Include a paragraph, a heading, a phone number, a URL, a code, and punctuation around mixed-direction text. Review those combinations in the working file and exported PDF. A layout that handles the test page correctly still needs a full review, but the test can reveal a composer or direction problem before it spreads through the document.

Visual appearance isn’t the only criterion. Unicode says explicit directional formatting characters affect display ordering, not text comparison, word breaks, parsing, or numeric analysis. When text is extracted for indexing, search, or reuse, check that its logical content remains usable. A PDF can appear correct to a reader while copy-and-pasted text arrives in an unexpected order.

Preflight the localized PDF before release¶

A localized PDF is ready for approval only after the team checks both content and production behavior. Exporting a file is not the same as proving that its fonts, images, geometry, and text are suitable for their destination.

Start with the receiving printer’s specification. Ask which PDF version or PDF/X preset to use, whether marks are required, what bleed settings apply, and which output intent or color instructions govern the job. Adobe’s print-ready PDF guidance treats PDF/X presets, marks, and bleeds as configurable options. The right settings depend on the printer’s specification, so don’t assume one preset fits every job.

A PDF/X label alone doesn’t replace the printer’s instructions. The PDF Association’s technical explanation of PDF/X says PDF/X-4 supports transparency, is based on PDF 1.6, and requires an embedded output-intent ICC profile for complete exchange. Confirm the requested PDF/X version and output intent with the production provider before exporting.

Adobe’s print-output guidance also calls for checking fonts, image resolution, overset text, links, licensing, bleed and margins, color suitability, and preflight status. The Adobe guidance identifies low-resolution images below 300 ppi as a print issue; treat that as a threshold cited in Adobe’s documentation and verify the printer’s own requirements for the job. A printer’s specification governs the final production decision.

Localized PDF preflight checklist

• Confirm that the export matches the approved language, locale, and source version.
• Check that the page size, margins, bleeds, and marks match the printer’s instructions.
• Review the PDF for clipped or overset text, awkward breaks, missing glyphs, and unexpected substitutions.
• Inspect links and images, including resolution and placement.
• Confirm font availability, embedding, and licensing requirements.
• Verify color settings and output intent against the receiving printer’s specification.
• Compare dates, numbers, units, pluralized strings, URLs, and identifiers with approved content.
• Open the exported PDF and review representative pages, not only the InDesign file.
• Keep the final export, the source file, and the approval record together.

The PDF review should compare like with like. Use the approved target copy and the final exported PDF, not a previous proof or an untracked edit. Check every page for obvious clipping and scan the most constrained layouts in detail: dense tables, small captions, footnotes, sidebars, and pages with mixed-direction text.

A common production snag is approving a PDF based on how it looks on one workstation, then discovering that the receiving provider expected a different preset or output intent. No universal setting can replace the printer’s job specification. Put that specification into the brief and get the export choice confirmed before final delivery.

Keep a record of corrections as well. If a reviewer flags a wrong product code, a font substitution, or a clipped caption, note the page and the approved fix. After the correction, check the exported PDF again; a change in one text frame can alter neighboring layout. Approval applies to the delivered export, not just to an earlier proof.

Common multilingual DTP failures and how to prevent them¶

Most costly DTP problems are not exotic. They come from unclear ownership, a weak source package, or a review that checks the words without checking how those words behave in the file.

Treating the reference PDF as the editable source. A PDF is useful for comparison, but the layout may not be structured for editing. Supply the native source and linked assets, and state which file is authoritative for content and which serves as the visual reference.

Skipping preflight until export. Missing fonts, modified links, overset text, and low-resolution images can already be present in the working file. Adobe’s InDesign Preflight documentation describes checks for those production issues. Run preflight on the source and on the localized working file so inherited errors don’t get mistaken for new ones.

Assuming translated text will fit because the source fits. Different wording can change line breaks and frame height. Identify tight areas before translation, give the designer room to adjust where allowed, and review the actual layout rather than promising identical line lengths.

Checking RTL copy only in isolation. A text editor may show the correct character sequence while the designed page misplaces digits or punctuation. Unicode’s bidirectional algorithm specification explains why mixed-direction content needs visual review. Put the exact kinds of strings used in the project into the QA sample.

Fixing a bidi issue by reversing characters. Logical order is the stored sequence; display order is computed for presentation. Reversing characters can break copying, searching, or downstream processing. Fix the composition setup or directional handling, then validate the rendered and extracted text.

Reviewing plural forms as isolated words. CLDR plural categories depend on the phrase changes required by numeric placeholders, not simply on English grammatical labels. The CLDR plural-rules specification supports checking full phrases and representative values. Give reviewers the complete string and context.

“CLDR uses short, mnemonic tags for these plural categories:”

• Unicode CLDR plural rules

The category labels are a framework, not a ready-made translation for each interface string. The project team still needs to check how its own sentence changes with the displayed value, and whether the final layout has enough room for each form.

Assuming that the same formatting appears in every application. Locale data and sorting behavior can differ across systems. Record the assumptions, render the final file in the intended workflow, and check ordering and date or number presentation there.

Approving a PDF without printer confirmation. PDF/X settings, marks, bleeds, and output intent depend on the destination’s requirements. Ask the printer for the job specification, use it when exporting, and retain it with the approval record.

Leaving review ownership vague. “The team has checked it” doesn’t tell anyone whether language, layout, or print settings were reviewed. Name the approver for each area, and make sure the final approval refers to the same export that will be delivered.

A useful project habit is to keep a short issue log beside the proof. Record the page, the observed problem, the responsible reviewer, and the agreed correction. The log helps the next reviewer distinguish a fixed issue from a new one and makes repeated defects easier to trace back to the handoff or source file.

FAQ¶

What should an agency project manager include in a multilingual DTP handoff?¶

Include editable source files, linked assets, font and licensing information, target locales, reference material, layout constraints, and printer specifications. State who approves linguistic, visual, and print-production checks, and record any accepted source-file issues.

How do you preflight an InDesign file before multilingual localization?¶

Open the packaged working file, check links and fonts, run InDesign Preflight, and inspect overset text, images, styles, and page geometry. Resolve source-file problems before layout begins, or document why an exception is intentional.

What should be checked in Arabic or Hebrew DTP layouts?¶

Check paragraph direction and the appropriate World-Ready composer, then inspect mixed-direction content such as digits, URLs, phone numbers, identifiers, and Latin product names. Review exported text as well as its visual appearance.

How do you check a localized PDF before sending it to print?¶

Compare the PDF with the approved source and target text, inspect page geometry, fonts, images, color, bleeds, and marks, and confirm the export preset and output intent with the printer. Review the actual exported file after any correction.

How should dates, numbers, and plurals be checked across locales?¶

Keep values separate from locale-specific presentation where the workflow allows, then check formatting against the target locale. Review complete pluralized phrases with representative numeric and fractional values where relevant.