Forem: Adriano Raiano

i18next in Production: Managing Translations at Scale

Adriano Raiano — Mon, 13 Apr 2026 06:19:34 +0000

i18next scales from a weekend project to a production app with millions of users — but the way you manage translations needs to evolve as your project grows. At prototype scale, a locales/en/translation.json file in your repo is all you need. At production scale — 10 languages, multiple teams, thousands of keys — manual file management becomes the bottleneck, not i18next itself.

This post covers the practical problems that appear when managing translations at scale, and the i18next ecosystem patterns that solve them.

Problem 1: Translation files in the repo become a bottleneck

At prototype scale, translation JSON files live in your repo. A developer adds a key, translates it, commits, done. At production scale, this becomes a problem:

Merge conflicts. Two developers add keys to the same namespace. Every PR that touches translations conflicts with every other one.
Translators need repo access. Your German translator shouldn't need to know how to create a Git branch.
Translations block deploys. A feature is done but the French translations aren't ready. Do you ship with missing translations or wait?

Pattern: Decouple translation delivery from code delivery

Instead of bundling translations in your build, load them at runtime from a CDN:

import i18next from 'i18next'
import Backend from 'i18next-http-backend'

i18next.use(Backend).init({
  fallbackLng: 'en',
  backend: {
    loadPath: 'https://cdn.example.com/locales/{{lng}}/{{ns}}.json'
  }
})

With this pattern, translations update independently of your app. Fix a typo, add a language, adjust tone — all without touching code.

The i18next-locize-backend takes this further: translations are served from a managed global CDN with built-in cache invalidation and versioning. No CDN configuration needed on your side.

import Backend from 'i18next-locize-backend'

i18next.use(Backend).init({
  fallbackLng: 'en',
  backend: {
    projectId: 'your-project-id'
  }
})

Problem 2: Nobody knows which keys are missing

At prototype scale, one developer manages all the keys. At production scale, different teams own different namespaces, and nobody has a complete picture of what's translated and what's not.

Common symptoms:

Users see untranslated keys in production (the checkout.confirmButton incident)
A new feature ships with 12 languages but only 8 have translations
Nobody knows that the emails namespace hasn't been touched in 3 months

Pattern: saveMissing + coverage tracking

i18next's saveMissing feature detects untranslated keys at runtime and reports them:

i18next.init({
  saveMissing: true,
  backend: {
    projectId: 'your-project-id',
    apiKey: 'your-api-key' // dev only
  }
})

When a missing key is encountered, it's automatically sent to your translation management system. No manual extraction step, no "did someone add this key?" questions.

With Locize, missing keys appear in the dashboard immediately. Combined with automatic translation, new keys can be translated into all target languages without any manual intervention — using your configured AI or MT provider with styleguide and glossary context.

