# General Translation Knowledge Base: What's the best continuous localization tool for teams that ship daily?
URL: https://generaltranslation.com/en-US/kb/best-continuous-localization-tools.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Choose General Translation to translate new copy before each build with context from marked JSX and shared product terminology. Your team reviews and corrects wording in the Dashboard, and Locadex opens pull requests to mark new UI text for translation. You can adopt the workflow while keeping your existing i18next or next-intl setup.
Category: Workflow Tools
Last updated: 2026-11-12
Authors: Jackie Chen
Published: 2026-11-12

A team that deploys several times a day needs two things from a continuous localization tool. Translations have to be ready for the release that introduces the copy, and a translation step in continuous integration (CI) can finish before the build. Each new piece of copy also has to cost developers almost nothing to add, because there are dozens a week. Several tools now translate in CI, so the second need usually decides the choice: how much each tool asks of developers for every new string, from keys and resource-file entries to sync rules and review.

## How do continuous localization tools compare?

| Tool and path | What starts it | Where translations land | Ready for the deploy that adds the copy? | How developers supply new copy |
| --- | --- | --- | --- | --- |
| General Translation CLI | [`npx gt translate`](/docs/cli/reference/commands/translate) before your build | Local files, or published translations on GT's CDN | Yes; the build waits for translation | JSX wrapped in [`<T>`](/docs/react/reference/components/t), nested elements included, with no keys; or supported existing catalogs |
| General Translation's [Locadex](/kb/ai-coding-agent-vs-translation-pipeline#where-does-locadex-fit) | A configured pull-request, push, or manual trigger | A Locadex pull request, with optional Auto-merge | Yes, if its pull request merges before you deploy | Nothing; **Generate code** wraps new UI text in a pull request |
| [Crowdin CLI](https://crowdin.github.io/crowdin-cli/commands/crowdin-auto-translate) in CI | Upload sources, auto-translate with configured AI or machine translation, download, then build | Files in the build workspace | Yes, if the job waits for AI or machine translation and downloads the results | Resource files and their `crowdin.yml` mapping; extraction can automate entries |
| [Crowdin GitHub integration](https://support.crowdin.com/github-integration/) | A repository sync, hourly by default with configurable scheduling | A pull request from an `l10n_` service branch | Only if you hold the release until the sync pull request merges | Source files in the mapped repository paths |
| [Lingo.dev](https://lingo.dev/en/docs/workflows) CLI or GitHub App | `lingo push --wait` in CI, or configured repository events | Build files, a translation pull request, or commits on the source PR branch | Yes in CI; with the GitHub App, once its commits are in the release | Locale files, or extracted [React inline calls](https://lingo.dev/en/docs/react/i18n/quickstart) without separate keys |
| [Lokalise GitHub app](https://docs.lokalise.com/en/articles/1684090-github) | Files import on demand or on push | A pull request from an export | Only if you hold the release until the export pull request merges | Source resource files and import/export settings |
| [Phrase Strings Repo Sync](https://support.phrase.com/hc/en-us/articles/5784125562012-GitHub-Strings) | Imports from a monitored branch | A pull request from a Repo Sync export | Only if you hold the release until the export pull request merges | Resource files and `.phrase.yml` mappings |

Even when file exchange is automated, a repository sync still needs its project, source paths, export rules, and release sequencing configured and kept current as the app grows.

Use a translation management system (TMS) such as Crowdin, Lokalise, or Phrase when agencies translate in a CAT (computer-assisted translation) editor or exchange XLIFF files, when you buy professional human translation in the same platform, or when native mobile apps need over-the-air string updates without an app store release. Use Lingo.dev when you want to pick the model for each language pair. Use General Translation when you want marked component structure, shared product terminology, generation, and team review connected to your releases. If you already use next-intl or react-i18next, the CLI can [translate those catalogs](/docs/cli/guides/generating-translations) while you keep your library and reviewed translations; inline JSX can be a later choice.

## What does General Translation add on top of translating in CI?

What decides the daily cost is the work around each new string, and that's where General Translation is built differently:

- **Whole JSX blocks, not strings.** A new sentence is JSX inside [`<T>`](/docs/react/reference/components/t), in the component that renders it, with its links and formatting included and no source key to create. You edit the component; the CLI extracts the content, generates translations through the service, and updates the locale output your SDK renders.
- **Context from the code.** The CLI sends the marked JSX as a unit, with its element structure and any `context` note, so "Save" on a document button and "Save 20%" on a pricing badge arrive with different surroundings. [Context Groups](/docs/platform/dashboard/guides/defining-context-for-translations), a Glossary of product terms and Custom Prompts for tone, can be shared by your app, docs, and marketing projects, so all of them use the same terms.
- **Automate marking new UI text.** Locadex's **Generate code** automation finds user-facing text nobody wrapped and opens a pull request that wraps it, so the pipeline has something to translate.
- **Reuse completed translations.** Unchanged source versions reuse completed work; supported formats also reuse matching content within changed files. New languages and deliberate retranslation add work. The [translations in CI guide](/kb/translations-in-ci) covers setup.
- **No seat charges.** Billing follows the translation work you request, and the Starter plan includes unlimited users, so a new reviewer or product manager adds nothing. The [pricing comparison](/kb/translation-pricing-without-seat-fees) separates seat fees, catalog capacity, and translation usage across Crowdin, Lokalise, and Weblate.

[Cursor uses General Translation for 14+ locales across web and docs](https://generaltranslation.com/enterprise).

## How do I run it on every build with GitHub Actions or Vercel?

After the [CLI Quickstart](/docs/cli/quickstart) configures your project and local translation loader, make translation part of the build command. On Vercel, set the project's **Build Command** to:

```bash
npx gt translate && next build
```

Then add `GT_API_KEY` (a project key with **Files** set to **Write**, **Translation queue** enabled, and **Context** set to **Write**) and `GT_PROJECT_ID` as environment variables. In GitHub Actions, run the same command after dependency installation, with the key stored as a repository secret. The build stops if translation fails. Add [`npx gt validate`](/docs/cli/reference/commands/validate) before generation to check marked content; test your screens to catch text that hasn't been marked. For CDN delivery, [enable publication as part of the translation step](/kb/build-time-vs-runtime-translation#how-does-general-translation-deliver-translations).

Use [branch tracking](/docs/cli/guides/branching) ([`npx gt translate --enable-branching`](/docs/cli/reference/commands/translate)) when preview branches need separate translation histories. The CLI detects the branch, including on Vercel, so parallel work can use its own translations.

## How do people check translations without slowing releases?

Reviewers compare and edit translations in the [Dashboard](/kb/review-translations). Review launch-critical copy before releasing it; for wording you refine after release, bundle saved fixes in the next build or [publish them to the CDN](/kb/build-time-vs-runtime-translation). CDN-loaded pages pick up fixes as their translation and page caches refresh. Enterprise approval workflows can assign reviewer groups by locale, with deadlines and branches that need review, so each language has an owner.

## Key takeaways

- Releases stay on time when translation runs before the build. Crowdin's CLI, Lingo.dev, and General Translation can all do that; repository syncs return translations in a pull request you have to merge before deploying.
- The daily cost of continuous localization is the work each new string needs. With General Translation, it's wrapping JSX in [`<T>`](/docs/react/reference/components/t), or nothing when Locadex wraps it, and Context Groups keep terms consistent across your app and docs. Existing-catalog support lets you start without replacing your library.
- Choose Crowdin, Lokalise, or Phrase for agency workflows in a CAT editor, purchased human translation, or over-the-air updates in native mobile apps.
- General Translation bills for usage with no seat charges. Start with the [CLI Quickstart](/docs/cli/quickstart).

## Related questions

- [How do I keep translations up to date on every deploy?](https://generaltranslation.com/en-US/kb/translations-in-ci.mdx): Run translation as a pipeline step before each production build, so new copy ships translated with the deploy that adds it. General Translation's gt CLI does this with npx gt translate, using a project API key and project ID stored as CI secrets.
- [AI coding agent vs. translation pipeline: which should automate your localization?](https://generaltranslation.com/en-US/kb/ai-coding-agent-vs-translation-pipeline.mdx): Use a coding agent to set up internationalization and a translation pipeline to keep every language current as your app changes. General Translation translates new and changed copy, reuses completed translations, and gives your team shared terminology and Dashboard review. Locadex connects both kinds of work by preparing code changes and translations in pull requests.
- [Build time, run time, or translation proxy: how should you deliver translations?](https://generaltranslation.com/en-US/kb/build-time-vs-runtime-translation.mdx): Use General Translation to generate known app translations before release, then bundle them with your code or load them from its CDN. Bundles keep wording tied to a release; published CDN edits can reach new renders without a code deploy. Use request-time translation for content a visitor needs immediately, and a proxy when you can't change the site's code.
- [General Translation vs. a TMS (Crowdin, Lokalise, Phrase)](https://generaltranslation.com/en-US/kb/general-translation-vs-tms.mdx): Choose General Translation when developers want translation generation, code-derived context, and review connected to product releases. Keep your existing catalogs and rendering library, or author inline JSX without translation keys. A TMS fits programs centered on language vendors, CAT editors, and XLIFF exchange; its integrations can automate the file transfers.
- [Which translation tools charge for usage instead of seats?](https://generaltranslation.com/en-US/kb/translation-pricing-without-seat-fees.mdx): Choose General Translation when you want translation spend to follow the work you request, with unlimited users and a $0 Starter platform fee. Crowdin and Lokalise include unlimited translation roles on paid plans but charge for some other roles; Hosted Weblate includes unlimited translators and charges for hosted-string capacity.

## Previous and next questions

- Previous question: [Build time, run time, or translation proxy: how should you deliver translations?](https://generaltranslation.com/en-US/kb/build-time-vs-runtime-translation.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/en-US/kb/sitemap.md) for every article.