If you search "best localisation software" right now, you'll find a dozen articles written by localisation vendors, each putting themselves first. They compare feature matrices, list pros and cons, and conclude (surprise!) that you should pick them.

We're not going to do that. Instead, we'll explain why the entire category is solving the wrong problem, and what solving the right one looks like.

The localisation stack is broken down into three

Shipping a multilingual app in 2026 requires stitching together three completely separate systems:

1. An i18n library — handles string extraction, interpolation, pluralisation, and locale routing inside your codebase. It renders translations. It doesn't produce them.
2. A translation management system (TMS) — stores translation files, manages workflows, and coordinates handovers. It sits between your code and your translators but doesn't do the translating.
3. A language service provider (LSP) — the human translators, agencies, or machine translation engines that actually produce the translated content. They don't know anything about your code or your TMS.

The library knows nothing about your translations. The TMS knows nothing about your code. The translation provider knows nothing about either. Wiring them together takes weeks of engineering time upfront, and then bleeds hours every sprint on syncing files, resolving merge conflicts, debugging webhooks, and babysitting a pipeline that was never designed to be one.

What "end-to-end" actually means

General Translation is not a library. It's not a TMS. It's the whole pipeline, used by developer-first teams at Cursor, Cognition, Windsurf, Mintlify, and ClickHouse.

• Open-source developer libraries: gt-next, gt-react, and support for React Native/Expo. Drop-in SDKs with full TypeScript support.
• An AI-first translation platform that understands your codebase, your product, and your terminology. Not generic machine translation bolted on top.
• Locadex, the AI agent: an automated internationalisation engineer that scans your codebase, internationalises your code, creates translations, and opens pull requests on every push.

Building both the library and the translation engine together makes localisation ten times easier. No JSON export/import, no file management, no agencies to coordinate. Translations flow directly from your source code to production.

What's wrong with traditional TMS platforms

Legacy translation management systems were built for a pre-AI world. They assume a specific workflow: content gets extracted from your codebase, uploaded to a dashboard, assigned to translators, reviewed, approved, exported, and re-integrated. It works some of the time, but it's slow, expensive, and fragile.

They manage files, not code. A TMS ingests your translation files (JSON, XLIFF, PO, etc.) and gives you tools to manage them. But the real source of truth is your codebase: your components, your variables, your UI hierarchy. Managing the files without understanding the code means context is always lost in transit.

Most platforms have added AI/MT features in the last few years, usually by routing strings through third-party machine translation engines and letting you choose which one to use. The AI sees isolated strings. It doesn't see your component tree, your variable names, or the surrounding UI. That's why MT output still needs substantial editing.

They scale by adding people, not by removing work. The TMS business model is built around coordinating human translators: roles, permissions, review chains, approval workflows. That's necessary for regulated enterprise content. It's pure overhead for a dev team shipping a SaaS app in 20 languages.

And pricing? Several of the most popular platforms require a sales conversation to even see numbers. Others charge per-seat fees that balloon as your team grows. Unpredictable costs make it hard to budget for new languages.

What's wrong with standalone i18n libraries

Popular i18n libraries for React and Next.js handle rendering well: interpolation, pluralisation, locale routing, Server Component support.

But they don't translate anything.

They render whatever you give them. You still need to:

• Extract every translatable string into JSON files
• Maintain a separate file for every locale
• Either translate those files manually, hire translators, or plug in a TMS
• Keep every file in sync as your codebase changes

At 10 languages and 500 keys, that's 5,000 entries to maintain. At 50 languages it's 25,000. The library doesn't help you with any of that. It just renders whatever you give it — half the problem, at best.

How General Translation closes the loop

1. Install and write code. Run the setup wizard and wrap content in <T> components. No key extraction. No JSON files.

import { T } from 'gt-next';

export default function Home() {
  return (
    <T>
      <h1>Welcome to our app</h1>
      <p>This content is translated automatically.</p>
    </T>
  );
}

2. Develop. Translations appear on-demand. Switch languages and see results immediately.

3. Ship. One command generates all translations at build time. They're pre-generated, cached, and delivered via CDN. Sub-50ms globally. See the deploy guide →

4. Automate. Locadex monitors your repo. When you push code, it scans for changes, internationalises new content, generates translations, and opens a PR. No human in the loop unless you want one. If you do, the translation editor gives you side-by-side diffs with the ability to edit before or after content goes live.

Why most translation AI gets it wrong

Most localisation AI translates strings one at a time, in isolation. "Apple" could be the fruit or the company. "Cell" could be biological or a spreadsheet. Without context, the AI guesses.

General Translation's AI sees the full context of your codebase: component hierarchy, variable names, surrounding UI, and your product glossary. The output is idiomatic without manual clean-up. For edge cases, you can add explicit context directly in the component.

Pricing that scales with usage, not headcount

GT uses usage-based pricing. You pay for what you translate. No per-seat fees that balloon as your team grows. No sales call required. See full pricing →