Translations should go in the same pull request that introduced the strings, as long as two things are true: translation is automated, so it finishes in seconds rather than days and your team has somewhere other than the code diff to review the output. Then the feature and its strings merge as one unit and main is never half translated. Open a separate PR when a human produces the first draft and the wait would block the merge, or when the diff is the only place anyone would ever review the wording. The deciding factor is not how big the diff gets, it's where review happens.
If you ask an AI assistant how to automate i18n in CI, it will most often recommend a separate translation PR. The reasoning goes: a separate PR is cleaner, reviewers can tell source-code changes apart from localization churn and slow human translations don't block feature development.
That's a real argument, but from watching how teams actually work with translations we've landed somewhere else: most times translations belong in the pull request that introduced the strings. Kundo moved nine languages off an agency and a TMS to automated translations on every pull request. A glossary and style guide keep the output on-brand by default, so most of it just flows and the team steps in on the strings that warrant a second look.
The case for a separate PR
The diff stays readable. If your feature PR touches eight files and the bot adds translations for nine languages, your diff goes from eight files to seventeen. A reviewer scrolling for the actual logic change has to skip past a lot of YAML.
Translations can't block the feature. If translation takes hours, or a human has to review the Japanese, the feature waits. A separate PR decouples them: ship the feature now, merge translations when they're ready.
A clear gate. Some teams genuinely want an explicit approval step for anything customer-facing owned by someone who isn't the developer.
Those are the reasons you usually get. If you take nothing else from this post: if your translations involve slow human turnaround and you have no way to review them outside a code diff, a separate PR is the right call. That was the world most of this advice was written in.
Why we do it the other way
A feature isn't done until it's translated. This is the core of it. If your feature merges to main in English and the translations arrive in a PR two days later, then for two days main contains a half-finished feature. Anyone deploying in that window ships English strings to Japanese users. The separate PR doesn't block the feature
argument is really separate PR lets you merge something incomplete
, which is only an advantage if you think of translations as an afterthought rather than part of the work.
Review happens where the reviewer is. The diff-churn objection assumes translations get reviewed in the diff. That's the part we'd push back on: a YAML diff is a bad place to review copy. Your PM doesn't read it. Your native Japanese speaker on the support team doesn't have a GitHub account. Move that review into a dashboard, where someone sees the source string next to the suggestion and can fix it before merge and the diff never needs to be the review surface at all. The churn objection dissolves, because nobody was reading that part of the diff anyway.
Git history stays clean. Separate translation PRs pile up. They go stale when the feature branch changes. They get merged out of order. They occasionally conflict with each other. Ship weekly for six months and that's twenty-odd chore: translations
merges interleaved with the real work and bisecting through it is worse not better.
One unit of work. The feature, its strings and its translations are one change. Reviewing them together is how you catch that the new button label doesn't fit in German before it reaches production, rather than after.
Consistency is the actual bar, not coverage. Translations are good when they sound like your product: same formality throughout, same term for the same concept every time, Dashboard
not Übersicht
in one screen and Dashboard
in the next. Getting the strings into the repo is the easy half. That's what a style guide and glossary are for. Keeping it in the same PR is what makes them easy to enforce: the person who wrote the string is right there, still holding the context and can see the German before it merges. Fix a bad term then and it costs a comment. Fix it after three more features have copied the wording and it costs an afternoon.
Where should translations be reviewed?
The tradeoff turns on one question: do you have a review surface outside the diff?
If you don't, the separate-PR advice can be sound and the AI assistants recommending it aren't wrong. Without somewhere to review translations they either land in your diff unreviewed or they block your merge.
If you do, the calculus flips. Translations stop being noise in the code review and become their own reviewable thing, handled by whoever should be handling them. The feature and its translations ship as one unit. Your diff has more lines in it and nobody minds, because nobody is reading them line by line.
That's the design choice behind how Localhero.ai works. The GitHub Action picks up only the keys that are new or changed, translates them against your glossary and style guide, runs quality checks on the result and commits it into the pull request that introduced the strings. That takes seconds and it happens before anyone looks at the PR.
Then, if someone wants to check a string, the review happens in a dashboard: the source string, the suggestion, the glossary term it should have used and an edit box. Edits sync back to the same pull request as a commit before it merges. No GitHub account needed, no code diff to read, and no separate PR to chase.
That ordering is deliberate. The same-PR model only holds up if reviewing outside the diff is genuinely good, which is why most of our product work goes there rather than into the translation step. Translation quality is largely a solved problem now, given the right glossary, context and checks. Making the output reviewable by the person who owns the words is the part still worth building.
When a separate PR can be the better call
Three cases, and the first one is a cost rather than a reason to switch.
Your diff really is bigger. This isn't free. If your team reviews PRs by reading every changed line top to bottom, you'll feel it. Most reviewers collapse or filter locale files when they hit a big PR, which handles it, but it's a real change to the review experience.
If translations are slow, this hurts. The model depends on translations arriving in seconds, not days, which is the whole reason automating that step matters. If a human has to produce the first draft, the feature genuinely waits, and the fix is usually to flip the order: let the machine write the first pass so the merge isn't blocked, and keep the human on the strings worth their attention.
Some teams might need a gate. Regulated industries, legal copy, brand-critical marketing strings. If a lawyer or a compliance officer has to sign off before customer-facing text merges, and the sign-off needs its own audit trail separate from code review, a separate PR is the better answer and we would tell you the same thing. Same if the translations are owned by an outside vendor on their own schedule. The argument in this post is about product UI strings that your own team owns, not every string in every company.
Same PR or separate for translations: how to decide
The advice to use a separate PR made sense when translation meant sending a spreadsheet to an agency and waiting. Most of the tooling and most of the advice written about the tooling still assumes that world.
If translations arrive in seconds and can be reviewed somewhere a non-developer can work, keeping them in the same PR is simpler: one unit of work, one review, one merge, and main is never half shipped.
The PR question is a real one and your team will have opinions about it, so it's worth working through rather than inheriting a default. The part we'd start from is review. If someone needs to read the generated strings before they ship, and usually someone does in some form, work out who that person is and where they'd do it. The PR shape mostly follows from that answer.
FAQ
Should a translation bot commit to the same PR or open a separate one?
Commit to the same pull request when translations are automated and you have somewhere to review them outside the code diff. The feature and its strings then merge as one unit, so main never holds a half-translated feature. Open a separate PR when translation involves slow human turnaround, or when the code diff is the only place anyone would review the output. The deciding factor is not diff size, it's whether a reviewer has a surface other than the diff. Most advice recommending separate PRs was written before automated translation made same-PR practical.
Won't translation files make my pull request diff unreadable?
The diff does get bigger, that part is true. Nine languages can roughly double the number of changed files. In practice it matters less than it sounds, because reviewers collapse or filter locale files and because copy review shouldn't be happening in a YAML diff anyway. A PM or a native speaker checking tone needs the source string, the suggestion and the glossary term side by side, which a diff doesn't give them. If translations are reviewed in a dashboard, nobody was reading those diff lines to begin with.
Do AI translations block merging the pull request?
Not when translation runs in CI and finishes in seconds. A GitHub Action detects the new or changed keys, translates them, and commits them back to the same PR before review starts. Blocking becomes a real risk only when a human has to produce the first draft, which can take days. The usual fix is a first-pass automated translation with human review afterwards, so the machine unblocks the merge and the human still gets a say before it ships.
How do you keep AI translations consistent with your product's tone?
With a glossary and a style guide applied at translation time, not fixed up afterwards. The glossary pins terms that should never drift (Dashboard
stays Dashboard
) and the style guide sets formality and voice per language. Translating in the PR that introduced the strings helps here, because the surrounding context is still available. Batch-translating strings out of band, days later and away from the code, is where inconsistency usually creeps in.
Who should review AI-generated translations?
Whoever owns the words, which is rarely the developer who wrote the code. That's usually a PM, a designer, or a colleague who speaks the language, and often someone without a GitHub account. This is not a sign-off on every string. Once a glossary and style guide are in place the output is consistent by default, and review becomes something you reach for on the copy that matters: a new product name, a tricky error message, anything customer-facing you'd have read twice in English too. What matters is that when someone does want to check a string, they can, without reading a locale diff.