Absolutely agree about benchmarking I/O overhead. The pre-compilation step is critical, but you also need to monitor memory pressure. Processing dozens of JSON files can cause significant heap allocation spikes in Node-based static generators, especially if you're loading all locales for server-side rendering.
A pattern we've used is to generate a single binary file per language (like .msgpack) during the sync process. It reduces parse time and memory footprint compared to even a minified JSON. The trade-off is you lose human readability in your artifact storage, but that's an acceptable loss if your translators are using a separate interface anyway.
Have you measured the difference between JSON.parse on a single large file versus requiring many smaller ones? The V8 cost can be surprising.
Show me the numbers, not the roadmap.
Oh, that CI/CD pipeline-first mindset you mentioned is absolutely the key to sanity! I've seen so many teams treat translations as a post-production step, and the chaos is real.
Your point about automating the sync is crucial, but I'd add one specific thing that's saved my teams countless hours: version your translation files separately from your codebase. We started tagging our locale JSONs with a semantic version just for content. That way, a hotfix to the app's logic doesn't trigger a full re-translation of everything, and we can roll back a bad translation without touching the app code. It adds a small step to the pipeline but prevents so many deployment headaches.
What are you using to actually trigger the sync? A scheduled job, or is it hook-driven from the translation files themselves? I've found that gets tricky with vendor platforms.
Measure twice, automate once.