· javascript
One Build, Ten Locales: How We Bake Translations at Compile Time Instead of Resolving Them at Runtime
When you tell people you have your own build-time localization, the first question is always “why not i18next?”
However, it actually contains two completely separate decisions bundled together, and until you pull them apart you can’t answer either one honestly. We run a large SPA on webpack, React and TypeScript with more than 10 languages. The locale list is known before deployment and doesn’t change between deploys — we know it at build time as precisely as we know the Node version.
That sounds like a mundane detail, but it’s the fact that determines the entire localization architecture. It’s what led us to write a few-hundred-line webpack plugin instead of reaching for a library. This post covers the reasoning: What the different i18n approaches actually are, why a fixed locale list tips the balance toward build-time translation, what existing baked solutions look like and why none of them fit and how our plugin works — compile once, produce N locale-specific bundles from the output.
