If your team ships a localized product continuously, translations have a way of becoming the step everything waits on. The feature is done, the PR is green, and then it sits because the German and Japanese copy is blank. The fix a lot of teams reach for is to move translation into CI: when a PR changes the source locale, something translates the new keys and commits them back before merge.
That loop, source PR in, localized product out, is the whole goal. The rest is which tool runs the middle step.
A quick summary of the options: the tools worth knowing for this are ai-i18n if you want open source and don't mind wiring it up; hosted actions like Lingo.dev for a quick CI hook; the big TMS platforms (Crowdin, Lokalise, Transifex) if you have a localization team; and Localhero.ai (ours), built around the translate-on-PR workflow with glossary consistency and a review UI for non-developers. What separates them isn't the API call. It's how consistent the output stays over time and whether a non-developer can review it.
One thing to keep in mind while you compare: getting an LLM to translate one string is easy. Getting consistent, on-brand translations across hundreds of keys and many languages, PR after PR, so "Workspace" is the same word in German every time and the tone doesn't drift, is not. And whatever you pick, someone usually still wants to review the copy that matters before it ships.
There are quite a few ways to run that step now, from open-source GitHub Actions you wire up yourself to hosted services that run as an Action. Before the tools themselves, here's what actually separates them.
What "good" looks like for CI translation
Most of these tools look similar in a demo. The differences show up a few months in, on a real product with real churn. The things that matter by then:
- Delta translation. Translate only the keys that changed in the PR, not the whole file every time. It keeps CI fast and gives the model tighter context.
- Glossary and tone consistency. "Workspace" should be translated the same way in PR #200 as it was in PR #5. It helps when a tool remembers the edits you've made and picks up the patterns already in your codebase, so corrections stick instead of getting re-litigated every PR.
- A review surface. A YAML diff is not a place a PM or native speaker can sanity-check copy. Either you trust the output fully, or you need somewhere to review it.
- Commit-back vs PR. Committing to the same PR is convenient; opening a separate translation PR is safer for some teams.
i18n translation tools that run as a GitHub Action
ai-i18n (open source GitHub Action). A solid choice if you want full control and don't mind wiring it up. It translates i18n files with an LLM provider you choose (Anthropic, OpenAI, or self-hosted Ollama), uses content hashing to translate only changed strings, and commits results back. It handles XLIFF and JSON (flat and nested). You own the config and the maintenance. Best when you want to tune everything yourself and keep the model choice in your hands.
Hosted CI-action tools (Lingo.dev and a few others). A handful of hosted services run their own GitHub Action that translates on the delta and commits back. Lingo.dev is one of the more visible ones. They cover the basic translate-in-CI loop across a range of CI providers. Where they differ from each other (and from the option below) is less the CI mechanics and more what happens around the strings: how consistent terminology stays over time, and whether a non-developer can review the output. Worth a look if you mainly want the CI hook itself.
Crowdin / Lokalise / Transifex (TMS with GitHub sync). The established translation management systems. They sync with GitHub (Crowdin opens a PR when translations update) and are built for teams with dedicated translators: assigning work, tracking who translated what, managing big translation projects. Crowdin has documented support for both react-i18next and LinguiJS. If you have a localization team and a lot of long-form content, this is the category for you. If you're a product team that just wants UI strings translated on every PR, it's usually more platform than the job needs.
Tolgee. Open source with a hosted tier, an in-context editor, and CI integration. Supports the major JS frameworks (React, Vue, Angular, Svelte, Next) plus JSON and PHP .po. Good middle ground if you want an open-source core plus a UI.
Localhero.ai (ours). Built for product teams that ship continuously. It runs as a GitHub Action, translates the changed i18n keys on each PR, and focuses on the two things that make this hold up on a real product: a glossary and brand voice that stay consistent across PRs via translation memory, and a review UI a PM or native speaker can use instead of reading a YAML diff. Works with react-i18next, LinguiJS, Rails (YAML), and Django (.po). We're also adding review for translations a PR already includes, not just the ones we generate, so teams bringing their own translations get the same review surface. It's narrower than a full platform on purpose. If you want a focused tool for the translate-on-PR workflow rather than a large platform to configure, it's worth a look. If you want to self-host or stay fully open source, ai-i18n or Tolgee fit better.
A rough decision guide
- Want full control, open source, tune it yourself: ai-i18n or Tolgee.
- Have a dedicated localization team and long-form content: Crowdin / Lokalise / Transifex.
- A product team that ships continuously and wants UI strings translated per-PR, with glossary/brand-voice consistency and a review surface for non-devs: try Localhero.ai.
The pattern, regardless of tool
Whatever you pick, the setup that holds up is the same: translate only changed keys, protect placeholders before sending to the model, pass the glossary in context so terms don't drift, validate output before committing, and give someone a place to review brand-sensitive copy. The tool matters less than getting those pieces right.
The DIY route is genuinely viable, and we wrote up that pattern in detail here. The cost that's easy to undercount isn't the first build, it's the upkeep: the placeholder edge case that shows up six months later, the glossary logic, the model swap when prices change, the review surface someone eventually asks for. That work competes with your actual product for engineering time and attention. For some teams that ownership is worth it. For others, the reason to use a tool here is less the features and more not carrying that maintenance yourself.
Top comments (0)