DEV Community: Adriano Raiano

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.

Supercharge Your i18next Workflow with the All-New i18next-cli

Adriano Raiano — Fri, 26 Sep 2025 06:09:00 +0000

The i18next ecosystem has been at the heart of web localization for over a decade. It was born in a world of jQuery and has evolved alongside the community through the rise of modern frameworks like React, Vue, and Svelte. As our applications have grown in complexity, so have the challenges of managing translations.

For years, the community has relied on tools like i18next-parser for the critical task of extracting translation keys. These tools were pioneers and have served us well. But as codebases swelled into the hundreds of thousands of lines and modern JavaScript syntax became the norm, we began to feel the friction. Slow extraction times, struggles with TypeScript and JSX, and the need for a patchwork of different tools to create a complete workflow became common pain points.

It was time for a change.

Today, we're thrilled to introduce i18next-cli, the official, next-generation, all-in-one toolkit for the i18next ecosystem. It’s a complete reimagining of the developer toolchain, built with three core principles in mind: raw performance, deep code intelligence, and a unified developer experience.

🚀 Want to try it without reading the complete announcement? 😉

We designed i18next-cli to provide immediate value. You can get an instant analysis of your project's translation status without any configuration. Just run this command in your repository's root:

npx i18next-cli status

It heuristically detects your project structure and gives you a report in seconds.

For those using i18next-parser, the transition is seamless. Our migration command automatically converts your legacy config file to the new format:

npx i18next-cli migrate-config

Why This Matters: A Better Workflow

Before diving into the features, let's talk about the impact:

Blazing Fast, By Design

Performance is not just a feature; it’s the foundation of a great developer experience. The single biggest bottleneck in older tools was the use of JavaScript-based parsers.

i18next-cli solves this by being built on SWC, a modern, Rust-based compiler. By leveraging native code, we've unlocked dramatic speed improvements. Workflows that once took over a minute to scan a large project now complete in under five seconds. This isn't just an upgrade; it's a transformation of the development loop, making localization tasks feel instantaneous.

One Tool to Rule Them All

A complete localization workflow requires more than just extraction. i18next-cli is a true toolkit, unifying all essential functions into a single, cohesive CLI with one configuration file.

extract: The core command to find and save keys with a powerful --watch mode.
sync: Keeps your language files synchronized, adding missing keys and removing unused ones.
types: Generates TypeScript definitions for ultimate type safety and autocompletion.
lint: Finds hardcoded strings in your code that should be translated, with smart heuristics to reduce false positives.
status: Gives you a high-level dashboard of your project's translation health, with detailed, per-namespace reporting.

It Just Works: Advanced Pattern Detection

i18next-cli was built with a scope-aware analyzer that creates a semantic understanding of your code. This means it handles a wide range of modern patterns automatically, with no extra configuration needed.

useTranslation with keyPrefix:
It understands that keyPrefix modifies the keys used by t.

const { t } = useTranslation('common', { keyPrefix: 'userProfile' });
// ✅ Correctly extracts 'userProfile.title' into the 'common' namespace
return <h1>{t('title')}</h1>;

<Trans> Component with Complex Children:
Parsing the <Trans> component is notoriously tricky. i18next-cli handles it beautifully, correctly serializing nested components and even extracting keys from props inside the component.

import { Trans, useTranslation } from 'react-i18next';

function WelcomeMessage() {
  const { t } = useTranslation();
  return (
    <Trans i18nKey="welcomeMessage">
      Hello <strong title={t('userTitle')}>{{name}}</strong>, welcome to our app!
    </Trans>
  );
}

The CLI correctly understands this and extracts two keys:

welcomeMessage, with the default value: "Hello <1>{{name}}</1>, welcome to our app!"
userTitle from the nested title prop.

Aliased and Destructured t functions:
Whether you rename t or pull it from an array, the toolkit follows along.

