Continuous localization is the localization workflow run at the pace of the code rather than the pace of a quarterly release: every merge that changes a string is picked up, the changed keys are handed off, the translations come back and are read into the catalog, and the locale build is tested with every build of the product, so a release never waits for translation and never ships with an English string it did not know about. Localization workflows that run continuously depend on the same record a quarterly one does, the catalog, the memory and the handoff, kept automatically rather than by hand. This page sets out what the continuous loop looks like, what a localization workflow has to keep to run it, and where the free worksheets on this site fit.
The loop, run on every merge
A merge changes a string; the catalog records the new or changed key with a status of new in every locale; the changed keys are gathered into a handoff generated from the record, on a schedule or on demand; the translator's file comes back and is read against the keys, each translation taking the reviewer's status; the locale build runs with the product's build and the defects are counted against the threshold. Continuous localization is that loop with no step done by hand, and the record is what makes each step start from the last one's state rather than from a person's memory.
What the workflow has to keep
The catalog, so a changed key is known the moment it is merged. The memory, so the handoff is costed from the leverage and the translator's tool offers the matches. The handoff, generated from the record so it never carries a stale key. The read-back against keys, so a translation lands where it belongs. And the test results per locale per build, so the ship decision is a reading. The translation memory leverage sheet and the localization testing checklist on this site work the two figures of the loop with no account, and Xlifflane Pro keeps the record between them.
Where continuous localization breaks on a small team
At the read-back, when the translator's file comes back for a key that was renamed after the handoff; at the plurals and placeholders, when a translation comes back with a placeholder missing and ships; and at the test, when the locale build is not part of the product's build and runs only before a release. Each is a step done by hand somewhere in a localization workflow that was supposed to be continuous, and the fix is the same each time: make the record do it.
Questions people ask about continuous localization
Does continuous localization mean translating on every commit?
It means the changed keys are known on every commit and handed off on whatever cadence the team sets, daily or per sprint. The translator sees batches; the catalog sees every change.
What is a localization workflow, in one line?
Freeze, cost, hand off, read back, test, ship: the six steps a release's strings go through, kept as a record so the next release starts from the last one's state.
Can a team without a build pipeline run continuous localization?
It can keep the catalog current and the handoffs regular, which is most of the value. The locale build tests run before each release instead of each build, and the checklist on this site scores them the same way.
Sources
- OASIS, XLIFF Version 2.1: the XML Localisation Interchange File Format the handoff is generated in
- ICU User Guide, Formatting Messages: MessageFormat, the syntax for plurals, selects and placeholders inside a localised string
- W3C Internationalization, Localization vs. Internationalization: what each term covers and why the second has to come first