Auto-Translating an Entire Project: What It Actually Takes (and When Not To)

"Auto-translate the whole thing" is one of those features that sounds like it makes the rest of a localization workflow unnecessary. It doesn't — it changes where your team's time goes, from typing translations to reviewing them. That's a real improvement, but only if you understand what the machine is actually doing before you point it at a production project.

What "auto-translate everything" actually does

Under the hood, it's the same single-string suggestion you'd get from clicking "Suggest" on one row, run in a loop across every string in every target language that doesn't already have one — or, if you choose the more aggressive mode, across every string regardless of whether a translation already exists. Each call goes to whichever engine you picked (Claude, Google Translate, or DeepL), and the result lands in the editor exactly where a human-typed translation would, with the same review status logic applying afterward.

That last part matters: a bulk auto-translate run from a translator account still produces suggestions that need review, same as always. It's only when an owner or maintainer runs it — someone whose individual suggestions are already auto-approved — that the output goes live without a second pair of eyes. That's a deliberate design choice, not an oversight, and it means the decision to skip review is yours to make explicitly, not something that happens by default.

Where it's genuinely the right call

• New languages on an established project. If English and Spanish are fully reviewed and battle-tested, auto-translating the initial pass for a new target language gives your reviewers a real draft to correct instead of a blank editor — correcting is faster than composing.
• Filling gaps after a content push. Shipped 40 new strings for a feature launch and don't want five languages sitting untranslated for a week? Auto-translate the untranslated-only mode, then let reviewers work through the queue at normal pace.
• Internal tools and admin panels. Lower stakes than customer-facing copy — a slightly awkward machine translation in an internal dashboard costs a lot less than one in your checkout flow.

Where it needs a human first, not last

• Anything with legal, medical, or financial consequences. Terms of service, consent language, dosage instructions — the cost of a subtle mistranslation is too high to let a bulk run skip review, no matter how good the engine is on that language pair.
• Idiom-heavy marketing copy. Machine translation is strongest on literal, structured text and weakest on wordplay, humor, and brand voice — exactly the strings where a human review pass earns its keep.
• Languages with sparse training data. Quality varies a lot by language pair. Spot-check a sample of a low-resource language's output before trusting a full-project run the same way you'd trust one in a widely-spoken language.

The overwrite mode is the dangerous button, not the safe one

Re-translating everything from scratch — including strings a human already reviewed and approved — is the mode to reach for rarely and deliberately, usually after switching MT providers or fixing a systemic terminology problem across a project. It's also the one most likely to silently undo a correction a reviewer made months ago for a good reason that isn't written down anywhere. If you're not sure whether to use "untranslated only" or "everything," untranslated-only is very likely the answer.

Treat the output as a first draft, every time

The honest framing for auto-translate isn't "translation done" — it's "first draft done, in every language, instantly." That's still a large amount of typing your team no longer has to do by hand. But the review workflow that exists for individual suggestions exists for a reason, and running a thousand strings through it at once doesn't change what any single one of them needs before it ships to a real user.