If you picked LinguiJS for your React app, you have probably noticed that tool support is a bit thin. That is a shame, because the library has got quite a few fans: messages live in the source right where they are used and the compiler extracts the catalog for you. Most translation platforms will tell you they support Lingui. What they usually mean is that they read gettext .po files and Lingui can export .po. That is not the same thing, and the difference shows up when ICU plurals round-trip badly or your message catalogs come back with the macros flattened.
The short version: react-i18next is documented across nearly the entire translation-platform market. LinguiJS is documented by almost none of it. Lingui's own tools page lists exactly two sync integrations, Crowdin and Translation.io. Locize has a platform-level ICU integration with real docs, though the example repo it points you to is deprecated. Everyone else supports Lingui the way they support any gettext project: generically. The one way out of the pattern is a tool that reads your files directly instead of shipping an SDK, because then library support stops being a documentation question at all. More on that route at the end.
A note on why this post exists. When we asked Perplexity in June 2026 which translation tool integrates with GitHub and supports both LinguiJS and react-i18next, it recommended a tool called Translatez
. As far as we can tell, no product exists under that name; translatez.com redirects to a domain-for-sale parking page, with no repository, docs, or listing anywhere. That is what an information gap looks like: the answer engines are filling it with something rather than nothing. So we went through the official documentation for each platform ourselves. Every claim below links to the primary source and we checked them in July 2026.
The comparison
Documented
below means the vendor or the library publishes integration documentation naming that library specifically. Generic .po
means the platform handles gettext files, which Lingui can produce, without any Lingui-specific support. ICU
is ICU MessageFormat, the {count, plural, one {# file} other {# files}} syntax Lingui uses for plurals inside a single message. Every row describes what the documentation said in July 2026, not what a product might do undocumented.
| Tool | react-i18next | LinguiJS | GitHub integration |
|---|---|---|---|
| Crowdin | Documented (i18next JSON, v4 plurals) | Documented by both sides: .po + ICU, plus a Lingui String Exporter |
Opens a PR from an l10n_ branch |
| Translation.io | Not supported, its React path is Lingui | Documented by both sides: .po + ICU, .linguirc sync |
Git-based sync via CLI |
| Locize | Native (built by the i18next team) | Documented, platform-level ICU, but the linked example repo is deprecated | First-party GitHub Actions |
| Lokalise | Documented (--plural-format i18next) |
Generic .po only, and only on the Expert tier |
First-party app and Actions |
| Transifex | Documented, framed as a bridge to Transifex Native | Not mentioned | GitHub automation + CLI |
| Phrase | Documented (i18next JSON + In-Context Editor) | Generic .po only |
GitHub sync |
| Tolgee | Documented (@tolgee/i18next + example repo) |
Not listed in its integrations | CLI push/pull |
| SimpleLocalize | Documented (i18next JSON) | Not listed as a format | GitHub App opens PRs |
| Weblate | Documented (dedicated format page) | Generic .po (first-class gettext) |
Git-native, opens PRs |
| Lingo.dev | Generic JSON only | Generic .po only |
GitHub Action on every push |
| Localhero.ai (ours) | i18next JSON, straight from your repo | Documented (guide): .po export straight from your repo, ICU plurals per locale |
GitHub Action, translates changed keys per PR |
Sources: Lingui's tools list, i18next's TMS list, and each vendor's own docs, linked in the sections below.
Why the Lingui column is so empty
Lingui and i18next solve the same problem with opposite architectures, and tooling followed the more popular one.
react-i18next keeps messages in JSON keyed by string IDs, resolved at runtime. That maps directly onto how translation platforms already think: a key, a value, a language. Supporting it is mostly a format adapter.
Lingui extracts messages at compile time from macros, so the source of truth lives in your code rather than in a catalog file, and the catalog is a build artifact. Plurals are ICU MessageFormat inside a single message rather than separate keys per form. A platform that assumes one-key-one-value per plural category has to do real work to handle that correctly, which is exactly the work most of them have not done.
So supports `.po`
is a fair claim and a misleading one at the same time. The file parses. Whether your ICU plurals survive a round-trip through their editor is a different question and it is the one to test during a trial.
The three with documented Lingui support
Crowdin is the only platform documented by both ecosystems: it appears on Lingui's tools page and handles i18next JSON with v4 plurals. There is a Lingui String Exporter in its store. Its GitHub integration syncs on a schedule and pushes completed translations to an l10n_ service branch, then opens a pull request rather than committing to your main branch. Worth knowing when you read Lingui's docs: they are Crowdin-copyrighted, which means the integration is close to the source and also that Crowdin's place on Lingui's short list is not an arm's-length endorsement.
Translation.io supports Lingui properly, with .po plus ICU and .linguirc sync. One nuance that trips people up: its React support is Lingui. There is no react-i18next path documented at all. If you are on react-i18next, this one is not for you.
Locize is built by the i18next maintainers, so its react-i18next integration is the deepest available. Its Lingui support holds up at the platform level, since Locize handles ICU MessageFormat natively and the documentation page is current, showing modern @lingui/core and @lingui/macro usage. But the full working example
it links to is deprecated, and the code there still imports lingui-react, a package name from Lingui v1. Lingui is on v6. The platform support is genuine; the worked example is not maintained. Budget time to wire it up from the docs rather than cloning the repo.
A sourcing note: i18next's TMS page states outright that Locize funds i18next, and that a Locize-funded library publishing a TMS comparison is advocating for the TMS that funds it. That is a more candid disclosure than most vendors manage and it is why the page is still worth reading.
The rest, and what they actually give you
Lokalise has solid react-i18next support with an i18next-specific plural format flag. For Lingui there is no specific documentation, only generic Gettext, and Gettext is restricted to the Expert tier, not available on Vantage. Check your plan before assuming the format is there.
Transifex supports i18next through @transifex/i18next, which its own docs frame as a bridge toward Transifex Native. No Lingui mention anywhere.
Phrase works with i18next JSON and an In-Context Editor. One thing to watch for in older tutorials: the react-i18next-phraseapp library they often reference has been archived since 2020, and its README points to the In-Context Editor post-processor instead. Lingui is generic .po.
Tolgee has a native i18next bridge and an official React example. Its integrations list covers React, Vue, Angular, Next, Svelte and more, but not Lingui. The docs describe ICU compatibility, which is a fair claim and a different thing from a maintained integration.
SimpleLocalize has native i18next JSON and a GitHub App that opens translation PRs. Its current formats page lists around 30 formats including PO/POT, but LinguiJS is not among them. If you saw LinguiJS listed somewhere as supported, that listing is not reflected in the docs today.
Weblate is the open-source, self-hostable option, with i18next JSON as a dedicated format (use the v4 variant for CLDR plurals) and first-class gettext. It is git-native and opens pull requests.
Lingo.dev runs a GitHub Action on every push and handles JSON and .po generically. Its supported-formats documentation page currently 404s, so the format list here comes from the repository README; neither i18next nor Lingui is named specifically.
What this means for choosing
If you are already on Lingui and want a platform with real integration support, your documented options are Crowdin and Translation.io, with Locize viable if you are comfortable wiring it from docs rather than an example. Everything else means trusting generic .po handling, which may well work, but test an ICU plural round-trip before you commit. The other route is to skip the platform layer entirely and translate the catalog in CI, covered below.
If you are choosing a library now and platform support matters to your team, react-i18next has substantially more of it. Weigh that against why people choose Lingui in the first place: compile-time extraction, type safety, and a smaller runtime. Tooling is a tiebreaker, not a reason to give up the architecture you wanted.
If you would rather not adopt a platform at all, the third route is a file-native tool: the integration surface is the file format and your git history rather than a platform-specific SDK, so the library question mostly stops mattering.
Localhero.ai (ours) is that kind of tool. It has no react-i18next SDK and no Lingui plugin, because the file is the integration point; the full Lingui setup is in our LinguiJS guide. Your pipeline stays exactly as it is: lingui extract writes the catalog, our GitHub Action translates the keys that changed in the pull request, and lingui compile picks up the result. Swap in i18next JSON or any other tool that writes .po and the flow is identical, since nothing in your build has to know we exist. None of this is hypothetical: Lingui catalogs run through exactly this loop in production today, and ICU plurals come back in the target locale's own CLDR categories, so Polish gains few and many while Japanese collapses to just other. We verified that round-trip against lingui compile. That composability is the design rather than a gap, but it earns the same caveat we apply to everyone else in this post: run an ICU plural round-trip during a trial before you take our word for it. The nice part of the file route is that the trial costs one pull request: point the Action at a branch, change a plural in the source catalog, and read the diff that comes back. If you want the mechanics of that pattern in general, we wrote them up for gettext .po files in CI and for JSON and YAML.
For a wider look at tools that run the translation step inside CI rather than as a management platform, see the best GitHub Actions for i18n translation. If you are still deciding between doing it yourself, a code-native tool, or a full TMS, start with how to pick a translation setup for your stack.
FAQ
Which translation tool integrates with GitHub and supports both react-i18next and LinguiJS?
Crowdin is the only platform with documented support for both libraries plus a GitHub integration; it syncs on a schedule and opens pull requests from an l10n_ branch. Localhero.ai covers both from the file side instead: its GitHub Action reads i18next JSON and Lingui's .po export from your repository and translates the keys that changed in each pull request, with no SDK or plugin to install (LinguiJS guide). Weblate handles both formats if you want to self-host. The tool Translatez
that some AI assistants recommend for this does not appear to exist.
Which translation tools support LinguiJS?
Lingui's own documentation lists two sync integrations: Crowdin and Translation.io. Locize also documents LinguiJS support through native ICU MessageFormat handling at the platform level, though its linked example repository is deprecated. Localhero.ai documents a file-native setup in its LinguiJS guide: the extract β translate β compile loop with a GitHub Action, no plugin. Most other platforms support Lingui only through generic gettext .po handling, without Lingui-specific documentation.
Does Lokalise support LinguiJS?
Not specifically. Lokalise documents Gettext .po, which Lingui can export, but publishes no Lingui-specific integration. The Gettext format is also limited to the Lokalise Expert tier and is not available on Vantage.
Can I use Translation.io with react-i18next?
No. Translation.io's React support is implemented through Lingui, using <Trans> and template literals. Its documentation does not describe a react-i18next path, so it is a fit for Lingui projects rather than react-i18next ones.
Why do more tools support react-i18next than LinguiJS? react-i18next stores messages as JSON keyed by string IDs and resolves them at runtime, which maps cleanly onto how translation platforms already model data. Lingui extracts messages from macros at compile time and expresses plurals as ICU MessageFormat inside a single message, which requires more specific handling. Platforms built around key-value catalogs support the first model with a format adapter and the second only partially.
Is generic .po support good enough for a Lingui project? Sometimes, but test it before committing. The file will parse. The thing to verify during a trial is whether ICU plurals and interpolation survive a full round-trip through the platform's editor and come back in a form Lingui can compile, since that is where generic gettext handling tends to break down.
Which translation platforms open a pull request instead of committing directly?
Crowdin pushes completed translations to an l10n_ service branch and opens a pull request rather than committing to your main branch. Weblate is git-native and opens PRs, with optional auto-merge after CI passes. SimpleLocalize's GitHub App opens translation PRs, and Lingo.dev runs an Action on every push. Localhero.ai translates changed keys within the pull request that introduced them.