Update dependency i18next to v26 #554
Loading…
Reference in a new issue
No description provided.
Delete branch "renovate/i18next-26.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
^25.3.2→^26.0.0Release Notes
i18next/i18next (i18next)
v26.5.11Compare Source
false,0or''is now returned when a flat key with the same dotted name also exists. With{ a: { b: false }, 'a.b': 'flat' },getResource('en', 'translation', 'a.b')andt('a.b')returned'flat': the nested result was checked for truthiness, so these present values fell through to the flat-key lookup. Without such a flat key they were already returned. A nestednull, which is not a valid lookup by default (returnNull: false), still falls back to the flat key. Thanks @lprnmns (#2461).v26.5.10Compare Source
supportedLngs, the best match no longer picks a different language whose code only starts with the same letters. The last fuzzy check took any supported code starting with the language part, so withsupportedLngs: ['en', 'fil-PH']a Finnish user (fi-FI) got Filipino instead of the fallback language, andha(Hausa) pickedhaw-US(Hawaiian). Other regions of the same language still match as before (de-CH→de-DE,pt-PT→pt-BR,fil→fil-PH). Compatibility note: a two-letter code no longer matches a supported three-letter code that extends it, likear→arz-EG,sw→swh-KEorno→nob-NO; list the two-letter code insupportedLngs(or map it withfallbackLng) if you relied on that. Thanks @Pharex38 (#2460).v26.5.9Compare Source
constructor,toStringormap. Only the top level was guarded, so{{constructor}}was treated as missing, but{{user.constructor}}rendered the function source (with a class instance, the full source code of the class), and{{user.toString}},{{items.map}}or a class method like{{user.greet}}did the same. The same lookup is used for translation keys whenignoreJSONStructureis on (the default): a nested key named like an inherited method that is missing in the current language (t('roles.constructor')withroles.constructoronly in the fallback language) returnedfunction Object() { [native code] }instead of falling back, andexists('roles.valueOf')returnedtrue. These keys are now missing, so the fallback language,missingInterpolationHandler,saveMissingand the missing key handler apply as for any other missing key. Getters defined on a class ({{user.fullName}}withget fullName()) still work. Nested lookups also no longer walk into the prototype via__proto__, so{{user.__proto__.constructor}}no longer prints the class source either. Thanks @Pharex38 (#2459).v26.5.8Compare Source
joinArraysnow get the same resolved details as strings. The joined value was extended withlastKeyin the place of the resolved lookup, so withpostProcessPassResolveda post processor got nousedLng,usedNSorexactUsedKey(t('steps', { joinArrays: ' / ' })reportedundefined/undefined:undefined). This affected the subliminal post processor used by the locize InContext editor, which could not map a joined array to its key. The nesting recursion guard did not get the parent key either, so arrays that nest each other (listA: ['a', '$t(listB)'],listB: ['b', '$t(listA)']) threwMaximum call stack size exceeded. They now stop at the guard, as strings do. Ani18nFormatplugin withhandleAsObjectandparsealso no longer throwsCannot read properties of undefined (reading 'usedNS')on joined arrays. Thanks @nk-batman21 (#2458).v26.5.7Compare Source
cacheInBuiltFormats: true, built-in formats now also work when thet()options contain a BigInt or a circular object. The cache key was built withJSON.stringifyover all options, including the interpolation values, which throws on those, so every built-in format in that call returned the raw value:t('num', { val: 12345678901234567890n })with'Total: {{val, number}}'returned'Total: 12345678901234567890'instead of'Total: 12,345,678,901,234,567,890', and passing an object with a back-reference (like an ORM entity) left all numbers, dates and lists of that call unformatted. When the key cannot be built, the value is now formatted without the cache, as withcacheInBuiltFormats: false. This also applies to formatters added withaddCached. Other calls still use the cache as before. Thanks @nk-batman21 (#2457).v26.5.6Compare Source
cloneInstance({ forkResourceStore: true })now copies the resources at every level. It copied them only down to the namespace objects, so nested keys and arrays stayed shared with the original instance:addResource()with a nested key (fork.addResource('en', 'translation', 'greeting.hello', 'Hi')) or a deepaddResourceBundle()on the fork also changed the original instance and every other fork. Flat keys were already isolated. Forking a large store takes a bit longer: with 300k keys in nested groups, about 11 ms instead of 3 ms per fork. Clones withoutforkResourceStorestill share the store as before. Thanks @nk-batman21 (#2456, follow-up to #2270).v26.5.5Compare Source
skipOnVariables: true, a{{placeholder}}inside a value inserted with an unescaped{{- var}}now stays literal, as it already did for{{var}}. The escape pass ran after the unescaped values were written and scanned them again, sot('{{- a}}', { a: '{{b}}', b: 'c' })returned'c'instead of'{{b}}'. With pre-built HTML that carries user text, liket('You may contact {{name}} at {{- emailHTML}}.', { name, emailHTML }), that text could pull another variable of the samet()call into the output. Results withskipOnVariables: false, and values without placeholders, are unchanged. Compatibility note: a{{- var}}value whose placeholders were meant to be filled from the samet()call now keeps them literally;skipOnVariables: falserestores the old behavior. Thanks @nk-batman21 (#2455, reported in #1595).v26.5.4Compare Source
skipOnVariables: true, a{{placeholder}}inside an interpolated value now stays literal also when the same placeholder appears later in the translation. Each value was written withString.replace, which replaces the first copy of the placeholder text, and that could be the copy inside an earlier value:t('{{name}} has {{count}} items', { name: '{{count}}', count: 5 })returned'5 has {{count}} items'instead of'{{count}} has 5 items'. The value is now written at the position of the matched placeholder. Results withskipOnVariables: falseare unchanged. Thanks @nk-batman21 (#2454, reported in #1595).useRawValueToEscape: true, a non-string value in an unescaped{{- var}}placeholder or withescapeValue: falseno longer throwsval.replace is not a function; it is converted to a string like any other value.v26.5.3Compare Source
countalso when the call passes an explicitns.t(($) => $.item)already failed withoutcount, butt(($) => $.item, { ns: 'items' })compiled, although at runtime it looks upiteminstead ofitem_one/item_otherand returns the key. It now fails the same way, also withordinal: true,defaultValue, annsarray, a key prefix andi18n.t. Calls withcount,context,returnObjects: trueand arrays of selectors, as well as return types, are unchanged. Thanks @nyarthan (#2452).v26.5.2Compare Source
t()call with a missing, misspelled or wrongly typed option now reports that option again (Property 'album' is missing,Type 'string' is not assignable to type 'number'), as TypeScript 5 and 6 do. TypeScript 7 elaborated the error against the default-value signature instead and ended in'{ count: 3; albm: "Summer"; }' is not assignable to type 'string': on a failed call TypeScript explains the last of the equally matching signatures, and TypeScript 7 sorts the 3-element[key, defaultValue, options?]last. It is now written as two signatures,[key, defaultValue]and[key, defaultValue, options]. This affects the default key checks with i18next{{name}}messages as well asparseInterpolation: 'icu'and'mf2'. Which calls compile, their return types and the error positions are unchanged on TypeScript 5.9, 6 and 7.v26.5.1Compare Source
false,0or''is now returned when a flat key with the same dotted name also exists. With{ a: { b: false }, 'a.b': 'flat' },getResource('en', 'translation', 'a.b')andt('a.b')returned'flat': the nested result was checked for truthiness, so these present values fell through to the flat-key lookup. Without such a flat key they were already returned. A nestednull, which is not a valid lookup by default (returnNull: false), still falls back to the flat key. Thanks @lprnmns (#2461).v26.5.0Compare Source
parseInterpolation: 'icu'andparseInterpolation: 'mf2'typet()options from the message's ICU MessageFormat arguments (i18next-icu) or MessageFormat 2 variables (i18next-mf2), so ICU and MF2 users no longer needparseInterpolation: falseand lose argument checking. Missing, misspelled and wrongly typed arguments fail, and so does leaving out the options for a message with arguments (t('greeting')); that error names the missing arguments. Opt-in, defaulttrueis unchanged.{name}takesstring | number,{n, number},pluralandselectordinaltakenumber,{d, date}and{t, time}takeDate,selecttakes its case keys or any string (forother), and arguments nested in cases are required too.#and tags are not arguments, apostrophe quoting is read like intl-messageformat does.{$name}takesstring | number, a variable annotated with:number,:integer,:currency,:percentor:unit(inline or through.input/.local) takesnumber,:datetime,:dateand:timetakeDate,:stringtakesstring, option and markup variables (minimumFractionDigits=$digits,{#link href=$url}) are required too,.localvariables are not arguments, and|quoted literals|and\{escapes are skipped.interpolationFormatTypeMapoverrides a type by ICU format or MF2 function name, e.g.date: Date | numberor a customuppercase: string.t(),getFixedT(),i18n.t, key prefixes, namespaces, the selector API and react-i18next'sTransvalues. Messages need literal types, as the resources file from i18next-cli'stypescommand has them.false(TypeScript 6), 0.5s instead of 0.26s with TypeScript 7. Messages that no call uses cost nothing.Property 'name' is missing) instead of'{ nmae: string }' is not assignable to type 'string'from the default-value overload.v26.4.7Compare Source
cloneInstance()no longer inheritspreload.loadResources()adds everypreloadlanguage to each load, and clones copiedpreloadfrom the parent, so a clone'sinit()and everychangeLanguage()walked all preloaded languages × all namespaces throughqueueLoad()/hasResourceBundle(), although the parent had already loaded them into the shared store. With i18next-http-middleware (one clone +changeLanguage()per request), 25 preloaded languages and 20 namespaces, that was most of the per-request CPU: the reproduction from the issue went from ~90 µs to ~10 µs per request, the same as with a single language. A clone now only loads what it uses itself: itschangeLanguage()no longer waits for parent preload languages that are still loading (the parent's owninit()still does), andclone.loadNamespaces()loads the new namespace for the clone's language and fallbacks instead of every preloaded language.clone.loadLanguages()works as before, the parent instance is unchanged, and passingpreloadtocloneInstance()keeps the old behavior. Thanks @theMostCuriousHomunculus for the detailed report (#2451).v26.4.6Compare Source
toResolveHierarchy()checked the rawfallbackLngvalue against the list, but the list holds formatted codes, so any fallback written differently from its formatted form slipped through:lng: 'de-CH'withfallbackLng: 'de-ch'gavelanguages['de-CH', 'de', 'de-CH'], and the same happened withfallbackLng: 'EN'+cleanCode,lowerCaseLng, and Intl aliases (iw-IL→he-IL). Missing keys were looked up in the same language twice. Only exact duplicates are removed; the order is unchanged. Thanks @lprnmns (#2450).v26.4.5Compare Source
hasLoadedNamespace(ns, { lng })no longer staysfalseforever when the passed inlngis loaded under another code, or not at all. It checked the load state of the rawlng, butloadLanguages()stores a language under its resolved code (de-ch→de-CH,de-CH→dewithload: 'languageOnly') and skips alngoutsidesupportedLngsentirely (only the fallback gets loaded), so that state never got set. react-i18next'suseTranslation(ns, { lng })then never became ready: withuseSuspenseit kept throwing an already resolved promise and React retried forever (100% CPU, SSR never finished), without it the load effect re-rendered in a loop. It now checks the code the language is actually loaded under, and for alngoutsidesupportedLngsonly waits for the fallback, which is also whatt()resolves to. Calls withoutlngand theprecheck(react-i18next'sbindI18n: 'languageChanging') are unchanged (react-i18next#1934).v26.4.4Compare Source
$t(. Its repeated group had overlapping alternatives ([^()"']+inside(?:...)*?, and inside parentheses[^()]also matched quotes), so a string containing$t(without a closing)made the engine try every way to split the text: about 2x the runtime per extra character, and a ~25 character value hungt()for minutes. With the default config this was reachable through any interpolated value (t('greet', { name: '$t(aaaaaaaaaaaaaaaaaaaaaaaa' })): escaping does not touch$,tor(, and theskipOnVariablescheck runs the regexp on the interpolated result, sonest: falsedid not help either. Every alternative now starts with a different character (plain char,",'or(), so there is only one way to match and the cost is linear. Quoted strings and one level of parentheses in nesting options keep working (#2336). The only difference: a lone"or'inside unquoted parentheses within$t(...)is no longer matched. Affects 25.3.3 to 26.4.3. See advisory GHSA-5jr9-983r-c8x4, CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Thanks to Anisetti Chaitanya Eshwar Prasad for the responsible disclosure.nest()now resolves$t(...)in a single pass and no longer nests text that came out of a resolved value. Every nested lookup reset the shared nesting regexp, so the loop started over from the beginning of the string after each match. That had two effects. First, a$t(...)inside a variable that the nested lookup deliberately kept literal (defaultskipOnVariables: true) was resolved anyway by the outer loop: withouter: 'A $t(inner) B'andinner: 'Hi {{name}}',t('outer', { name: '$t(secret)' })rendered thesecrettranslation. It now staysA Hi $t(secret) B, the same as without the outer nesting; withskipOnVariables: falseit is still resolved. Second, the cost was quadratic when an unclosed$t(preceded many nestings, which matters when an app passes untrusted input as the key itself (t(userInput)): 20,000 nestings took ~1.4 s, now ~25 ms. The resolved value is now sliced into the result instead of going throughString.replace, so$&,$`,$'and$$stay literal as before (26.4.2).v26.4.3Compare Source
ResourceStore.hasLanguageSomeTranslations()no longer enumerates every key of a large bundle on each call. It ranObject.keys()on the whole bundle just to learn whether it had at least one key, andinit()/changeLanguage()reach it three times per instance (once while picking the language, twice viasetResolvedLanguage()). With large flat bundles and one i18next instance per SSR request reusing the same resources, that showed up as measurable CPU work before anyt()call. Bundle objects already found non-empty are now remembered in aWeakSetshared across instances, so later checks are O(1): 2,000 inits with a 6,800-key bundle went from ~750 ms to ~20 ms, the same as a one-key bundle. Only the non-empty result is cached. No API removes single keys from a bundle, so a non-empty bundle stays non-empty, and empty bundles are re-checked every time, so keys added later (backend loads,addResource,addResourceBundle, direct or silent changes) count right away. The only edge case: a bundle emptied by hand withdeleteon every key while it is still in the store keeps counting as having translations; useremoveResourceBundle()for that. Thanks @dmchoi77 for the detailed report (#2449).v26.4.2Compare Source
$&,$`,$'and$$inside a nested value ($t(key)) now stay literal.nest()handed the resolved value straight toString.replaceas 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$. Throught()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 andt()never returned — also under the defaultescapeValue: truewhen the value arrives via a variable forwarded through nesting options ($t(key, { "name": "{{name}}" })with a name containing$&). The value is now$-escaped at theString.replacecall, the same guardinterpolate()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).v26.4.1Compare Source
keyPrefixoverload ofgetFixedT()is now available underenableSelector: 'strict'. Its constraint was gated ontrue | 'optimize'only, so under'strict'it collapsed tonever, the overload dropped out, and the returnedtsilently lost itskeyPrefixscope (t(($) => $.deep)failed withProperty 'deep' does not exist on type '{}'). The same call already typechecked undertrueand'optimize'. Thanks @hovelopin (#2446).v26.4.0Compare Source
toResolveHierarchyresults per(code, fallbackCode)pair. The hierarchy resolver runs on everyt()call and callsIntl.getCanonicalLocalesmultiple 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 whenoptions.fallbackLngchanges (reassignment or in-place array mutation); if you mutate other resolution-relevant options at runtime (load,lowerCaseLng,cleanCode,nonExplicitSupportedLngs), calli18next.services.languageUtils.clearCache()afterwards. Function-valuedfallbackLngand per-call array/objectfallbackLngoptions are never cached, so dynamic fallbacks keep working as before. Thanks @equaterina (#2444).@rollup/plugin-babelsupports 8, eslint on 9.x for neostandard). Removed the unusedcoverallspackage (CI uses the Coveralls GitHub Action) and replacedsinonwithnise+vitest.spyOnin the v1 compatibility tests, which resolves all opennpm auditfindings (0 vulnerabilities) and should close the dependabot alerts on the lockfile.v26.3.6Compare Source
typescriptpeer dependency range (^5 || ^6 || ^7). Withtypescript@7.0.2in a project,npm installfailed with anERESOLVEpeer conflict. The published types are TS7-compatible as-is: everytest/typescriptsuite produces identical results under 6.0 and 7.0.2. Reported in react-i18next#1927, thanks @andikapradanaarif.v26.3.5Compare Source
$t()nesting options blocks that span multiple lines are now parsed.nest()decided where the nested key ends by testingmatch[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 thes(dotAll) flag makes multiline options behave like the single-line form. Thanks @spokodev (#2440).getUsedParamsDetails(thereturnDetails: truepath) no longer mutates the passedreplaceobject. It wrotecountstraight ontooptions.replaceso the returnedusedParamswould include it — a caller reusing onereplaceobject acrosst()calls then carried a stalecountinto later interpolations (e.g. a previous call'scount: 5rendered instead of the current call's value). The details are now built from a copy;usedParamsstill includescount. Thanks @spokodev (#2441).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 regexlastIndexby the raw value length, but the escaped text written into the string is longer, solastIndexlanded 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 theString.replacecall so it can't distort the length arithmetic. Thanks @spokodev (#2442).v26.3.4Compare Source
deepExtend(used byaddResourceBundle(..., deep, overwrite)) no longer recurses into inherited properties. It checked key existence with theinoperator, which walks the prototype chain, so a source key matching an inherited built-in (e.g.hasOwnProperty,toString) caused recursion into the sharedObject.prototypefunction and, withoverwrite: true, could overwrite e.g.Object.prototype.hasOwnProperty.callwith a non-callable value — corrupting a shared built-in process-wide (DoS). Existence is now checked withObject.prototype.hasOwnProperty.call, so such keys are copied as plain own data instead. This complements the existing__proto__/constructorguard and is also strictly more correct for an own-property merge. Only affects applications that pass attacker-controlled data withdeep: trueandoverwrite: true; no standard backend/integration does this. Distinct from CVE-2026-48713 / CVE-2026-48714 (different packages,setPathmechanism). See advisory GHSA-6jcc-5g8w-32mx, CVSS 5.9 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H). Thanks to zx (Jace) @manus-use for the responsible disclosure.v26.3.3Compare Source
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)FilterKeysevaluated the whole array element type at once, sokeyof (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 optionalundefinedkeys (e.g.transKey1_withContext?: undefinedon elements that don't define it), which the context-detection helpers mistook for real context variants — they now skip keys typed asundefined. Also adds a dedicatedcontext+returnObjects: trueselector overload usingconst Fn+ReturnType<Fn>, soTargetis no longer collapsed tounknownviaApplyTarget. Resolves Problem 1 of #2398 (Problem 2 was already fixed on master). Thanks @sauravgupta-dotcom (#2438). Fixes #2398.v26.3.2Compare Source
join(separator: ', ')) now work at any position in the chain, not just first. Previously the comma-in-parens reassembly only repairedformats[0], so{{v, uppercase, join(separator: ', ')}}split thejoin(...)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).v26.3.1Compare Source
t()with akeyPrefixno longer pollutes its return type with sibling keys' values. A regression in 26.3.0 — the[Res] extends [never]guards added toKeysBuilderWithReturnObjects/KeysBuilderWithoutReturnObjectsturned the builders into deferred conditional types, soKeyPrefix<Ns>stopped resolving to a literal union andkeyPrefixinference widened to the whole namespace. Symptom:useTranslation(ns, { keyPrefix: 'a.b' })thent('title')would resolve to'<a.b>.title' | '<other.path>.title' | ...instead of just the scoped value. Affected everyreact-i18nextuser usingkeyPrefix. Restored to the eager 26.2.0 form. The same-namespace conflict handling from #2434 still works via_DropConflictKeysat the merge layer (inoptions.d.ts). Thanks @aaronrosenthal (#2436).v26.3.0Compare Source
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 singleCustomTypeOptions.resourcesdeclaration (or fall back to typing dependency namespaces asany) becauseresourcesis a single property of an interface and TypeScript reports TS2717 when two declarations of the same property disagree. The new interface merges naturally acrossdeclare module 'i18next'blocks, so each package can ship its owni18next.d.tsindependently. Per-property merge handles same-namespace contributions from multiple packages, and same-key/different-literal conflicts are silently dropped to avoid poisoningt()overload resolution. Fully backwards-compatible — existingCustomTypeOptions.resourcesaugmentations continue to work, and both surfaces can coexist. Scalar options (defaultNS,returnNull,enableSelector, etc.) still belong onCustomTypeOptions. Thanks @sh3xu (#2434). Fixes #2409.v26.2.0Compare Source
parseInterpolationTypeOption (defaulttrue). When set tofalseinCustomTypeOptions, the type-level extractor stops parsing translation strings for{{variable}}patterns. Required byi18next-icuusers — 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 byInterpolationOptionsand is unaffected. Fixes i18next-icu#85.enableSelectoronInitOptionssoi18next.init({ enableSelector: 'strict' })typechecks without a module augmentation. The runtime already readsopts?.enableSelectorfrom init options; this lands the matching type declaration next to the other selector-resolution knobs. Acceptsfalse | true | 'optimize' | 'strict'. Thanks @Faithfinder (#2431)v26.1.0Compare Source
enableSelector: 'strict'(TypeOptions + runtime option). Opt-in mode that drops the flattened-primary form fromNsResourceat 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 wheret($ => $.primary.foo)typechecks but doesn't resolve under the default mode (see #2429). Backward-compatible: defaultenableSelector: 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.v26.0.10Compare Source
getFixedTaccepts a fourth optionalfixedOptsargument carryingscopeNs— the full namespace list the boundtwas created for. The selector API usesscopeNsto detect when a path's first segment is a namespace prefix, without changing resolution scope. Resolution still uses the boundns(a single primary string in the typical react-i18next setup), so plaint('key')lookups stay isolated to the primary namespace exactly as before — onlyt($ => $.secondaryNs.foo)selectors now route correctly underuseTranslation([nsA, nsB]). Fixes the runtime side of #2429 for thereact-i18nextdefault-nsModecase. The 4th argument is opt-in: existing 3-arggetFixedT(lng, ns, keyPrefix)callers see no behavior change.v26.0.9Compare Source
string | number(wasstring). i18next stringifies values at runtime, so requiring callers to wrap numbers inString(...)for plain{{var}}placeholders was unnecessary friction — and could mask the real problem when a non-string value was passed alongside multiple interpolation slots (thet()overload resolution would fall through to the 3-arg form and report a confusing "not assignable to string" error against the options object). Typed format specifiers like{{x, number}},{{x, currency}},{{x, datetime}}, etc. keep their precise types; this only relaxes the no-format default. Thecountvariable remainsnumber-onlyv26.0.8Compare Source
ExistsFunctionshape so plain arrow functions can again be assigned toExistsFunction-typed variables (TypeScript cannot infer type predicates through multi-overload assignment). Directi18next.exists(key)calls still narrowkeytoSelectorKey— the predicate is now declared inline oni18n.exists. Custom wrappers that want the narrowing can type themselves astypeof i18next.exists2425v26.0.7Compare Source
missingKeydebug log now shows the actual plural-resolved key (e.g.foo.bar_manyfor Polishcount: 14) instead of the base key — making it obvious which plural category was expected and missing 2423@babel/runtimeruntime dependency. The build no longer generates any@babel/runtimeimports, so the package is unused by consumers. Rollup now usesbabelHelpers: 'bundled'so any helpers that are ever needed in the future will be inlined rather than imported externally 2424dist/esm/i18next.bundled.js. It was byte-identical todist/esm/i18next.jsbecause no helpers were being imported 2424v26.0.6Compare Source
Security release — all issues found via an internal audit.
escapeValue: falsewith interpolated variables inside a$t(key, { ... "{{var}}" ... })nesting-options block. In that narrow combination, attacker-controlled string values containing"can break out of the JSON options literal and inject additional nesting options (e.g. redirectlng/ns). The defaultescapeValue: trueconfiguration is unaffected because HTML-escaping neutralises the quote beforeJSON.parse. See the security note in the Nesting docs for the full pattern and mitigationsregexEscapetounescapePrefix/unescapeSuffixon par with the other interpolation delimiters. Prevents ReDoS (catastrophic-backtracking) when a misconfigured delimiter contains regex metacharacters, and fixes silent breakage of the{{- var}}syntax when the delimiter contains characters like(,[,..env*and*.pem/*.keyfiles in.gitignorev26.0.5Compare Source
cloneInstance().changeLanguage()no longer fails to update language state when the target language is not yet loaded — a race betweeninit()'s deferredload()and the user'schangeLanguage()could overwriteisLanguageChangingTo, causingsetLngPropsto be skipped 2422v26.0.4Compare Source
{{price, currency(EUR)}}are now correctly resolved to their base format type (e.g.numberforcurrency) instead of falling back tostring2378v26.0.3Compare Source
addResourceBundlenow accepts an optional 6thoptionsparameter ({ silent?: boolean; skipCopy?: boolean }) matching the runtime API 2419v26.0.2Compare Source
t("key", {} as TOptions)no longer produces a type error — the context constraint now bypasses strict checking whencontextisunknown(e.g. fromTOptions) 2418v26.0.1Compare Source
getFixedTaccepts a fourth optionalfixedOptsargument carryingscopeNs— the full namespace list the boundtwas created for. The selector API usesscopeNsto detect when a path's first segment is a namespace prefix, without changing resolution scope. Resolution still uses the boundns(a single primary string in the typical react-i18next setup), so plaint('key')lookups stay isolated to the primary namespace exactly as before — onlyt($ => $.secondaryNs.foo)selectors now route correctly underuseTranslation([nsA, nsB]). Fixes the runtime side of #2429 for thereact-i18nextdefault-nsModecase. The 4th argument is opt-in: existing 3-arggetFixedT(lng, ns, keyPrefix)callers see no behavior change.v26.0.0Compare Source
This is a major breaking release:
Breaking Changes
initImmediateoption — the backward-compatibility mapping frominitImmediatetoinitAsync(introduced in v24) has been removed. UseinitAsyncinstead.interpolation.formatfunction — the old monolithic format function (interpolation: { format: (value, format, lng) => ... }) is no longer supported. The built-in Formatter (or a custom Formatter module via.use()) is now always used. Migrate to the new formatting approach usingi18next.services.formatter.add()or.addCached()for custom formatters.showSupportNoticeoption and all related internal suppression logic (globalThis.__i18next_supportNoticeShown,I18NEXT_NO_SUPPORT_NOTICEenv var). See our blog post for the full story.simplifyPluralSuffixoption — this option was unused by the core PluralResolver (which relies entirely onIntl.PluralRules). It only had an effect in the old v1/v2/v3 compatibility layer. The v4 test compatibility layer now defaults totrueinternally.@babel/polyfillfrom devDependencies.Improvements
indexOf() > -1/indexOf() < 0with.includes()(~40+ occurrences)indexOf() === 0with.startsWith()where appropriatevarwithconst,'' + objectwithString(object),.substring()with.slice().apply(observer, [event, ...args])with direct callobserver(event, ...args).call(this, ...)in BackendConnector retry logicarray-callback-returnin LanguageUtilsgetBestMatchFromCodeseslint-disablecomments from source filesonce()method for one-time event subscriptionscheckedLoadedForcache to Translator instance, preventing cross-instance state leakageBackendModulegeneric parameter naming inconsistency between CJS and ESM type definitionsonce()method toi18nandResourceStoretype interfacestest.projectsconfigConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.
33012ba899d67935b94fView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.