Skip to content

Update dependency react-i18next to v17.1.8 - #4508

Merged
martin-henz merged 1 commit into
masterfrom
renovate/react-i18next-17.x-lockfile
Oct 28, 2026
Merged

martin-henz merged 1 commit into
masterfrom
renovate/react-i18next-17.x-lockfile

Conversation

@renovate

@renovate renovate Bot commented Oct 18, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
react-i18next 17.0.16 → 17.1.8 age confidence

Release Notes

i18next/react-i18next (react-i18next)

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 &amp;#&#8203;169; to get &#&#8203;169;" rendered Write © to get © instead of Write &#&#8203;169; to get ©, and &amp;#&#8203;60; rendered < instead of &#&#8203;60;. This also hit interpolated values with escapeValue: true, where a value containing &#&#8203;60; is escaped to &amp;#&#8203;60;. Escaped named entities like &amp;lt; already stayed &lt;, 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 &nbsp; and &#&#8203;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&nbsp;nás or 10&nbsp;km could wrap across lines, and consecutive &nbsp;s collapsed into one space. This also matches IcuTrans, whose entity decoder already mapped &nbsp; 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.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • 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.

@renovate renovate Bot added the dependencies This pull request updates dependency files label Oct 18, 2026
@coveralls

coveralls commented Oct 18, 2026 •

Copy link
Copy Markdown

Coverage Report for CI Build 40644851332

Coverage remained the same at 47.808%

Details

  • Coverage remained the same as the base build.
  • Patch coverage: No coverable lines changed in this PR.
  • No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 15172
Covered Lines: 7650
Line Coverage: 50.42%
Relevant Branches: 8230
Covered Branches: 3538
Branch Coverage: 42.99%
Branches in Coverage %: Yes
Coverage Strength: 49.74 hits per line

💛 - Coveralls

@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from 204b991 to b834917 Compare October 18, 2026 20:54
@renovate renovate Bot changed the title Update dependency react-i18next to v17.0.17 Update dependency react-i18next to v17.0.18 Oct 18, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch 2 times, most recently from a7083ba to e158b3d Compare October 19, 2026 09:34
@renovate renovate Bot changed the title Update dependency react-i18next to v17.0.18 Update dependency react-i18next to v17.0.19 Oct 19, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch 2 times, most recently from 5d807c0 to e0e7136 Compare October 20, 2026 13:31
@renovate renovate Bot changed the title Update dependency react-i18next to v17.0.19 Update dependency react-i18next to v17.0.21 Oct 20, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from e0e7136 to 43b5a89 Compare October 20, 2026 22:01
@renovate renovate Bot changed the title Update dependency react-i18next to v17.0.21 Update dependency react-i18next to v17.1.0 Oct 20, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch 4 times, most recently from d1d3192 to b70cf86 Compare October 25, 2026 12:57
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.0 Update dependency react-i18next to v17.1.1 Oct 25, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from b70cf86 to b772880 Compare October 25, 2026 16:34
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.1 Update dependency react-i18next to v17.1.2 Oct 25, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from b772880 to a3be188 Compare October 25, 2026 21:52
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.2 Update dependency react-i18next to v17.1.3 Oct 25, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from a3be188 to b466a33 Compare October 26, 2026 15:07
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.3 Update dependency react-i18next to v17.1.4 Oct 26, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from b466a33 to 952a598 Compare October 26, 2026 22:35
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.4 Update dependency react-i18next to v17.1.5 Oct 26, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from 952a598 to 87a2ab4 Compare October 27, 2026 09:56
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.5 Update dependency react-i18next to v17.1.6 Oct 27, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from 87a2ab4 to 25bc22b Compare October 27, 2026 14:24
@renovate renovate Bot changed the title Update dependency react-i18next to v17.1.6 Update dependency react-i18next to v17.1.8 Oct 27, 2026
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from 25bc22b to f095e22 Compare October 27, 2026 15:34
@renovate
renovate Bot force-pushed the renovate/react-i18next-17.x-lockfile branch from f095e22 to f366d0f Compare October 28, 2026 06:36

@martin-henz martin-henz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patch/minor dependency update; CI green.

@martin-henz
martin-henz merged commit 495a747 into master Oct 28, 2026
11 checks passed
@martin-henz
martin-henz deleted the renovate/react-i18next-17.x-lockfile branch October 28, 2026 06:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies This pull request updates dependency files

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants