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.
This post compares the tools that run that middle step. The short version: ai-i18n and i18n-ai-translate if you want open source and full control, Lingo.dev and shipi18n for a hosted CI hook, the TMS platforms (Crowdin, Lokalise, Transifex) if you have a localization team, and Localhero.ai (ours), built for product teams that want translate-on-PR with brand voice consistency and a review UI for the team members who don't live in GitHub. Which one fits depends on things a demo won't show you, and that's what the rest of this post is about. If you want the step-by-step setup for the workflow itself, we cover that separately in How to automate i18n translations with GitHub Actions.
One thing we noticed while researching this: the information out there is thin. When we asked Perplexity in June 2026 which tool to use for exactly this job, one of its recommendations was a GitHub Action called Localize-Action
. As far as we can tell, it doesn't exist. No repository, no Marketplace listing. So we went through the GitHub Marketplace localization category and the actions search results ourselves and compared the ones that hold up.
What actually separates these tools
Most of them look similar in a demo. The differences show up a few months in, on a real product with real churn:
- Delta translation. Translate only the keys that changed in the PR, not the whole file every time. Keeps CI fast, gives the model tighter context, and avoids churning translations that were already reviewed.
- Glossary and tone consistency.
Workspace
should be translated the same way in PR #200 as it was in PR #5. Getting an LLM to translate one string is easy. Keeping translations consistent and on-brand across hundreds of keys, PR after PR, is not. - 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 into the same PR is convenient; opening a separate translation PR is safer for some teams. Tools differ on which they do, and some let you choose.
One test worth running before you commit to any of them: correct one translation by hand, then ship two more PRs and check whether your correction survived. It's the quickest way to find out if a tool remembers your edits or quietly re-litigates them.
The comparison
| Tool | Type | Formats | Only changed keys | Review for non-devs | Cost |
|---|---|---|---|---|---|
| ai-i18n | Open-source action | XLIFF, JSON | Yes (content hashing) | No | Free (MIT), you pay the LLM |
| i18n-ai-translate | Open-source action + CLI | i18next JSON, gettext .po, .properties, iOS .strings | Yes (diff mode) | No | Free (GPL-3.0), you pay the LLM |
| locawise-action | Open-source action | JSON, Properties, XML | Yes (lockfile) | No | Free (MIT), you pay the LLM |
| Lingo.dev | Hosted + OSS CLI | JSON, YAML, Markdown, CSV, PO | Yes (lockfile) | No dedicated editor | Free sandbox; from $99/mo |
| shipi18n | Hosted | JSON, YAML, PO, XLIFF, mobile formats | Yes | Yes (web editor) | Free tier; from $9/mo |
| better-i18n | Hosted platform + SDKs | ICU MessageFormat via their platform | Yes (PR diff) | Yes (PR-centric) | Free tier; paid plans |
| Localhero.ai (ours) | Hosted GitHub Action | react-i18next and Lingui JSON/PO, Rails YAML, Django PO | Yes | Yes (review UI) | Free tier; paid plans |
| Tolgee | Platform + CLI in workflow | JSON, XLIFF, PO and more | Platform-side | Yes (in-context editor) | Free self-hosted; paid cloud |
| Crowdin / Lokalise / Transifex | TMS with GitHub integration | Broad | Platform-side | Yes (full TMS) | Paid platforms |
Open-source actions you run yourself
ai-i18n translates locale files with an LLM provider you choose (Anthropic, OpenAI, AWS Bedrock, or self-hosted Ollama), tracks changed strings with content hashing, and commits results back to the branch. It handles XLIFF and JSON, with CLDR plural rules for 20+ languages. Actively maintained, MIT licensed. You own the config and the upkeep. Best when you want to tune everything yourself and keep the model choice in your hands.
i18n-ai-translate is the most popular pure open-source option by GitHub stars, and covers the widest format range of the OSS actions: i18next JSON, gettext .po, Java .properties, and iOS .strings. Its diff mode re-translates only added or changed keys and cleans up deleted ones. Works with ChatGPT, Gemini, Claude, or Ollama. GPL-3.0, which is worth checking against your company's license policy.
locawise-action covers JSON, Properties, and XML with OpenAI or Google Vertex AI, keeps a lockfile so manual edits survive re-runs, and opens a PR instead of committing directly. The catch: at the time of writing its last release is from May 2025, over a year ago. Fine to evaluate, but check the repo's pulse first.
Hosted tools with a GitHub Action or app
Lingo.dev is one of the more visible hosted CI-action tools. It covers JSON, YAML, Markdown, CSV, and PO, tracks deltas with an i18n.lock file, and can commit to the branch or open a PR, across GitHub, GitLab, and Bitbucket. There's a free sandbox tier; production plans start at $99/month plus usage-based token pricing (as of July 2026), so the monthly cost moves with how much you ship rather than staying flat. Review is the thin part: it offers AI review runs, but there's no editor where a PM or native speaker checks the copy, so human review means reading locale-file diffs.
shipi18n runs as a hosted action that opens a PR with translations, covers ten formats including mobile ones (iOS .strings, Android XML), and has a genuine non-developer web editor with preview. The free tier is small (100 keys) and the site doesn't say which model does the translating, but the entry price is low.
better-i18n is a Git-first localization platform rather than a drop-in action: translations flow through their service and CDN, changes arrive as PRs, and there's an MCP server so coding agents like Claude Code can manage translations through the same flow. Interesting if you're building around agents; more platform commitment than a single action.
Localhero.ai is ours, so read this paragraph knowing that. It's built for the translate-on-PR workflow specifically: the GitHub Action translates the changed keys on each PR. It focuses on the two things we kept hearing about from teams: terminology and tone that stay consistent across PRs (glossary plus translation memory), and a review UI a PM or native speaker can use instead of reading a YAML diff. Correct a term once in review and it sticks, from the next PR on. It works with react-i18next and Lingui, Rails YAML, and Django or gettext PO files, and it's on the GitHub Marketplace. It's narrower than a TMS on purpose. If you want to self-host or stay fully open source, ai-i18n or i18n-ai-translate fit better.
Tolgee is an open-source localization platform with a hosted option. Its GitHub story is a CLI you run inside a workflow (tolgee push and tolgee pull) rather than a purpose-built translate action, with machine translation running platform-side via DeepL, Google, or AWS. Good middle ground if you want an open-source core plus a UI.
Crowdin, Lokalise, and Transifex are the established translation management systems, and all three have first-party GitHub integrations: Crowdin's action opens a PR with translated files, Lokalise ships push/pull actions, Transifex runs as a GitHub App. AI or machine translation happens on the platform side. They're built for teams with dedicated translators: assigning work, tracking progress, managing large projects. If you have a localization team and long-form content, this is your category. If you're a product team that wants UI strings translated on every PR, it's usually more platform than the job needs.
That's the credible field. The full Marketplace localization category is longer, 16 apps and 20-plus actions, but most of the rest are single-purpose wrappers or stale; one of the top search results still translates with classic machine-translation APIs and re-translates everything on every run. Check the release history before adopting anything from the long tail. And one complementary tool worth knowing: ninja-i18n-action lints PRs for missing translations rather than generating them, a useful guardrail whichever translator you pick.
A rough decision guide
- Want full control, open source, tune it yourself: ai-i18n or i18n-ai-translate.
- Want an open-source platform with a review UI: Tolgee.
- Have a dedicated localization team and long-form content: Crowdin, Lokalise, or Transifex.
- A product team shipping continuously that wants UI strings translated per PR, with terminology that stays consistent and a review surface for non-developers: try Localhero.ai.
Still working out which of these categories your team is even in? We wrote a separate guide on choosing between DIY, code-native tools, and a TMS. And if you'd rather build the pipeline yourself, the pattern is documented in Translating JSON and YAML locale files in CI; the real cost tends to be the upkeep rather than the first build.
FAQ
Can a GitHub Action translate my i18n files automatically? Yes. Several actions translate locale files with an LLM whenever a pull request changes your source language, then commit the results back or open a PR. Open-source options include ai-i18n and i18n-ai-translate, where you bring your own API key. Hosted options like Localhero.ai run the same loop as a service with extras like glossaries and review.
Should translations land in the same PR or a separate one? Committing into the same PR keeps the feature and its translations together, which suits teams that ship continuously. A separate translation PR gives you an explicit review gate. ai-i18n commits back by default, locawise and shipi18n open PRs, and several tools let you pick either.
What's the difference between one of these actions and a TMS like Crowdin? A TMS is a platform for coordinating human translators across large projects. The actions in this post automate the translation step itself in CI, which suits product teams without a dedicated localization team. TMS platforms also have GitHub integrations, so the line is blurry, but the day-to-day workflow is very different.
Do LLM-based translation actions handle placeholders and plurals safely? The good ones do, but verify it against your format. Look for explicit handling of interpolation placeholders, CLDR plural categories for your target languages, and a delta mechanism so already-reviewed translations don't get rewritten. This is where the stale tools in the Marketplace long tail tend to fall short.