← All Research

Document Translation for the Japanese Market in 2026: What Actually Breaks

By Linnk Research Team | August 2026 | 11 min read

Most document translation tooling is built English-first and localized afterwards. That ordering shows up immediately when Japanese enters the pipeline, because Japanese breaks assumptions that never had to be examined when the source and target were both alphabetic left-to-right languages with spaces between words.

This is a field report on what actually goes wrong, and what to check.

Contraction, not expansion

The standard localization warning is about text expansion: German runs 30% longer, so leave room. Japanese does the reverse. English to Japanese typically contracts, sometimes substantially — a 12-word English bullet can land as a short Japanese phrase.

That sounds harmless. It is not, because layout is a visual argument. A slide designed around three balanced bullets becomes three short fragments floating in whitespace. A table sized for English column headers has Japanese headers rattling around in cells three times too wide. The document is correct and looks unfinished, which in a business context is its own kind of wrong.

The mirror problem appears on the return trip. Japanese to English expands, and expands unevenly — a compact Japanese noun compound can become a six-word English phrase that no longer fits the cell it came from.

Tools that only test on European language pairs never encounter either failure, because expansion and contraction there are modest and symmetric.

The three OCR failures specific to Japanese

Vertical writing (縦書き, tategaki). Novels, legal documents, many government forms, and most newspapers set text top-to-bottom, right-to-left. An OCR engine that assumes horizontal reading order does not produce slightly-wrong output here — it produces confidently scrambled output, because it reads across columns instead of down them. Worse, many Japanese documents mix both directions on one page: vertical body text with horizontal headers, tables, and figure captions.

Ruby annotations (ふりがな / furigana). Small phonetic characters printed above or beside kanji to indicate pronunciation. OCR frequently either merges them into the main text — producing character soup — or drops them entirely. In educational, legal, and children's material, dropping them removes information the document exists to convey.

Half-width and full-width forms. Japanese has two width variants for numerals, Latin letters, and katakana. 2026 and ２０２６ are different codepoints meaning the same thing. Pipelines that don't normalize produce documents where dates, part numbers, and prices are inconsistent — and search or downstream validation silently fails to match them.

Add to these the ordinary difficulty of a dense script: Japanese has no spaces between words, so segmentation errors propagate directly into mistranslation with no visual cue that anything went wrong.

Register is a correctness problem

Japanese encodes social relationship in grammar. The keigo system — 尊敬語 (respectful), 謙譲語 (humble), 丁寧語 (polite) — is not decoration on top of a neutral sentence. It is a required choice, and getting it wrong changes what the document is.

A contract translated into casual form (だ・である体 where です・ます体 was required, or the reverse) reads to a Japanese business reader roughly the way a legal agreement written in text-message English would read: the content may be accurate and the document is not usable.

Machine translation has improved a great deal here, but it still has no access to the information it needs — who is writing to whom, and in what relationship. If your tool accepts a register instruction, set it. If it doesn't, a native reviewer needs to check the first page before the rest is trusted.

The related trap is company and person names. Japanese business documents carry titles and honorifics as part of the name (様, 御中, 部長), and stripping or mistranslating them is a visible discourtesy in exactly the documents where that matters most.

PowerPoint is the format that matters

In practice, the file type that generates the most Japanese business demand is the presentation deck, and it is the format that most translation tools handle worst.

The reasons are structural. Text sits in fixed-size boxes rather than reflowing. Speaker notes are a separate text layer that is often silently dropped. Diagrams are groups of individual text frames whose reading order is spatial rather than sequential. Charts carry text inside embedded objects. And Japanese contraction leaves boxes visibly under-filled, which on a slide — unlike in a paragraph — is immediately obvious to everyone in the room.

Excel has a parallel set of problems: formulas that reference text values, sheet names with length limits, and cells where a translated string quietly breaks a lookup.

A tool that handles PDF well tells you nothing about how it handles a deck. Test the format you actually send.

Getting to a usable result

For digital source files — a PDF, DOCX, XLSX, or PPTX that already contains a text layer — use a document translator that preserves the format rather than extracting text and translating it separately. DocTranslator handles the general case, and for the Japanese market specifically the localized product is docuhonyaku.com, which is built around these formats for Japanese output rather than treating Japanese as one target among many.

For scans and photographs there is an OCR stage before any of that, and it is where the vertical-text and ruby problems live. Scanned.to is built for translating scanned documents with the layout intact; when you only need the characters and will handle the document yourself, ScanRead.ai is the lighter path.

Whichever route, the review checklist is short and worth doing:

• Open the translated deck or document at full size. Does anything look empty, cramped, or clipped?
• Check register on the first page. Is it consistent with the document's purpose?
• Verify numbers, dates, and identifiers — half-width/full-width inconsistency shows up here first.
• Confirm speaker notes, footnotes, and figure captions survived.
• For vertical-text sources, read two paragraphs and confirm the order is right. Scrambled column order reads fluently and is completely wrong.

<!-- linnk:faq -->

Frequently Asked Questions

Why does my translated Japanese PowerPoint look empty?

Japanese typically contracts relative to English — often substantially. Text boxes sized for English copy end up under-filled. This is a layout problem rather than a translation problem, and it usually needs a pass to resize or rebalance boxes after translation.

Can OCR handle vertical Japanese text?

Some engines can, many cannot, and most will not tell you which. An engine that assumes horizontal reading order will read across the columns of a vertical document and produce fluent, scrambled output. Test with a known vertical page before trusting a pipeline on a batch.

What is keigo and why does it affect translation quality?

Keigo is the Japanese system of honorific registers that encodes the relationship between writer and reader in the grammar itself. It is not optional politeness — choosing the wrong register makes a business or legal document unusable, even when every individual sentence is accurate.

Should I translate into Japanese with a general tool or a Japanese-specific one?

For one-off documents where formatting doesn't matter, a general tool is fine. For business documents where layout, register, and format fidelity matter — decks, contracts, spreadsheets — a product built for the Japanese market handles the specific failure modes above rather than treating them as edge cases.

<!-- /linnk:faq -->