i18next

Frameworks & LibrariesMIT

i18next release notes.

Latest v26.4.2 · by i18nextWritten in JavaScriptWebsitei18next/i18nextRSS

Release activity

Release activity — 13 releases across 13 days since May 7, 2026. Each cell is one day; darker means more releases that day. Nothing is recorded before May 7, 2026. Older weeks are hidden at this screen width.
JunJulAugSep
SundayNo releases on May 24, 2026No releases on May 31, 2026No releases on Jun 7, 2026No releases on Jun 14, 2026No releases on Jun 21, 2026No releases on Jun 28, 2026No releases on Jul 5, 2026No releases on Jul 12, 2026No releases on Jul 19, 2026No releases on Jul 26, 2026No releases on Aug 2, 2026No releases on Aug 9, 2026No releases on Aug 16, 2026No releases on Aug 23, 2026No releases on Aug 30, 2026No releases on Sep 6, 2026
MondayNo releases on May 25, 2026No releases on Jun 1, 2026No releases on Jun 8, 2026No releases on Jun 15, 2026No releases on Jun 22, 2026No releases on Jun 29, 2026No releases on Jul 6, 2026No releases on Jul 13, 2026No releases on Jul 20, 2026No releases on Jul 27, 2026No releases on Aug 3, 2026No releases on Aug 10, 2026No releases on Aug 17, 2026No releases on Aug 24, 2026No releases on Aug 31, 2026
Tuesday1 release on May 26, 2026No releases on Jun 2, 2026No releases on Jun 9, 2026No releases on Jun 16, 2026No releases on Jun 23, 20261 release on Jun 30, 2026No releases on Jul 7, 2026No releases on Jul 14, 2026No releases on Jul 21, 2026No releases on Jul 28, 2026No releases on Aug 4, 2026No releases on Aug 11, 2026No releases on Aug 18, 2026No releases on Aug 25, 20261 release on Sep 1, 2026
WednesdayNo releases on May 27, 20261 release on Jun 3, 2026No releases on Jun 10, 2026No releases on Jun 17, 20261 release on Jun 24, 2026No releases on Jul 1, 20261 release on Jul 8, 2026No releases on Jul 15, 2026No releases on Jul 22, 2026No releases on Jul 29, 2026No releases on Aug 5, 2026No releases on Aug 12, 2026No releases on Aug 19, 2026No releases on Aug 26, 2026No releases on Sep 2, 2026
ThursdayNo releases on May 28, 2026No releases on Jun 4, 2026No releases on Jun 11, 2026No releases on Jun 18, 2026No releases on Jun 25, 2026No releases on Jul 2, 20261 release on Jul 9, 2026No releases on Jul 16, 2026No releases on Jul 23, 2026No releases on Jul 30, 2026No releases on Aug 6, 2026No releases on Aug 13, 20261 release on Aug 20, 2026No releases on Aug 27, 20261 release on Sep 3, 2026
FridayNo releases on May 29, 2026No releases on Jun 5, 2026No releases on Jun 12, 2026No releases on Jun 19, 20261 release on Jun 26, 2026No releases on Jul 3, 2026No releases on Jul 10, 2026No releases on Jul 17, 2026No releases on Jul 24, 2026No releases on Jul 31, 2026No releases on Aug 7, 2026No releases on Aug 14, 2026No releases on Aug 21, 2026No releases on Aug 28, 2026No releases on Sep 4, 2026
SaturdayNo releases on May 30, 2026No releases on Jun 6, 2026No releases on Jun 13, 2026No releases on Jun 20, 2026No releases on Jun 27, 2026No releases on Jul 4, 2026No releases on Jul 11, 2026No releases on Jul 18, 2026No releases on Jul 25, 2026No releases on Aug 1, 2026No releases on Aug 8, 2026No releases on Aug 15, 2026No releases on Aug 22, 2026No releases on Aug 29, 2026No releases on Sep 5, 2026

