# General Translation Knowledge Base: General Translation vs. Lingo.dev: which should you use? URL: https://generaltranslation.com/en-GB/kb/general-translation-vs-lingo-dev.mdx Docs index: https://generaltranslation.com/llms.txt Description: Lingo.dev is built around configurable translation engines, with CLI, React, and GitHub tools to reach them. General Translation is a localisation platform: libraries, code context, shared terminology, Dashboard review on every plan, and Locadex, which also internationalises your code. Choose Lingo.dev for model control per language pair. Category: Workflow Tools Last updated: 2026-10-28 Authors: General Translation Team Published: 2026-10-28 Lingo.dev is built around configurable translation engines: you choose the model for each language pair, and CLI, React, and GitHub tools translate files, render localised UI, and open translation pull requests. General Translation is a localisation platform built around its open-source libraries, code context, shared Context Groups, Dashboard review on every plan, and Locadex, an AI agent which can internationalise your code and keep translations current through pull requests. The choice is about how you configure and maintain that workflow: Lingo.dev gives you model control per language pair; General Translation connects code, translation, and team review in one platform. ## What Lingo.dev is Lingo.dev calls its translation APIs [localisation engines](https://lingo.dev/en/docs/platform/engines). Each engine assigns a model to each language pair, with ranked fallbacks, from what Lingo.dev describes as [hundreds of models](https://lingo.dev/en/docs/platform/llm-models), and attaches glossaries, rules, and a brand voice. AI reviewers [score translations](https://lingo.dev/en/docs/platform) after they're produced. You reach an engine through the `lingo` CLI, which pushes locale files and pulls translations back in [18 formats](https://lingo.dev/en/docs/cli/formats); a [GitHub App](https://lingo.dev/en/docs/workflows); an API; or a hosted [MCP server](https://lingo.dev/en/docs/mcp). [`@lingo.dev/react`](https://lingo.dev/en/docs/react/i18n/quickstart) renders translations from source-language calls, with CLI extraction and no separate key namespace. An [alpha compiler](https://lingo.dev/en/docs/react/compiler) translates plain JSX at build time with component context. Its [pricing](https://lingo.dev/en/pricing) passes the LLM provider's price through and adds usage fees, with a monthly base fee on its Production plan. ## Lingo.dev vs. General Translation at a glance | | Lingo.dev | General Translation | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Category | Configurable translation engines with CLI, React, and GitHub tools | Localisation platform: i18n libraries, CLI, Dashboard, and [Locadex](/docs/platform/locadex/quickstart) | | What renders translations | Your i18n library, `@lingo.dev/react`, or the alpha compiler | MIT-licensed `gt-next`, `gt-react`, `gt-vue`, and `gt-node`, or your existing i18next or next-intl set-up | | Where app copy lives | Locale files, `l.text()` calls with required context strings, or plain JSX in the alpha compiler | Inline JSX inside [``](/docs/react/reference/components/t), [`useGT`](/docs/react/reference/hooks/use-gt) strings, or your existing resource files | | Context | Engine glossary, rules, and brand voice; JSONC notes or `context` strings; component context in the alpha compiler | JSX structure, variables, [`context`](/docs/react/reference/components/t#context) notes, and Context Groups shared across projects | | Consistency across a site | One glossary, ruleset, and brand voice shared by every engine; AI reviewers check glossary compliance | A consistency check against existing translations; MDX structure checked against the source | | Human review | Review stage in the Enterprise async pipeline, or edits in repository files | Dashboard review on every plan, with annotations, version history, and roles; approval on Enterprise | | Internationalising the code | GitHub App translates files; alpha compiler transforms JSX at build time | Locadex wraps untranslated UI and opens a pull request | | Continuous translation | GitHub App opens or updates a translation pull request on push; `lingo push` in CI sends new and changed keys and keeps hand edits until the source changes | [`npx gt translate`](/docs/cli/reference/commands/translate) in CI, or Locadex pull requests | | Delivery | Files in your repository, or compiler bundles | Files in your repository, or General Translation's CDN | | Model choice | Any catalogue model per language pair; your own keys on Enterprise | Chosen by General Translation; Enterprise projects can select the provider | | Pricing | LLM cost at no markup, plus usage fees and a base fee on Production | [Usage-based, with no seat charges](https://generaltranslation.com/pricing) | ## Why teams choose General Translation over Lingo.dev ### Rendering translations in your app Both tools offer ways to render translations. Lingo.dev has three paths: 1. **Keep your i18n library.** Point `.lingo/config.json` at its source files, and `lingo push` sends new and changed keys. You still name every key, and per-string context comes from comments in JSONC files, read as [translator notes](https://lingo.dev/en/docs/cli/translator-notes). Plain JSON can't carry notes. 2. **Adopt `@lingo.dev/react`.** Each string becomes a call such as `l.text("Save", { context: "Form button" })`, where `context` is [required](https://lingo.dev/en/docs/react/i18n/quickstart). The CLI extracts those calls, and the runtime renders the translated values without a separate key namespace. 3. **Adopt the compiler.** It translates plain JSX with component context and embeds translations in locale bundles for Next.js App Router and Vite apps. Lingo.dev's docs label it [alpha and 'not recommended for production use'](https://lingo.dev/en/docs/react/compiler). General Translation's libraries render translations and format plurals, dates, numbers and currencies per locale, with or without an account. You wrap JSX in [``](/docs/react/reference/components/t) as written, with no key, hash or required context string. (React Native, TanStack Start and the Python SDKs are experimental.) ### Context from your code Lingo.dev combines engine-level glossaries, rules, and brand voice with per-string notes; its alpha compiler also preserves component structure and interpolation context. General Translation's CLI sends each [``](/docs/react/reference/components/t) block with its element structure and variable placeholders, so a sentence with a link and a plan name is translated as one unit. A [Context Group](/docs/platform/dashboard/guides/defining-context-for-translations) adds a Glossary and Custom Prompts to every project you assign it to, so your app, docs, and CMS content use the same terms. ### Review Lingo.dev's [human review stage](https://lingo.dev/en/docs/api/pipeline/human-review) runs inside its async pipeline, which the pricing page lists for Enterprise only. On other plans, people edit translated files in the repository. In General Translation's [Dashboard](/docs/platform/dashboard/guides/reviewing-translations), your team edits translations next to their source, compares locales, leaves annotations, and browses version history, on every plan with unlimited seats. Hand edits to downloaded files sync back with [`npx gt save-local`](/docs/cli/reference/commands/save-local). Translation approval requires an Enterprise plan. ### Continuous localisation of the code itself Lingo.dev's GitHub App translates the files your patterns match; it doesn't add i18n calls to your components. Locadex's **Generate code** template also wraps untranslated UI in [``](/docs/react/reference/components/t) and [`t()`](/docs/python/reference/functions/t) calls and opens a pull request. Translations published to General Translation's CDN with `--publish` reach an app that loads from it without a new build. Cursor uses General Translation for 14+ locales across web and docs. (See [production deployments](https://generaltranslation.com/enterprise).) ## When Lingo.dev makes sense * **You want to pick the model.** You compare and choose the LLM for each language pair yourself, or bring your own provider keys. * **One translation API for several services.** Many backends call the same engine with one glossary and set of rules. * **Formats General Translation doesn't read.** You exchange XLIFF, Flutter ARB, or Laravel PHP files. General Translation chooses the model for you; Enterprise projects can select Anthropic, OpenAI, xAI, or Google as the [provider](/docs/platform/core/reference/gt-class-methods/translation/enqueue-files). ## Moving from Lingo.dev to General Translation Lingo.dev's CLI writes ordinary locale files into your repository, so the move starts from files you already have. List them under [`files` in `gt.config.json`](/docs/cli/reference/config#files), run [`npx gt upload`](/docs/cli/reference/commands/upload) to bring the existing translations to the platform, then run [`npx gt translate`](/docs/cli/reference/commands/translate) for new and changed content. If the app uses i18next or next-intl, the CLI detects the library and translates its JSON files in that library's syntax, so you can keep the renderer. Import glossary terms into a [Context Group](/docs/platform/dashboard/guides/defining-context-for-translations), which accepts CSV, TSV, JSON, and text files. To move to inline JSX later, follow the [library migration guide](/docs/react/guides/migrating-i18n-libraries). If you used Lingo.dev's compiler, General Translation's compiler can wrap JSX text in [``](/docs/react/reference/components/t) at build time with [automatic JSX injection](/docs/cli/guides/using-auto-jsx), which is off by default. ## Is General Translation an alternative to Lingo.dev? Yes, for teams that want localisation handled from the component to the reviewed release. Lingo.dev offers configurable engines, React rendering, and automated translation pull requests. General Translation combines code context and shared terminology with Dashboard review on every plan, while Locadex can also add i18n calls to untranslated UI. ## Other Lingo.dev alternatives * **Intlayer:** keeps each component's content in a typed declaration file and fills missing languages with an AI provider you configure. (See [General Translation vs. Intlayer](/kb/general-translation-vs-intlayer).) * **Paraglide JS:** compiles your message catalogues into typed, tree-shakable functions. (See [General Translation vs. Paraglide JS](/kb/general-translation-vs-paraglide).) * **i18next, react-intl, and next-intl:** render the catalogues you provide and leave producing translations to another tool. (See [General Translation vs. i18n libraries](/kb/general-translation-vs-i18n-libraries).) For set-up without key files, see [i18n without translation files](/kb/i18n-without-translation-files). To hand set-up to Cursor or Claude Code, see [internationalising an app with a coding agent](/kb/ai-agent-i18n-setup). ## Key takeaways * Lingo.dev combines configurable translation engines with CLI, React, and GitHub tools; General Translation integrates libraries, code context, team review, and Locadex. * Lingo.dev offers React rendering and an alpha compiler with component context; its internal human review stage requires Enterprise. * General Translation keeps copy inline in [``](/docs/react/reference/components/t), translates it with its JSX structure as context, checks consistency, and lets your team review in the Dashboard on every plan. * Use Lingo.dev when you want to choose the model yourself or need XLIFF, ARB, or PHP files; moving to General Translation starts with the locale files its CLI already wrote. ## Related questions - [General Translation vs. Intlayer: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-intlayer.mdx): Intlayer keeps each component's content in a typed declaration file next to it, with every language written side by side, and can fill missing languages with an AI provider you configure. General Translation keeps copy inline in your components in one language and generates the other languages with the context of your code. - [Best AI translation tools for developers: APIs vs. localisation platforms](https://generaltranslation.com/en-GB/kb/best-ai-translation-tools.mdx): Use a translation API when you already own the localisation pipeline. Use General Translation when you want context, consistency checks, review, and continuous delivery managed together. DeepL, Google Cloud Translation, OpenAI, and Claude can power a production pipeline; General Translation provides one for your app, docs, and site. - [General Translation vs. i18next, react-intl, and next-intl: which i18n library should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-i18n-libraries.mdx): Open-source libraries such as i18next, react-intl, and next-intl don't translate anything. They display translations you supply in a catalogue file for each language, written by you, your translators or a separate service. General Translation's libraries are open source too and do the same job, but General Translation also does the translating, using your code as context. - [General Translation vs. Paraglide JS: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-paraglide.mdx): Choose General Translation to keep copy inline and generate translations with the structure of your React components, shared terminology, and Dashboard review. Choose Paraglide JS for compiled, typed message functions and per-message tree-shaking. Paraglide renders your catalogues; General Translation connects source copy to translation generation and ongoing updates. - [How do I internationalise an app with Cursor or Claude Code?](https://generaltranslation.com/en-GB/kb/ai-agent-i18n-setup.mdx): Start with General Translation's Setup for Agents prompt in Cursor or Claude Code, choose a feature and target languages, and have the agent implement and verify the result. Browser sign-in, machine-readable docs and MCP tools connect set-up to translation and review. Use Locadex to automate ongoing localisation through pull requests. ## Previous and next questions - Previous question: [DeepL alternatives: General Translation vs. DeepL](https://generaltranslation.com/en-GB/kb/general-translation-vs-deepl.mdx) - Next question: [How do I add i18n to a Next.js Pages Router app?](https://generaltranslation.com/en-GB/kb/add-i18n-to-nextjs-pages-router.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/en-GB/kb/sitemap.md) for every article.