For build-time key extraction (SSG, SSR, or when saveMissing isn't suitable for your runtime), the i18next-cli scans your source code and extracts all t() calls.

Problem 3: Translation quality drifts over time

At prototype scale, one person writes all translations and they're internally consistent. At production scale, different people translate different parts at different times. "Cancel" becomes "Dismiss" in one dialog and "Abort" in another. Your brand's name for a feature is translated three different ways.

Pattern: Glossary + Translation Memory + Styleguide

These three features work together to maintain consistency:

Glossary: Define approved and forbidden terminology. "Drive" means cloud storage, not driving. "Workspace" is always "Espace de travail" in French, never "Zone de travail."
Translation Memory: When a translator works on a new key, they see how similar strings were translated before. Fuzzy matching surfaces past translations with character-level diffs.
Styleguide: Define tone, formality level, target audience, and usage rules once. Applied automatically to all AI translation providers.

In Locize, all three are injected into AI translation prompts automatically — so even AI-generated first drafts are consistent with your established terminology and brand voice.

Problem 4: No review process for translations

At prototype scale, translations go straight to production. At production scale, a wrong translation in a legal disclaimer or a payment screen is a business problem.

Pattern: Review workflow

Enable per-language review so changes go through approval before going live:

A translator (or AI) creates or modifies a translation
The change is marked as "pending review"
A reviewer accepts or rejects the change
Only accepted translations are promoted to production quality

In Locize, the review workflow is configurable per language. Enable it for customer-facing languages (German, French, Japanese) while keeping it off for internal/developer languages where speed matters more than perfection.

Problem 5: No way to test translations before releasing

At prototype scale, "testing" means refreshing the page. At production scale, you need to verify translations in a staging environment without affecting production users.

Pattern: Branches and versions

Translation branches work like code branches:

Create a translation branch when you create a feature branch
Translate new strings in isolation
Test in staging against the branch translations
Merge the translation branch when the feature ships

In Locize, branches mirror your Git workflow. Each branch has its own CDN endpoint, so your staging environment can point to the branch translations while production serves from the main version.

Problem 6: SaaS customers need different translations

If you build a SaaS product, your customers may need to customize translations — different terminology, different tone, different branding. Managing a separate translation project per customer doesn't scale.

Pattern: Multi-tenant overrides

Locize supports multi-tenant localization: a parent project holds base translations, and each tenant gets a child project that inherits everything but can override specific keys. Each tenant has its own CDN endpoint.

This means:

Base translations are maintained once
Each customer can customize only the strings they care about
Overrides are served efficiently — only the diff, not the full translation set
Tenant users have isolated access — they can't see other tenants or the parent

Problem 7: Translation updates require a deploy

This is the most common friction point at scale. A translator fixes a typo. The fix sits in the TMS waiting for a developer to download the file, commit it, open a PR, get it reviewed, merge it, and deploy. Days pass. The typo is live in production the whole time.

Pattern: CDN delivery with instant publish

When translations are served from a CDN instead of bundled in your build, updates go live without deploying:

Translator fixes the typo in the editor
Clicks "Publish" (or auto-publish is enabled)
CDN cache is invalidated
Next time a user loads the app, they get the fixed translation

In Locize, publishing takes seconds. For the standard CDN, translations propagate globally within minutes. No code change, no build, no deploy, no PR.

The complete production setup

Here's what a production-grade i18next setup with Locize looks like:

Development:
  saveMissing: true → keys auto-appear in Locize
  Auto-translate → AI generates first drafts

Staging:
  Translation branch → isolated from production
  Review workflow → translators verify AI output

Production:
  CDN delivery → translations update without deploy
  Glossary + TM → consistency across 50K keys
  Multi-tenant → per-customer overrides
  MCP server → AI agents manage translations

Each piece is optional — you can adopt them incrementally as your project grows. Start with CDN delivery and saveMissing. Add review workflows when quality matters. Add branches when you have staging environments. Add multi-tenancy when your customers need it.

Getting started

If you're running i18next in production with local JSON files and want to move to a managed workflow:

Register for free — no credit card required
Migrate your project — the CLI imports your existing JSON files
Switch to i18next-locize-backend — one config change, same API
Enable saveMissing — new keys auto-appear in Locize
Enable auto-translate — AI translates new keys automatically

The entire migration takes less than an hour for most projects.

next-intl vs next-i18next: Choosing the Right i18n Library for Next.js

Adriano Raiano — Fri, 10 Apr 2026 05:44:13 +0000

Next.js developers choosing an i18n solution will likely narrow it down to two libraries: next-intl and next-i18next. Both support the App Router and Server Components. Both are actively maintained. But they take fundamentally different architectural approaches.

This post compares them on the things that matter for a real project: how translations are loaded, how they integrate with your stack, and what workflows they enable.

Architecture at a glance

	next-intl	next-i18next
Core	Standalone library (built on `intl-messageformat`)	Built on i18next — the most widely used JavaScript i18n framework — with react-i18next
Message format	ICU MessageFormat	i18next JSON format (the most common format in the JS ecosystem)
App Router	Supported	Supported via `getT()` / `useT()`
Pages Router	Limited/legacy	Full support via `next-i18next/pages`
Server Components	Supported	Supported
Translation loading	Custom async loader function (you build it)	Backend plugin ecosystem (drop-in packages for CDN, filesystem, Locize, chained caching)
Bundle size	Minimal runtime via ICU precompilation	Flexible — tree-shakeable, scales with features used
Type safety	Build-time catalog extraction	Full TypeScript support with selector API

How translations are loaded

This is the most important architectural difference.

next-intl: custom loader function

next-intl uses a request-scoped configuration function (i18n/request.ts) where you define how to load messages:

// i18n/request.ts
import { getRequestConfig } from 'next-intl/server'

export default getRequestConfig(async ({ locale }) => ({
  messages: (await import(`../../messages/${locale}.json`)).default
}))

You can load from local files, a CDN, a CMS, or any async source. There is no plugin system — you write the loader yourself. This is flexible but means every integration is custom code.

next-i18next: backend plugin ecosystem

next-i18next inherits the full i18next backend plugin ecosystem:

import i18next from 'i18next'
import Backend from 'i18next-locize-backend'

i18next.use(Backend).init({
  backend: {
    projectId: 'YOUR_PROJECT_ID'
  }
})

Available backends include:

i18next-http-backend — load from any HTTP/CDN endpoint
i18next-locize-backend — direct Locize CDN integration with saveMissing
i18next-fs-backend — load from filesystem (Node.js)
i18next-chained-backend — chain multiple backends (e.g., localStorage cache + remote)

This plugin architecture means integrations with TMS platforms, CDNs, and caching layers are available as drop-in packages rather than custom code.

Message format

next-intl: ICU MessageFormat

{
  "greeting": "Hello, {name}!",
  "items": "You have {count, plural, one {# item} other {# items}} in your cart."
}

ICU MessageFormat is an industry standard supported by many TMS platforms. next-intl includes a precompilation step (icu-minify) that reduces the runtime to under 1KB.

next-i18next: i18next format

{
  "greeting": "Hello, {{name}}!",
  "items_one": "You have {{count}} item in your cart.",
  "items_other": "You have {{count}} items in your cart."
}

i18next uses its own JSON format with {{interpolation}} syntax and key-based pluralization (suffix _one, _other, _few, etc.). This format is natively understood by Locize and other i18next-compatible tools. It is also widely adopted — i18next is the most downloaded i18n library in the JavaScript ecosystem.

Both formats handle plurals, interpolation, and nesting. The choice is largely about ecosystem compatibility.

saveMissing: automatic key discovery

next-i18next supports i18next's saveMissing feature. When your app encounters a translation key that doesn't exist yet, it can automatically report it to your TMS:

i18next.init({
  saveMissing: true,
  backend: {
    projectId: 'YOUR_PROJECT_ID',
    apiKey: 'YOUR_API_KEY'
  }
})

With the Locize backend, missing keys are batched and sent automatically. Combined with automatic translation, this creates a fully automated pipeline: write code → keys appear in Locize → AI translates → live on CDN.

next-intl does not support saveMissing. Key management is manual — you add keys to your JSON files or TMS yourself.

Translation management integration

next-i18next integrates directly with Locize via the dedicated i18next-locize-backend plugin. This provides:

CDN delivery at runtime (translations update without redeploy)
saveMissing (automatic key discovery)
InContext editor (translate on your running app)
Branches (translation CI/CD)
Multi-tenancy (per-tenant overrides)

The Locize backend is maintained by the same team that wrote i18next and next-i18next.

next-intl does not have a dedicated TMS plugin. You can integrate with any TMS by writing a custom loader in i18n/request.ts, but the integration is your responsibility. next-intl's documentation mentions Crowdin as a compatible TMS.

Routing and middleware

Both libraries handle locale routing via Next.js middleware:

next-intl uses createNavigation() and next-intl/middleware:

URL-based routing with dynamic [locale] segments
Domain-based routing supported
Built-in locale detection (URL, cookies, Accept-Language)

next-i18next (v16+) uses createProxy() (Next.js 16+) or createMiddleware():

Cookie-based locale detection
Mixed Router support (App Router + Pages Router coexisting)
basePath scoping for multi-router setups

Both approaches work well. The routing mechanism is rarely the deciding factor.

When to choose next-intl

You prefer ICU MessageFormat and want it built into the framework
You want a standalone, self-contained library with no external dependencies
You prefer to write custom loader functions for translation sources
You are building a Next.js-only project with no need to share i18n setup across other platforms

When to choose next-i18next

You want access to the largest i18n plugin ecosystem — drop-in backends for CDN, filesystem, caching, and managed services
You want saveMissing — automatic key discovery from your running app, no manual extraction needed
You want CDN delivery — translations that update without redeploying your app
You want a managed translation backend with AI translation, review workflows, and a translator UI via Locize
You need branches and multi-tenancy for complex localization workflows
You want to share the same i18n setup across React, Vue, Node.js, React Native, or other platforms in your stack
You want the proven maturity of i18next — 15+ years, most downloaded i18n library in JavaScript

Summary

Both next-intl and next-i18next are production-ready libraries for Next.js internationalization. The choice comes down to what you need beyond basic translation:

next-intl is a self-contained solution with ICU message format. Good for Next.js-only projects where you want to manage everything yourself.
next-i18next connects you to the i18next ecosystem — the most widely adopted i18n infrastructure in JavaScript. Backend plugins, saveMissing, CDN delivery, AI-powered translation, and a managed backend via Locize are all available as drop-in additions, not custom code you write and maintain.

For teams that want their translations to work across multiple platforms, update without redeploying, and scale with managed infrastructure — next-i18next with Locize is the most complete setup available.

How to Set Up Automatic Translation with i18next and Locize

Adriano Raiano — Thu, 09 Apr 2026 06:57:38 +0000

Most i18next setups require manual steps to manage translations: extract keys, send them for translation, download the results, commit the files, deploy. Each step is a context switch, and the longer the cycle, the more likely translations lag behind your code.

This guide shows how to eliminate all of those manual steps using i18next's saveMissing feature and Locize's automatic translation workflow. The result: you write code, and translations appear — in all your target languages, live on the CDN, without a deploy.

What the automated workflow looks like

Developer writes t('checkout.title', 'Complete your order')
     ↓
i18next detects the key is missing
     ↓
saveMissing sends it to Locize automatically
     ↓
Locize auto-translates into all target languages
(using your configured AI/MT provider + styleguide + glossary)
     ↓
Translations publish to CDN
     ↓
Your app fetches the updated translations at next load

No files to commit. No deploy to trigger. No translator to email (unless you want human review).

Step 1: Set up i18next with Locize backend

Install the packages:

npm install i18next i18next-locize-backend

For React, also add react-i18next. For Next.js, add next-i18next. The backend plugin works with any i18next setup.

Configure i18next with the Locize backend and saveMissing enabled:

import i18next from 'i18next'
import Backend from 'i18next-locize-backend'

i18next
  .use(Backend)
  .init({
    fallbackLng: 'en',
    saveMissing: true,
    backend: {
      projectId: 'YOUR_PROJECT_ID',
      apiKey: 'YOUR_API_KEY' // needed for saveMissing — remove in production
    }
  })

Important: saveMissing should only run in development. In production, remove the apiKey and set saveMissing: false. See the going to production guide for details.

The allowedAddOrUpdateHosts option defaults to ['localhost'], so saveMissing only fires on localhost even if you forget to disable it.

Step 2: Enable automatic translation in Locize

In your Locize project:

Go to Project Settings > EDITOR, TM/MT/AI, ORDERING
Enable Automatic Translation Workflow

Choose which translation provider to use:

Locize AI — built-in, works on all paid plans, no external API key needed. Token-based billing.
Locize MT — built-in machine translation, character-based billing.
BYOK (Bring Your Own Key) — use your own OpenAI, Gemini, Mistral, or DeepL key. Available on Professional ($99/mo) and above. No markup — you pay the provider directly.

All providers (where possible) automatically receive context from your project's styleguide, glossary, and translation memory. This is what makes Locize's automatic translations better than raw API calls — the AI knows your brand voice, approved terminology, and past translations.

Step 3: Write code — translations happen automatically

Use translation keys in your components:

import { useTranslation } from 'react-i18next'

function Checkout() {
  const { t } = useTranslation()
  return (
    <div>
      <h1>{t('checkout.title', 'Complete your order')}</h1>
      <p>{t('checkout.subtitle', 'Review your items before payment')}</p>
      <button>{t('checkout.pay', 'Pay now')}</button>
    </div>
  )
}

When your app runs in development:

i18next encounters checkout.title for the first time
saveMissing batches the key (5-second debounce) and sends it to Locize
Locize receives the key with its default value ("Complete your order")
Automatic translation kicks in — the key is translated into all target languages
Translations appear on the Locize CDN

Next time the app loads, i18next fetches the translations from the CDN, including all the auto-generated translations.

Step 4: Improve translation quality with context

Automatic translation works better with context. There are several ways to provide it:

Styleguide

Define your brand voice once in Project Settings > Styleguide:

Tone of voice (formal, casual, technical)
Target audience
Do's and don'ts
Per-language overrides

The styleguide is automatically injected into every AI translation prompt.

Glossary

Add approved terminology in Project Settings > Glossary. Terms can be marked as approved or forbidden, with target-language equivalents. The glossary is injected into AI prompts as "use these exact translations."

Key-level context

When using saveMissing, you can include context descriptions:

// In your i18next config:
i18next.t(key, defaultValue, tDescription);
i18next.t(key, { defaultValue, tDescription });

Or add context directly in the Locize editor for each key. This context appears in the AI prompt and is shown to human translators.

Step 5: Optional — add human review

For content where AI quality is sufficient (internal tools, developer-facing UI, technical docs), you can skip review entirely.

For brand-critical content, AI or MT translations are marked as "fuzzy" (quality: AI or MT). A translator reviews them in the Locize editor and accepts or modifies them. Only accepted translations are promoted to "human translated" quality.

Step 6: Deploy translations without redeploying

Translations served via the Locize CDN update independently of your app deployment:

Auto-publish (if enabled for your version): translations go live on the CDN as soon as they're saved
Manual publish: click "Publish" in the Locize UI, or call locize publish-version from the CLI or a GitHub Action

Your app fetches translations from the CDN on each load. A copy fix, a new language, or a tone adjustment — all live without touching your codebase.

The AI agent workflow (bonus)

If you use an AI coding assistant (Claude, Cursor, VS Code), the Locize MCP server lets your assistant manage translations directly:

"Report these new keys to Locize" — the AI-agent equivalent of saveMissing. New keys on the reference language trigger automatic translation when enabled.
"What's the translation coverage for my project?" — check if all languages are ready before publishing.
"Publish the latest version" — push translations to CDN from your AI assistant.

The MCP server exposes 22 tools covering the full translation lifecycle.

Summary

Step	What happens	Manual effort
Write code with `t('key')`	i18next detects missing key	None
saveMissing sends key to Locize	Key appears in project	None
Automatic translation	AI/MT translates all languages	None
Human review (optional)	Translator reviews in editor	Optional
CDN delivery	Translations go live	None (auto-publish) or one click

The entire pipeline from code to live translations can be fully automatic. The only manual step is human review — and that is optional.

Why We Added a Console Notice to i18next — and Why We Removed It

Adriano Raiano — Sat, 28 Mar 2026 08:00:45 +0000

i18next turns 15 this year. It has almost 15 million weekly npm downloads,
powers applications in every industry across the world, and is maintained
by a small core team — the same people who founded Locize.

This is the story of a decision we made, what it cost, and why we reversed it.

The sustainability problem nobody talks about

Open source maintainers are expected to deliver production-grade software,
respond to issues, fix security vulnerabilities, and keep pace with a
fast-moving ecosystem — for free.

We've tried the standard approaches:

GitHub Sponsors — the numbers were honest and we're grateful for every contributor, but they never came nearly close to funding even a minimal part of a single full-time engineer.
README badges and funding links — almost no one reads them.
NPM funding metadata — same story.

The reality is that i18next exists today because of Locize — our own
managed localization product, built by the i18next core team to fund the
library's continued development. Every security fix, every new feature,
every improvement is made possible because Locize pays for the
time to build it.

The problem: most i18next users don't know this. They use the library,
file issues, request features, and have no idea how it stays maintained.
We're not complaining — that's the nature of open source. But it does
create a real tension.

What we decided to do

In v25.8.0, we introduced a single console.info line that appeared
when i18next initialized:

🌐 i18next is made possible by our own product, Locize — consider powering your project with managed localization (AI, CDN, integrations): https://locize.com 💙

The reasoning was straightforward. console.info is a developer-facing
channel. It doesn't affect your end users, it doesn't break builds, it
doesn't affect performance. And it reaches the one audience we actually
wanted to reach: the developers who choose which tools their teams use.

We provided an opt-out via showSupportNotice: false, and
later added a globalThis kill-switch for PaaS and third-party dependency
scenarios, and an I18NEXT_NO_SUPPORT_NOTICE (and later also a NODE_ENV=production) environment variable for
CI/CD pipelines.

What happened next

The developer community responded — loudly, and with legitimate concerns.

The loudest complaints were about developer experience: the notice
appearing multiple times in Next.js builds, flooding test logs, appearing
inside design systems that consumers couldn't configure. We addressed most
of these iteratively: improving the deduplication logic, adding the
globalThis kill-switch, documenting the suppression options properly.

But the complaint that made us think hardest came from a PaaS provider
who filed a detailed incident report. Their claim: the console notice may
have caused Google Safe Browsing to block hundreds of customer sites.

We investigated carefully. Our honest technical assessment is that
console.info output is not evaluated by Google Safe Browsing — GSB scans
DOM content, not console output, and a link to locize.com in the console
would have to affect our own platform and thousands of direct users if that
were the mechanism. We still believe the actual cause was unrelated to
the notice.

But here's what we couldn't dismiss: the reporter had a real production
incident, affecting real customers, and the only change they made — adding
the globalThis kill-switch at the infrastructure level via a Cloudflare
worker — correlated with the block being lifted. We can argue about
causation. We cannot argue about the operational burden that placed on them.

And we made a mistake in our response: we suggested a "bad actor on a
subdomain" as the likely root cause. That was an assumption that didn't
fit their specific setup — they don't host user-generated content — and
we shouldn't have made it. We apologized for that.

What the data actually showed

We tracked where new Locize registrations came from, based on an optional
"how did you hear about us?" field at signup. Over approximately two months
and 226 responses:

Source	Signups	Share
Google / Search	88	39%
i18next ecosystem	46	20%
Other / Noise	33	14.6%
AI tools (ChatGPT, Gemini, etc.)	15	6.6%
Console notice (explicit)	14	6.2%
Word of mouth	11	4.8%
GitHub / npm / docs	10	4.4%
Blog posts	10	4.4%

14 people explicitly cited the console notice. The "i18next ecosystem"
bucket likely includes more who saw it but described it differently.
The notice drove some awareness. Not zero.

Why we're removing it

We're removing the notice in v26.0.0. The sustainability argument hasn't changed — i18next exists because Locize exists, and that's still true.
But the way we chose to communicate that created costs we didn't fully anticipate, and when we weighed those costs honestly, removing it was the right call.

We're removing it because when we weigh the costs and benefits honestly,
the math has changed:

The production friction — PaaS providers, library authors, third-party dependency scenarios — turned out to be more complex than we anticipated.
The edge cases were real: CI pipelines, test logs, design systems, environments where suppression required infrastructure-level intervention.
The community cost — issues filed, trust eroded, developers who saw it as a betrayal of open source principles — was higher than we expected.
The conversion impact was real, and we're not convinced it would grow faster than the community cost it was accumulating.

v26.0.0 is a major release with several breaking changes and modernization
work. Removing the notice cleanly — including the showSupportNotice
option, the globalThis mechanism, and the env var — fits naturally into
that release.

How you can actually support i18next

If this post resonated with you, here's what actually helps:

Try Locize. It's built by the i18next team, integrates deeply with the ecosystem, and there's also a free plan to get started. If it fits your workflow, it directly funds the library you're using.
Tell your team or decision-makers. If your company uses i18next in production, knowing that Locize funds its development is relevant information for anyone evaluating localization tooling.
Mention it when it comes up. When someone asks about i18next in your community or on social media, it costs nothing to mention that Locize is how the library stays maintained.

We're not going anywhere. i18next will keep improving. The team is the
same, the commitment is the same, and the library remains fully free and
MIT-licensed.

We just learned something about how to talk about that — and we're
adjusting accordingly.

— The i18next / Locize team

next-i18next v16: App Router, Pages Router, and Everything In Between

Adriano Raiano — Mon, 23 Mar 2026 08:00:17 +0000

When next-i18next was first released, Next.js only had the Pages Router. The library became the go-to way to add i18n to Next.js apps, wrapping _app with appWithTranslation, calling serverSideTranslations in getStaticProps, and letting Next.js handle locale routing.

Then Next.js introduced the App Router with Server Components, and our advice changed: "You don't need next-i18next anymore for App Router... just use i18next and react-i18next directly." We even published a streamlined setup guide showing how to wire it all up manually.

But honestly? That manual wiring was boilerplate. Every project needed the same middleware, the same getT helper, the same I18nProvider setup. And projects migrating from Pages Router to App Router, or running both routers side by side, had no clean path.

next-i18next v16 fixes all of that.

What's New

getT() for Server Components — async, namespace-aware, type-safe
useT() for Client Components — reads language from URL params automatically
createProxy() for language detection and routing — edge-safe, zero Node.js dependencies
I18nProvider for client hydration — with lazy-loading support for additional namespaces
basePath scoping — run both App Router and Pages Router in the same app
No-locale-path mode — cookie-based language without URL prefixes
Full Pages Router compatibility — appWithTranslation and serverSideTranslations via next-i18next/pages

Already using the manual i18next setup from our 2025 blog post? Migration is straightforward: replace your custom helpers with next-i18next/server and next-i18next/client, and your middleware with createProxy().

App Router Setup

1. Install

npm install next-i18next i18next react-i18next

2. Translation Files

Place your translations in your project. The simplest approach uses a resourceLoader with dynamic imports:

app/i18n/locales/en/common.json
app/i18n/locales/en/home.json
app/i18n/locales/de/common.json
app/i18n/locales/de/home.json

3. Configuration

Create i18n.config.ts:

import type { I18nConfig } from 'next-i18next/proxy'

const i18nConfig: I18nConfig = {
  supportedLngs: ['en', 'de'],
  fallbackLng: 'en',
  defaultNS: 'common',
  ns: ['common', 'home'],
  resourceLoader: (language, namespace) =>
    import(`./app/i18n/locales/${language}/${namespace}.json`),
}

export default i18nConfig

The resourceLoader uses dynamic imports to load translation files, they get bundled at build time and loaded on demand. If you prefer, you can also place files in public/locales/ and skip the resourceLoader (the default filesystem loader will pick them up).

4. Proxy (Language Detection & Routing)

Create proxy.ts at your project root. Next.js 16 renamed the old middleware.ts convention to proxy.ts:

import { createProxy } from 'next-i18next/proxy'
import i18nConfig from './i18n.config'

export const proxy = createProxy(i18nConfig)

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|assets|favicon.ico|sw.js|site.webmanifest).*)'],
}

