DEV Community: Babelize

JSON Translation Files Explained: A Beginner’s Guide to Localization

Mohit Sapat — Sun, 25 Oct 2026 07:57:44 +0000

TL;DR: A JSON translation file stores your app's user-facing text for one language as key-value pairs, such as en.json and fr.json. Your code calls t("auth.login") instead of hardcoding text, and the i18n library returns the value from the active locale's file. Every locale uses identical keys; only the translated values change.

A JSON translation file is where your app's words live. Learn how JSON locale files are structured, how the t() function finds the right string, how to name and organize files per language, how to translate a JSON file without breaking it, and the mistakes that cause missing text in production.

What Is a JSON Translation File?

A JSON translation file (also called a JSON locale file or JSON language file) stores the user-facing text of your application for one language. Instead of writing text directly inside your components, you give every string a key and put the actual words in a file per language. At runtime, your i18n library loads the file for the active locale and looks up each key.

Think of it like a dictionary:

{
    "welcome": "Welcome",
    "login": "Log in",
    "logout": "Log out",
    "profile": "Profile"
}

Here, welcome, login, logout, and profile are translation keys. The values are the text users see. A French file has the exact same keys with French values, and a German file has the same keys with German values. That is the whole contract of a multi-language JSON setup: keys are identical across every locale, only the values change.

JSON became the default format for web localization because every JavaScript runtime can parse it natively, bundlers can import it directly, and it maps cleanly to the nested objects that libraries like next-intl, react-i18next, vue-i18n, and FormatJS expect.

Why Use JSON Instead of Hardcoding Text?

On a small project, writing text directly inside your components feels normal. The moment someone asks to support French, then German, then Japanese, every hardcoded string becomes a file you have to edit, a review you have to repeat, and a place a translation can be forgotten.

Instead, your component asks for a key:

<h1>{t("welcome")}</h1>

Now the component does not care which language the user speaks. The translation file does the rest. This separation is the core of internationalization; if the distinction between preparing code and adapting content is new to you, our explainer on i18n vs l10n covers it in detail.

Adding a language means adding a file, not editing components
Translators can work on text without touching the codebase
Copy changes go through a single, reviewable place
Tools can diff, validate, and machine-check the files in CI

Flat vs Nested Keys

There are two common ways to shape a JSON translation file. A flat file uses one level of keys, usually with dots in the key name:

{
    "auth.login.title": "Sign in to your account",
    "auth.login.button": "Log in",
    "auth.logout": "Log out"
}

A nested file groups related strings into objects:

{
    "auth": {
        "login": {
            "title": "Sign in to your account",
            "button": "Log in"
        },
        "logout": "Log out"
    }
}

In most libraries you read both shapes the same way, with dot notation: t("auth.login.button"). Nested files are easier to scan and let you pass a whole group to one component. next-intl, for example, expects nested messages and lets you scope a hook to a branch with useTranslations("auth.login"), then call t("button"). Flat files are easier to grep and diff line by line, and some translation tools prefer them. Pick one shape per project and stick with it; mixing them leads to keys that resolve in one locale and not another.

login > title and button, auth > logout). Both resolve t("auth.login.button") to "Log in"; next-intl can scope a nested branch with useTranslations("auth.login") and then call t("button")."/>

Flat and nested files hold the same strings and resolve the same dot-notation key.

Whichever shape you choose, name keys by meaning and location, not by content. checkout.payButton survives a copy change from "Pay now" to "Complete purchase". A key called payNow does not, and a key called text1 tells nobody anything.

Naming and Organizing Locale Files

Name each file after a BCP 47 language tag: en.json, fr.json, de.json, ja.json, and add a region only when content actually differs, as in pt-BR.json and pt-PT.json. Use hyphens rather than underscores, since the JavaScript Intl API and HTML lang attributes expect hyphenated tags. Our guide to locale codes and BCP 47 covers the traps, such as Japanese being ja, not jp.

A single file per locale is fine for small apps. As the app grows, split each locale into a folder of namespaces, one per feature:

locales/
├── en/
│   ├── common.json
│   ├── auth.json
│   └── billing.json
├── fr/
│   ├── common.json
│   ├── auth.json
│   └── billing.json
└── pt-BR/
    ├── common.json
    ├── auth.json
    └── billing.json

Namespaces keep files small enough to review, reduce merge conflicts when several people add strings at once, and let a library load only the namespaces a page needs instead of every string in the app.

Start with one file per locale; split each locale into feature namespaces as the app grows.

How t() Finds a Translation

The t() function (short for "translate") does not translate anything. It is a lookup. Given a key, it resolves the value in the active locale's messages, fills in any variables, and returns a string. Here is a minimal version in plain JavaScript that shows the moving parts:

const messages = {
    en: { cart: { title: "Your cart", greeting: "Hi {name}!" } },
    fr: { cart: { title: "Votre panier" } },
};

function t(locale, key, values = {}) {
    const lookup = (loc) => key.split(".").reduce((node, part) => node?.[part], messages[loc]);
    const template = lookup(locale) ?? lookup("en") ?? key;
    return template.replace(/\{(\w+)\}/g, (_, name) => values[name] ?? `{${name}}`);
}

t("fr", "cart.title");                      // "Votre panier"
t("fr", "cart.greeting", { name: "Léa" });  // "Hi Léa!" (fell back to English)
t("fr", "cart.total");                      // "cart.total" (missing everywhere)

Real libraries add caching, plural rules, and formatting, but follow the same three steps:

Resolve the key by walking the dot path through the active locale's messages.
Fall back when it is missing. i18next walks its fallbackLng chain (for example pt-BR → pt → en). next-intl reports the missing message through its onError handler and renders a fallback, by default the key path.
Interpolate variables into the string.

That fallback behavior is why a missing key rarely crashes your app. Instead, a French user quietly sees English, or worse, sees cart.total on screen. Treat missing keys as bugs and catch them before users do: our guide to automating app localization includes a short Node.js script that fails CI when a locale is missing keys.

Placeholders: {name} vs {{name}}

Variables are where JSON translation files stop being interchangeable between libraries. The two dominant syntaxes look almost identical:

// ICU syntax: next-intl, react-intl / FormatJS, vue-i18n
"greeting": "Welcome back, {name}!"

// i18next default syntax: i18next, react-i18next
"greeting": "Welcome back, {{name}}!"

Both are called the same way, t("greeting", { name: user.firstName }), but a file written for one library will print literal braces in the other. If you migrate between libraries, convert placeholders as part of the move.

Always use placeholders rather than concatenating fragments. t("hello") + " " + name forces English word order on every language. A single message with {name} lets the translator put the name wherever the grammar needs it.

Plurals in JSON Translation Files

Plurals are the other big syntax split. ICU-based libraries keep every plural form inside one message:

{
    "itemCount": "{count, plural, =0 {Your cart is empty} one {# item} other {# items}}"
}

i18next (v21 and later) uses separate keys with a plural-category suffix, and picks one based on the count you pass:

{
    "itemCount_zero": "Your cart is empty",
    "itemCount_one": "{{count}} item",
    "itemCount_other": "{{count}} items"
}

Either way, the set of plural forms belongs to each language, not to English. Polish needs one, few, many, and other; Japanese needs only other. A Polish i18next file therefore has keys like itemCount_few that the English file does not. Our ICU MessageFormat plurals guide explains the categories and why a count === 1 check breaks in most languages.

Loading JSON Files in Real Libraries

next-intl (Next.js App Router)

next-intl loads one messages file per locale on the server, in the request config. Only the locale being rendered is imported:

// src/i18n/request.ts
import { getRequestConfig } from "next-intl/server";
import { hasLocale } from "next-intl";
import { routing } from "./routing";

export default getRequestConfig(async ({ requestLocale }) => {
    const requested = await requestLocale;
    const locale = hasLocale(routing.locales, requested) ? requested : routing.defaultLocale;

    return {
        locale,
        messages: (await import(`../../messages/${locale}.json`)).default,
    };
});

Server Components then call getTranslations() and Client Components call useTranslations(). The full setup is in our step-by-step next-intl tutorial.

react-i18next

react-i18next takes resources organized by language and namespace. You can bundle them directly, or lazy-load them over HTTP with a backend plugin such as i18next-http-backend:

import i18n from "i18next";
import { initReactI18next } from "react-i18next";
import enCommon from "./locales/en/common.json";
import frCommon from "./locales/fr/common.json";

i18n.use(initReactI18next).init({
    resources: {
        en: { common: enCommon },
        fr: { common: frCommon },
    },
    lng: "en",
    fallbackLng: "en",
    defaultNS: "common",
    interpolation: { escapeValue: false }, // React already escapes output
});

Components use const { t } = useTranslation("common"). If you are still choosing between the two libraries, see our next-intl vs react-i18next comparison.

No framework (plain HTML)

A static site can use the same files with a few lines of JavaScript: mark elements with data-i18n, fetch locales/fr.json, and swap the text. How to translate a static HTML website walks through a tested runtime and a build step that writes one page per language.

How to Translate a JSON File Safely

Translating a JSON file looks like a simple find-and-replace job. It is the step where most localization bugs are introduced, because a translator or a machine translation tool that does not understand the file's rules can break it in ways that only show up at runtime.