13 releases since May 7, 2026

Changelog

v26.4.2

Latest
Fixed 1
  • Special replacement sequences like $&, $`, $', and $$ inside nested values now stay literal instead of being interpreted as replacement patterns

From i18next

  • fix: $&, $`, $' and $$ inside a nested value ($t(key)) now stay literal. nest() handed the resolved value straight to String.replace as the replacement argument, so those sequences were read as replacement patterns: $& re-inserted the $t(...) match, $` / $' inserted the text before / after it, and $$ collapsed to $. Through t() the $& case was worse than a wrong string: the nested lookup resets the shared nesting regexp, so the re-inserted $t(...) was matched again on every pass and t() never returned — also under the default escapeValue: true when the value arrives via a variable forwarded through nesting options ($t(key, { "name": "{{name}}" }) with a name containing $&). The value is now $-escaped at the String.replace call, the same guard interpolate() already has, and a non-string value returned by a formatter in the nesting chain ($t(key, myFormat)) is stringified before that. Nested values are still not HTML-escaped (#854). Thanks @mahirhir (#2447).
View originalPermalink
How v26.4.2 went

v26.4.1

Fixed 1
  • the selector-form keyPrefix overload of getFixedT() is now available under enableSelector: 'strict'

From i18next

  • fix(types): the selector-form keyPrefix overload of getFixedT() is now available under enableSelector: 'strict'. Its constraint was gated on true | 'optimize' only, so under 'strict' it collapsed to never, the overload dropped out, and the returned t silently lost its keyPrefix scope (t(($) => $.deep) failed with Property 'deep' does not exist on type '{}'). The same call already typechecked under true and 'optimize'. Thanks @hovelopin (#2446).
View originalPermalink
How v26.4.1 went

v26.4.0

Changed 4
  • Cache `toResolveHierarchy` results per `(code, fallbackCode)` pair to reduce per-call overhead from ~886 ns to ~41 ns in render-heavy UIs
  • Invalidate the hierarchy cache automatically when `options.fallbackLng` changes through reassignment or in-place array mutation
  • Require calling `i18next.services.languageUtils.clearCache()` manually after runtime mutations of resolution-relevant options (`load`, `lowerCaseLng`, `cleanCode`, `nonExplicitSupportedLngs`)
  • Update all devDependencies and replace `sinon` with `nise` + `vitest.spyOn` in v1 compatibility tests

From i18next

  • perf: cache toResolveHierarchy results per (code, fallbackCode) pair. The hierarchy resolver runs on every t() call and calls Intl.getCanonicalLocales multiple times, which showed up prominently when profiling render-heavy UIs (e.g. virtualized data grids); with the cache the per-call cost drops from ~886 ns to ~41 ns. The cache is invalidated automatically when options.fallbackLng changes (reassignment or in-place array mutation); if you mutate other resolution-relevant options at runtime (load, lowerCaseLng, cleanCode, nonExplicitSupportedLngs), call i18next.services.languageUtils.clearCache() afterwards. Function-valued fallbackLng and per-call array/object fallbackLng options are never cached, so dynamic fallbacks keep working as before. Thanks @equaterina (#2444).
  • chore: update all devDependencies (Babel stays on 7.x until @rollup/plugin-babel supports 8, eslint on 9.x for neostandard). Removed the unused coveralls package (CI uses the Coveralls GitHub Action) and replaced sinon with nise + vitest.spyOn in the v1 compatibility tests, which resolves all open npm audit findings (0 vulnerabilities) and should close the dependabot alerts on the lockfile.
View originalPermalink
How v26.4.0 went

v26.3.6

Fixed 1
  • Allow TypeScript 7 in the optional typescript peer dependency range to resolve npm install peer conflict errors

From i18next

  • fix: allow TypeScript 7 in the optional typescript peer dependency range (^5 || ^6 || ^7). With typescript@7.0.2 in a project, npm install failed with an ERESOLVE peer conflict. The published types are TS7-compatible as-is: every test/typescript suite produces identical results under 6.0 and 7.0.2. Reported in react-i18next#1927, thanks @andikapradanaarif.
View originalPermalink
How v26.3.6 went

v26.3.5

Fixed 3
  • Nesting options blocks that span multiple lines are now parsed correctly by adding the dotAll flag to the nesting regexp
  • getUsedParamsDetails no longer mutates the passed replace object and no longer carries stale count values across multiple t() calls
  • Placeholder escaping with skipOnVariables: true and escapeValue: true now correctly prevents interpolation of placeholders within interpolated values containing escapable characters

From i18next

  • fix: $t() nesting options blocks that span multiple lines are now parsed. nest() decided where the nested key ends by testing match[1] with /{.*}/, whose dot does not cross line breaks — so a $t(key, { ... }) options object containing a newline was treated as having no options, mis-split as formatters, and the nested lookup ran without its options (placeholders stayed unresolved). The nesting regexp itself already matches newlines inside $t(...); adding the s (dotAll) flag makes multiline options behave like the single-line form. Thanks @spokodev (#2440).
  • fix: getUsedParamsDetails (the returnDetails: true path) no longer mutates the passed replace object. It wrote count straight onto options.replace so the returned usedParams would include it — a caller reusing one replace object across t() calls then carried a stale count into later interpolations (e.g. a previous call's count: 5 rendered instead of the current call's value). The details are now built from a copy; usedParams still includes count. Thanks @spokodev (#2441).
  • fix: with the default skipOnVariables: true + escapeValue: true, a {{placeholder}} carried inside an interpolated value now stays literal even when the value contains escapable characters. The skip logic advanced the regex lastIndex by the raw value length, but the escaped text written into the string is longer, so lastIndex landed inside the inserted value and a trailing {{placeholder}} in it got interpolated — leaking another in-scope variable that should have stayed literal (values without escapable characters were already skipped correctly). The advance now uses the escaped length that is actually written, and the regex-safe $-doubling is applied only at the String.replace call so it can't distort the length arithmetic. Thanks @spokodev (#2442).
View originalPermalink
How v26.3.5 went

v26.3.4

Security 1
  • deepExtend (used by addResourceBundle with deep and overwrite) no longer recurses into inherited properties by checking key existence with Object.prototype.hasOwnProperty.call instead of the in operator, preventing prototype pollution that could corrupt shared built-in properties when overwriting with attacker-controlled data

From i18next

  • fix(security): deepExtend (used by addResourceBundle(..., deep, overwrite)) no longer recurses into inherited properties. It checked key existence with the in operator, which walks the prototype chain, so a source key matching an inherited built-in (e.g. hasOwnProperty, toString) caused recursion into the shared Object.prototype function and, with overwrite: true, could overwrite e.g. Object.prototype.hasOwnProperty.call with a non-callable value — corrupting a shared built-in process-wide (DoS). Existence is now checked with Object.prototype.hasOwnProperty.call, so such keys are copied as plain own data instead. This complements the existing __proto__/constructor guard and is also strictly more correct for an own-property merge. Only affects applications that pass attacker-controlled data with deep: true and overwrite: true; no standard backend/integration does this. Distinct from CVE-2026-48713 / CVE-2026-48714 (different packages, setPath mechanism). Thanks to zx (Jace) for the responsible disclosure.
View originalPermalink
How v26.3.4 went

v26.3.3

Fixed 1
  • selector `t($ => $.arr, { returnObjects: true, context })` on a JSON array of heterogeneous objects now preserves each element's full shape instead of collapsing to a union of partial element types

From i18next

  • fix(types): selector t($ => $.arr, { returnObjects: true, context }) on a JSON array of heterogeneous objects now preserves each element's full shape (e.g. { transKey1: string; transKey2: string }[]) instead of collapsing to a union of partial element types. Two type-level causes: (1) FilterKeys evaluated the whole array element type at once, so keyof (A | B) only saw the keys common to every element — it now distributes over the object union and filters each element independently; (2) when TypeScript merges mismatched array element types it injects phantom optional undefined keys (e.g. transKey1_withContext?: undefined on elements that don't define it), which the context-detection helpers mistook for real context variants — they now skip keys typed as undefined. Also adds a dedicated context + returnObjects: true selector overload using const Fn + ReturnType<Fn>, so Target is no longer collapsed to unknown via ApplyTarget. Resolves Problem 1 of #2398 (Problem 2 was already fixed on master). Thanks @sauravgupta-dotcom (#2438). Fixes #2398.
View originalPermalink
How v26.3.3 went

v26.3.2

Fixed 1
  • Chained formatters with a parenthesized option that contains the format separator now work at any position in the chain, not just first

From i18next

  • fix: chained formatters with a parenthesised option that contains the format separator (e.g. join(separator: ', ')) now work at any position in the chain, not just first. Previously the comma-in-parens reassembly only repaired formats[0], so {{v, uppercase, join(separator: ', ')}} split the join(...) option on the inner comma and never rejoined it, producing corrupt output. Replaced the first-position-only repair with a position-independent pass that re-joins fragments until each open paren closes. Thanks @spokodev (#2437).
View originalPermalink
How v26.3.2 went

v26.3.1

Fixed 1
  • t() with a keyPrefix no longer pollutes its return type with sibling keys' values by restoring eager conditional type resolution in KeysBuilderWithReturnObjects and KeysBuilderWithoutReturnObjects

From i18next

  • fix(types): t() with a keyPrefix no longer pollutes its return type with sibling keys' values. A regression in 26.3.0 — the [Res] extends [never] guards added to KeysBuilderWithReturnObjects / KeysBuilderWithoutReturnObjects turned the builders into deferred conditional types, so KeyPrefix<Ns> stopped resolving to a literal union and keyPrefix inference widened to the whole namespace. Symptom: useTranslation(ns, { keyPrefix: 'a.b' }) then t('title') would resolve to '<a.b>.title' | '<other.path>.title' | ... instead of just the scoped value. Affected every react-i18next user using keyPrefix. Restored to the eager 26.2.0 form. The same-namespace conflict handling from #2434 still works via _DropConflictKeys at the merge layer (in options.d.ts). Thanks @aaronrosenthal (#2436).
View originalPermalink
How v26.3.1 went

v26.3.0

Added 1
  • Introduce ResourceNamespaceMap as a separate mergeable augmentation surface for namespace resource types in monorepos, allowing multiple packages to contribute their own namespaces independently via declare module 'i18next' blocks without coordination conflicts

From i18next

  • feat(types): introduce ResourceNamespaceMap — a separate mergeable augmentation surface for namespace resource types, designed for monorepos where multiple packages each want to contribute their own namespaces. Previously, every package had to coordinate on a single CustomTypeOptions.resources declaration (or fall back to typing dependency namespaces as any) because resources is a single property of an interface and TypeScript reports TS2717 when two declarations of the same property disagree. The new interface merges naturally across declare module 'i18next' blocks, so each package can ship its own i18next.d.ts independently. Per-property merge handles same-namespace contributions from multiple packages, and same-key/different-literal conflicts are silently dropped to avoid poisoning t() overload resolution. Fully backwards-compatible — existing CustomTypeOptions.resources augmentations continue to work, and both surfaces can coexist. Scalar options (defaultNS, returnNull, enableSelector, etc.) still belong on CustomTypeOptions. Thanks @sh3xu (#2434). Fixes #2409.
View originalPermalink
How v26.3.0 went

v26.2.0

Added 1
  • Add new `parseInterpolation` TypeOption (default `true`) to customize type-level extraction of translation strings, allowing `i18next-icu` users to disable parsing of `{{variable}}` patterns
Fixed 1
  • Expose `enableSelector` on `InitOptions` to allow `i18next.init({ enableSelector: 'strict' })` to typecheck without module augmentation

From i18next

  • feat(types): new parseInterpolation TypeOption (default true). When set to false in CustomTypeOptions, the type-level extractor stops parsing translation strings for {{variable}} patterns. Required by i18next-icu users — the default extractor mistakes ICU MessageFormat nested-brace plurals like {count, plural, one {{count} row} other {{count} rows}} for an interpolation block and demands a phantom variable name. The flag is type-only; runtime interpolation is governed by InterpolationOptions and is unaffected. Fixes i18next-icu#85.
  • fix(types): expose enableSelector on InitOptions so i18next.init({ enableSelector: 'strict' }) typechecks without a module augmentation. The runtime already reads opts?.enableSelector from init options; this lands the matching type declaration next to the other selector-resolution knobs. Accepts false | true | 'optimize' | 'strict'. Thanks @Faithfinder (#2431)
View originalPermalink
How v26.2.0 went

v26.1.0

Added 1
  • Add enableSelector: 'strict' mode as a TypeOptions and runtime option that exposes every namespace uniformly under its own key on $ and rewrites leading selector path segments matching the scope's namespace list as namespace prefixes
Fixed 1
  • Eliminate silent-miss surface area where t($ => $.primary.foo) typechecks but doesn't resolve at runtime

From i18next

  • feat: enableSelector: 'strict' (TypeOptions + runtime option). Opt-in mode that drops the flattened-primary form from NsResource at the type level — every namespace (primary included) is exposed only under its own key on $, uniformly across single- and multi-ns hooks. At runtime, a leading selector path segment matching the scope's namespace list is always rewritten as a namespace prefix, including the primary. Eliminates the silent-miss surface area where t($ => $.primary.foo) typechecks but doesn't resolve under the default mode (see #2429). Backward-compatible: default enableSelector: false | true | 'optimize' behavior is unchanged. Note: strict mode is incompatible with the #2405 pattern (keys whose names match sibling namespaces) — those users should stay on default mode.
View originalPermalink
How v26.1.0 went

v26.0.10

Added 1
  • getFixedT accepts a fourth optional fixedOpts argument carrying scopeNs, the full namespace list the bound t was created for
Fixed 1
  • Selector API now detects when a path's first segment is a namespace prefix without changing resolution scope, allowing t($ => $.secondaryNs.foo) selectors to route correctly under useTranslation([nsA, nsB])

From i18next

  • feat: getFixedT accepts a fourth optional fixedOpts argument carrying scopeNs — the full namespace list the bound t was created for. The selector API uses scopeNs to detect when a path's first segment is a namespace prefix, without changing resolution scope. Resolution still uses the bound ns (a single primary string in the typical react-i18next setup), so plain t('key') lookups stay isolated to the primary namespace exactly as before — only t($ => $.secondaryNs.foo) selectors now route correctly under useTranslation([nsA, nsB]). Fixes the runtime side of #2429 for the react-i18next default-nsMode case. The 4th argument is opt-in: existing 3-arg getFixedT(lng, ns, keyPrefix) callers see no behavior change.
View originalPermalink
How v26.0.10 went

More in Frameworks & Libraries

View all
React

The library for web and native user interfaces.

Meta
vue

This is the repo for Vue 2. For Vue 3, go to https://github.com/vuejs/core

vuejs
Vue

The progressive JavaScript framework for building user interfaces.

Vue.js
bootstrap

The most popular HTML, CSS, and JavaScript framework for developing responsive, mobile first projects on the web.

twbs
react-native

react-native release notes.

Meta
D3

Bring data to life with SVG, Canvas and HTML.

Observable

Discussion

If you publish i18next, you can claim this product by proving you administer its repository.