The proxy handles:

Language detection from cookie → Accept-Language header → fallback
Redirecting bare URLs to locale-prefixed paths (/about → /en/about)
Setting a custom header for Server Components to read the current language

Still on Next.js 14 or 15? Use createMiddleware from next-i18next/middleware in your middleware.ts: same API, just the old file convention.

5. Root Layout

app/[lng]/layout.tsx:

import { initServerI18next, getT, getResources, generateI18nStaticParams } from 'next-i18next/server'
import { I18nProvider } from 'next-i18next/client'
import i18nConfig from '../../i18n.config'

initServerI18next(i18nConfig)

export async function generateStaticParams() {
  return generateI18nStaticParams()
}

export default async function RootLayout({
  children,
  params,
}: {
  children: React.ReactNode
  params: Promise<{ lng: string }>
}) {
  const { lng } = await params
  const { i18n } = await getT()
  const resources = getResources(i18n)

  return (
    <html lang={lng}>
      <body>
        <I18nProvider language={lng} resources={resources}>
          {children}
        </I18nProvider>
      </body>
    </html>
  )
}

A few things to note:

initServerI18next(config) stores the configuration, call it once at module scope
getResources(i18n) serializes the loaded translations so the client can hydrate without re-fetching
I18nProvider creates a client-side i18next instance hydrated with those resources

