# General Translation Knowledge Base: What is the best localisation software for developers? URL: https://generaltranslation.com/en-GB/kb/best-localization-software.mdx Docs index: https://generaltranslation.com/llms.txt Description: Look for one system that covers the whole pipeline, from the i18n library in your code to translation and delivery, instead of stitching together a separate library, translation management system and translation vendor. Category: Workflow Tools Last updated: 2026-05-04 Authors: Jackie Chen Published: 2026-05-04 If you search for 'best localisation software' right now, you'll find a dozen articles written by localisation vendors, each ranking 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. ## Video The video is narrated in English, with English captions. [What is the best localization software for developers?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-best-localization-software.mp4) (44 secs) General Translation covers the whole pipeline, from your code to translation and delivery. Run `npx gt init` and wrap the content in a `` component, put one command in your build that writes the translations, and connect your repository so Locadex can open a pull request with new translations when you push. ## The localisation stack is broken 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 handoffs. 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 up front, then drains 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, Ramp, Profound, Cognition, Sierra and ClickHouse. * **Open-source developer libraries**: [`gt-next`](/docs/react/nextjs-quickstart), [`gt-react`](/docs/react/react-quickstart), and support for [React Native/Expo](/docs/react/react-native-quickstart). 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](/docs/platform/locadex/quickstart) that scans your codebase, internationalises your code, creates translations and opens pull requests on every push. Building 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 straight 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 is 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 heavy 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. For a dev team shipping a SaaS app in 20 languages, it's pure overhead. And pricing? Several of the most popular platforms make you speak to sales just to see the figures. 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 [set-up wizard](/docs/cli/quickstart) and wrap content in [``](/docs/react/reference/components/t) components. No key extraction. No JSON files. ```tsx import { T } from 'gt-next'; export default function Home() { return (

Welcome to our app

This content is translated automatically.

 ); } ``` **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. [See the deploy guide →](/docs/react/nextjs-quickstart#11-deploy-to-production) **4. Automate.** [Locadex](/docs/platform/locadex/quickstart) 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 and lets you 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 your full codebase context: component hierarchy, variable names, surrounding UI, your product glossary. The output is idiomatic without manual clean-up. For edge cases, you can [add explicit context](/docs/react/reference/components/t#props) 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 →](https://generaltranslation.com/pricing) ## Related questions - [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. - [How do I set up SEO for a multilingual Next.js app?](https://generaltranslation.com/en-GB/kb/multilingual-nextjs-seo.mdx): Give every language its own URL, set the html lang attribute, point each page's canonical URL at itself, add hreflang alternates for every language, translate titles and descriptions, and list every language version in your sitemap. - [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. ## Previous and next questions - Previous question: [How do I set up SEO for a multilingual Next.js app?](https://generaltranslation.com/en-GB/kb/multilingual-nextjs-seo.mdx) - Next question: [Can I do i18n without translation files?](https://generaltranslation.com/en-GB/kb/i18n-without-translation-files.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/en-GB/kb/sitemap.md) for every article.