chore(deps): bump react-i18next from 15.7.4 to 17.0.11

[dependabot]

Bumps react-i18next from 15.7.4 to 17.0.11.

Changelog

Sourced from react-i18next's changelog.

17.0.11

• chore: html-parse-stringify updated to ^4.0.1. The parser powering <Trans> is now actively maintained under the i18next org (i18next/html-parse-stringify) after years without upstream releases. 4.x brings modern dual ESM/CJS packaging with an exports map, zero runtime dependencies, reworked TypeScript types and a long list of parser fixes (literal < in text, multiline/CRLF attribute values, comments containing >, doctype handling, quote-aware bracket handling).
• refactor(Trans): the internal escapeLiteralLessThan scanner (~80 lines) is replaced by the parser's new allowedTags option with identical semantics: only numbered tags, kept basic HTML tags and known component names are parsed as markup, any other tag-shaped sequence in the translation stays literal text. Rendered output is unchanged (all 493 tests pass, including the #1880 and #1893 escaping cases).

17.0.10

• fix(warnings): the useTranslation and Trans "You will need to pass in an i18next instance" warnings now match the useSSR wording, mentioning the props/context alternatives and the most common unexplained cause at scale: duplicate react-i18next copies in monorepo setups. The Trans variant also referenced the internal i18nextReactModule name; it now points to the public initReactI18next API.
• feat(warnings): development-only warning (SUSPENDED_WHILE_LOADING, logged once) right before useTranslation suspends while translations are loading. With the default useSuspense: true and no <Suspense> boundary this previously surfaced as a blank screen or a cryptic React error; the warning now names both fixes (add a <Suspense> boundary or set react.useSuspense: false). No-op in production builds; the process.env.NODE_ENV check is wrapped so runtimes without a process global (raw ESM in the browser, some edge runtimes) stay silent instead of throwing.
• ci: weekly workflow typechecking the test suite against @types/react@next / @types/react-dom@next, so the next React major's type changes (like the React 18 TFunctionResult/children wave) surface before user reports.

17.0.9

• fix: allow TypeScript 7 in the optional typescript peer dependency range (^5 || ^6 || ^7). With typescript@7.0.2 in a project, npm install failed with an ERESOLVE peer conflict. Fixes #1927, thanks @​andikapradanaarif.
• fix(types): <Trans t={t} ns="ns" …> with a t from useTranslation(['ns']) now typechecks under TypeScript 7. TS7 intersects the Ns inference candidates coming from the t prop (readonly ['ns']) and the ns prop ('ns') into an unsatisfiable 'ns' & readonly ['ns'], where TS6 resolved them. The ns prop on TransProps, TransSelectorProps and IcuTransWithoutContextProps now also accepts a single namespace out of an array-typed Ns (Ns | (Ns extends readonly (infer S extends string)[] ? S : never)) — which matches runtime behavior and is unchanged under TS5/TS6.

17.0.8

• fix(types): <Trans i18nKey={$ => ...}> now typechecks under enableSelector: 'strict'. The Trans component's conditional type was gated on _EnableSelector extends true | 'optimize', excluding 'strict' and falling back to the legacy string-key signature. Runtime was already correct (it calls keyFromSelector(i18nKey) whenever typeof i18nKey === 'function'); this is a type-only fix that widens the conditional to include 'strict'. Thanks @​Faithfinder (#1921)

17.0.7

• feat: useTranslation([nsA, nsB, ...]) now passes its full namespace list to getFixedT via the new scopeNs opt (requires i18next ≥ v26.0.10). This makes selector calls with a secondary-namespace prefix resolve correctly under default nsMode: t($ => $.nsB.foo) previously missed silently because the bound ns was the primary string only and i18next's selector rewrite needed an array. Resolution semantics are unchanged — plain t('key') lookups still stay isolated to the primary namespace by default; use nsMode: 'fallback' to opt into multi-ns fallback resolution as before. Fixes i18next#2429 for useTranslation-based callers.

17.0.6

• fix: restore the v17 nodesToString output format consumed by i18next-cli's extractor while still rendering 1919 correctly
  • 17.0.5 fixed 1919 by changing what nodesToString produced, which inadvertently changed the extracted translation strings for keep-tags wrapping non-keep React elements
  • The fix now lives in the renderer: indexed <N> placeholders nested inside a keep-tag are scoped to that tag's own original React children (matching kept tags by name and positional occurrence at each level), so the translation string format produced by nodesToString is unchanged

17.0.5

• fix: <Trans /> no longer breaks child rendering when a kept HTML node (transKeepBasicHtmlNodesFor) wraps a non-keep React element 1919 — superseded by 17.0.6, which keeps the same runtime fix without changing the nodesToString output

17.0.4

• fix: avoid React does not recognize the 'i18nIsDynamicList' prop on a DOM element warning 1915

17.0.3

• fix: avoid invalid prop on React.Fragment inside <Trans /> 1914

17.0.2

• fix(types): values prop on <Trans /> now only requires interpolation variables for the specific i18nKey, not all variables in the namespace 1913

17.0.1

• chore: bump minimum i18next peer dependency to >= 26.0.1 (forgot to do it in last version)
• fix: migrate test setup from removed legacy interpolation.format to i18n.services.formatter.add() (i18next v26)

... (truncated)

Commits

• 274e2e6 17.0.11
• 3c4c563 build
• 1e7ccae chore: html-parse-stringify ^4.0.1 + 17.0.11 changelog
• 4412e25 html-parse-stringify ^4.0.0: replace escapeLiteralLessThan with the parser's ...
• 5787979 ci: types-compat falls back to latest when no @​types/react pre-release tag ex...
• 3b71c27 17.0.10
• 57c3500 build
• c62476f chore: sync package-lock with i18next ^26.2.0 devDependency bump
• 0126bd1 improve instance warnings (monorepo hint) + dev-only suspense warning + weekl...
• 8b4a9ea 17.0.9
• Additional commits viewable in compare view