const { t: translate } = useTranslation('ns1');
const [t2] = useTranslation('ns2');

// ✅ Extracts 'key1' into 'ns1'
translate('key1');

// ✅ Extracts 'key2' into 'ns2'
t2('key2');

Key Fallbacks and returnObjects:
It understands advanced i18next features, extracting all static keys from a fallback array and preserving nested objects when you need them.

// ✅ Extracts both 'key.primary' and 'key.fallback'
t(['key.primary', 'key.fallback']);

// ✅ Preserves the entire `countries` object in your JSON files
t('countries', { returnObjects: true });

🚀 Try it Now - Zero Config!

We designed i18next-cli to provide immediate value. For most projects, you can get an instant analysis of your translation status without any configuration. It heuristically detects your project structure and gives you a report in seconds.

Just run this command in your repository's root directory:

npx i18next-cli status

Migration Made Easy

For existing users of i18next-parser, we've made the transition seamless. The toolkit includes a migration command that automatically converts your legacy config file to the new format.

npx i18next-cli migrate-config

Taking Your Workflow to the Cloud with Locize

i18next-cli provides a best-in-class workflow for managing your local translation files in Git. As your project grows, however, managing translations across a team of developers, translators, and product managers can become a challenge.

This is where locize, our translation management platform, is the natural next step. We built i18next-cli to be the perfect bridge between local development and a professional, cloud-based localization workflow.

The CLI is fully integrated with locize, allowing you to migrate your project and synchronize translations with simple commands (locize-migrate, locize-sync). It moves your translations out of JSON files and into a powerful platform built specifically for collaboration.

Get Started Today

We believe i18next-cli sets a new standard for localization tooling. It’s a reflection of our commitment to the i18next community and our mission to create a truly seamless developer experience.

Check out the full documentation, advanced configuration, and plugin system on the official GitHub repository. We can't wait to see how it speeds up your workflow.

The Art of the Key: A Definitive Guide to i18n Key Naming for Longevity and Sanity

Adriano Raiano — Tue, 23 Sep 2025 08:23:00 +0000

Internationalization (i18n) is the blueprint for global software. At its heart lies a deceptively simple element: the translation key. Your team's approach to naming these keys isn't a minor detail—it's a foundational architectural decision. A poor strategy creates "i18n debt," a silent tax on every future feature that slows development and inflates costs. A great one ensures longevity and streamlines collaboration for years to come.

The Key is a Three-Party Contract 📜

Think of an i18n key not as a variable, but as a stable, multi-party contract between three stakeholders:

Developers: They need a predictable interface to retrieve text. The key should offer clues about a string's purpose, reducing the need to constantly jump between the codebase and translation files.
Translators: The key is often their first and most important piece of context. A key like userProfile.buttons.saveChanges is a beacon of clarity; key_123 is a black box that invites guesswork and errors.
Systems (TMS): A Translation Management System uses the key as a unique, immutable ID to manage a string's entire history, screenshots, comments, and glossary terms. If a key changes, that contract is broken, the history is lost, and the string must be re-translated from scratch.

A strategy that only serves one party will inevitably fail. What looks like a simple naming convention is actually a complex system design problem that must balance the needs of everyone involved.

Why Key Naming is a Critical Architectural Decision 🏗️

Choosing your key strategy hastily is like building a house on a shaky foundation. The i18n debt you incur manifests in several painful ways:

Maintenance Brittleness: When keys are tied to file paths, refactoring UI code becomes a nightmare. Developers become afraid to make changes for fear of breaking translations in a dozen languages.
Increased Bugs: Ambiguous or reused keys are a primary source of localization bugs. Using a single key for "Read" can lead to grammatical errors when the context shifts from a verb ("Read more") to a status ("Message Read").
Collaboration Friction: A chaotic system forces translators to constantly ask developers for clarification, pulling them away from feature development and slowing down the entire localization cycle.
Reduced Scalability: As an application grows, a flat list of keys becomes unmanageable and kills performance. A scalable architecture requires a structured approach from day one to enable optimizations like code-splitting translations.

