# General Translation Knowledge Base: General Translation vs. Locize: which should you use?
URL: https://generaltranslation.com/en-US/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 fixed translation goes live without a redeploy. Locize pairs with your i18n library; it doesn't replace it, so the library setup, the keys, and the wiring stay with your engineers. 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 up), 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 separately from code. (See [Locize versioning](https://www.locize.com/docs/versioning).)
- **In-context editing.** The [`locize` package](https://github.com/locize/locize) adds an editor popup to your site when the URL includes `?incontext=true`, and screenshots are matched to keys with 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 with 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 keeping 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 with matching source and target key structures. A companion metadata file can attach a `context` note or `maxChars` limit to any key. See [Keyed metadata](/docs/cli/reference/keyed-metadata).

Or go further and let General Translation be the library too. [`<T>`](/docs/react/reference/components/t) wraps JSX and translates it in place, and [`useGT`](/docs/react/reference/hooks/use-gt) covers 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, have no i18next underneath, 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 [`<T>`](/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 catalogs; shared Glossary and Custom Prompts |
| Delivery | CDN by default, with versions; or downloaded into your build | Bundled files, or published updates through General Translation's CDN without an app redeploy |
| Pricing | Plan tiers with 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 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 [`<T>`](/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 catalog key, or use inline [`<T>`](/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 per 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 components and marked JSX structure included during translation. Try its CLI with existing catalogs when you want to evaluate translation and Dashboard review before changing 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 keep i18next and let the CLI translate new keys, or move one feature at a time to [`<T>`](/docs/react/reference/components/t). (See [Migrating i18n libraries](/docs/react/guides/migrating-i18n-libraries).) Glossary terms can come along 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 catalogs; translation, review, and publishing are configured around those catalogs.
- General Translation can translate the i18next files you already have, or be your i18n library and translation together, 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-US/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 catalog 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, and General Translation also does the translating, with your code as context.
- [Why use General Translation instead of a TMS (Smartling, Lokalise, Phrase, Crowdin, or Transifex)?](https://generaltranslation.com/en-US/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-US/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-US/kb/general-translation-vs-weblate.mdx): Weblate is a self-hostable, Git-based localization 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-catalog maintenance too.
- [Can I do i18n without translation files?](https://generaltranslation.com/en-US/kb/i18n-without-translation-files.mdx): Yes. With gt-react or gt-next, content stays inline in your components inside a `<T>` 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-US/kb/general-translation-vs-lingui.mdx)
- Next question: [General Translation vs. Lokalise: which should you use?](https://generaltranslation.com/en-US/kb/general-translation-vs-lokalise.mdx)

## Sitemap

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