Scaling i18n Beyond Lazy Loading: What Framework Comparisons Miss About Real-World Localization

I've read a lot of "how we scaled our i18n" posts. They almost all follow the same arc: team evaluates frameworks, picks i18next or FormatJS, implements lazy loading per namespace, ships it, writes the blog post. Bundle size goes down, page load improves, everyone's happy. I know because we wrote that exact post internally 18 months ago. Then we spent the next 12 months dealing with everything the framework comparison didn't cover. This post is about those 12 months. Not the framework choice — the infrastructure, workflow, and operational problems that show up at scale but never make it into the comparison table. The framework comparison trap Most i18n framework evaluations look something like this: Criteria i18next FormatJS Polyglot Bundle size (core) ~40KB ~32KB ~3KB Lazy loading Plugin-based Built-in Manual ICU support Plugin Native None React integration react-i18next react-intl Manual TypeScript Good Good Weak Community Large Large Small This is accurate and useful for picking a l