[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
react-i18next	17.0.15 → 17.1.9

---

Release Notes

i18next/react-i18next (react-i18next)

v17.1.9

Compare Source

• 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).

v17.1.8

Compare Source

• 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).

v17.1.7

Compare Source

• 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; to get &#​169;" rendered Write © to get © instead of Write &#​169; to get ©, and &#​60; rendered < instead of &#​60;. This also hit interpolated values with escapeValue: true, where a value containing &#​60; is escaped to &#​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).

v17.1.6

Compare Source

• 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).

v17.1.5

Compare Source

• 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).

v17.1.4

Compare Source

• 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.

v17.1.3

Compare Source

• fix(IcuTrans): numeric HTML entities above U+FFFF, like emoji, now decode to the right character. "Hello &#x1F44B; <0>friend</0> &#&#8203;127881;" rendered U+F44B and U+F389, private-use glyphs that usually show as a box, instead of 👋 and 🎉: the decoder used String.fromCharCode, which keeps only the low 16 bits of the code point. This shows up with translations that a TMS or CMS exports HTML-encoded. Entities above U+10FFFF, which are no valid code points, now stay as written instead of becoming U+0000. Entities below U+10000, including surrogate pairs written as two entities, decode as before. Thanks @​nk-batman21 (#​1940).

v17.1.2

Compare Source

• fix(Trans): when the only child is a string, a tag whose index the children don't have now renders its own text. <Trans i18nKey="welcome">Welcome</Trans> with "Welcome <1>friend</1>" rendered Welcome e, and defaults="Hi <1>there</1>" with the child Hi rendered Hi i. The fallback for a single object of components ({{ 1: <strong /> }}) looked the tag up on the string and rendered one of its characters. It now applies only when that child is an object, so {{ 1: <strong /> }} renders as before, and the tag falls back to its inner text, as it already did with several children or with a number or an element as the only child. This also stops a single-entry array child holding null ({[null]}, e.g. from a .map that returned null) from throwing Cannot read properties of null. Thanks @​Cayan (#​1939).

v17.1.1

Compare Source

• fix(Trans): with components as an object with index keys, the component for key 0 is now rendered. components={{ 0: <a href={path} /> }} with "You're eligible. <0>Get started here.</0>" rendered the text without the link, a self-closing <0/> rendered nothing, and in <0>a <1>b</1></0> both elements were lost, while keys 1 and up and the array form worked. The object was passed on as the indexed children, so <0> resolved to the object itself. It is now looked up by key, like a named components map. This also fixes an array components next to react.transDefaultProps.components, which the merge turns into such an object ({ Bold, 0, 1 }) and so lost its first entry, and a self-closing named tag in a mixed object ({ 0: <a />, Bold: <b /> } with <Bold/>), which rendered as the text <Bold />. Arrays, named maps and index objects starting at 1 render as before. Thanks @​nk-batman21 (#​1938).

v17.1.0

Compare Source

• feat(types): with i18next's new parseInterpolation: 'icu' (or 'mf2') type option (i18next v26.5.0), the values of IcuTrans and IcuTransWithoutContext are typed from the message of i18nKey, like the options of t(): a misspelled argument, a value of the wrong type or a value meant for another key is a type error. values was Record<string, any> before, and still is with any other parseInterpolation setting. values stays optional, as on Trans. useTranslation's t and Trans values get the checks from i18next's types without changes here.
• fix(types): IcuTrans and IcuTransWithoutContext now infer the literal i18nKey (const type parameter, as Trans does), so props that depend on the key are checked against that key instead of all keys of the namespace.

v17.0.21

Compare Source

• fix(IcuTrans): explicit values now win over interpolation.defaultVariables, as they do in t(). IcuTrans merged them the other way round, so <IcuTrans values={{ user: 'John Doe' }} /> rendered the configured default variable user instead of John Doe. Trans had the same inverted merge and is fixed too. Compatibility note: only names that are set both in values and in defaultVariables render differently.
• feat: new entry point react-i18next/IcuTransWithoutContext (with types) for React Server Components. Importing IcuTransWithoutContext from react-i18next in a Server Component could fail the build with createContext is not a function, because the main entry creates the React context when it is loaded. Like react-i18next/TransWithoutContext, the new entry point does not.
• fix(build): the ESM build's dist/es/package.json now declares "sideEffects": false, like the root package.json already did. Bundlers use the nearest package.json, so the ESM build counted as having side effects and unused exports were kept: an app that only uses Trans still bundled IcuTrans with its HTML entity decoder, useTranslation and use-sync-external-store. With esbuild, a Trans-only bundle (React and i18next external) goes from 20.9 KB to 11.6 KB minified, 8.3 KB to 5.0 KB gzipped.
• docs: the icu.macro Babel macro is now marked as deprecated in favour of using IcuTrans directly. It fails on Babel 8 (t.jSXIdentifier is not a function), <Plural count={count}> renders the raw ICU message, and a React key on <Plural>/<Select> becomes an ICU case. It keeps working on Babel 7 and is not removed. The IcuTrans docs page has a corrected example and props table and covers Server Components.

v17.0.20

Compare Source

• fix: useTranslation no longer suspends when a missing namespace is loaded by a synchronous backend. With useSuspense (the default), a namespace that wasn't in the store yet always made the component throw the loading promise, even when the backend had already delivered the resources while that promise was being created. React then showed the Suspense fallback and rendered again right away, which appears as a fallback flash (a white flash in React Native) and costs performance. The hook now starts the load first, checks the store again and only suspends if the namespace is still missing. This helps every backend that calls back synchronously, for example i18next-resources-to-backend with a static resources object or a loader that returns the data directly. Async backends, and an instance that isn't initialized yet, still suspend as before. Thanks @​oblador (#​1937).

v17.0.19

Compare Source

• fix: useTranslation with an inline selector keyPrefix (useTranslation('ns', { keyPrefix: ($) => $.role })) returned a new t on every render, so every effect, useCallback and useMemo depending on t ran again each time. The cached t was compared against the keyPrefix function itself, and an inline arrow is a new function on every render. It is now compared against the key the selector resolves to (with the same options and namespace list getFixedT resolves it with), so t keeps its identity as long as the resolved prefix does, just like a string keyPrefix. A selector that resolves to a different key still gets a new t, and i18next still resolves the selector on each t call as before. Fixes #​1936.
• fix: useTranslation kept returning the previous t when only the namespace (useTranslation('a') → useTranslation('b')) or only the i18n instance (another instance with the same language, via props or I18nextProvider) changed on a mounted component. That t kept resolving against the old namespace or instance until something else (the language, the ready state, a bound i18n event) produced a new one. Both are now part of the check that decides whether the cached t can be reused.

v17.0.18

Compare Source

• fix(Trans): with shouldUnescape, the default unescape now turns   and &#​160; into a no-break space (U+00A0) instead of a regular space (U+0020). The regular space dropped what the entity is for: u nás or 10 km could wrap across lines, and consecutive  s collapsed into one space. This also matches IcuTrans, whose entity decoder already mapped   to U+00A0. Compatibility note: only affects shouldUnescape; snapshots or exact textContent comparisons of such text now contain U+00A0 (Testing Library's default normalizer still matches it as a space). A custom react.unescape function can restore the old mapping for text nodes. Thanks @​lprnmns (#​1935).

v17.0.17

Compare Source

• perf: useTranslation no longer unsubscribes and resubscribes its i18n listeners on every render. The subscribe callback handed to useSyncExternalStore depended on the merged options object, which is rebuilt whenever props is a new object: with no options (the {} default), with options passed inline (useTranslation('ns', { keyPrefix })), and through withTranslation and <Translation>. A new subscribe makes React resubscribe, so each render of each caller ran i18n.off and i18n.on in an extra effect. It now depends only on the instance and the bindI18n/bindI18nStore event names. No updates were ever missed, because React re-checks the snapshot after resubscribing; this only removes the churn, which adds up with many mounted components that re-render often. Reported via next-i18next#2349.

v17.0.16

Compare Source

• fix(Trans): a selector i18nKey that points into a secondary namespace of useTranslation now resolves the same way t() does. With const { t } = useTranslation(['ns1', 'ns2']), t($ => $.ns2.message) works since 17.0.7, but <Trans t={t} i18nKey={$ => $.ns2.message} /> rendered the raw key (or its children). Trans always passed an ns option to t, filled from t.ns (the primary namespace only), and an explicit ns makes i18next's fixed t skip the hook's full namespace list (scopeNs). When Trans or TransWithoutContext gets a t that carries its own namespace and no ns prop, it now leaves ns out and lets that t apply its own. String keys, keyPrefix, nsMode: 'fallback', an explicit ns prop and Trans without a t prop behave as before. Compatibility note: if the primary namespace has a nested object named like a secondary namespace (ns1 → ns2.message), Trans now resolves $ => $.ns2.message to ns2:message, as t() already does. Fixes #​1933.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • Between 12:00 AM and 03:59 AM, only on Monday (* 0-3 * * 1)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud