Continuous localization: shipping strings on every commit

The old way to localize software was a "localization phase": build the product, freeze it, hand a giant file to translators, wait weeks, paste the results back, and pray nothing changed. For products that ship every week, that model is broken on arrival. Continuous localization replaces the big batch with a constant trickle.

The idea in one line

Treat translatable text like code: as soon as a new string lands in the repo, it's automatically sent for translation, and the finished translation flows back — often before the feature even ships. Localization stops being a phase and becomes a background process.

How it actually works

Strings live in the repo as resource files with stable keys.
A connector or CI step watches for new or changed strings on each push.
New strings are sent to the TMS automatically and queued for translators.
Finished translations are committed back (often as a pull request) and merged.
Automated QA runs on the way through, flagging tag or placeholder breakage.

The translator sees a steady stream of small jobs instead of one overwhelming file — which, counterintuitively, produces better quality, because small batches are easier to keep in context.

What it fixes

No more launch-day scramble. No more "we forgot to send the last sprint's strings". No more stale translations because the English changed after the file went out. The languages move at the speed the product moves.

Stop thinking of localization as a phase at the end. Think of it as a pipe that's always slightly flowing.

What it asks of you

Continuous localization rewards discipline upstream: externalized strings, stable keys, good context (screenshots or descriptions), and a willingness to let an automated flow do the file-shuffling. It also wants a language partner who can handle frequent small batches without per-job overhead — not everyone is set up for that cadence.

Do you need it?