Investing time to establish a robust strategy is a down payment on future agility, enabling your team to build and scale a global product efficiently.

The Three Philosophies of Key Naming

Three dominant philosophies have emerged for naming keys. The choice between them is a fundamental decision about where to place the burden of complexity in your workflow.

1. Structured (Semantic) Keys: The Path of Order

This is the most robust and widely recommended approach. It involves creating abstract but descriptive identifiers that are decoupled from the source language text.

Example: t('userProfile.labels.firstName'), t('errors.network.timeout')
Pros:
- ✅ High Maintainability: The English source text can be changed without touching the code, preserving all existing translations.
- ✅ Provides Context: A key like checkout.buttons.confirmOrder tells translators its location and purpose.
- ✅ Avoids Collisions: A partial namespacing is built-in, preventing ambiguity. But can also be improved with real namespaces.
Cons:
- ❌ Increased Upfront Effort: It's a "write-it-twice" workflow: create the key in code, then add its value in a JSON file.
- ❌ Reduced In-Code Readability: The code shows t('userProfile.labels.firstName'), not the actual text.

However, this readability drawback is being solved by innovations in the i18next ecosystem. The new Selector API transforms the experience. Instead of a magic string, you use a type-safe function: t($=>$.userProfile.labels.firstName). This enables autocompletion, compile-time checks, and seamless refactoring in TypeScript, turning a historic weakness into a major strength.

2. Natural Language (Content-as-Key): The Path of Convenience

This philosophy prioritizes initial development speed by using the full source language string (typically English) as the key itself.

Example: t('Please enter your email address')
Pros:
- ✅ High In-Code Readability: The code is self-documenting, showing the exact default text.
- ✅ Low Initial Effort: It's the fastest way to start, as there's no need to invent a separate keying system.
Cons:
- ❌ Extremely Brittle: This is the deal-breaker. Fixing a simple typo or rephrasing the text changes the key, breaking the link to all existing translations and forcing costly re-translation.
- ❌ Problematic for Complex Strings: Using paragraphs or strings with HTML as keys is unwieldy and error-prone.
- ❌ Inherent Ambiguity: It can't differentiate between two identical strings that need different translations based on context (e.g., "View" as a noun vs. a verb).

3. Content-Agnostic (Generated) Keys: The Path of Ultimate Decoupling

A less common approach that uses machine-generated identifiers as keys.

Example: t('key_aB38fG1p')
Pros:
- ✅ Guaranteed Uniqueness and Stability: Eliminates human error in naming and ensures the key is never changed.
- ✅ Complete Decoupling: The key is independent of both content and code structure, offering maximum architectural flexibility.
Cons:
- ❌ Zero Human Readability: The keys are meaningless without a sophisticated layer of tooling.
- ❌ Heavy Reliance on Tooling: This approach is only viable with mature tools like IDE extensions that display source text inline and a robust TMS that provides all context to translators.

Ultimately, Structured (Semantic) keys represent the most balanced approach. They place a manageable burden on the developer during initial implementation to reduce systemic friction and cost for all stakeholders over the long term.

The Great Debate: To Reuse or Not to Reuse? 🤔

Developers are trained on the "Don't Repeat Yourself" (DRY) principle, so creating a common.save key seems efficient. However, this is a dangerous trap.

"Creating new messages is cheaper than trying to manage shared messages."

The flaw is that textual identity is not semantic identity. While two strings may be identical in English, their correct translations can vary dramatically depending on context. The unbreakable rule is to adopt the linguist's perspective: the fundamental unit of translation is the message in context.

Dangers of Reuse:

