Automating translations

The usual shape is a CI job that runs on pull requests. It compares the branch against the base branch, finds locale keys that are new or changed, translates those and commits the result back to the same pull request. Nothing runs on merge and nothing re-translates the whole catalog every time.

The part teams usually get wrong is the diff. Most CI systems do a shallow clone by default, which leaves nothing to compare against, so the job either translates everything or nothing.

Partly. A prebuilt GitHub Action exists, so GitHub is the path with the least setup. Anywhere else that runs a shell, you run the CLI yourself with a --changed-only flag, which does the same base-branch diff. You need Node 18 or later, an API key in the runner environment and a clone that actually contains the base branch.

The one thing that does not carry over is branch detection. A command that reads GitHub's own environment variables cannot identify the branch on other runners, so use the explicit translate command instead.

Same PR, in most cases. The argument for a separate PR is that it keeps the code diff clean, but that assumes reviewers have somewhere else to check the copy. If they do not, splitting means the strings ship unreviewed.

The deciding factor is whether a reviewer has a surface outside the code diff, not how large the diff gets.

For a one-off pass, yes, it will look fine. What degrades is consistency across runs: the same term rendered three different ways in three files and silent omissions when a batch is large. Agents also tend to forget the step entirely, which is how untranslated strings reach production.

An agent is good at writing the source string and bad at guaranteeing the same decision twice. So it is worth making translation a deterministic build step and letting the agent do what it is actually good at. If you work in Claude Code or Cursor, an agent skill can give your assistant your glossary and naming conventions so the strings it writes match your existing patterns.

YAML for Rails, JSON for React and Vue (i18next, next-intl, react-intl, LinguiJS, vue-i18n) and gettext .po for Django, Phoenix and Lingui.

The .po format behaves differently from key-based formats. The source text is the key, so editing copy orphans its translations and how many plural forms a message needs depends on the target language. Lingui's .po is different again, storing ICU MessageFormat inline rather than using gettext's indexed plural slots.

Two mechanisms. A glossary pins terms that must always translate a particular way, or never translate at all. A style guide captures tone, formality and how you address the user, which matters more in languages with a formal and informal register than it does in English.

Set both up front. Without them the output reads like a translation instead of like your product.

Reviewers edit in a dashboard and the edits sync back to the originating pull request as a commit. Someone who does not use git, a PM or a native-speaker colleague, can correct copy without a checkout.

You can also turn off automatic translation per language, which teams do when they have a native speaker for one market and want AI for the rest.

Take translation off the release path entirely. If it runs per pull request rather than per release, there is no batch to prepare and nothing to wait for at the end: the strings for a feature are translated by the time that feature merges.

The pattern that holds up at a weekly cadence is the same one you already use for tests. Tests run, translations generate, code ships. What breaks cadence is treating localization as a phase, collecting strings into a handoff and waiting for them to come back, because that queue only ever grows with release frequency.

Reviewing is the part worth designing for. If a native speaker has to read every string before merge, that becomes the new bottleneck, so most teams reviewing at this cadence check the high-traffic surfaces and let the rest ship, correcting later if needed.

Sometimes, genuinely. If you employ translators who need a web workbench, translation memory and vendor management, a TMS is doing real work that a CI step does not replace.

What a TMS costs you is a second system of record. Strings live both in the repo and in the platform, so someone has to keep them in sync. If your strings already live in git and the bottleneck is that nobody remembers to translate them, a CI step is the smaller fix.

It depends on volume, but usually less than the coordination it replaces. The thing to compare is not per-word rates against an agency. It is the total of what you spend now, including the engineering time spent shepherding strings between systems.

You cannot read everything once you are past a few languages. What works is sampling plus targeted checks: verify that glossary terms are honoured, that placeholders and ICU structure survived and that plural categories match the target language rather than the source. Then have a human read the high-traffic surfaces.

By making the automated path the default and reserving human attention for the copy that matters. Most teams that struggle here are trying to run a manual process that nobody is assigned to.

Broadly three: do it yourself with scripts, use a code-native tool that runs in CI, or adopt a full TMS. Which fits depends on how often you ship, whether you employ translators and whether your strings already live in the repo.