6. Server Components

import { getT } from 'next-i18next/server'

export default async function Page() {
  const { t } = await getT('home')
  return <h1>{t('title')}</h1>
}

getT() reads the language from the proxy-set header, loads the requested namespace if needed, and returns a namespace-typed t function plus the resolved lng. No prop drilling, no manual language passing.

For generateMetadata:

export async function generateMetadata() {
  const { t } = await getT('home')
  return { title: t('meta_title') }
}

For the Trans component in Server Components, use react-i18next/TransWithoutContext and pass both t and i18n:

import { Trans } from 'react-i18next/TransWithoutContext'
import { getT } from 'next-i18next/server'

export default async function Page() {
  const { t, i18n } = await getT()
  return (
    <Trans t={t} i18n={i18n} i18nKey="welcome">
      Welcome to <strong>next-i18next</strong>
    </Trans>
  )
}

7. Client Components

'use client'
import { useT } from 'next-i18next/client'

export default function Counter() {
  const { t } = useT('home')
  return <button>{t('click_me')}</button>
}

useT reads the language from URL params ([lng] or [locale]) and keeps the i18next instance in sync. In no-locale-path mode (where there are no URL params), it uses the language set by I18nProvider.

No-Locale-Path Mode

Not every project wants /en/about and /de/about. Some prefer clean URLs with cookie-based language:

const i18nConfig: I18nConfig = {
  supportedLngs: ['en', 'de'],
  fallbackLng: 'en',
  localeInPath: false,
  resourceLoader: (language, namespace) =>
    import(`./app/i18n/locales/${language}/${namespace}.json`),
}

Routes live directly under app/ (no [lng] segment). Language switching uses the useChangeLanguage hook:

'use client'
import { useChangeLanguage } from 'next-i18next/client'

export function LanguageSwitcher() {
  const changeLanguage = useChangeLanguage()
  return <button onClick={() => changeLanguage('de')}>Deutsch</button>
}

This sets the cookie, updates the i18next instance, and triggers a server re-render — all in one call.

Mixed Router: App Router + Pages Router Together

This is where v16 really shines. Many real-world projects have an existing Pages Router app and want to start building new features with the App Router, without rewriting everything.

The basePath option scopes the proxy to a specific URL prefix:

// i18n.config.ts (App Router)
const i18nConfig: I18nConfig = {
  ...shared,
  basePath: '/app-router',
  resourceLoader: (language, namespace) =>
    import(`./public/locales/${language}/${namespace}.json`),
}

// proxy.ts
import { createProxy } from 'next-i18next/proxy'
import i18nConfig from './i18n.config'

export const proxy = createProxy(i18nConfig)

export const config = {
  matcher: ['/app-router/:path*'],
}

The proxy only handles /app-router/* routes. Pages Router pages at / continue using Next.js built-in i18n routing with appWithTranslation and serverSideTranslations from next-i18next/pages. Both routers share the same translation files from public/locales/.

Pages Router (Unchanged)

If you're on the Pages Router and upgrading from v15, the only change is the import path:

// Before (v15)
import { appWithTranslation, useTranslation } from 'next-i18next'
import { serverSideTranslations } from 'next-i18next/serverSideTranslations'

// After (v16)
import { appWithTranslation, useTranslation } from 'next-i18next/pages'
import { serverSideTranslations } from 'next-i18next/pages/serverSideTranslations'

Everything else — next-i18next.config.js, getStaticProps, getServerSideProps, custom backends — works exactly the same.

Custom Backends

next-i18next supports any i18next backend plugin. When you provide a custom backend via the use option, the default resource loader is skipped automatically.

On the server side, custom backends work through the shared singleton instance, translations are fetched once and cached:

import { defineConfig } from 'next-i18next'
import HttpBackend from 'i18next-http-backend'

export default defineConfig({
  supportedLngs: ['en', 'de'],
  fallbackLng: 'en',
  use: [HttpBackend],
  i18nextOptions: {
    backend: {
      loadPath: 'https://cdn.example.com/locales/{{lng}}/{{ns}}.json',
    },
  },
})

On the client side, pass backends through I18nProvider. Since backend classes are functions (not serializable), import them in a 'use client' component:

'use client'
import { I18nProvider } from 'next-i18next/client'
import HttpBackend from 'i18next-http-backend'
import ChainedBackend from 'i18next-chained-backend'
import LocalStorageBackend from 'i18next-localstorage-backend'

export function I18nProviderWithBackend({ children, language, resources, supportedLngs }) {
  return (
    <I18nProvider
      language={language}
      resources={resources}
      supportedLngs={supportedLngs}
      use={[ChainedBackend]}
      i18nextOptions={{
        backend: {
          backends: [LocalStorageBackend, HttpBackend],
          backendOptions: [
            { expirationTime: 60 * 60 * 1000 }, // 1 hour localStorage cache
            {}, // HttpBackend defaults
          ],
        },
      }}
    >
      {children}
    </I18nProvider>
  )
}

This gives you server-rendered translations at initial load, with client-side lazy-loading of additional namespaces through the chained backend. The i18next-http-backend example demonstrates this pattern with both App Router and Pages Router in a single project.

A Note on Serverless Environments

On the server, next-i18next uses a module-level singleton i18next instance. Translations are loaded once and reused across all subsequent requests within the same process — great for performance, and custom backends like i18next-http-backend or i18next-locize-backend benefit from this since they don't re-fetch on every request.

However, in serverless environments (Vercel Serverless Functions, AWS Lambda, Google Cloud Functions, etc.), the module-level cache only lives as long as the warm function instance. Each cold start re-initializes the singleton and re-fetches translations.

For serverless deployments, we recommend one of these approaches:

1. Bundle translations at build time (recommended for most projects):

Use resourceLoader with dynamic imports: translations are bundled into the deployment artifact at build time, so there's zero runtime fetching:

export default defineConfig({
  supportedLngs: ['en', 'de'],
  fallbackLng: 'en',
  resourceLoader: (language, namespace) =>
    import(`./app/i18n/locales/${language}/${namespace}.json`),
})

2. Download translations in CI/CD:

Download translations from your TMS before building (e.g., via locize-cli or an API). This bundles them with your deployment and avoids runtime HTTP requests entirely.

3. Use HTTP backends with caching:

If you must load translations at runtime, combine i18next-http-backend with i18next-chained-backend and i18next-localstorage-backend on the client side for fast subsequent loads. On the server side, the singleton cache will keep translations warm as long as the function instance is alive.

Avoid relying on HTTP-based backends as the sole translation source in serverless, each cold start adds latency and a potential point of failure.

Bonus

Connect to an awesome translation management system and manage your translations outside of your code.

Let's synchronize the translation files with Locize. This can be done on-demand or on the CI server or before deploying the app.

What to do to reach this step:

In Locize: signup at https://www.locize.app/register and login
In Locize: create a new project
Install the locize-cli (npm i locize-cli) or use the Locize commands built into i18next-cli (npm i -D i18next-cli)
In Locize: add all your additional languages (this can also be done via API or using the migrate command of the locize-cli)

Syncing translations

With locize-cli:

Use locize download to download the published Locize translations to your local repository before bundling your app. Or use locize sync to synchronize bidirectionally.

With i18next-cli:

i18next-cli is a unified toolchain that goes beyond syncing — it also handles key extraction, type generation, locale synchronization, and linting. Its built-in Locize integration wraps locize-cli commands:

npx i18next-cli locize-download   # download translations from Locize
npx i18next-cli locize-sync       # upload/sync translations to Locize
npx i18next-cli locize-migrate    # migrate local translations to Locize

If your Locize credentials are missing, it will guide you through an interactive setup.

For projects that want to load translations directly from Locize at runtime, use i18next-locize-backend as a custom backend:

import { defineConfig } from 'next-i18next'
import LocizeBackend from 'i18next-locize-backend'

export default defineConfig({
  supportedLngs: ['en', 'de'],
  fallbackLng: 'en',
  use: [LocizeBackend],
  i18nextOptions: {
    backend: {
      projectId: 'your-project-id',
    },
  },
})

On the server, the singleton instance caches translations, no re-fetching per request. On the client, combine with i18next-chained-backend and i18next-localstorage-backend for offline-first loading with automatic background refresh.

Wrapping Up

next-i18next v16 is a single package that handles every Next.js i18n scenario:

App Router with Server Components and Client Components
Pages Router with the familiar appWithTranslation / serverSideTranslations API
Mixed setups where both routers coexist
Custom backends for loading from CDN, API, or Locize
Locale-in-path and no-locale-path modes

For the complete code, check out the examples on GitHub:

Happy coding!

npx i18next-cli instrument

Adriano Raiano — Wed, 04 Mar 2026 07:18:25 +0000

Internationalizing a React application used to mean a tedious weekend of hunting down every hardcoded string, manually wrapping each one in a t() call, injecting useTranslation() hooks into every component, and praying you didn't miss a corner case. The reality is that most apps ship without i18n simply because the upfront cost feels too high.

The new instrument command in i18next-cli changes that equation entirely. In this post, we'll take a React + Vite + TypeScript project — Taskly — from zero i18n to a cloud-synced, multi-language application in just a few steps.

The Starting Point: A Standard React App

Taskly is a typical modern project: Vite, React, and TypeScript. It has no i18n dependencies and no translation files—just English strings scattered throughout the JSX:

// DashboardPage.tsx (before)
<h1>Here's your overview</h1>
<p>You have {activeCount} tasks left to complete.</p>

This is the "Before" state. Let's start the transformation.

Step 1 — Instrument: Let the CLI Do the Heavy Lifting

Instead of manual search-and-replace, we run:

npx i18next-cli instrument

If no i18next.config.ts exists, the CLI opens an interactive setup wizard first:

Welcome to the i18next-cli setup wizard!
✔ What kind of configuration file do you want? TypeScript (i18next.config.ts)
✔ What locales does your project support? en,de,fr,it,es,ja
✔ What is the glob pattern for your source files? src/**/*.{js,jsx,ts,tsx}
✔ What is the path for your output resource files? public/locales/{{language}}/{{namespace}}.json
✔ Configuration file created at: i18next.config.ts

