i18next

i18next is a mature, widely-adopted internationalization (i18n) framework for JavaScript that provides everything needed to translate an application: pluralization, context, nesting, interpolation, and language detection. It runs in the browser, Node.js, Deno, and React Native, and ships with zero runtime dependencies, keeping it lightweight and portable across build targets.

What sets i18next apart is its plugin architecture: translation loading (backends), language detection, formatting, and post-processing are all pluggable via a single .use() API, letting teams swap in HTTP/filesystem backends, browser language detectors, or custom formatters without touching core code. A large companion ecosystem (react-i18next, i18next-http-backend, i18next-browser-languagedetector, and more) builds on this same interface, making it the default choice for internationalizing React, Vue, Angular, and vanilla JS projects alike.

What You Get

• A t() translation function with key nesting, interpolation ({{variable}}), and context/pluralization support out of the box
• A .use() plugin API for backends (HTTP, filesystem, in-memory), language detectors, formatters, and post-processors
• Automatic language and namespace resolution with fallback chains, so missing translations degrade gracefully instead of breaking the UI
• cloneInstance() and getFixedT() for multi-tenant/SSR apps that need isolated or namespace-scoped translator instances per request
• First-class TypeScript definitions (hand-authored .d.ts/.d.mts) covering the full options and API surface, including typed selector-based key lookups

Common Use Cases

• Translating a React, Vue, or Angular single-page app via the matching companion binding (react-i18next, vue-i18next, angular-i18next)
• Server-side rendered apps that need a fresh, request-scoped translator instance (via cloneInstance) to avoid leaking state across requests
• Loading translation JSON over HTTP or from the filesystem via i18next-http-backend / i18next-fs-backend, with lazy per-namespace loading
• Detecting a visitor’s preferred language from the browser, cookies, or query string using i18next-browser-languagedetector
• Applying locale-aware pluralization and number/date formatting through the built-in Formatter and PluralResolver modules

Under The Hood

Architecture The I18n class in src/i18next.js extends a small custom EventEmitter and owns instance lifecycle (init, changeLanguage, cloneInstance). On init() it wires up a set of single-responsibility services — LanguageUtils for locale-code resolution, PluralResolver for CLDR-style plural rules, Interpolator for {{var}}/nesting substitution, Formatter for value formatting, and BackendConnector (src/BackendConnector.js) which queues and dedupes async loads of translation resources per language/namespace pair. A Translator (src/Translator.js, the largest module at 645 lines) is the actual t() implementation: it resolves keys against the in-memory ResourceStore, triggers backend loads for missing namespaces, then pipes the result through interpolation, pluralization, and a registered postProcessor chain (e.g. sprintf-style formatting). Extension points (backend, languageDetector, i18nFormat, formatter, postProcessor, 3rdParty) are all registered through one .use(module) call keyed off a module.type string, which is what lets the ecosystem of companion packages plug into the same core without forking it. Tech Stack The package has zero runtime dependencies — package.json declares only an optional typescript peer dependency for consumers who want type-checking. Source is plain ES modules (no TS at the source level); the public API surface is instead hand-maintained in index.d.ts/index.d.mts (19KB), which is unusual for a package this size and signals deliberate API-surface control. The build pipeline uses Rollup (rollup.config.mjs) to emit CJS, ESM, and UMD bundles, with Babel handling syntax transforms for older test targets. Tests run on Vitest 4.x across three separate workspace configs (runtime, compatibility, typescript), the last of which uses @arktype/attest to assert inferred TypeScript types, not just runtime behavior. Code Quality The test/ directory holds 66 test files spanning interpolation, pluralization, backend concurrency, language detection, selector-based key access, and a dedicated security.test.js. Several non-trivial async races are documented inline with direct references to the originating GitHub issue numbers (e.g. the init/changeLanguage ordering fix referenced at src/i18next.js lines 214-216, and the selector-scoping logic at lines 406-419) — evidence of a codebase that has absorbed a decade of real-world edge cases rather than one written in a vacuum. Naming is consistent and each module (ResourceStore, LanguageUtils, BackendConnector) has a narrow, single responsibility, which keeps the 3,148-line src/ tree easy to navigate despite its age. API Design The .use().use().init({...}) chaining pattern is the standout DX decision: adding a backend and a language detector is two .use() calls before init(), and the same pattern is what every companion package (react-i18next, i18next-http-backend) targets, so the mental model transfers across the whole ecosystem. getFixedT(lng, ns, keyPrefix) gives callers a pre-scoped t function for a given namespace/language without re-passing options on every call, and hasLoadedNamespace() supports Suspense-style loading gates in frameworks like React. The trade-off is that a zero-dependency core means common needs (fetching translations over HTTP, detecting browser language) require pulling in a companion package rather than working out of the box, which adds a small amount of assembly for newcomers relative to a more batteries-included i18n library.