Grammatical Context: "Read" (present-tense verb) and "Read" (past-tense status) require different translations. A single key forces them to be the same.
Domain Context: "Cancel" for a subscription is a significant action; "Cancel" for a dialog box is trivial. The translation should reflect this.
Future Divergence: Two "Back" buttons might be identical today, but next month a PM may want one of them to say "Previous Step." Changing the shared key breaks the other instance.

Your default policy should be: never reuse keys. Each string instance in the UI should have its own unique key. An approach that creates distinct keys like userProfile.buttons.save and documentEditor.buttons.save is vastly superior because they are free to evolve independently.

Building for Scale: Namespaces and Performance

As an application grows, a flat list of keys collapses into chaos. A structured system is essential for scale and performance.

Namespacing: Partition keys into logical groups. The most robust strategy is to namespace by feature or domain (checkout, adminDashboard). This aligns your i18n structure with your application architecture and is resilient to UI refactoring.
Nesting: Use a dot (.) separator to create a hierarchy within namespaces. A nesting depth of 2-3 levels (checkout.paymentForm.submitButton) provides the best balance of organization and simplicity.
Code-Splitting: A key benefit of namespacing is performance. Instead of loading one giant translation file, modern libraries like i18next can load namespaces on demand. When a user navigates to the checkout page, you only fetch the checkout translations, dramatically improving your app's initial load time.

Beyond Plain Text: Mastering Complex Content

Modern UIs are dynamic. Simply concatenating strings is the cardinal sin of i18n—it hardcodes English grammar into your app and is guaranteed to fail in other languages.

ICU Message Format

The industry standard is the ICU (International Components for Unicode) Message Format, which embeds logic directly into your translation string.

Pluralization: Handle complex plural rules for different languages with a single key.

"notifications.unread": "{count, plural, =0 {You have no new messages.} one {You have one new message.} other {You have # new messages.}}"

Gender: Handle gendered language without cluttering your application code.

"user.activity.likedPost": "{gender, select, female {She liked your post.} male {He liked your post.} other {They liked your post.}}"

But seems the simpler i18next format is preferred by most developers and offers interpolation, context, nesting, formatting, pluralization and much more...

Rich Text and HTML

Never embed raw HTML in translations and render it with dangerouslySetInnerHTML. This is a major security risk. The correct solution is component interpolation.

Libraries like react-i18next use a <Trans> component that lets you safely mix text and React components. This maintains a clean separation of concerns, allowing translators to reorder the sentence while you retain full control over the link's behavior in your code.

<Trans i18nKey="terms.agreement">
  Please agree to our <Link to="/terms">Terms of Service</Link>.
</Trans>

Bridging the Context Gap: Empowering Translators for Success

Even with a perfect key naming convention, the single greatest threat to translation quality remains the void of context. Professional translators are linguistic experts, not mind readers. A successful internationalization workflow is not just about extracting strings; it is about exporting context.

The Tooling Revolution: From Guesswork to Certainty

While good naming and comments are essential, the most comprehensive solution lies in a modern Translation Management System (TMS). These platforms are purpose-built to serve as a central hub for your entire localization workflow, with a primary focus on delivering rich context. Key features include in-context editors, screenshot attachments, translation memory, and term bases.

Bringing Context Directly Into the Code

The deepest integrations go a step further, closing the gap between the developer's editor and the translator's tool. For example, the tight bond between i18next and its creator's TMS, locize, enables a workflow that embeds context provision directly into the development process.

Traditionally, a developer would add a key in the code, then add the default value in a JSON file, and then perhaps go to a separate system to add a comment for the translator. Modern integrations streamline this into a single, frictionless action right in the code:

// This single function call defines the key, the default text, AND the context for the translator.
i18next.t(
  'userProfile.buttons.requestExport', // The stable, semantic key
  'Request My Data',                   // The default value for the source language
  { tDescription: 'A button that allows the user to request a GDPR data export. Should have a formal tone.' } // The context for the translator
);