Then the instrumentation begins. The tool performs a deep static analysis of your codebase and:

Wraps hardcoded user-facing strings in t() calls, generating a key from the content
Injects useTranslation() hooks into React components that need them
Adds import { useTranslation } from 'react-i18next' where missing
Falls back to import i18next from 'i18next' with i18next.t() in non-component files
Generates a ready-to-use src/i18n.ts initialization file
Automatically injects import './i18n' into your entry file (src/main.tsx)
Detects language-switcher patterns and injects i18n.changeLanguage() calls

After the run you'll see a summary like:

✔ Scanned complete: 101 candidates, 101 approved, 1 language-change site(s)

Instrumentation Summary:
  Total candidates:     101
  Approved:            101
  Skipped:               0
  Language-change sites: 1

✔ 5 file(s) ready for instrumentation

▶  Next step: run 'i18next-cli extract' to extract the translation keys into your locale files.

The generated src/i18n.ts is already wired up to load your translation files using lazy dynamic imports, and i.e. src/main.tsx now imports it automatically:

// src/main.tsx — modified by the instrument command
import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import App from './App'
import './i18n'          // ← injected automatically

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <App />
  </StrictMode>,
)

// src/i18n.ts — generated by the instrument command
import i18next from 'i18next'
import { initReactI18next } from 'react-i18next'
import resourcesToBackend from 'i18next-resources-to-backend'

i18next
  .use(initReactI18next)
  .use(resourcesToBackend((language: string, namespace: string) =>
    import(`../public/locales/${language}/${namespace}.json`)))
  .init({
    returnEmptyString: false,
    fallbackLng: 'en',
    defaultNS: 'translation'
  })

export default i18next

Step 2 — The Human Touch: Manual Adjustments

⚠️ First-Step Tool: The instrument command uses heuristic-based detection and is designed as a first pass to identify and suggest transformation candidates. It will not catch 100% of cases, and you should expect both false positives and false negatives. Always review the suggested transformations carefully before committing them to your codebase. Think of it as an intelligent code assistant, not an automated compiler.

Static analysis is powerful, but some strings need a guiding hand. The CLI provides the // i18next-instrument-ignore comment to opt individual strings out of instrumentation.

Brand names and UI chrome

In Sidebar.tsx for example, "Taskly" is a brand name — it must never be translated:

{/* i18next-instrument-ignore */}
<span className={styles.brandName}>Taskly</span>

Dynamic labels mapped from data

The navigation labels are stored in a NAV_ITEMS array. The CLI instruments each label literal independently, but the right approach is a single t() call keyed by item.page. You can place comment-hints to guide the CLI:

const NAV_ITEMS = [
  {
    // t('navLabel.dashboard', 'Dashboard')
    page: 'dashboard',
    // i18next-instrument-ignore
    label: 'Dashboard',
    // ...
  },
  // ...
]

// Then in JSX, adjust to use the data-driven key:
<span className={styles.navLabel}>
  {t(`navLabel.${item.page}`, item.label)}
</span>

The ignore comment keeps the literal in the array (needed at runtime as the fallback), while the comment-hint registers the key for extraction. A quick manual edit connects the two.

Language switcher — detected automatically

The CLI detects patterns that change the application language and injects i18n.changeLanguage() alongside them. In SettingsPage.tsx, the original onClick only called updateSettings:

// Before
onClick={() => updateSettings({ language: lang.code })}

// After — instrument detects the language-change pattern and injects:
onClick={() => { i18n.changeLanguage(lang.code); updateSettings({ language: lang.code }); }}

No manual change needed here — the CLI handled it.

Step 3 — Extract: Generate Your Translation Files

With the code instrumented, now run:

npx i18next-cli extract

This parses every source file, collects all t() calls or Trans component keys and their default values, and writes them into your locale files:

Updated: public/locales/en/translation.json
Updated: public/locales/de/translation.json
Updated: public/locales/fr/translation.json
Updated: public/locales/it/translation.json
Updated: public/locales/es/translation.json
Updated: public/locales/ja/translation.json
✔ Extraction complete!

Your public/locales/en/translation.json now contains every key with its English default value:

{
  "heresYourOverview": "Here's your overview",
  "highPriority": "High priority",
  "howAreYou": "How are you today?",
  "navLabel": {
    "dashboard": "Dashboard",
    "tasks": "My Tasks",
    "settings": "Settings",
  },
  ...
}

You now have a complete English baseline ready for the world.

The other locale files have the same keys but empty values — ready to be translated.

Bonus: TypeScript Definitions

If you're using TypeScript, one extra command gives you fully typed translation keys — so typos in t() calls and Trans components become compile errors:

npx i18next-cli types

✔ TypeScript definitions generated successfully.
  ✓ Resources interface written to src/@types/resources.d.ts
  ✓ TypeScript definitions written to src/@types/i18next.d.ts

Run this after every extract and your editor will autocomplete translation keys and flag any that don't exist.

Step 4 — Migrate: Push to Locize

At this point, you have a fully extracted English baseline.

You could manually share these JSON files with translators, wait for them to finish, and try to merge their changes back into your codebase. But dealing with new keys, deleted keys, and merge conflicts quickly becomes a maintainability nightmare. Instead, it's time to streamline the process and move your localization workflow to the cloud.

Add your Locize credentials to i18next.config.ts (you can also use environment variables or just follow the interactive prompt):

// i18next.config.ts
export default {
  locales: ['en', 'de', 'fr', 'it', 'es', 'ja'],
  extract: {
    input: 'src/**/*.{js,jsx,ts,tsx}',
    output: 'public/locales/{{language}}/{{namespace}}.json'
  },
  locize: {
    projectId: 'your-project-id',
    apiKey: process.env.LOCIZE_API_KEY,
    version: 'latest'
  }
}

Then push everything to Locize in one command:

npx i18next-cli locize-migrate

If necessary, the CLI prompts for your credentials on the first run, offers to save them securely, then migrates all locale files:

✔ Retry successful!
added language de...
added language es...
added language fr...
added language it...
added language ja...
transfering latest/en/translation...
transfered 94 keys latest/en/translation...
...
downloading translations after migration...
✔ 'locize migrate' completed successfully.

💡 Automatic Translation: If you have Locize's Machine / AI Translation feature enabled, your target languages will be translated automatically after migration — asynchronously.

Pro Tip: In case the translated files are not ready yet, wait a moment after migrating and run npx i18next-cli locize-download to pull those new translations back into your local project.
npx i18next-cli locize-download

Step 5 — Iterate: Adding New Keys

Development doesn't stop after the initial migration. When you add a new feature:

// DashboardPage.tsx
<p>{t('howAreYou', 'How are you today?')}</p>

Just run two commands:

npx i18next-cli extract      # picks up the new key locally
npx i18next-cli locize-sync  # syncs new keys to Locize, downloads translations

