# General Translation Knowledge Base: General Translation vs. Locize: which should you use? URL: https://generaltranslation.com/en-GB/kb/general-translation-vs-locize.mdx Docs index: https://generaltranslation.com/llms.txt Description: Locize is a translation management system from the creators of i18next that delivers translations from a CDN, collects new keys from your running app, and adds AI translation and an in-context editor. You still maintain the i18n library and its keys. General Translation can be your i18n library and translate it, or translate the i18next files you already have. Category: Workflow Tools Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 Locize is a translation management system (TMS) built by the team behind i18next. Your app keeps using i18next (or another i18n library), Locize stores the keys and their translations, AI or your translators fill in each language, and the app loads the results from Locize's CDN, so a corrected translation goes live without a redeploy. Locize works alongside your i18n library rather than replacing it, so the library set-up, the keys and the wiring remain your engineers' responsibility. General Translation can be both: its own open-source i18n libraries plus the translation, or just the translation for i18next files you already have. ## What Locize does well * **Built for i18next.** [`i18next-locize-backend`](https://github.com/locize/i18next-locize-backend) loads translations from Locize's CDN, and with i18next's `saveMissing` option it sends new keys to Locize as you develop. [`i18next-cli`](https://github.com/i18next/i18next-cli) includes Locize sync, download and migrate commands, and its `localize` command wraps hardcoded strings in `t()`, extracts keys, connects a Locize project and requests AI translation in one run. * **Updates without a redeploy.** Translations publish to a CDN (a Standard CDN on every plan, a Pro CDN from the Growth plan upwards), with a [cache duration you set per version](https://www.locize.com/docs/integration/cdn-types-standard-vs-pro) and an option for private, API-key-only publishing. * **Versions.** A project has a `latest` working version, a `production` version and any custom versions, such as `staging` or one per mobile app release, so you can promote or roll back translations independently of code. (See [Locize versioning](https://www.locize.com/docs/versioning).) * **In-context editing.** The [`locize` package](https://github.com/locize/locize) adds an editor pop-up to your site when the URL includes `?incontext=true`, and screenshots are matched to keys using text recognition. * **AI and machine translation.** [Locize's own AI service](https://www.locize.com/ai), or your own OpenAI, Gemini, Mistral or DeepL key, translates using your style guide, glossary and translation memory, with quality estimation, AI review and a human review workflow. * **Plural keys per language.** For i18next JSON, Locize [generates the plural keys](https://www.locize.com/docs/integration/i18n-formats/pluralization) each target language needs (such as Polish `_few` and `_many`) and shows every form in its editor. * **Beyond i18next.** [`locize-cli`](https://github.com/locize/locize-cli) imports and exports formats including XLIFF, Android XML, Apple `.strings`, PO, RESX, Fluent and Java properties, and Locize publishes examples for react-intl, vue-i18n and Lingui. There's also a GitHub Action, an MCP server and a Figma plugin. ## What Locize still leaves to your engineers Here's `saveMissing` with `i18next` 26.4.7 and `i18next-locize-backend` 10.0.3, rendering Spanish for a key Locize hasn't seen yet. The request function stands in for Locize's servers and logs each call: ```js title="test.mjs" import i18next from 'i18next'; import Backend from 'i18next-locize-backend'; // Pretend CDN: English and Spanish both have one key so far. const cdn = { en: { inbox: { title: 'Inbox' } }, es: { inbox: { title: 'Bandeja de entrada' } }, }; await i18next.use(Backend).init({ lng: 'es', fallbackLng: 'en', saveMissing: true, backend: { projectId: 'demo-project', apiKey: 'demo-write-key', // write key: development only referenceLng: 'en', allowedAddOrUpdateHosts: () => true, reloadInterval: false, request: async ({ url, method, body }) => { console.log(method, url, body ? JSON.stringify(body) : ''); const lng = url.match(/latest\/(\w+)\//)?.[1]; return { status: 200, data: JSON.stringify(method === 'GET' ? cdn[lng] ?? {} : {}) }; }, }, }); // New copy added in code, with an English default value console.log(i18next.t('inbox.title')); console.log(i18next.t('inbox.empty', 'No messages yet.')); await new Promise((r) => setTimeout(r, 6000)); // saveMissing is debounced ``` ```text title="Output" GET https://api.lite.locize.app/demo-project/latest/es/translation GET https://api.lite.locize.app/demo-project/latest/en/translation Bandeja de entrada No messages yet. POST https://api.lite.locize.app/missing/demo-project/latest/en/translation {"inbox.empty":"No messages yet."} ``` This example shows what `saveMissing` registers: the English key and value. Translation and publication happen after registration. A Locize integration connects these steps: 1. Set up i18next, name a key for each string, and call `t()` with it. 2. Send new keys to Locize with `saveMissing` in development (it's limited to `localhost` by default, and [the write key must never ship](https://www.locize.com/docs/guides/going-to-production)) or with a sync command in CI. 3. Translate with AI or your translators, review the results, and publish them to the version your app reads. 4. Load translations from the CDN at run time, or download them into your build, and register each new language in the app. The context that reaches a translator or the AI is the key, its English value, any context note and [screenshots matched to it](https://www.locize.com/docs/context), not the component that renders the string. Locize plans have a monthly base price that includes words, CDN downloads, languages, namespaces and versions, with extra blocks of words and downloads on larger plans, and AI and machine translation priced per token or character. (See [Locize pricing](https://www.locize.com/pricing), checked October 2026.) ## General Translation for i18next teams You don't have to rewrite anything to try General Translation. The CLI detects `i18next` in your `package.json` and translates your JSON files while preserving i18next's interpolation syntax (or ICU syntax, if you use `i18next-icu`): ```json title="gt.config.json" { "defaultLocale": "en", "locales": [ "es" ], "files": { "json": { "include": [ "locales/[locale]/*.json" ] } } } ``` [`npx gt translate --dry-run`](/docs/cli/reference/commands/translate) finds `locales/en/translation.json`, and [`npx gt translate`](/docs/cli/reference/commands/translate) writes `locales/es/translation.json`. Use this file workflow for messages whose source and target key structures match. A companion metadata file can attach a `context` note or `maxChars` limit to any key. See [Keyed metadata](/docs/cli/reference/keyed-metadata). Alternatively, go further and let General Translation be the library as well. [``](/docs/react/reference/components/t) wraps JSX and translates it in place, and [`useGT`](/docs/react/reference/hooks/use-gt) handles strings, so there are no keys to name. [`useTranslations`](/docs/react/reference/hooks/use-translations) keeps a keyed dictionary for teams that want one. `gt-next`, `gt-react` and `gt-vue` are MIT-licensed, aren't built on i18next, and work without a General Translation account. ## Locize vs. General Translation at a glance | Feature | Locize | General Translation | | ----------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | What it is | A TMS that pairs with i18next or another i18n library | Open-source i18n libraries plus AI translation, or translation for your existing files | | Where strings live | Keys in your code; values in Locize | In your code inside [``](/docs/react/reference/components/t), or in the resource files you already have | | How new copy gets in | `saveMissing` in development, or sync commands in CI | [`npx gt translate`](/docs/cli/reference/commands/translate) in your build, or [Locadex](/docs/platform/locadex/quickstart) pull requests | | Who translates | Locize's AI, your own AI or machine translation key, or your translators | AI with context from your code, Glossary and Custom Prompts, reviewed by your team in the Dashboard | | Context for each string | Key, English value, context notes, screenshots, glossary and style guide | Marked JSX structure with inline libraries; keyed metadata for catalogues; shared Glossary and Custom Prompts | | Delivery | CDN by default, with versioning; or downloaded into your build | Bundled files, or updates published through General Translation's CDN without redeploying the app | | Pricing | Plan tiers based on words, CDN downloads, languages and versions; AI and machine translation as top-ups | [Usage-based translation](https://generaltranslation.com/pricing) | ## Why teams choose General Translation over Locize General Translation lets an i18next team adopt translation generation and Dashboard review first, then move to inline copy when it wants to remove key maintenance too. * **Faster.** Run translation before your build so that new copy ships in the languages you support. The CLI reuses existing translations and translates new or changed content; adding a language is one line in `gt.config.json`. * **Cheaper to run.** Start with the i18next files you already maintain. Moving a feature to [``](/docs/react/reference/components/t) then removes the work of naming keys and keeping a source dictionary in step with its components. * **Higher quality.** Add a context note to a catalogue key, or use inline [``](/docs/react/reference/components/t) blocks to send the sentence's JSX structure and plural branches into translation. A shared [Context Group](/docs/platform/dashboard/guides/defining-context-for-translations) keeps product terminology consistent across app and documentation projects, and reviewers edit the results in the Dashboard. * **Lower risk.** Keep i18next and your reviewed translations while you evaluate General Translation. Bundled translation files make no runtime calls to General Translation; its MIT-licensed JavaScript libraries also work without an account when you supply translations. With General Translation, Cursor ships 14+ locales across web and docs. (See [production deployments](https://generaltranslation.com/enterprise).) ## When Locize is the better fit Choose Locize when translators want to edit on the live site, when you keep separate translation versions for each mobile app release, or when you exchange XLIFF, Fluent or Java properties files. Choose General Translation's inline libraries when you want readable source copy in your components and marked-up JSX structure preserved during translation. Try its CLI with your existing catalogues if you want to evaluate translation and Dashboard review before switching libraries. ## Moving from Locize to General Translation Download your current translations with `locize-cli` and keep them in your repository, then point `gt.config.json` at the English files and run [`npx gt upload`](/docs/cli/reference/commands/upload) to send your sources and existing translations to the platform. From there, you can either keep i18next and let the CLI translate new keys, or move over to [``](/docs/react/reference/components/t) one feature at a time. (See [Migrating i18n libraries](/docs/react/guides/migrating-i18n-libraries).) You can bring your glossary terms across too: Context Group imports accept CSV, TSV, JSON and text files. ## Key takeaways * Locize, from the creators of i18next, is a strong TMS for i18next apps, with CDN delivery, `saveMissing`, versions, in-context editing and AI translation. * It pairs with your i18n library and its keyed catalogues; translation, review and publishing are configured around those catalogues. * General Translation can translate the i18next files you already have, or serve as both your i18n library and your translation solution, with the context of the code and every language shipped with each release. ## Related questions - [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. - [Why use General Translation instead of a TMS (Smartling, Lokalise, Phrase, Crowdin, or Transifex)?](https://generaltranslation.com/en-GB/kb/general-translation-vs-tms.mdx): A translation management system (TMS) such as Smartling, Lokalise, Phrase, Crowdin, or Transifex coordinates translators, but engineers still extract strings, send them out, wait for translations, and wire them back into the product. General Translation translates content in your code with its context, ships every language with each release, and runs on open-source libraries with no lock-in. - [General Translation vs. Tolgee: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-tolgee.mdx): Tolgee combines keyed messages, in-context editing and AI translation in a self-hostable platform. General Translation keeps readable copy directly in your components and generates translations from the marked JSX, so you can ship new copy in every language without maintaining message keys. - [General Translation vs. Weblate: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-weblate.mdx): Weblate is a self-hostable, Git-based localisation platform built for translating repository files with a community or team. General Translation integrates translation generation into development and releases, using marked JSX and shared product context. Keep your gettext files or adopt inline authoring to remove source-catalogue maintenance too. - [Can I do i18n without translation files?](https://generaltranslation.com/en-GB/kb/i18n-without-translation-files.mdx): Yes. With gt-react or gt-next, content stays inline in your components inside a `` component, and translations are generated at build time as output, so there are no keys or per-locale JSON files to write and keep in sync. ## Previous and next questions - Previous question: [General Translation vs. Lingui: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-lingui.mdx) - Next question: [General Translation vs. Mobility: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-mobility.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/en-GB/kb/sitemap.md) for every article.