Generating enterprise documents in 16 languages
A regulated buyer in Gujarat and one in Japan need the same rigour in different languages — and a PDF that renders their script correctly on a machine we do not control. Two generation paths, an embedded-font pipeline, and one capability we deliberately did not ship.
What this system does
Agentora's client-facing deliverables — assessment reports and delivery packs — are generated documents, and its marketing site is the first thing a prospective client reads. This case study covers making both work in languages other than English, including nine Indian languages.
The problem
For a cooperative bank in Gujarat or an enterprise in Japan, an English-only deliverable is not a rough edge. It is a blocker to the document being read by the people who have to act on it, and in regulated settings, to it being circulated internally at all.
The naive approach — run the finished English document through a translation step — fails in two distinct ways. Technically, a PDF renderer with no font covering Gujarati or Japanese does not fail loudly; it silently emits blank boxes, so the document looks broken rather than untranslated. Substantively, post-hoc translation of regulatory and architectural language tends to lose register and precision exactly where precision matters most.
There was also an existing-asset problem. Some artifacts have already been generated in English and human-approved. Regenerating them from scratch in another language would discard that review, but translating them at export preserves it.
On the marketing side, adding sixteen language versions of a site that already ranks is an SEO hazard: done carelessly, the language variants read as duplicate content competing with each other, and moving English pages to new URLs discards their existing standing.
Constraints
The boundaries the design had to respect, before any solution was chosen.
- Fonts must be embedded in the PDF. Relying on the reader's machine having a Gujarati or CJK face is not an option.
- Nine Indian scripts plus CJK need genuine glyph coverage, not a fallback that silently degrades.
- Translation must not quietly alter regulatory meaning; a human review step stays in the loop.
- Sixteen locales have to remain maintainable by a small team, not hand-curated forever.
- English pages must keep their existing URLs — no SEO regression on the site that already ranks.
The architecture
Rather than choosing between translating output and generating natively, we built both and used each where it is stronger, then layered site localization on top.
- 1
Translate-at-export for approved artifacts
An English artifact that has already been generated and human-approved is translated at render time, so the approved substance is preserved and only the presentation layer changes. This is the right path when the review has already happened.
- 2
Engine-native generation for new documents
For documents generated fresh, the language is pushed up into the generation prompt itself: a language directive is appended so the model writes in the target language from the start. This produces markedly better register and domain terminology than translating finished English prose, because the model composes in the target language rather than mapping to it.
- 3
Script-aware font embedding
The PDF pipeline selects and embeds a Noto face matching the document's script, so Devanagari, Gujarati, Tamil, Telugu, Kannada, Malayalam, Bengali, Gurmukhi and CJK all render from fonts carried inside the file rather than resolved on the reader's machine.
- 4
Glyph sanitization at the boundary
The default PDF font is WinAnsi-encoded, which means characters like arrows and the ≥ and ≤ symbols do not fail loudly — they render as empty boxes. Those characters are sanitized at the rendering boundary so a stray symbol cannot quietly corrupt a client-facing page.
- 5
Site localization without breaking English
The marketing site uses per-locale message catalogs with localized routes under a locale segment, while English keeps its existing root URLs. The edge proxy picks a default locale from the request's country, a cookie lets the visitor override it, and the sitemap emits hreflang alternates so search engines treat the sixteen versions as alternates of one page rather than competing duplicates.
Key decisions and their trade-offs
Every decision below cost something. The trade-off is stated alongside the reasoning.
Hybrid: both translate-at-export and native generation
Why
They solve different problems. Translation preserves an existing human approval on an artifact that already exists; native generation gives better language quality for anything generated fresh. Picking only one would have meant either discarding approvals or accepting weaker prose.
Trade-off
Two paths to maintain and two sets of failure modes, rather than one pipeline to reason about.
English keeps root URLs; localized versions are prefixed
Why
The English pages already have search standing. Moving them to a prefixed URL to make the scheme symmetrical would have discarded that for a purely aesthetic gain.
Trade-off
The routing is asymmetric — one locale behaves differently from the other fifteen — which is a permanent small complexity in the codebase.
India defaults to English, not Hindi
Why
Indian enterprise and BFSI business is conducted in English, and Hindi is not the regional language across much of the country. Defaulting an Indian visitor to Hindi would be wrong more often than right. Geography is a weak signal for language preference, so it sets a default rather than a decision, and the visitor can always override it.
Trade-off
A Hindi-preferring visitor has to switch languages explicitly rather than being served it automatically.
Deliberately exclude Arabic and right-to-left output from PDFs
Why
The PDF text-shaping layer crashed on bidirectional reordering. The options were to ship a locale that produces broken or incorrectly-ordered documents, or to gate it off and document the gap. For a document a bank may circulate to its board, a wrong-but-plausible rendering is worse than a clearly unsupported one.
Trade-off
Arabic-speaking markets are not served by the PDF pipeline today. This is a known, documented gap with a fallback to English rather than a silent failure.
Technologies used
Document generation
- react-pdf
- Noto font family
- Font subsetting & embedding
AI
- Anthropic Claude
- Prompt-level language directives
Web localization
- next-intl
- Next.js proxy (geo headers)
- hreflang sitemap
Engine
- Java
- Spring Boot
Outcome
- Sixteen language catalogs ship on the marketing site — English plus nine Indian and six international languages — with hreflang alternates emitted from the sitemap so the variants are indexed as alternates rather than duplicates.
- The regional-language PDF pipeline, including script-aware font embedding, is merged, and engine-native generation in the target language is built into the generation capabilities.
- Right-to-left output is explicitly gated off with a documented fallback, so an unsupported locale degrades to English rather than producing a malformed document.
Known limitations
What this design does not do. Stated because an architecture without documented trade-offs has usually not been examined closely enough.
- Arabic and right-to-left scripts are not supported in PDF output. The locale is gated off and falls back to English.
- Translations are machine-generated with human review in the loop. They are not certified or sworn translations, and are not presented as such.
- Embedding fonts for non-Latin scripts increases PDF file size compared with the Latin-only baseline.
- Geo-IP is a default, not a detection of preference. It will be wrong for some visitors, which is why the override exists.
Want this level of rigour on your AI initiative?
Start with a free AI Readiness Assessment, or book a Discovery Workshop to get a scored, costed roadmap.