Translate values, never keys. "login": "Connexion" is right. "connexion": "Connexion" means the French build can no longer find login.
Preserve placeholders exactly. {name} and {{count}} must survive untouched. A translated {nom} renders as a literal or throws.
Keep ICU syntax intact. Keywords like plural, select, one, and other are code, not English. Only the text inside the branches gets translated.
Keep rich-text tags. If a message contains <link>Terms</link>, the tag names must stay the same so your component can map them.
Escape quotes and save as UTF-8. A French value containing a straight double quote must be written as \". Accented and non-Latin characters can be stored directly in UTF-8; there is no need for \u escapes.
Validate the result. Parse every file after translation. One missing comma makes the entire locale fail to load.

Generic machine translation, including pasting a whole file into a chatbot, tends to fail on exactly these points: it translates keys, rewrites placeholders, "fixes" ICU keywords, or returns a file with a trailing comma. It also lacks context; "Open" as a button and "Open" as a ticket status translate differently in many languages. Whatever tool you use, run the same automated checks on its output that you would run on a human translator's. For step-by-step scripts (a translation API with placeholder protection, an LLM, validation and plural forms), see how to translate JSON files for i18n.

JSON vs Other Translation File Formats

JSON dominates web projects, but it is not the only format. You will meet these as soon as you add a mobile app or work with a translation agency:

Format	Typical use	Notes
JSON	JavaScript web apps (next-intl, i18next, vue-i18n)	Native to JS, supports nesting, no comments
YAML	Ruby on Rails, some static site generators	Allows comments, indentation-sensitive
PO / gettext	Django, PHP, Linux and C projects	Source text as the key, translator comments, built-in plural forms
XLIFF	Exchange with translation agencies and CAT tools	XML standard holding source and target side by side
ARB	Flutter	JSON-based, ICU messages, metadata in `@key` entries
`.strings` / `.xcstrings`	iOS and macOS	Apple's string catalogs; `.xcstrings` is JSON-based
`strings.xml`	Android	XML resources with a dedicated `plurals` element

One limitation stands out: JSON has no comments, so there is nowhere to tell a translator that "Save" is a verb on a button and not a noun. Teams work around this with a separate description file, a context field in their translation platform, or descriptive key names. If you are standardizing on JSON, see how Babelize handles JSON locale files.

Common Mistakes With JSON Locale Files

Concatenating translated fragments. Build whole sentences with placeholders, never by joining keys.
Reusing one key in two contexts. Key by meaning, so each context can be translated independently.
Key drift between locales. A key added to en.json but not to de.json silently falls back to English. A key renamed in one file but not the others is the same bug in reverse.
Invalid JSON. Trailing commas, single quotes, and comments are all illegal in JSON and stop the locale from loading.
Duplicate keys. JSON.parse does not complain about them; the last value wins, so an earlier translation silently disappears.
Encoding problems. Save files as UTF-8 without a byte order mark. A BOM makes JSON.parse throw, and non-UTF-8 encodings turn accents into garbage.
One giant file. Thousands of keys in a single file make reviews painful and force every page to load every string.

Catch Missing Keys in CI

Key drift is easy to detect automatically. This Node script flattens every locale file and compares its keys against en.json, failing the build if any are missing or extra:

// scripts/check-locales.mjs
import fs from "node:fs";
import path from "node:path";

const dir = "messages";
const flatten = (obj, prefix = "") =>
    Object.entries(obj).flatMap(([key, value]) =>
        value && typeof value === "object" ? flatten(value, `${prefix}${key}.`) : [`${prefix}${key}`]
    );
const keysOf = (file) => new Set(flatten(JSON.parse(fs.readFileSync(path.join(dir, file), "utf8"))));

const source = keysOf("en.json");
let failed = false;

for (const file of fs.readdirSync(dir).filter((f) => f.endsWith(".json") && f !== "en.json")) {
    const keys = keysOf(file);
    const missing = [...source].filter((k) => !keys.has(k));
    const extra = [...keys].filter((k) => !source.has(k));
    if (missing.length || extra.length) {
        failed = true;
        console.error(`${file}: missing [${missing.join(", ")}] extra [${extra.join(", ")}]`);
    }
}

process.exit(failed ? 1 : 0);

Because JSON.parse runs on every file, the script also fails on invalid JSON. If you use i18next plural suffixes, strip _zero, _one, _two, _few, _many, and _other before comparing, since each language legitimately has a different set. To catch strings that never made it into a JSON file at all, pair this with pseudo-localization testing.

If you would rather not maintain the script, babelize check runs the same key comparison plus placeholder and plural checks with npx @babelize/cli check. It only reads your files, so it needs no account and no network access.

Type-Safe Translation Keys

With TypeScript, you can make a typo in a key a compile error instead of a blank label. Both major libraries type keys from your source-language JSON file through module augmentation. In next-intl:

// global.d.ts
import messages from "./messages/en.json";

declare module "next-intl" {
    interface AppConfig {
        Messages: typeof messages;
    }
}

And in react-i18next:

// i18next.d.ts
import "i18next";
import common from "./locales/en/common.json";

declare module "i18next" {
    interface CustomTypeOptions {
        defaultNS: "common";
        resources: { common: typeof common };
    }
}

With either in place, t("auth.logn") fails type checking and your editor autocompletes valid keys.

Frequently Asked Questions

What is a JSON translation file?

A JSON translation file stores an application's user-facing text for one language as key-value pairs, for example en.json for English and fr.json for French. The code references keys, and the i18n library loads the file for the active locale and returns the matching value.

How should I name JSON locale files?

Name each file after a BCP 47 language tag, such as en.json, fr.json, or pt-BR.json, using hyphens rather than underscores. Add a region only when content differs between regions. For larger apps, use one folder per locale with a JSON file per feature namespace.

Should translation keys be flat or nested?

Both work, and most libraries read either shape with dot notation such as auth.login.button. Nested files are easier to scan and let you scope translations to a component; flat files are easier to search and diff. Choose one shape per project and use it consistently.

How do I translate a JSON file without breaking it?

Translate only the values, never the keys. Keep placeholders such as {name} or {{count}}, ICU keywords like plural and other, and rich-text tags exactly as they are. Save the file as UTF-8, escape double quotes, and parse every file in CI to catch invalid JSON.

What happens when a translation key is missing?

Most libraries fall back instead of crashing. i18next tries the fallback language chain and then shows the key itself. next-intl reports the error and renders a fallback, by default the key path. Users see English or a raw key, so check for missing keys in CI.

Final Thoughts

JSON translation files look simple, and that is their strength: one file per locale, identical keys, values that change. The work is in keeping them that way. Use meaningful nested keys, BCP 47 file names, placeholders instead of concatenation, and real plural syntax. Translate values only, validate every file, and fail the build when locales drift apart.

Keeping ten locale files in sync by hand is the part that does not scale. Babelize (our product) detects new and changed keys in your source JSON, generates placeholder-safe translations for every locale, and commits them back to your repository. You can run it from the terminal with the Babelize CLI.

Written with AI assistance and reviewed by the Babelize team.

Originally published on the Babelize blog. Disclosure: Babelize is our product, an AI localization tool for Next.js, React and Vue apps: it turns hardcoded strings into a reviewed i18n pull request.

How We Turn a Next.js App's Hardcoded Strings Into a Reviewed i18n Pull Request

Mohit Sapat — Sat, 24 Oct 2026 15:12:43 +0000

TL;DR: Babelize parses every file with a Babel AST, extracts only user-facing text (whole JSX sentences become ICU messages with placeholders, tags and plurals), names keys from the file path and first words, hashes source text into a lockfile so reruns only translate what changed, validates every LLM translation for lost placeholders, broken ICU and untranslated output, then rewrites components to use next-intl and opens a diff or pull request for review.

Every React app starts with hardcoded text, and nobody wants to spend a sprint moving 900 strings into JSON files by hand. This is how Babelize does it: an AST pass that finds the text worth translating, keys that stay stable between runs, a lockfile so reruns cost nothing, an LLM whose output we refuse to trust, and a code rewrite that keeps your formatting. Plus the cases where it deliberately stops and asks you.

The Problem: Text Lives Inside Components

A typical Next.js page looks like this:

// src/app/dashboard/page.tsx
export default function Dashboard({ user, count }) {
  return (
    <main>
      <h1>Welcome back, {user.name}</h1>
      <p>Read the <Link href="/terms">terms</Link> before you continue.</p>
      <input placeholder="Search projects" className="input" />
      <span>{count} projects</span>
    </main>
  );
}

Find-and-replace can't localize this. "Welcome back," and {user.name} are one sentence, and other languages put the name somewhere else. The link sits in the middle of a sentence. placeholder is user-facing, className isn't. "projects" needs a plural form, and Polish has four of them. Doing it properly means understanding the code, not the text.

Step 1: Find the Strings with an AST, Not a Regex

