The problem with distributed translations

When you have forty-plus micro-frontends, each bundling its own i18n files, things get messy fast. Translators work against a single source of truth, but by the time those strings reach production they've been copied, transformed, and cached in ways nobody fully understands. We had duplicate keys, stale translations shipping weeks after fixes, and bundle sizes that kept creeping up.

A shared translation runtime

The answer wasn't a shared library — it was a shared service. We extracted translation loading into a shell-level provider that fetches a single JSON manifest at boot, then exposes an injection token every micro-frontend can consume. Each app declares which namespaces it needs; the provider deduplicates and lazy-loads only the delta.

Tooling around the pipeline

The real win came from the tooling. A GitHub Action validates every PR against the canonical XLIFF files, flags missing keys per locale, and blocks merge until coverage thresholds are met. Translators push to a Phrase project; a webhook triggers a pipeline that compiles, deduplicates, and uploads to S3. The shell picks up new strings on the next deploy — no micro-frontend rebuild required.

Results

Bundle sizes dropped by roughly 12 percent across the board. Translation lag went from weeks to hours. And onboarding a new micro-frontend now takes one config line instead of a copy-paste ritual.