Sourced from i18next's releases.
v26.5.10
- fix: when none of the detected languages is in
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.9
- fix: nested lookups no longer resolve to methods inherited from the prototype, like
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.8
- fix: arrays returned with
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.7
- fix: with the default
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).
Sourced from i18next's changelog.
26.5.10
- fix: when none of the detected languages is in
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).26.5.9
- fix: nested lookups no longer resolve to methods inherited from the prototype, like
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).26.5.8
- fix: arrays returned with
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).26.5.7
- fix: with the default
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).
00b6a3f
26.5.109bdd4f6
buildfb168f3
changelog for 26.5.102584a56
fix: don't match a supported language that only starts with the same
letters ...6c98e55
build3465ae4
26.5.95888c16
changelog for 26.5.9db036c8
fix: don't walk into the prototype via proto in nested
lookups0815882
fix: don't interpolate inherited methods like constructor from nested
values ...45ae264
26.5.8