Every file is parsed with @babel/parser (JSX and TypeScript plugins, with error recovery so one broken file doesn't stop the run). Then visitors walk the tree looking for JSX text, whole JSX elements, string literals, template literals, + concatenations and both branches of ternaries.

Most of the work is deciding what not to extract:

Attributes: only an allowlist is user-facing: title, placeholder, alt, aria-label, aria-description, label, description (plus accessibilityLabel and accessibilityHint for React Native). className, href and everything else is left alone.
Objects: a string under a copy-like key (label, title, message) is UI text; under a data-like key (href, url, id, className) it's data.
Calls: console.*, throw, new Error(...) and hook arguments are skipped, along with almost every other call argument.
Values that look like data: URLs and paths, CSS selectors, colors, ISO dates, all-caps identifiers like SKU12345, pure numbers and symbols, and text under three characters.
Files: node_modules, build output, tests, specs and .d.ts files.

Sentences, not fragments

The key decision: a JSX element with mixed children becomes one ICU message, so translators see the whole sentence. Interpolations become named placeholders, and inline tags like <Link>, <b> or <code> become tags inside the message:

"Welcome back, {name}"
"Read the <link>terms</link> before you continue."
"{count, plural, one {# project} other {# projects}}"

The plural comes from a deliberately narrow rule: exactly one placeholder with a count-like name (count, total, n, or ending in Count), referenced directly, and followed by an English noun we can singularize. {data?.count} items doesn't qualify, because if data is undefined you'd ship "NaN items" in nine languages.

When an element can't be folded into a sentence safely (a child expression with side effects, spread props, children passed through, literal braces in the text), it's kept as separate fragments and you get a warning instead of a guess.

Step 2: Keys That Stay Put

Key names are boring on purpose. The namespace comes from the file path, with noise like src, app, components and a trailing page or index stripped. The key is the first five words, camelCased. So "Welcome back, {name}" in src/app/dashboard/page.tsx becomes dashboard.welcomeBack.

Collisions get _2, _3 suffixes. On later runs, a string whose text hasn't changed gets its existing key back instead of a new copy, so a rerun never renames keys under you.

Step 3: A Lockfile, So Reruns Are Nearly Free

Localization isn't a one-off, because you keep shipping English. So every key's source text is hashed (SHA-256) into a lockfile, along with its translations per locale:

.babelize/local/babelize-lock.json

On the next run, keys fall into four groups:

Unchanged: reused, nothing sent anywhere.
New: translated.
Changed source: the hash differs, so it's translated again.
Missing a locale: you added Japanese, or the glossary changed, so only the gaps are translated.

Commit the lockfile with your code. Teammates and CI then get the same "already translated" view, and a rerun after a small feature only pays for the handful of strings you added.

Step 4: Translate, Then Don't Trust the Output

Keys go to the model in batches of 15, three batches at a time. You can use your own key (Anthropic, OpenAI, Gemini, Groq, OpenRouter) or Babelize's hosted translation. Before sending, placeholders, tags and brand names are swapped for opaque tokens like [#VAR_0#], and the prompt says each must come back exactly once. ICU messages keep their argument names, #, and the target language's own plural categories.

Then every value is checked before it's written:

Placeholder lost: a token is missing or duplicated, so {name} would never render.
Invalid ICU: the plural or select no longer parses, or a branch was dropped.
Markup mismatch: the <link> tag disappeared from a branch.
Untranslated: the model handed the English back.

A rejected key gets one targeted repair attempt, with a note telling the model what was wrong. If that fails too, the key is left out of the locale file. It's never filled with English and never shipped broken. It's also kept out of the lockfile, so the next run retries it, and the CLI exits with code 6 so CI notices a partial run.

Step 5: Rewrite the Code Without Wrecking Your Diff

Injection reuses the exact source positions recorded during extraction, and rewrites files with recast, so your formatting, comments and quote style survive. For Next.js App Router projects with next-intl:

A component that's already async and isn't in a 'use client' file gets await getTranslations(). Everything else gets useTranslations(). Components are never made async behind your back.
Rich text becomes t.rich() with your original element passed back in, so the link keeps its href and props.

const t = useTranslations();

<h1>{t("dashboard.welcomeBack", { name: user.name })}</h1>
<p>
  {t.rich("dashboard.readTheTermsBeforeYou", {
    link: (chunks) => <Link href="/terms">{chunks}</Link>,
  })}
</p>

Then the project is wired up:

i18n/request.ts picks the language from a NEXT_LOCALE cookie, then the browser's Accept-Language.
next.config is wrapped with next-intl's plugin, and the root layout's children with NextIntlClientProvider.
Messages go to public/locales/<locale>.json.
No middleware and no /de/... routes, so your URLs, auth and redirects stay untouched.

On local runs, your own Prettier or Biome config then runs on the changed source files, so the diff reads like a teammate wrote it.

What It Refuses to Guess

The interesting part of a tool like this is where it stops. Babelize reports these instead of improvising:

Module-level constants used outside a render: translating them at import time would freeze one language. You get "move it inside the component".
Strings with no place for a hook, outside any component: extracted and translated, but listed as not wired in, with the reason.
Dynamic keys like t(`status.${s}`): once one appears, the "unused keys" report turns itself off rather than flagging keys that are in use.
A run that would delete existing translations aborts.
Hardcoded dates and currency get a warning, because formatting them belongs to Intl, not to translators.

Local Diff or Pull Request

There are two ways to run the same pipeline:

npx babelize

This runs in your project folder. It needs a git repo and a clean working tree, works on a temporary copy of the project, and only writes back if none of your files changed in the meantime. You review with git diff and commit, lockfile included. With your own LLM key in the environment you don't need an account.

Or connect the repo with the GitHub App. The same pipeline then opens a pull request, and can keep one PR per branch up to date as you push.

Either way the rule is the same: nothing lands in your code until a human reviews it. Localization tools that write straight to production are how you end up with "Willkommen zurück, undefined".

Written with AI assistance and reviewed by the Babelize team. Every technical detail was checked against the Babelize engine source.

Plurals, Genders, and Variables: ICU MessageFormat for Developers

Mohit Sapat — Thu, 22 Oct 2026 13:07:17 +0000

TL;DR: ICU MessageFormat is a translation string syntax that puts plural rules, gender, and variables inside one message, such as {count, plural, one {# item} other {# items}}. Your code passes raw values; each locale's translation picks its own CLDR plural categories (zero, one, two, few, many, other), so Polish gets four forms, Arabic six, and Japanese one.

Your English pluralization logic will break in Polish, Arabic, and Russian. Learn how ICU MessageFormat handles plurals, gender, numbers, and nested variables so your translated strings stay grammatical in every language you ship.

ICU MessageFormat Syntax Cheat Sheet

Every ICU construct you will actually use, with what it renders. The # inside a plural branch is replaced by the formatted number.

Construct	Syntax	Renders as
Variable	`Hello, {name}!`	Hello, Ana!
Plural	`{count, plural, one {# file} other {# files}}`	1 file · 5 files
Exact match	`{count, plural, =0 {No files} one {# file} other {# files}}`	No files
Select	`{gender, select, female {She} male {He} other {They}} replied`	They replied
Ordinal	`{n, selectordinal, one {#st} two {#nd} few {#rd} other {#th}}`	21st · 22nd · 23rd · 4th
Offset	`{n, plural, offset:1 =0 {Nobody} =1 {{name}} one {{name} and # other} other {{name} and # others}}`	Ana and 2 others (n = 3)
Number	`{price, number, ::currency/EUR}`	€1,234.50 (en) · 1.234,50 € (de)
Date	`{when, date, medium}`	Oct 13, 2026
Rich text tag	`You have <b>{count}</b> new messages`	You have 3 new messages
Escaping	`'{literal}'` and `''`	{literal} and '

Two rules hold in every message: a plural, select, or selectordinal must end with an other branch, and the translator writes the whole sentence inside each branch. The sections below explain each construct and the mistakes that break them.

The Bug That Ships in Almost Every App

Here is a line of code that exists in thousands of production codebases right now:

const label = count === 1 ? "1 item" : `${count} items`;

It works perfectly. In English. The moment you translate it, it quietly becomes wrong in most of the world's languages, and nobody on your team will notice because nobody on your team reads Polish.

English has two plural forms: singular and everything else. That is unusually simple. According to the Unicode CLDR plural rules, languages fall into six possible plural categories — zero, one, two, few, many, and other — and each language uses a different subset.

Language	Plural categories	Notes
Japanese, Korean, Chinese, Vietnamese	1	other only: same form for 0, 1, 2, 100
English, German, Dutch, Turkish	2	one / other
Spanish, Italian	3	one / many / other: many covers exact millions (1 millón de usuarios)
French, Portuguese (BR)	3	one / many / other: 0 and 1 share one; many covers exact millions
Czech, Slovak	4	one / few / many / other: many is for decimals
Polish, Russian, Ukrainian	4	one / few / many / other
Arabic	6	zero / one / two / few / many / other

Russian is a good illustration of why a ternary cannot save you. The word for "file" changes based on the last digit of the number: 1 файл, 2 файла, 5 файлов, 21 файл, 22 файла, 25 файлов. There is no way to express that with count === 1. There is also no way to express it by adding a second key called items_plural, which is the workaround most teams reach for next.

What ICU MessageFormat Actually Is

ICU MessageFormat is a string syntax, originally from the International Components for Unicode project, that moves grammatical decisions out of your code and into the translation string itself. It is supported by next-intl, react-intl / FormatJS, i18next (via the ICU plugin), Android, iOS, Java, and most translation management platforms. If you are still choosing a React library, our next-intl vs react-i18next comparison covers how each one handles ICU.

The basic ICU syntax is a placeholder in curly braces: {argument} for a plain value, or {argument, type, options} where the type is plural, select, selectordinal, number, date, or time. The same message in ICU, stored in an ordinary JSON translation file, looks like this:

{
  "fileCount": "{count, plural, one {# file} other {# files}}"
}

And the Polish translator, without touching your code, writes:

{
  "fileCount": "{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}"
}

Your component stays identical in both cases:

t("fileCount", { count: files.length })

That is the whole idea. The code passes data. The translation decides grammar. The # is a placeholder for the number, already formatted for the locale — so a German user sees 1.234 Dateien and an American sees 1,234 files without you writing a single formatting branch.

The count picks a CLDR plural category per locale, and the category picks the branch. The same code works for English, Polish and Arabic.

The Four Constructs Worth Knowing

1. Simple arguments

The basic case — a variable dropped into a sentence:

"greeting": "Welcome back, {name}!"

This already buys you something important: the translator controls where {name} goes. In Japanese, the name comes before the greeting. If you had written t("welcome") + " " + name, the translator would have been stuck.

2. plural

"notifications": "{count, plural,
  =0 {No new notifications}
  one {# new notification}
  other {# new notifications}
}"

Note the difference between =0 and zero. The =0 form is an exact match — it fires whenever the value is literally 0, in any language. The zero category is a grammatical category used by languages like Arabic and Latvian, and it may not fire for the number 0 at all in a language that does not have it. Use =0 for "empty state" copy and leave the named categories for grammar.

3. select

For gender agreement and any other branching that is not numeric:

"invited": "{gender, select,
  male {He invited you to {project}}
  female {She invited you to {project}}
  other {They invited you to {project}}
}"

This matters more than English developers expect. In Spanish, French, Russian, Hebrew, and Arabic, adjectives and past participles agree with gender. A message like "You are subscribed" has two different forms in Russian depending on who is reading it. If your product knows the user's gender, expose it as a select argument. If it does not, that is a real product decision — tell your translators so they can pick a neutral phrasing instead of guessing.

4. selectordinal

"rank": "You finished {place, selectordinal,
  one {#st} two {#nd} few {#rd} other {#th}
} in the leaderboard"

Ordinals follow their own rules that are unrelated to plural rules — 1st, 2nd, 3rd, 4th, 21st, 22nd. Hardcoding a suffix table is a classic source of "22th" bugs.

ICU Plural Rules by Language

These are the CLDR categories each language uses, with example numbers that land in each one. Cardinal rules drive plural; ordinal rules drive selectordinal. Your translation for a locale needs a branch for every category that locale uses, and nothing else.

Language	Cardinal (plural)	Ordinal (selectordinal)
English	one (1) · other (0, 2, 3)	one (1st, 21st) · two (2nd, 22nd) · few (3rd, 23rd) · other (4th)
German, Dutch	one (1) · other (0, 2, 3)	other
Spanish, Italian	one (1) · many (1,000,000) · other (0, 2, 3)	Spanish: other · Italian: many (8, 11, 80) · other
French	one (0, 1, 1.5) · many (1,000,000) · other (2, 3)	one (1er) · other
Portuguese	one (0, 1, 1.5) · many (1,000,000) · other (2, 3)	other
Russian, Ukrainian	one (1, 21, 31) · few (2–4, 22) · many (0, 5–20) · other (1.5)	Russian: other · Ukrainian: few (3, 23) · other
Polish	one (1) · few (2–4, 22) · many (0, 5–21) · other (1.5)	other
Czech, Slovak	one (1) · few (2–4) · many (1.5) · other (0, 5, 6)	other
Arabic	zero (0) · one (1) · two (2) · few (3–10) · many (11–99) · other (100, 101)	other
Hebrew	one (1) · two (2) · other (0, 3, 4)	other
Hindi	one (0, 1) · other (2, 3)	one (1) · two (2, 3) · few (4) · many (6) · other
Latvian	zero (0, 10–20) · one (1, 21, 31) · other (2–9)	other
Welsh	zero (0) · one (1) · two (2) · few (3) · many (6) · other (4, 5, 7)	zero · one · two · few · many · other
Japanese, Chinese, Korean, Turkish	Turkish: one (1) · other · others: other only	other

Two details catch people out. French and Portuguese put 0 in one, so "0 fichier" is singular. Spanish, French, Italian, and Portuguese now have a many category for exact millions ("1 millón de usuarios"), so a translation with only one and other will fall back to other there.

Rules change between CLDR releases, so check against the runtime your users actually have instead of a table:

new Intl.PluralRules("pl").resolvedOptions().pluralCategories;
// ["few", "many", "one", "other"]

new Intl.PluralRules("en", { type: "ordinal" }).select(22);
// "two"  →  22nd

Numbers, Dates, and Currency Inside Messages

ICU also wraps the Intl formatting APIs, so you can keep formatting inside the message where the translator can see it in context:

"invoice": "Your invoice for {amount, number, ::currency/USD} is due {date, date, medium}"

The rule to internalize: pass raw values, never pre-formatted strings. If you call amount.toFixed(2) before handing the value to your translation layer, you have permanently locked every locale into American decimal separators. Pass the Number. Pass the Date. Let the formatter decide. For formatting outside of messages, see our guide to the JavaScript Intl API.

Nesting and Rich Text

Real interface copy has links and bold spans in the middle of sentences. The wrong instinct is to split the sentence into three keys — prefix, link text, suffix — and concatenate. That produces unreadable translation files and breaks in any language with different word order.

Instead, keep the sentence whole and pass the markup as a function:

// message
"terms": "By continuing you accept our <link>Terms of Service</link>."

// component
t.rich("terms", {
  link: (chunks) => <a href="/terms">{chunks}</a>,
})

The translator sees one coherent sentence and can move the link anywhere inside it. Your JSX stays in your code where it belongs.

You can also nest constructs. This is legal and occasionally necessary:

"shared": "{count, plural,
  one {{gender, select,
    female {She shared # file}
    other {They shared # file}
  }}
  other {{gender, select,
    female {She shared # files}
    other {They shared # files}
  }}
}"

Nesting select inside plural multiplies the branches: two levels mean four full sentences to translate.

It is also where readability dies. If a message needs two levels of nesting, that is usually a signal to split it into two separate UI strings instead.

Mistakes That Show Up in Code Review

Concatenating translated fragments. t("deleted") + " " + count + " " + t("items") is unfixable by a translator. One key, one sentence.
Reusing a key in two places. "Open" as a button and "Open" as a status are the same word in English and different words in German. Key by meaning, not by string.
Omitting the other branch. It is the required fallback. A message without it throws at runtime in strict formatters.
Putting HTML in the message string. Raw <b> tags invite XSS through translation files and break when a translator mangles a tag. Use rich-text callbacks.
Translating the ICU syntax itself. A machine translator with no ICU awareness will happily translate the literal word other or reorder the braces, producing a message that fails to parse. Validate ICU syntax in CI.

Validating ICU in CI

Because ICU messages are strings, a broken one is not a compile error — it is a runtime crash on a page only your Polish users visit. Worth adding to your pipeline:

Parse every message in every locale with the FormatJS parser and fail the build on syntax errors
Check that the set of variables in each translation matches the source message — a missing {count} is a silent content bug
Assert that every plural message includes an other branch
Snapshot-render a few numbers (0, 1, 2, 5, 21, 101) per locale and eyeball the output once

A pseudo-localization pass complements these checks: it exercises every message in a fake locale and exposes concatenated sentences and hardcoded strings before real translators see them.

babelize check covers the first two from the command line: npx @babelize/cli check reports broken ICU and plural forms and lost placeholders in every locale file. It only reads files, so it needs no account and no network access.

When You Do Not Need ICU

Most strings in a typical app are static labels with no variables. Those do not need ICU and wrapping them in it adds nothing. ICU earns its complexity specifically where a message contains a count, a name, a date, a currency, or a gendered reference — which in practice is a minority of your keys, and the source of most of your localization bugs.

FAQ

What is ICU MessageFormat?

ICU MessageFormat is a string syntax that lets a single translation key express plural rules, gender agreement, number formatting, and conditional text. It moves grammatical decisions out of application code and into the translation string, so each locale can supply its own plural categories and word order.

What are the ICU plural rules?

ICU uses the Unicode CLDR plural categories zero, one, two, few, many, and other. Each language uses its own subset: English uses one and other, Polish and Russian use one, few, many, and other, Arabic uses all six, and Japanese uses only other. The other branch is required in every plural message.

What is the difference between =0 and zero in an ICU plural?

=0 is an exact match that fires whenever the value is literally zero, in any language, and is used for empty-state copy. zero is a grammatical plural category used by languages such as Arabic and Latvian, and it may not fire for the number 0 in languages that lack that category.

Which i18n libraries support ICU MessageFormat?

next-intl and react-intl (FormatJS) support ICU natively. i18next supports it through the i18next-icu plugin. ICU is also supported on Android, iOS, Java, and most translation management platforms.

Should I put HTML inside my ICU messages?

No. Raw HTML in translation files invites XSS and breaks when a translator mangles a tag. Use tag placeholders with a rich-text callback so the markup stays in your components while the translator keeps control of the full sentence.

The Short Version

Pluralization is grammar, and grammar belongs to the language, not to your if statement. ICU MessageFormat exists so that a translator who has never seen your codebase can produce a correct Polish sentence without asking you to ship new code. Adopt it for every message containing a variable, validate the syntax in CI, and pass raw numbers and dates rather than formatted strings.

Once ICU messages are in place, keeping every locale in sync as your source strings change becomes the next bottleneck — which is exactly the part Babelize automates, detecting new and changed keys and generating ICU-valid translations across your locale files through a Git-native workflow. See the Babelize ICU documentation for how messages are validated.

Written with AI assistance and reviewed by the Babelize team. Every formatted output was checked with intl-messageformat.

Originally published on the Babelize blog. Disclosure: Babelize is our product, an AI localization tool for Next.js, React and Vue apps: it generates and syncs your JSON locale files from your repo.

Lokalise and Crowdin Alternatives for Developers (2026)

Mohit Sapat — Sat, 17 Oct 2026 12:49:48 +0000

TL;DR: The main Lokalise and Crowdin alternatives are Phrase (enterprise suite), Tolgee (open source, in-context editing, free tier), Locize (i18next, from $7/mo) and Weblate (open source, Git-native). Crowdin, Tolgee and Locize have free plans; Lokalise and Phrase offer only trials. If your strings are still hardcoded, you need a code tool first: i18next-cli for a free partial pass, or Babelize (our product) for the whole repo as a pull request.

Lokalise and Crowdin are built for localization teams: translators, reviewers, vendors and workflows. If you are a developer who mostly wants your app to speak more languages, you may be paying for a translator workspace you never open, or discover that the tool assumes your strings already live in translation files. This guide compares seven alternatives on what developers actually care about, with prices checked on October 16, 2026 and Lingo.dev added on October 28.

First, Know Which Problem You Have

Localization tools solve one of two different problems, and most comparisons blur them:

Managing translations. Your app already uses t("checkout.title") and has locale files. You need a place where translators and machine translation fill in other languages, and a sync that brings them back to your repo. This is what a translation management system (TMS) does: Lokalise, Crowdin, Phrase, Tolgee, Locize and Weblate.
Internationalizing the code. Your app still has <h1>Welcome back</h1> hardcoded in hundreds of components. Before any TMS can help, someone has to find those strings, replace them with translation calls, set up the i18n library and create the locale files.

Every TMS below starts at step two. Their own documentation describes importing translation files or keys that already exist. If you are at step one, that is the work to solve first.

The two are not either-or. A common path is to internationalize the code first, then add a TMS only if and when you bring in human translators. The locale files are plain JSON or gettext either way, so any of the tools below can take over from there.

The Alternatives at a Glance

Tool	Free plan	Cheapest paid plan	Open source	Opens PRs in your repo
Lokalise	No (14-day trial)	Explorer: $169/mo, or $149/mo billed yearly	No	Yes
Crowdin	Yes: 60K hosted words, 1 private project	Pro: $59/mo, or from $50/mo billed yearly	No	Yes
Phrase	No (14-day trial)	$525/mo billed yearly for a developer team plan	No	Yes
Tolgee	Yes: 30,000 words, 3 seats	Translate: €69/mo ($79), or €58/mo billed yearly	Yes, self-hostable	Through the CLI in CI
Locize	Yes: 2,000 words, 2 languages	Starter: $7/mo	No	Through GitHub Actions
Weblate	Self-hosting free; hosted free for public projects	€47/mo (10,000 hosted strings)	Yes (GPLv3+)	Yes
Lingo.dev	Yes: Sandbox, 100K tokens a day, LLM costs passed through	Production: $99/mo plus usage	Yes: CLI and compiler (Apache-2.0)	Yes, through its GitHub App
Babelize	Yes: 5 projects, 10,000 AI credits a month	Starter: $9/mo, or $7/mo billed yearly	No (the Elements UI library is)	Yes

Prices are the vendors' public list prices on October 16, 2026, and they change. The units also differ: hosted words, hosted strings, seats or characters, so compare the limit that matters for your app, not just the dollar figure.

Crowdin: The Generous Free Plan

Crowdin's free plan is the most usable in this list: 60,000 hosted words, one private project, unlimited public projects and unlimited translators, with Crowdin AI and machine translation included. Hosted words are words multiplied by target languages, so 60,000 is about 6,000 source words in ten languages. The catch, from its pricing page: users on the free plan donate translations to Crowdin's translation memory. Open-source projects can apply for a free license if they meet conditions such as an OSI license, public code and an active community.

The GitHub integration syncs your source and translation files and opens pull requests from an l10n_ branch. Best for: projects that bring in many outside or volunteer translators. (pricing, GitHub integration)

Lokalise: Strong Workflows, No Free Plan

Lokalise has no free plan, only a 14-day trial. The entry Explorer plan is $169 a month ($149 billed yearly) for 5 projects and 10 languages, with unlimited translator and reviewer seats, 5 advanced seats, and a quota of machine-translated words from DeepL and Google Translate. Its GitHub integration pulls your language files and opens pull requests. The strengths are on the team side: translation memory, glossaries, tasks, in-context editors and over-the-air SDKs that update mobile apps without a release. (pricing, GitHub integration)

Phrase: Enterprise Depth

Phrase Strings is part of a suite that also translates documents. Its cheapest plan that includes Strings seats for a team is $525 a month billed yearly. It syncs with GitHub, GitLab and Bitbucket and exports translations as pull requests. If you need vendor management, quality review and one platform for software and documents, it is a serious option; for a small team it is a lot of tool. (pricing)

Tolgee: Open Source With In-Context Editing

Tolgee is open source (Apache-2.0, with enterprise parts licensed separately) and can be self-hosted for free with up to 10 seats. The cloud has a free plan of 30,000 words and 3 seats. Its standout feature is in-context editing: hold Alt, click a string in your running app and translate it on the spot. Its CLI extracts keys already used through the Tolgee SDK for React, Vue and Svelte, so you still write the translation calls yourself. (pricing, CLI extraction)

Locize: Cheapest Paid Plan, Built for i18next

Locize comes from the creators of i18next and is the cheapest paid option here at $7 a month for 15,000 words and 5 languages. Its distinguishing feature is delivery through a CDN, so translation updates can reach users without a redeploy. If you already use i18next it fits naturally. The same team publishes i18next-cli, covered below. (pricing)

Weblate: Open Source and Git-Native

Weblate is a web TMS built on version control, licensed GPLv3+ and free to self-host. Hosted plans start at €47 a month for 10,000 hosted strings, where hosted strings are source strings times the number of languages plus one. Public open-source projects can use the free Libre plan. It opens merge requests with translation changes and supports many engines, from DeepL to self-hosted Ollama. (hosting, version control)

Lingo.dev: AI Translation Wired Into CI

Lingo.dev is built around AI translation rather than a translator workspace. Its CLI pushes your locale files to a translation "engine" (your choice of LLM, plus brand voice, glossary and AI review), and its GitHub App opens or updates a translation pull request on every push to the default branch. The CLI is open source under Apache-2.0 and handles eighteen file formats, from JSON and YAML to PO, XLIFF and Flutter ARB. The free Sandbox plan allows 100K tokens a day; Production starts at $99 a month plus usage, and LLM costs are passed through without markup. (pricing, GitHub)

Like Lokalise and Crowdin, the CLI translates files that already exist. For hardcoded strings, Lingo.dev also has a compiler, covered in the next section.

If Your Strings Are Still Hardcoded

None of the platforms above will turn <h1>Welcome back</h1> into a translation call across your codebase. These tools do part or all of that job:

i18next-cli instrument (free, MIT). It scans source code for hardcoded user-facing strings and wraps them in i18next calls. Its README says it is heuristic and will not catch every case, and its docs cover React and JavaScript/TypeScript. A good free start for React apps. (GitHub)
Lingo.dev Compiler (free, open source). It reads your JSX at build time and injects AI translations without changing your components, so there are no keys or t() calls in your code. It supports Next.js (App Router) and Vite with React and needs an LLM provider. Its docs currently say it is in alpha, "unstable, not recommended for production use". (docs)
Editor extensions. Lokalise's i18n Ally has experimental "extract hard-coded strings" commands that work one file at a time, and Crowdin's VS Code extension extracts a selected string to a key you type. Useful for touch-ups, slow for a whole app.
Babelize (our product). It scans a React, Next.js, Django or static HTML repo (Vue and React Native in beta), replaces hardcoded strings with translation calls (react-i18next, next-intl or Django gettext), writes the locale files, translates them into the languages you pick, and opens a pull request you review. It also runs locally as npx @babelize/cli translate. Here is how it works on a Next.js app.

Here is what that looks like on a React component. Before:

export function Welcome() {
  return <h1>Welcome back</h1>;
}

After the pull request, the component reads its text from translation files, and each language has its own file:

import { useTranslation } from "react-i18next";

export function Welcome() {
  const { t } = useTranslation();
  return <h1>{t("welcome.welcomeBack")}</h1>;
}

// locales/fr.json
{ "welcome": { "welcomeBack": "Bon retour" } }

In fairness, here is what Babelize does not do yet: it writes JSON and gettext .po files only (no XLIFF, YAML, ARB, iOS or Android string files), it has no marketplace of human translators and no in-context editor, and it does not push translation updates to mobile apps over the air. If those are what you need, a TMS above is the better fit, and the two can work together: Babelize internationalizes the code and produces the locale files, and a TMS can manage them from there.

A Worked Example: 500 Strings, 5 Languages

List prices are hard to compare because each tool counts differently. Take a typical small SaaS app: 500 UI strings averaging 5 words and 30 characters, so about 2,500 source words and 15,000 source characters, translated into 5 languages. Using each vendor's own counting rules:

Tool	How it counts	This app	Plan that fits
Crowdin	Hosted words × target languages	12,500 hosted words	Free (60K)
Tolgee	Hosted words	12,500	Free (30,000)
Locize	Words and languages	2,500 words, 5 languages	Starter, $7/mo
Weblate	Source strings × (languages + 1)	3,000 hosted strings	€47/mo hosted, or free self-hosted
Lokalise	Seats, projects, languages	1 project, 5 languages	Explorer, $149–169/mo
Phrase	Seats and managed words	within limits	$525/mo billed yearly
Babelize	Source characters × target languages	75,000 credits for the first full run	Growth, $29/mo, or Starter plus your own LLM key

Two things the table does not show. First, the TMS prices assume your strings are already in translation files; none of them does the work of getting them there. Second, Babelize's first run is the expensive one: it keeps a lockfile, so later runs only translate new or changed strings. If you change 50 strings in a month, that is about 7,500 credits, which fits the free plan. A TMS, by contrast, charges for the words it hosts every month.

So for this app, Crowdin or Tolgee is cheapest for managing translations, and Babelize is the only option here that also does the code work.

Still choosing the i18n library itself? The best i18n libraries for every framework in 2027 picks one per framework.

How to Choose

Strings still hardcoded: start with code instrumentation (i18next-cli for a free partial pass in React, or Babelize for the whole repo as a PR), then decide whether you need a TMS at all.
Volunteer or outside translators: Crowdin or Weblate.
Open source and self-hosted: Tolgee or Weblate.
Already on i18next, small budget: Locize.
AI translation in CI, files already extracted: Lingo.dev, or Babelize if you also want the extraction done.
A localization team with reviewers and vendors: Lokalise or Phrase.

Whichever you choose, the locale files are plain JSON or gettext in your repo, so you are not locked in. See JSON translation files explained for the format, translation memory explained for what a TMS adds, and the SaaS localization guide for the full process.

Frequently Asked Questions

What is the best Crowdin alternative for developers?

It depends on where your strings are. If they are already in translation files, Weblate and Tolgee are the closest open-source alternatives, and Lingo.dev if you want AI translation through pull requests. If your strings are still hardcoded in components, a TMS will not help yet: Babelize extracts them and opens a reviewable PR, and the Lingo.dev Compiler translates at build time but is still in alpha.

What is the best Lokalise alternative?

For a team that needs translator workflows, Phrase is the closest match and Crowdin the cheaper one, with a free plan. For a developer who mainly wants the app translated, Tolgee, Locize, Lingo.dev or Babelize cost far less: Lokalise starts at $149 a month billed yearly, while those start free.

Is there a free alternative to Lokalise?

Yes. Crowdin has a free plan with 60,000 hosted words and one private project, Tolgee's cloud is free up to 30,000 words and 3 seats, Locize is free for 2,000 words, and Weblate and Tolgee can be self-hosted for free. Lokalise itself only offers a 14-day trial.

What is the cheapest Crowdin alternative?

Among paid plans, Locize starts at $7 a month and Babelize at $9 a month ($7 billed yearly). Self-hosting Tolgee or Weblate costs only your server, if you are comfortable running it.

Do Lokalise or Crowdin find hardcoded strings in my code?

Not as a platform feature. Both manage translation files and keys that already exist. Lokalise's i18n Ally extension can extract strings experimentally, one file at a time, and Crowdin's VS Code extension extracts a selected string. To wrap strings across a whole repo, use a code instrumentation tool such as i18next-cli or Babelize.

Which localization tools are open source?

Tolgee (Apache-2.0 for its core) and Weblate (GPLv3+) are open source and self-hostable. Lokalise, Crowdin, Phrase and Locize are proprietary services.

Written with AI assistance and reviewed by the Babelize team. Prices were checked on each vendor's pricing page on October 16, 2026 (Lingo.dev on October 28) and are linked in the post.

Originally published on the Babelize blog. Disclosure: Babelize is our product. It is included in the comparison and marked as ours, along with what it does not do yet.

Translating Your SaaS into German: What Actually Changes

Mohit Sapat — Thu, 15 Oct 2026 13:00:21 +0000

TL;DR: Translating a SaaS into German changes more than the words: UI text runs about 30% longer and short labels often double or triple, you must choose formal Sie or informal du for every string, numbers and dates use German formats (1.299,00 €, 13.10.2026), and you need German legal pages (Impressum under the DDG, privacy policy, cookie consent), VAT-inclusive consumer prices, and payment methods such as SEPA Direct Debit and invoice.

Germany is usually the first non-English market a SaaS product goes after, and the translation is the easy part. Strings get longer, the product has to choose how formally it talks, numbers and dates flip their separators, and the legal and billing pages need more than a translator. This guide covers what actually changes, with measurements from real open-source apps.

German Text Is About 30% Longer, and Short Strings Grow the Most

"German is longer" is common knowledge. How much longer is worth measuring, because it decides how much room your buttons need. We compared the English and German UI strings of two widely used open-source apps, Excalidraw and Mastodon, character by character (placeholders and tags removed, untranslated strings skipped):

	Excalidraw	Mastodon
Translated strings compared	566	1,574
Total length, German vs English	+28%	+29%
Strings that got longer	81%	79%
Strings at least 1.5× as long	25%	30%
Short strings (1–10 characters): median growth	+27%	+50%
Short strings: 1 in 10 grows by at least	+88%	+183%

The averages are manageable. The tail is what breaks layouts, and it sits in the shortest strings: the labels on buttons, tabs, and menu items, where you have the least room. Some real pairs from those files:

Undo → Rückgängig machen (4.2×)
Unmute → Stummschaltung aufheben (3.8×)
Retry → Erneut versuchen (3.2×)
Edit → Bearbeiten (2.5×)
Move canvas → Zeichenfläche verschieben (2.3×)

What to do about it:

Never give text a fixed width. Let buttons and tabs grow, and decide in advance what happens when they cannot: wrap, truncate with a tooltip, or move into an overflow menu.
Budget for 3× on labels under 10 characters and about 1.5× on sentences, not a flat 30%.
Test before you translate. A pseudo-locale that pads every string by 40% shows where the layout breaks without waiting for a translator.
Turn on hyphenation for long compounds. German glues nouns together ("Zahlungsmethodenverwaltung"), and a single word can be wider than a narrow column.

/* Works only when the page declares its language: <html lang="de"> */
.card-title,
.table-header {
  hyphens: auto;
  overflow-wrap: break-word;
}

hyphens: auto uses the browser's German dictionary, so it only works when the document or element has lang="de". That is one more reason to set the lang attribute from the active locale instead of hardcoding en.

Du or Sie: Pick One Before You Translate Anything

German has two forms of "you": informal du and formal Sie. Every sentence that addresses the user commits to one, so the choice affects thousands of strings, and switching later means retranslating all of them.

Developer and consumer tools have moved toward du. In the German files we measured, Excalidraw uses informal forms (du, dein, dich) 60 times and formal Sie zero times; Mastodon uses informal forms 252 times against a handful of formal ones. Products that sell to banks, insurers, law firms, or the public sector usually stay with Sie, because that is how their customers write to each other.

Match how your customers talk to each other, not how your English copy sounds. Casual English does not automatically mean du.
Write the decision down in your style guide and glossary, and give it to every translator and every AI prompt.
Never mix the two. A product that says du on the dashboard and Sie in billing emails reads as two different companies. Search your German files for both forms before each release.

Numbers, Dates, and Currency Flip

German swaps the roles of the comma and the period, writes the currency symbol after the amount, and puts the day before the month. The browser already knows all of this, as long as you format values with Intl instead of string templates. Every output below was generated by Intl in Node.js:

new Intl.NumberFormat("de-DE").format(1234567.891);
// "1.234.567,891"   (en-US: "1,234,567.891")

new Intl.NumberFormat("de-DE", { style: "currency", currency: "EUR" }).format(1299);
// "1.299,00 €"

new Intl.NumberFormat("de-DE", { style: "percent", maximumFractionDigits: 1 }).format(0.195);
// "19,5 %"   (note the space before %)

const date = new Date("2026-10-13T14:05:00Z");
new Intl.DateTimeFormat("de-DE", { dateStyle: "medium", timeZone: "Europe/Berlin" }).format(date);
// "13.10.2026"

new Intl.ListFormat("de", { type: "conjunction" }).format(["Rechnung", "SEPA-Lastschrift", "PayPal"]);
// "Rechnung, SEPA-Lastschrift und PayPal"

"German" is also more than one locale. Switzerland and Austria format differently, so do not let de-DE stand in for every German speaker:

new Intl.NumberFormat("de-CH", { style: "currency", currency: "CHF" }).format(1299.5);
// "CHF 1'299.50"

new Intl.NumberFormat("de-AT", { style: "currency", currency: "EUR" }).format(1299.5);
// "€ 1.299,50"

Two more details: German uses the 24-hour clock in UI text, and the week starts on Monday, which matters for calendars, date pickers, and weekly reports. Our Intl API guide covers the formatting APIs in depth, and the locale codes guide explains when to use de versus de-DE, de-AT, or de-CH.

Typography That Translators Get Right and Code Gets Wrong

Quotation marks are „like this“ (low-high), not "like this". If your code wraps user content in quotes, the quotes belong in the translation string, not in the component.
Nouns are capitalized, so CSS text-transform: capitalize on English-style title case will mangle German. Let the translation decide capitalization.
Sentence fragments do not survive. "Delete" + " " + itemName works in English; German often needs the object before the verb. Translate whole sentences with placeholders, using ICU MessageFormat for counts.
Gender-inclusive language is a live style choice in German. Teams pick doubled forms ("Nutzerinnen und Nutzer"), neutral participles ("Nutzende"), or symbols ("Nutzer*innen"). Neutral forms are the least controversial and the easiest to keep short. As with du and Sie, pick one and apply it everywhere.

Legal Pages Are Not a Translation Task

Some German requirements have no English equivalent, so translating your existing legal pages will not cover them. The usual list for a SaaS product with German customers looks like this; have a German lawyer review it, because this is a summary, not legal advice:

Impressum (legal notice). Commercial websites aimed at Germany must name the operator, a postal address, and contact details. Since May 14, 2024 the legal basis is § 5 of the Digitale-Dienste-Gesetz (DDG), which replaced the Telemediengesetz. An Impressum that still cites "§ 5 TMG" is out of date.
Datenschutzerklärung (privacy policy) under the GDPR (DSGVO in German), in German, covering every tool that processes personal data.
Cookie consent under the TDDDG, the renamed TTDSG: non-essential cookies and trackers need consent before they load.
A data processing agreement (Auftragsverarbeitungsvertrag, AVV). German business customers will ask for one before signing, along with where your data is hosted. Have it ready instead of drafting it during a deal.

Pricing and Billing Change Too

Show the right price. Prices shown to consumers must include VAT, which is 19% for most digital services in Germany. Business-only pricing pages can show net prices, marked "zzgl. MwSt." (plus VAT).
Collect VAT IDs for business customers in other EU countries so you can invoice under the reverse-charge rules.
Offer the payment methods Germans use. German shoppers rely on PayPal, SEPA Direct Debit, and paying on invoice (Kauf auf Rechnung) much more than shoppers in most Western markets, and cards make up a comparatively small share of online purchases. For B2B SaaS, accepting SEPA Direct Debit and paying an invoice by bank transfer removes a common blocker.
Localize the invoice itself. A German customer's accountant expects German labels, the correct VAT breakdown, and dates and amounts in German format.

A Practical Order of Work

Internationalize first. Move every user-facing string into locale files and format every number and date with Intl. Translating hardcoded strings is wasted work; see i18n vs l10n for the difference.
Run a pseudo-locale with 40% padding and fix the layouts that break, especially buttons, tabs, and table headers.
Decide du or *Sie*, gender-inclusive style, and a glossary of product terms that stay in English.
Translate the UI, with a German speaker reviewing at least onboarding, billing, and error messages.
Handle legal and billing separately: Impressum, privacy policy, consent, AVV, VAT display, and payment methods.
Launch the German locale behind its own URL (/de/) with hreflang, so German searchers land on German pages.

If German is your first market after English, our guide to choosing your first SaaS languages covers how to sequence the next ones.

Frequently Asked Questions

How much longer is German text than English?

In the English and German UI strings of Excalidraw and Mastodon, German was 28 to 29% longer in total, about 80% of strings got longer, and a quarter to a third grew by 50% or more. Short labels grow the most: one in ten short Mastodon labels grew by 183% or more.

Should a SaaS product use du or Sie in German?

Developer and consumer tools increasingly use du, while products for conservative industries such as finance, insurance, law, and the public sector usually use Sie. Match how your customers write to each other, document the choice, and never mix the two forms in one product.

How do I format prices and dates for German users?

Use the Intl APIs with the de-DE locale instead of string templates. They produce 1.299,00 € for prices, 13.10.2026 for dates, and 19,5 % for percentages, and they handle Austrian (de-AT) and Swiss (de-CH) conventions too.

Does a SaaS website need an Impressum for Germany?

Commercial websites aimed at German users generally need one. Since May 14, 2024 the requirement is in § 5 of the Digitale-Dienste-Gesetz (DDG), which replaced § 5 of the Telemediengesetz (TMG). Have a German lawyer confirm what yours must contain.

Which payment methods should a SaaS offer in Germany?

Beyond cards, offer SEPA Direct Debit and payment by invoice or bank transfer, and consider PayPal for self-serve plans. German buyers use these methods far more than shoppers in most other Western markets.

Written with AI assistance and reviewed by the Babelize team. The length and du/Sie figures were measured on Excalidraw's and Mastodon's own translation files, and the format examples were generated with Node's Intl.

Originally published on the Babelize blog. Babelize is an AI localization tool for Next.js, React and Django apps: it marks strings, keeps your locale files in sync, and opens the changes as a pull request.

next-intl vs react-i18next: Which React i18n Library Should You Use?

Mohit Sapat — Tue, 13 Oct 2026 12:44:03 +0000

TL;DR: Use next-intl for Next.js App Router apps: it translates in Server Components, ships locale routing and middleware, and uses ICU MessageFormat out of the box. Use react-i18next (i18next) when you need React Native, other frameworks, or a shared Node.js backend, or already rely on the i18next plugin ecosystem.

If you're adding internationalization to a React or Next.js app, you will hit the same fork in the road almost immediately: next-intl or react-i18next? Both are mature, actively maintained, and used in production by thousands of teams. They just make very different assumptions about where your app runs and who renders your text.

The Short Answer

Use next-intl if your app is a Next.js App Router project. It was designed around Server Components, locale-aware routing, and ICU MessageFormat, so the common path needs very little glue code.

Use react-i18next if your app is not Next.js-only — a Vite SPA, React Native, Remix, an Electron app, or a monorepo that shares translations across web and mobile — or if your team already runs on i18next and its plugin ecosystem.

The rest of this guide explains why, with real setup code for both, a feature-by-feature comparison, the pitfalls that catch teams in production, and what a migration looks like.

At a Glance (October 2026)

Current releases and npm downloads, pulled from the npm registry on October 13, 2026. Download counts include installs pulled in by other packages, so read them as a measure of reach, not of how many apps use each library directly.

	next-intl	react-i18next + i18next
Latest version	4.14.9	react-i18next 17.0.16 · i18next 26.4.4
Weekly npm downloads	~7.1M	~17.9M (react-i18next) · ~24.1M (i18next)
Runs on	Next.js 12–16 only	Any React 16.8+ app, React Native, Node.js
Message format	ICU MessageFormat	i18next JSON (ICU via `i18next-icu`)
Server Components	Built in (`getTranslations`)	Per-request i18next instance; hooks are client-only
Locale routing	Built in (`defineRouting`, `proxy.ts`)	Bring your own

What Are next-intl and react-i18next?

react-i18next

react-i18next is the official React binding for i18next, a framework-agnostic internationalization core that has been around for over a decade. i18next itself knows nothing about React; react-i18next adds hooks (useTranslation), a Trans component for rich text, and a provider. Around that core sits a large ecosystem: language detectors, HTTP and filesystem backends, caching layers, an ICU plugin, and integrations with most translation management systems.

Because the core is framework-agnostic, the same i18next configuration and the same translation files can power a React web app, a React Native app, and a Node.js backend that sends localized emails.

next-intl

next-intl is built specifically for Next.js. It supports both the Pages Router and the App Router, but its design centers on the App Router: translations work in async Server Components, Client Components, Server Actions, metadata, and route handlers, and it ships its own locale-aware routing, middleware, and navigation helpers. Messages use ICU MessageFormat out of the box, so plurals, selects, and number and date formatting live inside the translation string.

Feature Comparison

Feature	next-intl	react-i18next
Framework scope	Next.js only	Any React renderer (web, React Native, Electron)
App Router & Server Components	First-class: `getTranslations` and `useTranslations` in server code	Works, but hooks are client-only; server code needs a per-request i18next instance
Pages Router	Supported	Supported (commonly via next-i18next)
Message syntax	ICU MessageFormat, built in	i18next JSON format; ICU via the i18next-icu plugin
Plurals	`{count, plural, one {…} other {…}}`	Suffixed keys: `key_one`, `key_other`
Routing & middleware	Built in: `defineRouting`, middleware, `createNavigation`	Not included; you write your own
Type safety	Module augmentation of `AppConfig`	Module augmentation of `CustomTypeOptions`
Namespaces & lazy loading	Nested message objects; load what you need in `request.ts`	Namespaces are a core concept; lazy loading via backends
Language detection	Middleware: URL prefix, cookie, `Accept-Language`	i18next-browser-languagedetector or custom detector
Plugin ecosystem	Small and focused	Extensive
Learning curve	Gentle for Next.js developers	Moderate: more configuration options and concepts

Setting Up next-intl in the App Router

A current next-intl (v4) App Router setup is split into a few small files. First, a single routing definition that the middleware and navigation helpers share:

// src/i18n/routing.ts
import { defineRouting } from "next-intl/routing";

export const routing = defineRouting({
    locales: ["en", "fr", "de"],
    defaultLocale: "en",
});

The middleware negotiates the locale and redirects or rewrites requests to the right prefix. (In Next.js 16 the middleware.ts convention was renamed to proxy.ts; the content is the same.)

// src/proxy.ts  (src/middleware.ts on Next.js 15 and earlier)
import createMiddleware from "next-intl/middleware";
import { routing } from "./i18n/routing";

export default createMiddleware(routing);

export const config = {
    matcher: "/((?!api|_next|_vercel|.*\\..*).*)",
};

Request configuration tells next-intl which messages to load for the current request:

// src/i18n/request.ts
import { getRequestConfig } from "next-intl/server";
import { hasLocale } from "next-intl";
import { routing } from "./routing";

export default getRequestConfig(async ({ requestLocale }) => {
    const requested = await requestLocale;
    const locale = hasLocale(routing.locales, requested) ? requested : routing.defaultLocale;

    return {
        locale,
        messages: (await import(`../../messages/${locale}.json`)).default,
    };
});

Then the [locale] layout wraps the tree in NextIntlClientProvider so Client Components can read messages, and calls setRequestLocale so pages can be statically rendered:

// src/app/[locale]/layout.tsx
import { NextIntlClientProvider, hasLocale } from "next-intl";
import { setRequestLocale } from "next-intl/server";
import { notFound } from "next/navigation";
import { routing } from "@/i18n/routing";

export function generateStaticParams() {
    return routing.locales.map((locale) => ({ locale }));
}

export default async function LocaleLayout({ children, params }) {
    const { locale } = await params;
    if (!hasLocale(routing.locales, locale)) notFound();
    setRequestLocale(locale);

    return (
        <html lang={locale}>
            <body>
                <NextIntlClientProvider>{children}</NextIntlClientProvider>
            </body>
        </html>
    );
}

Using translations looks the same everywhere. In an async Server Component you await getTranslations(); in a regular component — server or client — you call useTranslations():

// Server Component
import { getTranslations } from "next-intl/server";

export default async function Pricing() {
    const t = await getTranslations("Pricing");
    return <h1>{t("title")}</h1>;
}

// Client Component
"use client";
import { useTranslations } from "next-intl";

export function SeatCounter({ count }: { count: number }) {
    const t = useTranslations("Pricing");
    return <p>{t("seats", { count })}</p>;
}

Finally, createNavigation(routing) gives you locale-aware Link, redirect, usePathname, and useRouter wrappers, so you never hand-build /fr/pricing URLs. For the full walkthrough from an empty project, see our step-by-step guide to i18n in Next.js with next-intl.

Setting Up react-i18next in the App Router

react-i18next was designed before Server Components existed, and its hooks rely on React context, which only exists in Client Components. In the App Router that leaves two layers to configure.

Server side: the common pattern is to create a fresh i18next instance per request, so concurrent requests in different languages never share state. i18next-resources-to-backend lets you lazy-load JSON files per language and namespace with dynamic imports:

// src/i18n/server.ts
import { createInstance } from "i18next";
import resourcesToBackend from "i18next-resources-to-backend";
import { initReactI18next } from "react-i18next/initReactI18next";

export async function getT(locale: string, ns = "common") {
    const i18n = createInstance();
    await i18n
        .use(initReactI18next)
        .use(resourcesToBackend((lng: string, ns: string) =>
            import(`../locales/${lng}/${ns}.json`)))
        .init({ lng: locale, ns: [ns], defaultNS: ns, fallbackLng: "en" });

    return i18n.getFixedT(locale, ns);
}

// In a Server Component
const t = await getT(locale, "pricing");
return <h1>{t("title")}</h1>;

Client side: a separate, long-lived i18next instance initialized in a client module, with useTranslation() in Client Components. You keep the client instance's language in sync with the locale segment of the URL, often by passing it down from the layout.

You also write locale routing yourself: a middleware that reads the cookie or Accept-Language header, redirects to a locale prefix, and a [lng] segment in your app directory. None of this is hard, but it is code you own and maintain. (If you are on the Pages Router, next-i18next wraps most of this for you; it does not target the App Router.)

Message Syntax: ICU vs i18next JSON

This is the difference that matters most to translators, and it is easy to overlook. next-intl uses ICU MessageFormat:

{
    "Pricing": {
        "seats": "{count, plural, =0 {No seats} one {# seat} other {# seats}}"
    }
}

i18next uses its own JSON format, where interpolation uses double braces and plurals are separate keys with CLDR category suffixes:

{
    "seats_zero": "No seats",
    "seats_one": "{{count}} seat",
    "seats_other": "{{count}} seats"
}

Both handle languages with complex plural rules correctly, because both resolve the category with Intl.PluralRules. The i18next format is easier to read for simple strings; ICU keeps the whole sentence in one key, which translators and translation platforms generally handle better for gender and nested selects. If you want ICU with i18next, add the i18next-icu plugin — but then you are using the ICU format, not the i18next one, so pick one per project. Our ICU MessageFormat guide covers plural and select syntax in depth.

Type Safety

Both libraries can type-check your translation keys, and both do it the same way: TypeScript module augmentation pointing at your source-language JSON file. Neither generates code.

// next-intl: global.d.ts
import { routing } from "@/i18n/routing";
import messages from "./messages/en.json";

declare module "next-intl" {
    interface AppConfig {
        Locale: (typeof routing.locales)[number];
        Messages: typeof messages;
    }
}

// react-i18next: i18next.d.ts
import common from "./locales/en/common.json";

declare module "i18next" {
    interface CustomTypeOptions {
        defaultNS: "common";
        resources: { common: typeof common };
    }
}

With either setup, a typo like t("pricng.title") becomes a compile error. next-intl can additionally type ICU arguments in recent versions, so a missing count is caught as well.

Bundle Size and Performance

Avoid picking either library based on a headline bundle number; what dominates in practice is how many messages you ship to the browser, not the size of the runtime.

With next-intl, text rendered in Server Components is resolved on the server and arrives as HTML. The message catalog itself does not need to be sent at all for those components. For Client Components, NextIntlClientProvider passes messages down; on large apps you can pass only the namespaces a subtree needs (for example with pick(messages, ["Pricing"])) instead of the entire file.

With react-i18next, server-rendered text works the same way when you use a per-request instance. Client Components need the resources loaded into the client instance, and the ecosystem's answer is namespaces plus a backend (HTTP or dynamic import) that loads pricing.json only when a component asks for the pricing namespace.

Both approaches can produce lean pages. next-intl makes the lean path the default in the App Router; react-i18next makes it a configuration choice.

Where translation runs: next-intl resolves text per request on the server; react-i18next uses a per-request server instance plus a client instance.

Which One Should You Choose?

Choose next-intl if:

The app is Next.js, and you have no plans to share translations with a non-Next.js client
You use the App Router and want translations in Server Components without extra glue
You want locale routing, middleware, and localized navigation handled for you
You prefer ICU MessageFormat, or your translation vendor expects it

Choose react-i18next if:

You ship React Native, Electron, Vite, or Remix apps alongside (or instead of) Next.js
You want one translation setup shared by the frontend and a Node.js backend
Your team already uses i18next and its file format, detectors, or backends
You need a specific plugin, such as a CMS or translation-platform backend that loads strings at runtime

A useful tiebreaker: whoever owns the most code that renders text wins. If 90% of your UI lives in a Next.js app, use next-intl there even if a small React Native app uses i18next — sharing raw JSON between two formats is easier than fighting the wrong library in your main app.

Decision guide: next-intl for Next.js App Router apps, react-i18next for cross-platform setups or existing i18next teams.

Migrating from react-i18next to next-intl

Teams moving an existing Next.js app to the App Router often make this switch. The work splits into three parts:

Convert the message files. Merge namespaces into nested objects (or keep one file per namespace and merge them in request.ts), turn {{name}} into {name}, and collapse key_one/key_other pairs into a single ICU plural. Script this; do not do it by hand.
Replace the calls. useTranslation("pricing") becomes useTranslations("Pricing"), and <Trans> becomes t.rich() with tag callbacks.
Delete your routing glue. Custom locale middleware and link helpers get replaced by defineRouting, createMiddleware, and createNavigation. Keep your existing URL structure so you do not lose rankings; see our hreflang and multilingual SEO guide before changing locale prefixes.

Migrate route by route behind a feature branch, and run a pseudo-locale through the converted pages to catch any string that slipped through untranslated.

Common Pitfalls

Calling useTranslation() in a Server Component. With react-i18next, hooks need a Client Component. Use a per-request instance on the server instead of adding "use client" everywhere.
Sharing one global i18next instance on the server. Changing its language for one request can leak into another concurrent request. Create an instance per request.
Forgetting setRequestLocale with next-intl. Without it, pages that use translations opt into dynamic rendering, and you lose static generation.
Passing the whole catalog to the client. Wrapping the root in a provider with every message for every feature is convenient, but it ships text the page never shows.
Mixing message formats. ICU strings in an i18next project without the ICU plugin render literally, braces and all.
Inconsistent locale codes. en_US in file names, en-US in the URL, en in the HTML lang attribute. Pick BCP 47 tags once; our locale codes guide explains the rules.
Hand-formatting numbers and dates. Both libraries expose locale-aware formatting; pass raw values, never toFixed(2) strings.

FAQ

What is the difference between next-intl and react-i18next?

next-intl is built specifically for Next.js, with first-class App Router and Server Component support, built-in locale routing, and ICU MessageFormat. react-i18next is the React binding for i18next, a framework-agnostic library that also runs in React Native, Vite, Remix, and Node.js, with a large plugin ecosystem.

Which library works best with the Next.js App Router?

next-intl. Its getTranslations and useTranslations APIs work in Server Components, and it provides routing, middleware, and navigation helpers. react-i18next works in the App Router too, but its hooks are client-only, so server rendering requires creating an i18next instance per request.

Can I use react-i18next with React Native?

Yes. react-i18next supports React Native, which makes it a strong choice for projects that share translations between web and mobile. next-intl only targets Next.js, so a React Native app would need a different library.

Does next-intl support ICU MessageFormat?

Yes. next-intl uses ICU MessageFormat natively for plurals, selects, and number and date formatting. i18next uses its own JSON format with suffixed plural keys such as key_one and key_other, and supports ICU only through the i18next-icu plugin.

Is next-intl or react-i18next faster?

Neither runtime is a meaningful bottleneck. What matters is how many messages reach the browser. next-intl renders Server Component text on the server by default, while react-i18next achieves similar results with per-request server instances and lazily loaded namespaces on the client.

The Short Version

next-intl is the specialist: if your product is a Next.js App Router app, it gives you Server Component translations, routing, and ICU with the least code. react-i18next is the generalist: if your translations need to work across React Native, other frameworks, or a backend, its framework-agnostic core and ecosystem are hard to beat. Pick based on where most of your text renders, keep your message files in one format, and type your keys either way. If you are still deciding how to structure those files, start with our explanation of JSON translation files.

Whichever library you choose, the translation files still have to stay in sync as your source strings change. Babelize detects new and changed keys and generates translations for every locale in your repository, with guides for both the Next.js and React SDKs.

Written with AI assistance and reviewed by the Babelize team.