General Translation localizes React components, not dictionaries

The T wrapper replaces dictionary extraction

The core idea of General Translation is stated in one sentence in the README, and it is a positioning claim rather than a feature list. Instead of translating strings, you translate entire React components by wrapping them in a T element, and the claim is that no refactoring into dictionaries is needed. The usual i18n workflow has three painful stages: extract every user visible string into a catalogue, replace each usage with a key lookup, and keep the catalogue synchronised with the code forever. Component level translation removes the first stage, because the boundary is drawn around the component rather than around the string. The cost moves to a different place, since the component becomes the unit that has to be sent somewhere for translation and brought back, which means the tooling around that round trip matters more than usual. The suite is described as a fully integrated set of i18n tools for React apps, with the same idea extended to the other frameworks through separate packages.

A wizard and an API key are the entry price

The getting started path is one command, and it is run with npx so there is nothing to install first:

npx gt@latest

The same command appears under Quick Start as the setup wizard, and the documentation points to a hosted dashboard where the project can be set up instead, through a Locadex integration link. Two things are worth being clear about before you run it. First, an account is part of the flow, since the instructions ask you to create a free API key at generaltranslation.com, and the service is where the translation itself happens. This is the significant architectural fact about the product, and it differs from a self-contained library such as a pure JavaScript i18n runtime that only formats strings you have already translated by hand. Second, the wizard is the part that touches your project, so it is worth running it on a scratch branch the first time and reading the diff. The full documentation lives at generaltranslation.com/docs, and the project also maintains a Discord community and GitHub discussions for questions.

A package for every framework and every build tool

The repository is a monorepo of many published packages, and the package table is the clearest description of the scope. There is gt-next for automatic i18n in Next.js, gt-react for React, gt-vue described as lightweight i18n for Vue, and gt-i18n as a pure JavaScript i18n library. The gt package is the CLI tool for continuous localization, and gt-sanity is a plugin for Sanity Studio v3. Two packages exist for working inside an existing codebase rather than a new one. locadex is an AI agent for automating i18n in complex codebases, and @generaltranslation/compiler is a build plugin for webpack, Vite, Rollup and esbuild. There is also an ESLint plugin for React Core integration and a core TypeScript library marked as internal. The spread tells you something useful about the product. The framework packages handle rendering and extraction, the compiler package handles the transformation step inside a bundler, and the CLI plus the agent handle the workflow around a repository. A team on a bundler that the compiler plugin does not cover has to check that first, because the whole component model depends on that transform running.

Locadex is the migration path for an existing codebase

Most teams arrive at a localization tool with an existing React application that has no internationalization at all, and the cost of getting there is the real blocker. That is the gap locadex is aimed at. It is described as an AI agent for automating i18n in complex codebases, and it appears twice in the documentation, once as a package in the table and once as the hosted setup path in Quick Start. The distinction from the wizard matters. The wizard is the interactive configuration step, while the agent is aimed at the bulk work of taking code that was never written for localization and making it localizable, which is a mechanical but volume-heavy task across a large component tree. The release list shows locadex moving on its own version line, with locadex at 1.0.247 published on 2026-10-14, a patch number far ahead of the 2.x versions of the other packages, which is the usual sign of a service-backed component that is still finding its shape.

The monorepo runs on turbo, vitest and oxlint

The root package.json is a workspace definition with packages, examples, test applications under tests/apps and bundle analysis tools, all built with pnpm workspaces and turbo. The scripts show the pipeline in a few lines. Building filters turbo to the packages directory, testing does the same, and typechecking widens the filter to include the examples and the test applications, which is a sensible split, since the examples are the part that breaks when a package changes its contract. Formatting and linting run with oxlint and oxfmt, and a separate check script verifies the library defaults and a release version check runs before publishing:

    "build": "turbo run build --filter='./packages/*' --ui tui",
    "watch": "pnpm build:watch",
    "build:watch": "turbo watch build --filter='./packages/*' --ui tui",
    "analyze:bundle": "pnpm --filter gt-bundle-analysis start",
    "test": "turbo run test --filter='./packages/*'",

There is also a size budget enforced with size-limit, which matters for a library that injects a wrapper around components, and a bundle analysis tool that reports what the packages cost. Publishing is handled by changesets, with the version and changelog steps scripted, and the repository carries a rust-toolchain.toml even though the packages are TypeScript, which suggests a native component somewhere in the toolchain. The linting stack is oxlint and oxfmt rather than eslint and prettier for the workspace, with eslint reserved for the React Core plugin.

The examples double as the supported stack list

The examples directory is effectively a compatibility matrix, and it is worth reading as one. For Next.js there are next-chatbot, next-create-app, next-gt-starter, next-pages-router and next-ssg, which covers the app router, the pages router, static generation and a starter, and next-chatbot is the interesting one because it is a realistic application rather than a hello world. For React there is expo-react-native, which shows the library working outside the browser, and for the plain bundler cases there are vite-create-app, vite-spa, rollup-spa and webpack-spa, one per bundler. The presence of a Vite, a Rollup and a Webpack example for the same kind of application tells you the compiler plugin is expected to work across all three, which is what the package table claims. Each example also carries its own oxlint configuration, for example the next and react variants, which is a small signal that the lint rules differ per stack. The README for the examples directory is part of the tree, and test-fixtures/ and tests/ at the top level hold the fixtures the test suite runs against.

A hosted service under an MIT licence

The licence of the code is MIT, which covers the packages themselves, but the workflow expects a hosted service, and that is the line to think about before adopting. The instructions ask for a free API key from generaltranslation.com, the dashboard is where projects are configured, and the translation work is the part that leaves your repository. What that means in practice depends on how sensitive your interface text is, and on whether the service offers a plan you can live with. On the release side, three packages moved together on 2026-10-14, with the CLI at gtx-cli 2.26.5, the core gt package at 2.26.5 and locadex at 1.0.247, and the version alignment between the CLI and the core package is what keeps a project from mixing a new CLI with an old library. The repository is not archived, the last push was on 2026-10-15, and the releases are frequent enough that pinning matters.

Editorial conclusion

General Translation fits a React or Next.js team that never adopted string dictionaries and does not want to, since the component level model removes the extraction step that dominates most i18n migrations, and the same packages cover Vue, plain JavaScript and Sanity. It does not fit a project that must keep translation entirely in house, because the workflow expects a free API key from generaltranslation.com and the actual translation happens as a service, and it does not fit a team that needs every package pinned, since three packages release together and the versions move on their own schedule. Before you start, run npx gt@latest in a scratch project to see what the wizard changes, read the documentation at generaltranslation.com/docs, and check which of your build tools the compiler plugin covers, since the webpack, Vite, Rollup and esbuild plugin is what decides whether the transformation happens at all in your pipeline.

Frequently asked questions

Official sources

1. generaltranslation/gt on GitHub
2. License: MIT
3. Project website
4. README
5. Releases