Translation Pipeline and Workflow Vocabulary
5 exercises — 5 exercises practising TMS workflow vocabulary, continuous localization pipelines, handoff stages, and translation review terminology.
0 / 5 completed
Quick reference: localization pipeline stages
- String extraction — identifying translatable strings in code and writing them to resource files (en.json, messages.xliff)
- TMS — Translation Management System — Crowdin, Phrase, Lokalise; manages projects, workflows, TM, and glossary
- Continuous localization — automated pipeline: extract on commit → upload to TMS → translate → sync back → merge; eliminates release crunch
1 / 5
A developer describes their team's localization approach: "We send content to translators two weeks before each release." A localization engineer calls this a batch waterfall approach and suggests switching to continuous localization. What is the key difference?
Continuous localization integrates translation into the development workflow — the translation backlog is small and constant rather than large and crisis-driven at release time.
The engineering implementation: a CI job (triggered on merge to main) runs string extraction, compares new/changed strings to the previous baseline, uploads only the delta to the TMS via API, and the TMS immediately assigns the new strings to translators. Another CI job (scheduled every few hours) syncs completed translations back to the repo via a bot PR. The result: when a feature ships, translations are already in the repo for most languages. Release-blocking "waiting for translations" situations become rare. The caveat: translators need context for new strings — screenshots, descriptions, and in-context review tooling become more important in continuous workflows.
Key vocabulary:
• continuous localization — strings extracted and uploaded to TMS automatically on every commit
• localization crunch — the time pressure created by batch waterfall: all translations due right before release
• delta upload — uploading only new or changed strings to the TMS (not the full file) to minimize translator work
The engineering implementation: a CI job (triggered on merge to main) runs string extraction, compares new/changed strings to the previous baseline, uploads only the delta to the TMS via API, and the TMS immediately assigns the new strings to translators. Another CI job (scheduled every few hours) syncs completed translations back to the repo via a bot PR. The result: when a feature ships, translations are already in the repo for most languages. Release-blocking "waiting for translations" situations become rare. The caveat: translators need context for new strings — screenshots, descriptions, and in-context review tooling become more important in continuous workflows.
Key vocabulary:
• continuous localization — strings extracted and uploaded to TMS automatically on every commit
• localization crunch — the time pressure created by batch waterfall: all translations due right before release
• delta upload — uploading only new or changed strings to the TMS (not the full file) to minimize translator work