How to Create a Multilingual PDF Document

Font selection is the foundation of multilingual PDF creation. A font that does not include the characters for your target languages will cause those characters to appear as empty boxes or substitute glyphs — a serious quality failure. Unicode fonts with broad language coverage are essential. Noto fonts (Google, free) are specifically designed for multilingual use — the Noto project aims to cover all Unicode characters, with specific font families for each script (Noto Sans, Noto Serif, Noto Arabic, Noto CJK for Chinese/Japanese/Korean, etc.). Using Noto fonts guarantees that your document will display correctly across all the languages they support. For professional documents where brand fonts are required: verify whether your brand fonts support the required character sets. Many commercial fonts cover Latin, Greek, and Cyrillic but not Arabic, Hebrew, CJK (Chinese, Japanese, Korean), or Indic scripts. Check the font's character coverage specification before committing to it for a multilingual project. You may need to use your brand font for Latin-script languages and substitute a compatible Noto or similar font for non-Latin scripts. For CJK (Chinese, Japanese, Korean): these scripts require font files that are substantially larger than Latin fonts — CJK fonts can be 10-30MB because they contain thousands of characters. Be prepared for larger PDF file sizes when including CJK languages. Font subsetting (embedding only the characters actually used) mitigates this: a Japanese-language section that uses 1,000 of a font's 20,000 characters embeds only the 1,000 used characters. All fonts must be embedded in the PDF. Verify this by checking File > Properties > Fonts in any PDF reader. All fonts should show 'Embedded Subset.'

Arabic, Hebrew, Persian (Farsi), and Urdu are right-to-left (RTL) languages. Including these languages in a PDF document requires specific attention to text directionality and layout that cannot be handled by simply typing the text into a standard left-to-right layout. Word processors with RTL support: Microsoft Word handles Arabic and Hebrew well. For a Word document, set the text direction for RTL paragraphs by selecting the text and pressing Ctrl+Right Shift (for RTL) or Ctrl+Left Shift (for LTR). Headings, tables, and bullet lists in RTL sections should all have their alignment and text direction set correctly. Dedicated layout software: Adobe InDesign's 'Middle East' edition (or the standard edition with the Middle East features enabled) has full support for Arabic, Hebrew, and Persian including correct text rendering, proper numeral styles, and mirrored layout features. For multilingual documents that include RTL languages, InDesign is the most reliable tool. Layout approach: Multilingual documents with RTL and LTR sections typically use one of two approaches. Approach 1 — Parallel layout: LTR version on the left half of a spread, RTL version on the right half. Approach 2 — Sequential sections: LTR language sections sequentially followed by RTL language sections (or vice versa). The sequential approach is more practical for most document types. For RTL sections, pagination and headers/footers should also be mirrored if the content runs in RTL. A document title that appears in the top-right for LTR becomes top-left for RTL. Page numbers may need to count in the opposite direction if the RTL section is designed as a standalone booklet within the larger document.

1. 1Identify all target languages and determine which require RTL support or special character sets
2. 2Select Unicode fonts (such as Noto) that cover all required character sets
3. 3Create the master layout in English or the primary language first, using consistent styles and grid
4. 4Create separate documents for each additional language, adapting the layout for text expansion and RTL as needed
5. 5Convert each language version to PDF with fonts fully embedded
6. 6Use LazyPDF's merge tool to combine all language PDFs in a consistent order, then add page numbers

Text expansion is one of the most practical challenges in multilingual document design. English text, when translated to European languages, typically expands by 20-35%. German is famously verbose: a 100-word English passage may become 130+ words in German. Finnish and Czech also expand significantly. Japanese and Chinese, conversely, often compact text — they carry more meaning per character and may actually be shorter than the English source. Text expansion has direct layout consequences. A button label, table cell, or caption that fits perfectly in English may overflow or force line breaks in German. A form field sized for an English address may not accommodate a German compound noun address. Mitigating expansion in PDF documents: Design your original layout with 20-30% more space than the English text requires in each text block. This feels wasteful in the English version but prevents overflow in European language versions. Use flexible text boxes that can grow in height (rather than fixed-height boxes that clip) where possible. Avoid designing layouts where text must fit precisely — instead design for approximate fit with some flexibility. For CJK languages: Japanese, Chinese, and Korean characters are wider than Latin characters and have different line-spacing requirements. CJK text typically needs line spacing of 1.5-2.0 (versus 1.15-1.4 for Latin languages) for comfortable reading. CJK punctuation also has specific spacing requirements around brackets, commas, and periods. Test your layout in all languages before finalizing. Even experienced multilingual designers are sometimes surprised by how a particular language combination interacts with a specific layout. A proof-reading pass by a native speaker of each language is valuable not just for accuracy but for catching layout issues that are not visible without reading the text.

Once all language versions are created as individual PDFs, the assembly step creates the final multilingual document. The sequence in which languages appear matters for different document types. For product documentation distributed globally: alphabetical order by language name (in English) is neutral and predictable. Or, order by geographic region: Americas, Europe, Asia-Pacific, MENA. For documents in the EU: some organizations order by EU official language alphabetically in their own language (Bulgarian: BG first, then Danish: DA, etc.). This follows EU document conventions. For commercial documents: lead with the primary commercial market's language, then additional markets in descending order of commercial importance. Before final assembly, ensure all language PDFs use the same page size (critical — mixing A4 and US Letter in one document looks unprofessional). Check that all pages are correctly oriented (not accidentally rotated). Verify that each language section has its own clearly labeled section divider page. Use LazyPDF's merge tool to combine all language PDFs in your chosen sequence. Review the merged document page by page — pay particular attention to the boundaries between language sections and ensure no pages were dropped or duplicated in the merge. After merging, use LazyPDF's page-numbers tool to add continuous page numbers through the entire document. For documents where each language section should appear to have independent page numbers (like a warranty booklet where each language version starts at page 1), this requires more advanced tools like Adobe Acrobat Pro's page labels feature.

For multilingual documents with legal significance, the relationship between language versions matters. Key questions to address before finalizing a multilingual document: Which version controls in case of conflict? For contracts with provisions in multiple languages, one version is typically designated as the controlling or authoritative version (often English in international business). This governing language clause must appear clearly in each language version. Are all translations legally certified? For official government filings, immigration documents, legal affidavits, and medical records, translations typically need to be certified by a qualified, often sworn translator. Amateur or machine translations are not acceptable for these purposes regardless of how well they are formatted. Do local regulations specify language requirements? EU product documentation, pharmaceutical package inserts, and consumer contracts must appear in the official language(s) of each member state where the product is sold. Requirements vary — some products need all EU languages, others only the language of the country of sale. For pharmaceutical products in the EU: the SmPC (Summary of Product Characteristics) and PIL (Patient Information Leaflet) must appear in the official language of each member state. These cannot be machine-translated — they require qualified medical translators and regulatory review in each market. For software user interfaces and digital products: EU Digital Services Act, EU Accessibility Act, and similar regulations increasingly require digital products to be available in multiple EU languages. PDF documentation should align with whatever language support the software itself provides.