[dependabot]

Bumps the i18n group with 2 updates in the / directory: i18next and react-i18next.

Updates i18next from 26.5.6 to 26.5.11

Release notes

Sourced from i18next's releases.

v26.5.11

• fix: a nested false, 0 or '' 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') and t('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 nested null, which is not a valid lookup by default (returnNull: false), still falls back to the flat key. Thanks @​lprnmns (#2461).

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 with supportedLngs: ['en', 'fil-PH'] a Finnish user (fi-FI) got Filipino instead of the fallback language, and ha (Hausa) picked haw-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, like ar → arz-EG, sw → swh-KE or no → nob-NO; list the two-letter code in supportedLngs (or map it with fallbackLng) 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, toString or map. 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 when ignoreJSONStructure is on (the default): a nested key named like an inherited method that is missing in the current language (t('roles.constructor') with roles.constructor only in the fallback language) returned function Object() { [native code] } instead of falling back, and exists('roles.valueOf') returned true. These keys are now missing, so the fallback language, missingInterpolationHandler, saveMissing and the missing key handler apply as for any other missing key. Getters defined on a class ({{user.fullName}} with get 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 joinArrays now get the same resolved details as strings. The joined value was extended with lastKey in the place of the resolved lookup, so with postProcessPassResolved a post processor got no usedLng, usedNS or exactUsedKey (t('steps', { joinArrays: ' / ' }) reported undefined/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)']) threw Maximum call stack size exceeded. They now stop at the guard, as strings do. An i18nFormat plugin with handleAsObject and parse also no longer throws Cannot 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 the t() options contain a BigInt or a circular object. The cache key was built with JSON.stringify over 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 with cacheInBuiltFormats: false. This also applies to formatters added with addCached. Other calls still use the cache as before. Thanks @​nk-batman21 (#2457).

Changelog

Sourced from i18next's changelog.

26.5.11

• fix: a nested false, 0 or '' 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') and t('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 nested null, which is not a valid lookup by default (returnNull: false), still falls back to the flat key. Thanks @​lprnmns (#2461).

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 with supportedLngs: ['en', 'fil-PH'] a Finnish user (fi-FI) got Filipino instead of the fallback language, and ha (Hausa) picked haw-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, like ar → arz-EG, sw → swh-KE or no → nob-NO; list the two-letter code in supportedLngs (or map it with fallbackLng) 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, toString or map. 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 when ignoreJSONStructure is on (the default): a nested key named like an inherited method that is missing in the current language (t('roles.constructor') with roles.constructor only in the fallback language) returned function Object() { [native code] } instead of falling back, and exists('roles.valueOf') returned true. These keys are now missing, so the fallback language, missingInterpolationHandler, saveMissing and the missing key handler apply as for any other missing key. Getters defined on a class ({{user.fullName}} with get 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 joinArrays now get the same resolved details as strings. The joined value was extended with lastKey in the place of the resolved lookup, so with postProcessPassResolved a post processor got no usedLng, usedNS or exactUsedKey (t('steps', { joinArrays: ' / ' }) reported undefined/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)']) threw Maximum call stack size exceeded. They now stop at the guard, as strings do. An i18nFormat plugin with handleAsObject and parse also no longer throws Cannot 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 the t() options contain a BigInt or a circular object. The cache key was built with JSON.stringify over 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 with cacheInBuiltFormats: false. This also applies to formatters added with addCached. Other calls still use the cache as before. Thanks @​nk-batman21 (#2457).

Commits

• a0ab5e9 26.5.11
• a08cf9e build
• 81677f9 changelog for 26.5.11
• a92934e fix: keep a nested null falling back to a flat key
• ad6e1ac fix: preserve falsy nested resource values (#2461)
• 00b6a3f 26.5.10
• 9bdd4f6 build
• fb168f3 changelog for 26.5.10
• 2584a56 fix: don't match a supported language that only starts with the same letters ...
• 6c98e55 build
• Additional commits viewable in compare view

Updates react-i18next from 17.1.3 to 17.1.9

Changelog

Sourced from react-i18next's changelog.

17.1.9

• fix(useTranslation): namespaces added to or removed from the ns array are now picked up. The hook used the array itself as the useMemo dependency list, and React only compares the entries both lists have in common when its length changes, so going from useTranslation(['nsA']) to useTranslation(['nsA', 'nsB']) kept returning ['nsA']: React warned that the dependency array changed size, nsB was never loaded, and with nsMode: 'fallback' keys only in nsB rendered as the key. Removing a namespace kept the old list the same way. The namespaces are now compared by content, so a growing list loads the new namespace (suspending until it is loaded, as switching from 'nsA' to 'nsB' already does) and t uses it. Lists that keep their length behave as before. Thanks @​lprnmns (#1945).

17.1.8

• fix(Trans): an interpolation variable named format is no longer dropped. Trans reads format in an interpolation object as the formatter name ({{ value, format }}), so with {{ format }} as the only key nothing was left: <Trans>Export as {{ format }}</Trans> warned TRANS_INVALID_OBJ and used the default string Export as instead of Export as {{format}}. When format is the object's only key it is now treated as the variable. {{ value, format }} works as before. Without an i18nKey, the key derived from the children changes accordingly, from Export as to Export as {{format}}. i18next-cli serializes Trans children with react-i18next, so extracting with this version produces the same key. Thanks @​Pharex38 (#1944).

17.1.7

• fix(IcuTrans): each HTML entity in a translation is now decoded exactly once. Named, decimal and hexadecimal entities were decoded in three passes, and each pass decoded the output of the previous one, so an escaped numeric entity was decoded twice: "Write &[#169](https://github.com/i18next/react-i18next/issues/169); to get &[#169](https://github.com/i18next/react-i18next/issues/169);" rendered Write © to get © instead of Write &[#169](https://github.com/i18next/react-i18next/issues/169); to get ©, and &[#60](https://github.com/i18next/react-i18next/issues/60); rendered < instead of &[#60](https://github.com/i18next/react-i18next/issues/60);. This also hit interpolated values with escapeValue: true, where a value containing &[#60](https://github.com/i18next/react-i18next/issues/60); is escaped to &[#60](https://github.com/i18next/react-i18next/issues/60);. Escaped named entities like < already stayed <, as browsers and Trans decode them. Unknown named entities and entities above U+10FFFF still stay as written. Thanks @​Pharex38 (#1943).

17.1.6

• fix(Trans): a count passed in tOptions is now used. Trans spread tOptions and then set its own count prop, so a count only in tOptions was overwritten with undefined: <Trans i18nKey="items" tOptions={{ count: 5 }} /> rendered the key items instead of 5 items, and with children Trans could pick the wrong plural form. Like context, Trans now falls back to tOptions.count, handled the same way as the count prop. A count prop, a count in the children or values.count still take precedence, and tOptions is not modified. Thanks @​nk-batman21 (#1942).

17.1.5

• fix(Trans): with an array of keys and no children, Trans now falls back to the last key when none of them has a translation, as t() does. It used the array itself as defaultValue, which i18next handles as an object, so <Trans i18nKey={['notifications.crm_item_created', 'crm_item_created']} components={[<strong />]} /> rendered key 'crm_item_created (en)' returned an object instead of string. instead of crm_item_created. An array of selectors falls back to the key of the last selector. The first key that has a translation still wins, and children, defaults and tOptions.defaultValue are used as before. With saveMissing, these calls now report the missing key, like a single i18nKey does. Thanks @​nk-batman21 (#1941).

17.1.4

• fix(types): without allowObjectInHTMLChildren, the children of HTML elements now use React's own type (DOMAttributes<T>['children']) instead of the ReactI18NextChildren | Iterable<ReactI18NextChildren> union. Both accept the same children, so nothing compiles differently. For default installs the global HTMLAttributes augmentation now repeats whatever @types/react declares, so changes in React's types flow through instead of meeting a copy, and type errors on element children no longer list an extra Iterable<...>. With allowObjectInHTMLChildren: true nothing changes. First step of #1928.

Commits

• 4f4236d 17.1.9
• e1a6945 build
• 8e9b59e changelog for 17.1.9
• 46564b6 fix: refresh translations when namespaces are added (#1945)
• 3f0880e 17.1.8
• 9802f17 build
• fb5fa17 changelog for 17.1.8
• 63f4e41 fix(Trans): don't drop an interpolation variable named format (#1944)
• 8655c0f 17.1.7
• 5e2cf4a build
• Additional commits viewable in compare view

[komed3]

@dependabot rebase