This elegant approach solves multiple problems at once. The developer provides crucial context at the moment of creation, when it's top of mind. The "write-it-twice" friction of structured keys is dramatically reduced, and the translator receives a rich contextual package automatically (i.e. via saveMissing feature). The debate is no longer solely about the key's name but about the entire localization context pipeline, which a modern toolchain can fully automate.

A Unified Strategy: Your Team's Checklist ✅

Synthesizing these principles, here is a recommended framework for modern applications. It is a hybrid approach that champions structured keys as the default, backed by clear conventions and deep integration with your toolchain.

Default to Structured (Semantic) Keys. They offer the best balance of maintainability, scalability, and clarity.
Enforce a "Don't Reuse" Policy. Create a unique key for every unique instance of a string. Make exceptions only for a strictly governed common namespace (e.g., country names, months).
Mandate a Translation Management System (TMS). For any serious project, a TMS like locize is essential infrastructure. It bridges the context gap with features like in-context editors, screenshots, translation memory, and glossaries, making the structured key approach truly powerful.
Integrate Your Toolchain. Use IDE extensions like i18n Ally and modern library features like the i18next Selector API to supercharge your developer experience. Automate hygiene checks in your CI/CD pipeline to find and remove unused keys.

Use this checklist to define and document your team's strategy:

[ ] Casing Convention: camelCase or snake_case? (Be consistent).
[ ] Namespace Strategy: By feature/domain?
[ ] Nesting Depth: Max 2-3 levels?
[ ] Reuse Policy: Unique keys by default?
[ ] common Namespace Governance: What are the explicit, documented rules for adding new keys to it?
[ ] Context Provisioning: How will you provide context to translators? Leverage tight integrations like the i18next-locize backend to allow developers to pass descriptions directly from their code using options like tDescription.
[ ] Complex Content Handling: How will you handle plurals/rich text? (ICU, <Trans>).
[ ] Maintenance Process: How will you audit orphaned keys? (find unused translations).

Taming Stateful at the Edge: A Real-Time API with Cloudflare Durable Objects

Adriano Raiano — Tue, 23 Sep 2025 07:39:00 +0000

Serverless architecture has revolutionized how we build applications, but it comes with a well-known Achilles' heel: managing state. For stateless functions, it’s a dream. But as soon as your application requires real-time collaboration, live presence, or persistent chat, you enter a world of complexity. How do you manage WebSocket connections when your functions are ephemeral?

The traditional workarounds are often complex and costly. You might find yourself managing sticky sessions on load balancers or bolting on a separate stateful service like Redis just to handle pub/sub and connection mapping. This adds significant operational overhead, undermining the core promise of serverless.

At Vaultrice, we faced this exact dilemma. We needed to build a global, low-latency, and strongly-consistent backend for real-time state, without building a traditional, resource-intensive server fleet. This post details the architectural journey we took and how we solved this problem by betting on Cloudflare's cutting-edge stack, with Durable Objects at its core.

The Game Changer: Our Bet on Cloudflare Durable Objects

After evaluating the landscape, we chose Cloudflare Durable Objects (DOs) as the foundation of our architecture. They offered solutions to the most difficult stateful problems:

For Strong Consistency: We needed to guarantee atomic operations for features like live vote counters and collaborative data editing. The single-threaded execution model of a Durable Object instance was the perfect fit. It ensures that all operations for a given data object are processed serially, eliminating the risk of race conditions that plague eventually-consistent systems.
For Cost-Effective, Stateful WebSockets: The biggest challenge in building a real-time service is managing persistent WebSocket connections at scale. The Durable Object WebSocket Hibernation API was the key. This powerful feature allows us to maintain a client's WebSocket connection at the Cloudflare edge while the DO itself hibernates, waking it only when a message arrives. This is fundamental to our ability to offer a generous free tier and an efficient, scalable service making powerful real-time features accessible to projects of any scale.

The Vaultrice Architecture: A High-Level Flyover