The new key appears in public/locales/en/translation.json immediately after extract, and after locize-sync all other languages will have it translated (instantly if Auto-Translation is on, or pending your translators' review).

Command reference

Command	When to use
`extract`	After every code change — keeps local JSON in sync with your source
`types`	After `extract` — generates TypeScript definitions for type-safe translation keys
`locize-migrate`	Once, for the initial bulk push of local resources to Locize
`locize-sync`	Ongoing — two-way sync between local files and Locize
`locize-download`	Pull the latest translations from Locize without pushing changes

Step 6 — Going Further: Dynamic Translation Loading

Bundling JSON files works well, but i18next-locize-backend lets you decouple your translations entirely from your deployment cycle.

npm install i18next-locize-backend

// src/i18n.ts
import i18next from 'i18next'
import { initReactI18next } from 'react-i18next'
import LocizeBackend from 'i18next-locize-backend'

i18next
  .use(initReactI18next)
  .use(LocizeBackend)
  .init({
    fallbackLng: 'en',
    backend: {
      projectId: 'your-project-id',
      version: 'latest'
    }
  })

export default i18next

Benefits:

No re-deploys for copy changes. Fix a typo in the Locize editor and it appears in your live app at the next page load — no build, no deploy.
Smaller bundles. Only the user's language is fetched, on demand.
Phased rollouts. Use Locize versioning to promote translations independently of code versions.

Step 7 — Power Features: `saveMissing` and the InContext Editor

`saveMissing` — Zero-friction key registration

During development, enable saveMissing to automatically push newly written keys to Locize the moment they appear in the running app — no extract step needed:

i18next.use(LocizeBackend).init({
  saveMissing: true,        // push unknown keys to Locize immediately
  backend: { projectId: 'your-project-id', apiKey: 'your-api-key' }
})

This pairs beautifully with Locize AI: as soon as a new key arrives, Locize translates it into every configured language automatically.

InContext Editor — Edit translations in place

Add the Locize InContext Editor to your development build for a visual, in-page translation workflow — click any string, edit it directly in the browser, and save it back to Locize without ever leaving the app.

npm install locize-lastused locize

import LastUsed from 'locize-lastused'
import { locizePlugin } from 'locize'

i18next
  .use(LastUsed)    // tracks which keys are actually used in production
  .use(locizePlugin) // enables the InContext Editor
  // ...

locize-lastused also flags keys in your Locize dashboard that haven't been used recently — making it easy to clean up stale translations alongside your code.

The Full Journey at a Glance

1.  npx i18next-cli instrument       → Wrap strings, inject hooks, generate i18n.ts
2.  [manual tweaks]                  → Ignore brand names, fix dynamic key patterns
3.  npx i18next-cli extract          → Generate local translation JSON
    npx i18next-cli types            → Generate TypeScript definitions (optional)
4.  npx i18next-cli locize-migrate   → Push everything to Locize (first time)
    [Locize AI translates async]
    npx i18next-cli locize-download  → Pull auto-translated files back locally
5.  [code new feature]
    npx i18next-cli extract          → Pick up new keys
    npx i18next-cli locize-sync      → Two-way sync with Locize

Optional upgrades:
    → i18next-locize-backend         → Fetch translations dynamically (no re-deploy)
    → saveMissing: true              → Auto-register new keys from running app
    → locize InContext Editor        → Edit translations visually in the browser
    → locize-lastused                → Track and clean up stale keys

We went from a standard React app with 100+ hardcoded strings to a fully instrumented, cloud-synced, multi-language application in minutes — not a weekend.

Summary: The Workflow

Phase	Commands
Setup	`instrument` → `extract` → `locize-migrate`
Daily Dev	`extract` → `locize-sync`
Live Updates	Use `i18next-locize-backend` for instant publishing

By leveraging the i18next-cli, we've turned what used to be a grueling manual task into a streamlined, automated pipeline.

Want to see if your project is ready? Run:

npx i18next-cli status

It gives you an instant overview of your current i18n health.

Example app: github.com/locize/taskly
i18next-cli: github.com/i18next/i18next-cli
Locize: locize.com
Video: Youtube

Finally: A Free Plan for the Official i18next Platform

Adriano Raiano — Sat, 21 Feb 2026 11:48:30 +0000

Stop manually editing JSON files. The "native" home for i18next is now free for hobbyists and side projects.

The "Manual JSON" Struggle is Real

If you’ve ever built a multi-language app with i18next, you know the drill. You start with one en/translation.json file. It’s fine. Then comes de/translation.json. Then a teammate adds a key to one but forgets the other. Then a translator sends you an Excel sheet, and you spend your Friday night copy-pasting strings into nested objects.

We created i18next in 2011 to solve the code side of internationalization. A few years later, we built Locize to solve the management side.

Until today, Locize was mostly a "pay-as-you-go" service with a 14-day trial. But we heard you: "I want to use the official tool for my side projects, but I don't want a ticking clock on my trial."

We listened. Today, we’re launching the Locize Free Plan.

What’s in the Free Plan?

We wanted this to be actually useful, not just a "demo" tier.

2,000 Words: Plenty for a landing page, a SaaS MVP, or a personal blog.
100,000 Downloads/mo: Enough to handle a healthy amount of traffic via our CDN.
The Full "Native" Experience: You get automatic missing key handling, the In-Context Editor, and runtime updates.

Why this matters for the i18next ecosystem

Transparency is one of our core values. We don't have venture capital funding. Locize is what funds the development of i18next. When you use Locize — even on the free plan — you are helping us maintain the open-source libraries you use every day, like i18next, react-i18next, and i18next-cli. It’s a sustainable cycle: the service funds the framework, and the framework makes the service better.

How to set it up (The 2-Minute Version)

Integration is exactly what you'd expect from the creators of the framework. You just swap your local backend for the Locize backend.

import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import Backend from 'i18next-locize-backend';

i18n
  .use(Backend)
  .use(initReactI18next)
  .init({
    fallbackLng: 'en',
    backend: {
      projectId: 'your-project-id',
      apiKey: 'your-api-key', // only use in development!
      referenceLng: 'en'
    },
    // This allows you to send missing keys 
    // from your code directly to Locize!
    saveMissing: true 
  });

With saveMissing: true, you don't even have to type keys into the Locize UI. You just write t('new_hero_title') in your React component, and the key appears in Locize automatically.

Growing beyond "Hobby" scale?

For teams that need more, we’ve also introduced new Fixed Pricing Plans.

Our "pay-as-you-go" model is flexible but sometimes hard to budget for. Now, you can choose a fixed tier (Starter, Professional, or Enterprise) so you know exactly what your base cost is every month, with fair, graduated overages if you go viral.

Let's build together

We’ve been maintaining i18next for over 15 years. This new pricing model is our way of making sure the "Native Home" for i18next is accessible to everyone — from the dev building their first portfolio to the enterprise scaling to hundreds of languages.

Check out the new plans here: locize.com/pricing

I’d love to hear what you think in the comments! What's the biggest pain point you have with i18n right now?

PS. Locize has no sales reps. You can sign up, try it, and talk directly to the engineers. No "discovery calls," no sales pitches, just real support from the people who build the platform.

Back to Our Roots: The All-New locize.com

Adriano Raiano — Mon, 19 Jan 2026 11:08:34 +0000

We’ve been relatively quiet lately, but for a good reason. We weren’t just redesigning a website; we were rethinking how we present the tool we’ve built for you.

We are launching the new locize.com website.

If you’ve been with us since the beginning, this update might feel familiar. We’ve stripped away the "marketing fluff" and returned to the core philosophy of our very first site: content-first, developer-focused, and radically transparent.

Less Noise, More Clarity

In the world of SaaS, it’s easy to get lost in buzzwords. We decided to go the other way. The new website is more elegant and significantly easier to read, focusing on the information you actually need to get your job done.

But it’s not just a visual change. We’ve rebuilt the engine under the hood to make the entire experience faster and more intuitive.

A World-Class Documentation Experience

Documentation is important for us. We’ve overhauled the Docs from the ground up:

Lightning Fast Search: Find the exact API call or configuration setting instantly.
Enhanced Readability: A cleaner layout that stays out of your way while you code.
Better Blog Experience: Our blog and tutorials now feature a refined reading style and a powerful new search to help you find localization best practices in seconds.

A Modern App for a Modern Workflow

The new screenshots you see across the new site aren't just "marketing assets" — they are a reflection of the major UI and UX improvements we’ve made to the Locize App itself.

We’ve updated the design of the platform to be more modern, faster, and easier to navigate. Whether you are managing complex multi-namespace architectures or a single small project, the interface is now more responsive and streamlined.

What you see on the website is what you get in the tool:

Modernized UI: A cleaner, high-contrast interface.
Speed Improvements: Faster loading and save times.
Refined UX: Fewer clicks to get to your most important tasks.
New Power Features: We've integrated automated backups, simplified AI translation, advanced charts, and more user roles.

Why We Changed

We believe that a localization platform should be an invisible, high-performance part of your tech stack. It shouldn't require a sales deck to understand. By going back to our roots, we are doubling down on what made Locize the industry standard for i18next and modern localization: technical excellence without the overhead.

Reflecting on our journey, having created the foundation with i18next, it has been a long road to what Locize is today. We want this journey to continue with you.

Explore the new site, search the docs, and log in to the app to feel the difference.

The Invisible Engine: How the Team Behind i18next is Securing the Future of Global Software

Adriano Raiano — Tue, 06 Jan 2026 07:10:55 +0000

If you have ever used a localized web application — one that seamlessly switches from English to German to Japanese — there is a very high chance you were relying on i18next. It is the absolute standard for internationalization in the JavaScript ecosystem. But like many pillars of modern digital infrastructure, it faces the age-old open-source dilemma: how do you maintain, improve, and innovate on a massive free project without burning out?

The answer unfortunately isn't donations; it's Locize.

Many developers don't realize that the creators of i18next are also the founders of Locize. This isn't just a coincidence — it's a symbiotic relationship designed to solve the sustainability crisis in open source. Locize isn't just a translation management system; it is also the financial backbone that ensures i18next remains well-maintained, free, and cutting-edge. Every new customer on Locize doesn’t just get a powerful localization platform; they directly secure the future of the open-source framework they rely on.

And that future is looking faster and smarter than ever. The team has been busy shipping major updates to both sides of the ecosystem.

Rust, Speed, and the New i18next-cli

On the open-source side, the developer experience just got a massive upgrade. The team recently launched the new i18next-cli, a complete reimagining of the toolchain.

Moved away from the slower, legacy extraction tools, the new CLI is built on SWC (a super-fast Rust-based compiler). The result? Operations that used to take minutes now take seconds. It’s a unified tool that handles key extraction, code linting, and locale syncing without the configuration headaches of the past. It represents exactly what commercial backing allows an open-source team to do: take the time to rebuild foundational tools to be performant and modern.

AI That Just Works

On the commercial side, Locize is tackling the biggest buzzword of the year — AI — but in a way that actually respects a developer's time.

With the new built-in Locize AI service, the friction of machine translation is effectively gone. Previously, integrating AI meant hunting for API keys from third-party providers (OpenAI, Google, etc.), configuring billing, and worrying about rate limits. Locize has abstracted all of that away. You no longer need your own API key; the service is integrated directly into the platform, allowing teams to translate content instantly with context-aware AI. It’s "click and go" localization, designed to let developers focus on code, not vendor management.

The Next Step: Killing the Download Cost

The team isn’t stopping there. In a move to further align their incentives with their customers', Locize has just launched an alternative “Standard” CDN type as opposite to the current “Pro” CDN.

This new infrastructure is available to customers free of charge. This effectively eliminates download costs for translation files, removing the "tax" on scaling your application to more users. It’s a bold move that doubles down on the philosophy that your localization platform should empower your growth, not penalize it.

Additionally, for those just starting out, the team is hinting at upcoming changes designed to lower the cost barrier even further for entry-level projects. While the full details are still under wraps, it signals a commitment to accessibility for projects of all sizes.

A Sustainable Ecosystem

In an industry where open-source maintainers often step away due to lack of support, the i18next and Locize model stands out. It offers a clear path forward: build incredible tools that solve real problems, and use that success to fuel the open-source code that runs the world.

For developers and CTOs, the message is simple. When you choose Locize, you aren't just buying a service. You’re investing in the longevity of the tools you use every day.

Supercharge Your GitBook Docs with Live, Real-Time Polls

Adriano Raiano — Tue, 04 Nov 2025 10:05:00 +0000

Technical documentation is often a one-way street: you write it, and users read it. But what if your documentation could be interactive? What if you could gather feedback, survey your readers, and make your content a living, collaborative space?

Today, we're excited to bridge that gap by launching the Vaultrice Voting Integration for GitBook!

You can now add beautiful, real-time, and interactive polls directly into any GitBook page. It's the perfect way to engage your readers and gather valuable feedback right where they are.

From Static Pages to Interactive Experiences

The Vaultrice integration adds a new "Vaultrice Voting Widget" block to your GitBook editor. With just a few clicks, you can create and configure a poll without ever leaving GitBook.

This integration is powered by our @vaultrice/react-components library, which handles all the complexity of real-time data synchronization. When a user votes, the results are securely stored in Vaultrice and updated instantly for every other reader across the globe.

Common Use Cases

This opens up a world of possibilities for your documentation:

Gather feedback on a new feature proposal right on the doc page.
Let users vote on which tutorial you should write next.
Quickly survey readers about the clarity of an article.
Run engaging, fun polls for internal team documentation.

Getting Started in 3 Simple Steps

You can get your first poll running in under five minutes.

Get Your Credentials: Create a free Vaultrice account to get your projectId, apiKey, and apiSecret.
Install the Integration: Find and install the "Vaultrice Voting Integration" from here - and configure it.
Configure the Block: Add the "Vaultrice Voting Widget" block to any page, paste in your credentials, and write your poll questions.

That's it! Your interactive poll is now live.

A Note on Security

For enhanced security in a public-facing context like documentation, we highly recommend locking down your API key. Using Origin Restriction, you can ensure your key can only be used for requests coming from GitBook's integration service.

Simply add https://integrations.gitbook.com as an allowed origin in your Vaultrice project dashboard. This is a powerful way to secure your credentials, and you can learn more about it in our Security Documentation.

See It in Action: The i18next Documentation

We're thrilled that the popular internationalization framework i18next is one of the first to adopt this new integration. They are actively using it to gather feedback from their vast community of developers.

You can see the poll live in their documentation and cast a vote yourself!

See the live poll on i18next.com

Conclusion

We believe that documentation should be a living, breathing part of your product's ecosystem. By adding a layer of real-time interactivity, you can get closer to your users and build better products.

We can't wait to see the creative ways you use this to engage your readers.

From API Keys to E2EE: A Practical Guide to Securing Your Real-Time App

Adriano Raiano — Wed, 22 Oct 2025 10:11:00 +0000

When you're building a new real-time feature, the initial focus is on making it work. You spin up a prototype, get the data flowing, and celebrate that first magical moment when two browser tabs update simultaneously. But before you ship to production, a critical question arises: Is this secure?

Security in real-time applications is non-trivial. How do you protect your API credentials on the client-side? How do you ensure one user can't access another user's data? How do you handle sensitive information with maximum confidentiality?

At Vaultrice, we believe security shouldn't be an afterthought. It should be a series of layers you can apply as your application grows in complexity. In this guide, we'll walk through a practical, progressive journey of securing a real-time React application, moving from a basic prototype to a production-ready, end-to-end encrypted system using Vaultrice's security model.

The Scenario: A Collaborative "To-Do" List

Imagine we're building a simple collaborative to-do list app. Multiple users can join a shared list and add or remove items.

Prototype Goal: Get a basic real-time list working.
Production Goal: Ensure only authorized users can access their own lists, their identity is verified, and the to-do items (which might be sensitive) are kept private.

Stage 1: The Prototype (Security Level 0) 🐣

At the start, we just want to get things working. We'll use Direct Authentication with an API key and secret.

The Code:

import { NonLocalStorage } from '@vaultrice/sdk';

// For a quick prototype, we place credentials directly.
const credentials = {
  projectId: 'YOUR_PROJECT_ID',
  apiKey: 'YOUR_API_KEY',
  apiSecret: 'YOUR_API_SECRET'
};

const sharedTodoList = new NonLocalStorage(credentials, 'our-first-todo-list');

// We can now read and write to the list.
await sharedTodoList.setItem('task-1', { text: 'Build prototype' });

Security Analysis (Level 0):

What's working: All communication is automatically encrypted in transit with TLS (HTTPS), and all data is encrypted at rest by default on the backend. This is SF 0: Transport + Default At-Rest Encryption and it's always active on all plans.
The Risk: Our apiSecret is exposed in the client-side code. A malicious actor could steal these credentials and use them from anywhere to access our data. This is fine for a local demo, but unacceptable for production.

Stage 2: Production-Ready (Security Levels 1 & 2) 🚀

Now, let's take our app to production. We need to lock down our credentials, control data access, and verify user identities.

Upgrading Authentication: Secure Access Tokens

First and foremost, we must remove the long-lived apiSecret from our client-side code. The gold standard for this is using Backend-Issued Access Tokens.

The Pattern: Your own backend has a secure endpoint that uses your apiKey and apiSecret to generate a short-lived access token for the client. The client then initializes the SDK with this temporary token, never knowing the secret.

Action: Create a serverless function or API endpoint on your trusted backend.

// On your trusted backend (e.g., /api/vaultrice-token)
import { retrieveAccessToken } from '@vaultrice/sdk';

async function generateTokenForClient(origin) {
  const accessToken = await retrieveAccessToken(
    'YOUR_PROJECT_ID',
    'YOUR_API_KEY',    // Kept securely on the server
    'YOUR_API_SECRET', // Kept securely on the server
    { origin } // Pass the client's origin if using Origin Restrictions
  );
  return { accessToken };
}

Client-Side Implementation: Your client code is now much more secure. You can use the getAccessToken provider for automatic, hands-free token management.

// In your React App
import { NonLocalStorage } from '@vaultrice/sdk';

const secureTodoList = new NonLocalStorage({
  projectId: 'YOUR_PROJECT_ID',
  // The SDK will call this function automatically to get and refresh tokens
  getAccessToken: async () => {
    const response = await fetch('/api/vaultrice-token');
    if (!response.ok) throw new Error('Failed to fetch token');
    const { accessToken } = await response.json();
    return accessToken;
  }
}, 'your-object-id');

Result: You've achieved maximum credential security. Your apiSecret is never exposed to the browser, and the client operates on temporary, revokable tokens.

Layer 1: Perimeter Defense with Origin Restrictions (SF 1)

Next, we prevent our API key from being used on any other website.

Action: In the Vaultrice dashboard, we edit our API key and add our app's domain (e.g., https://mytodoapp.com) to the Origin Restrictions list.
Result: The Vaultrice backend will now reject any request made with this key that doesn't originate from our domain. This is an essential first step for all production applications.

Layer 2: Data Access Control with ID Signatures (SF 2)

We must ensure a user can only access their own to-do list, not someone else's. We can't trust the client to be honest about which list it wants to access.

Action: We enable Object ID Signature Verification in our project's Class settings. Then, we create an endpoint on our backend that signs the objectId for a logged-in user.

// On your trusted backend server
function getSignedTodoListId(user) {
  const objectId = `todo-list-${user.id}`;
  // You sign the ID with your private key
  const signature = signWithYourPrivateKey(objectId);
  return { objectId, signature };
}

Client-Side Implementation: The client now fetches this signed ID from the backend before initializing the SDK.

// Fetch the authorized object ID and signature from our backend
const { objectId, signature } = await fetch('/api/get-todo-list-id');

// Vaultrice will now verify this signature on every request
const userTodoList = new NonLocalStorage(credentials, {
  id: objectId,
  idSignature: signature
});

Result: A user can no longer guess another user's objectId and access their data. The Vaultrice API will reject any request where the signature doesn't match the ID.

Layer 3: Optional Server-Side Hardening (SF 3)

For an extra layer of protection on the server, you can enable Automatic At-Rest Encryption.

What it is: This feature transparently encrypts data values on the Vaultrice server with a unique key before they are stored in the database. This protects against a direct breach of the underlying database infrastructure.
Action: In your Class settings, simply enable the "Additional At-Rest Encryption" checkbox.
Result: Enhanced server-side data protection with no code changes required in your SDK implementation.

Stage 3: Maximum Confidentiality (Security Level 3) 🛡️

Our app is now secure for general use. But what if our to-do items contain highly sensitive information? For this, we need Security Level 3 and SF 4: End-to-End Encryption (E2EE).

Action: We enable E2EE by providing a passphrase during SDK initialization. This passphrase is known only to the client and is never sent to the server.

import { NonLocalStorage } from '@vaultrice/sdk';

const sensitiveList = new NonLocalStorage(credentials, {
  id: signedObjectId, // from Stage 2
  idSignature: signature, // from Stage 2
  passphrase: 'user-secret-passphrase-never-sent-to-server'
});

// We must fetch the salt from the server to derive the encryption key
await sensitiveList.getEncryptionSettings();

// This data is encrypted ON THE DEVICE before being sent.
// Not even Vaultrice can read its content.
await sensitiveList.setItem('task-1', { text: 'Top secret plan' });

Result: The content of our to-do list is now fully confidential. Vaultrice only stores ciphertext, providing the highest level of privacy. It's important to note that server-side atomic operations are incompatible with E2EE, as the server cannot decrypt the data to operate on it. So those operations are not E2EE encrypted.

Conclusion

Security is a journey, not a destination. By starting with a simple prototype and progressively adding layers of protection as needed, you can move to production with confidence. Vaultrice's layered security model provides a clear path to secure your real-time application, from basic transport encryption all the way to zero-knowledge, end-to-end encrypted collaboration.

Choose the security level that matches your needs and start building with confidence on the Vaultrice free tier.

How to Add a Live "Who's Online" List to Your React App in 5 Minutes

Adriano Raiano — Thu, 09 Oct 2025 07:11:00 +0000

Modern collaborative apps have a magical feature: that little pile of avatars in the corner showing you who else is on the team and who's currently active. In tools like Figma or Slack, this rich presence transforms a simple user list into a dynamic team dashboard.

Building this feature is traditionally complex. It requires a backend to merge a static list of team members with real-time connection data, manage sessions, and broadcast updates.

What if you could do it all with a single, powerful React component?

In this tutorial, we'll go beyond a basic "who's online" list and build a rich team presence indicator in minutes, showcasing the advanced features of the Vaultrice <Presence /> component.

The Goal: A Rich Team Presence Component

We will build a presence indicator that:

Shows a predefined list of team members.
Clearly indicates who is online (full color) and offline (faded).
Merges real-time connection data with the predefined user list.
Is fully customizable to match our brand.

Step 1: The "Backend" & Setup (90 seconds)

First, let's get our project ready.

Get Credentials: Sign up for a free account at the Vaultrice App to get your projectId, apiKey, and apiSecret.
Install the Library: Install the pre-built Vaultrice React components.
```
npm install @vaultrice/react-components
```

Step 2: Define Your Team & Add the Component (3.5 minutes)

The <Presence /> component can take a list of predefinedUsers. It uses this list as the "source of truth" and merges it with live connection data.

Let's create our TeamPresence.tsx component:

import React from 'react';
import { Presence } from '@vaultrice/react-components';
import type { JoinedConnection } from '@vaultrice/sdk';

// in production you may want to pass the credentials vie environment variables, and maybe also use the access token mechanism: https://www.vaultrice.com/docs/security#authentication-methods
const credentials = {
  projectId: 'YOUR_PROJECT_ID',
  apiKey: 'YOUR_API_KEY',
  apiSecret: 'YOUR_API_SECRET'
};
const currentUser = {
  id: 'jane-456',
  name: 'Jane Smith',
  avatarUrl: 'https://i.pravatar.cc/150?u=jane-smith',
  role: 'Developer'
};

// This is your predefined list of all team members for this project
const teamMembers = [
  { id: 'john-123', name: 'John Doe', role: 'Team Lead', avatarUrl: '...' },
  { id: 'jane-456', name: 'Jane Smith', role: 'Developer', avatarUrl: '...' },
  { id: 'bob-789', name: 'Bob Wilson', role: 'Designer' }
];

export function TeamPresence() {
  return (
    <div className="presence-container">
      <h3>Project Team:</h3>
      <Presence
        id="project-alpha-presence"
        user={currentUser}
        credentials={credentials}
        predefinedUsers={teamMembers}
        showOfflineUsers={true}
        maxAvatars={6}
      />
    </div>
  );
}

With this single component, you've implemented a complete team presence system.

What We Just Did (The Advanced Features Explained)

This is far more than a simple list of who's online. Let's break down a few props we used from the <Presence /> component:

predefinedUsers={teamMembers}: We provided a static array of our team. The component now knows about all team members, not just the ones who are currently connected.
showOfflineUsers={true}: This tells the component to display users from the predefinedUsers list even if they are not currently connected. The component renders them with a different style (which we control in our CSS) to indicate their offline status.

Try It Yourself: Interactive Demo

Don't just take our word for it. We've published a live Storybook demo of the <Presence /> component with all the features we've discussed. You can change the current user, toggle offline visibility, and see how the component responds in real-time.

➡️ Open the Interactive Storybook Demo

Conclusion

The <Presence /> component is a powerful tool that goes far beyond a simple online indicator. By leveraging its advanced features like predefined users and custom rendering, you can build a rich, informative, and polished team presence system in minutes. This is a perfect example of how a high-level component can abstract away immense backend complexity and deliver a fantastic developer experience.

Stop building presence logic from scratch. Add a rich team presence indicator to your app today with the Vaultrice free tier.

Forem: Adriano Raiano

i18next in Production: Managing Translations at Scale

Problem 1: Translation files in the repo become a bottleneck

Pattern: Decouple translation delivery from code delivery

Problem 2: Nobody knows which keys are missing

Pattern: saveMissing + coverage tracking

Problem 3: Translation quality drifts over time

Pattern: Glossary + Translation Memory + Styleguide

Problem 4: No review process for translations

Pattern: Review workflow

Problem 5: No way to test translations before releasing

Pattern: Branches and versions

Problem 6: SaaS customers need different translations

Pattern: Multi-tenant overrides

Problem 7: Translation updates require a deploy

Pattern: CDN delivery with instant publish

The complete production setup

Getting started

Further reading

next-intl vs next-i18next: Choosing the Right i18n Library for Next.js

Architecture at a glance

How translations are loaded

next-intl: custom loader function

next-i18next: backend plugin ecosystem

Message format

next-intl: ICU MessageFormat

next-i18next: i18next format

saveMissing: automatic key discovery

Translation management integration

Routing and middleware

When to choose next-intl

When to choose next-i18next

Summary

Further reading

How to Set Up Automatic Translation with i18next and Locize

What the automated workflow looks like

Step 1: Set up i18next with Locize backend

Step 2: Enable automatic translation in Locize

Step 3: Write code — translations happen automatically

Step 4: Improve translation quality with context

Styleguide

Glossary

Key-level context

Step 5: Optional — add human review

Step 6: Deploy translations without redeploying

The AI agent workflow (bonus)

Summary

Further reading

Why We Added a Console Notice to i18next — and Why We Removed It

The sustainability problem nobody talks about

What we decided to do

What happened next

What the data actually showed

Why we're removing it

How you can actually support i18next

next-i18next v16: App Router, Pages Router, and Everything In Between

What's New

App Router Setup

1. Install

2. Translation Files

3. Configuration

4. Proxy (Language Detection & Routing)

5. Root Layout

6. Server Components

7. Client Components

No-Locale-Path Mode

Mixed Router: App Router + Pages Router Together

Pages Router (Unchanged)

Custom Backends

A Note on Serverless Environments

Bonus

What to do to reach this step:

Syncing translations

Wrapping Up

npx i18next-cli instrument

The Starting Point: A Standard React App

Step 1 — Instrument: Let the CLI Do the Heavy Lifting

Step 2 — The Human Touch: Manual Adjustments

Brand names and UI chrome

Dynamic labels mapped from data

Step 7 — Power Features: `saveMissing` and the InContext Editor

`saveMissing` — Zero-friction key registration