Our architecture is designed for simplicity and performance, abstracting the power of the edge into a developer-friendly API.

The flow is straightforward:

The Stateless Entrypoint (Cloudflare Worker): Every request first hits a standard Cloudflare Worker. Its job is purely to handle authentication (verifying API keys or access tokens) and route the request to the correct Durable Object instance.
The Stateful Core (Durable Object): This is where the real work happens. Each Durable Object acts as a self-contained, stateful micro-server for a single data object—like a chat room, a shared document, or a user's settings. It manages the in-memory state, handles WebSockets, and interacts with its private, strongly-consistent transactional storage. All complexity is contained here.
The Simple Abstraction (Our SDK or our React bindings): All of this is hidden behind our simple, localStorage-like SDKs (NonLocalStorage and SyncObject). The developer never interacts with the Durable Object directly; they just call familiar methods like nls.setItem('key', 'value') or doc.title = 'New Title'.

Key Challenges We Abstract Away For You

Building this architecture reliably is non-trivial. The real value of Vaultrice is in the hard problems we've already solved so our users don't have to.

Seamless Reconnection & Presence:

Ensuring a user's presence is accurately reflected across flaky networks and browser tabs is notoriously difficult. We built a robust session management system within our DOs that handles reconnection and state reconciliation automatically, so your "who's online" list is always accurate.

Secure, Multi-Tenant Data Isolation:

Architecting a secure multi-tenant system requires careful data scoping. Our platform maps each customer's data objects to unique Durable Object instances, providing a strong layer of isolation. This is then enhanced by our own security model, with features like Object ID Signature Verification, which cryptographically ensures that even a valid API key can only access authorized data objects.

Concurrency & Data Integrity:

With many users modifying the same data, preventing data corruption is paramount. Instead of forcing developers to build complex locking mechanisms, Vaultrice provides a suite of server-side atomic operations for common mutations like counters, array pushes, and object merges, which are executed safely within the single-threaded context of the DO.

Conclusion: Leverage the Edge, Today

Stateful applications at the edge are the future of the real-time web, but the path to building them from scratch is fraught with complexity. By building Vaultrice on Cloudflare's powerful serverless platform, we've created a "batteries-included" solution that makes this new architecture accessible to any developer.

We handled the hard parts of distributed systems so you can focus on what matters: building amazing user experiences.

See this architecture in action by cloning our React Chat Starter on GitHub.
Deploy your first global, real-time feature in minutes on our generous free tier.

DEV Community: Adriano Raiano

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

Language switcher — detected automatically

Step 3 — Extract: Generate Your Translation Files

Bonus: TypeScript Definitions

Step 4 — Migrate: Push to Locize

Step 5 — Iterate: Adding New Keys

Command reference

Step 6 — Going Further: Dynamic Translation Loading

Step 7 — Power Features: saveMissing and the InContext Editor

saveMissing — Zero-friction key registration

InContext Editor — Edit translations in place

The Full Journey at a Glance

Summary: The Workflow

Finally: A Free Plan for the Official i18next Platform

The "Manual JSON" Struggle is Real

What’s in the Free Plan?

Why this matters for the i18next ecosystem

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

Growing beyond "Hobby" scale?

Let's build together

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

Less Noise, More Clarity

A World-Class Documentation Experience

A Modern App for a Modern Workflow

Why We Changed

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

Supercharge Your GitBook Docs with Live, Real-Time Polls

From Static Pages to Interactive Experiences

Common Use Cases

Getting Started in 3 Simple Steps

A Note on Security

See It in Action: The i18next Documentation

Conclusion

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

The Scenario: A Collaborative "To-Do" List

Stage 1: The Prototype (Security Level 0) 🐣

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

Upgrading Authentication: Secure Access Tokens

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

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

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

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

Conclusion

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

The Goal: A Rich Team Presence Component

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

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

What We Just Did (The Advanced Features Explained)

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

`saveMissing` — Zero-friction key registration