chore(deps): Bump i18next from 26.5.6 to 26.5.10 (#2272)

Bumps [i18next](https://github.com/i18next/i18next) from 26.5.6 to
26.5.10.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/i18next/i18next/releases">i18next's
releases</a>.</em></p>
<blockquote>
<h2>v26.5.10</h2>
<ul>
<li>fix: when none of the detected languages is in
<code>supportedLngs</code>, 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
<code>supportedLngs: ['en', 'fil-PH']</code> a Finnish user
(<code>fi-FI</code>) got Filipino instead of the fallback language, and
<code>ha</code> (Hausa) picked <code>haw-US</code> (Hawaiian). Other
regions of the same language still match as before (<code>de-CH</code> →
<code>de-DE</code>, <code>pt-PT</code> → <code>pt-BR</code>,
<code>fil</code> → <code>fil-PH</code>). Compatibility note: a
two-letter code no longer matches a supported three-letter code that
extends it, like <code>ar</code> → <code>arz-EG</code>, <code>sw</code>
→ <code>swh-KE</code> or <code>no</code> → <code>nob-NO</code>; list the
two-letter code in <code>supportedLngs</code> (or map it with
<code>fallbackLng</code>) if you relied on that. Thanks <a
href="https://github.com/Pharex38"><code>@​Pharex38</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2460">#2460</a>).</li>
</ul>
<h2>v26.5.9</h2>
<ul>
<li>fix: nested lookups no longer resolve to methods inherited from the
prototype, like <code>constructor</code>, <code>toString</code> or
<code>map</code>. Only the top level was guarded, so
<code>{{constructor}}</code> was treated as missing, but
<code>{{user.constructor}}</code> rendered the function source (with a
class instance, the full source code of the class), and
<code>{{user.toString}}</code>, <code>{{items.map}}</code> or a class
method like <code>{{user.greet}}</code> did the same. The same lookup is
used for translation keys when <code>ignoreJSONStructure</code> is on
(the default): a nested key named like an inherited method that is
missing in the current language (<code>t('roles.constructor')</code>
with <code>roles.constructor</code> only in the fallback language)
returned <code>function Object() { [native code] }</code> instead of
falling back, and <code>exists('roles.valueOf')</code> returned
<code>true</code>. These keys are now missing, so the fallback language,
<code>missingInterpolationHandler</code>, <code>saveMissing</code> and
the missing key handler apply as for any other missing key. Getters
defined on a class (<code>{{user.fullName}}</code> with <code>get
fullName()</code>) still work. Nested lookups also no longer walk into
the prototype via <code>__proto__</code>, so
<code>{{user.__proto__.constructor}}</code> no longer prints the class
source either. Thanks <a
href="https://github.com/Pharex38"><code>@​Pharex38</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2459">#2459</a>).</li>
</ul>
<h2>v26.5.8</h2>
<ul>
<li>fix: arrays returned with <code>joinArrays</code> now get the same
resolved details as strings. The joined value was extended with
<code>lastKey</code> in the place of the resolved lookup, so with
<code>postProcessPassResolved</code> a post processor got no
<code>usedLng</code>, <code>usedNS</code> or <code>exactUsedKey</code>
(<code>t('steps', { joinArrays: ' / ' })</code> reported
<code>undefined/undefined:undefined</code>). 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
(<code>listA: ['a', '$t(listB)']</code>, <code>listB: ['b',
'$t(listA)']</code>) threw <code>Maximum call stack size
exceeded</code>. They now stop at the guard, as strings do. An
<code>i18nFormat</code> plugin with <code>handleAsObject</code> and
<code>parse</code> also no longer throws <code>Cannot read properties of
undefined (reading 'usedNS')</code> on joined arrays. Thanks <a
href="https://github.com/nk-batman21"><code>@​nk-batman21</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2458">#2458</a>).</li>
</ul>
<h2>v26.5.7</h2>
<ul>
<li>fix: with the default <code>cacheInBuiltFormats: true</code>,
built-in formats now also work when the <code>t()</code> options contain
a BigInt or a circular object. The cache key was built with
<code>JSON.stringify</code> over all options, including the
interpolation values, which throws on those, so every built-in format in
that call returned the raw value: <code>t('num', { val:
12345678901234567890n })</code> with <code>'Total: {{val,
number}}'</code> returned <code>'Total: 12345678901234567890'</code>
instead of <code>'Total: 12,345,678,901,234,567,890'</code>, 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
<code>cacheInBuiltFormats: false</code>. This also applies to formatters
added with <code>addCached</code>. Other calls still use the cache as
before. Thanks <a
href="https://github.com/nk-batman21"><code>@​nk-batman21</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2457">#2457</a>).</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/i18next/i18next/blob/master/CHANGELOG.md">i18next's
changelog</a>.</em></p>
<blockquote>
<h2>26.5.10</h2>
<ul>
<li>fix: when none of the detected languages is in
<code>supportedLngs</code>, 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
<code>supportedLngs: ['en', 'fil-PH']</code> a Finnish user
(<code>fi-FI</code>) got Filipino instead of the fallback language, and
<code>ha</code> (Hausa) picked <code>haw-US</code> (Hawaiian). Other
regions of the same language still match as before (<code>de-CH</code> →
<code>de-DE</code>, <code>pt-PT</code> → <code>pt-BR</code>,
<code>fil</code> → <code>fil-PH</code>). Compatibility note: a
two-letter code no longer matches a supported three-letter code that
extends it, like <code>ar</code> → <code>arz-EG</code>, <code>sw</code>
→ <code>swh-KE</code> or <code>no</code> → <code>nob-NO</code>; list the
two-letter code in <code>supportedLngs</code> (or map it with
<code>fallbackLng</code>) if you relied on that. Thanks <a
href="https://github.com/Pharex38"><code>@​Pharex38</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2460">#2460</a>).</li>
</ul>
<h2>26.5.9</h2>
<ul>
<li>fix: nested lookups no longer resolve to methods inherited from the
prototype, like <code>constructor</code>, <code>toString</code> or
<code>map</code>. Only the top level was guarded, so
<code>{{constructor}}</code> was treated as missing, but
<code>{{user.constructor}}</code> rendered the function source (with a
class instance, the full source code of the class), and
<code>{{user.toString}}</code>, <code>{{items.map}}</code> or a class
method like <code>{{user.greet}}</code> did the same. The same lookup is
used for translation keys when <code>ignoreJSONStructure</code> is on
(the default): a nested key named like an inherited method that is
missing in the current language (<code>t('roles.constructor')</code>
with <code>roles.constructor</code> only in the fallback language)
returned <code>function Object() { [native code] }</code> instead of
falling back, and <code>exists('roles.valueOf')</code> returned
<code>true</code>. These keys are now missing, so the fallback language,
<code>missingInterpolationHandler</code>, <code>saveMissing</code> and
the missing key handler apply as for any other missing key. Getters
defined on a class (<code>{{user.fullName}}</code> with <code>get
fullName()</code>) still work. Nested lookups also no longer walk into
the prototype via <code>__proto__</code>, so
<code>{{user.__proto__.constructor}}</code> no longer prints the class
source either. Thanks <a
href="https://github.com/Pharex38"><code>@​Pharex38</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2459">#2459</a>).</li>
</ul>
<h2>26.5.8</h2>
<ul>
<li>fix: arrays returned with <code>joinArrays</code> now get the same
resolved details as strings. The joined value was extended with
<code>lastKey</code> in the place of the resolved lookup, so with
<code>postProcessPassResolved</code> a post processor got no
<code>usedLng</code>, <code>usedNS</code> or <code>exactUsedKey</code>
(<code>t('steps', { joinArrays: ' / ' })</code> reported
<code>undefined/undefined:undefined</code>). 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
(<code>listA: ['a', '$t(listB)']</code>, <code>listB: ['b',
'$t(listA)']</code>) threw <code>Maximum call stack size
exceeded</code>. They now stop at the guard, as strings do. An
<code>i18nFormat</code> plugin with <code>handleAsObject</code> and
<code>parse</code> also no longer throws <code>Cannot read properties of
undefined (reading 'usedNS')</code> on joined arrays. Thanks <a
href="https://github.com/nk-batman21"><code>@​nk-batman21</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2458">#2458</a>).</li>
</ul>
<h2>26.5.7</h2>
<ul>
<li>fix: with the default <code>cacheInBuiltFormats: true</code>,
built-in formats now also work when the <code>t()</code> options contain
a BigInt or a circular object. The cache key was built with
<code>JSON.stringify</code> over all options, including the
interpolation values, which throws on those, so every built-in format in
that call returned the raw value: <code>t('num', { val:
12345678901234567890n })</code> with <code>'Total: {{val,
number}}'</code> returned <code>'Total: 12345678901234567890'</code>
instead of <code>'Total: 12,345,678,901,234,567,890'</code>, 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
<code>cacheInBuiltFormats: false</code>. This also applies to formatters
added with <code>addCached</code>. Other calls still use the cache as
before. Thanks <a
href="https://github.com/nk-batman21"><code>@​nk-batman21</code></a> (<a
href="https://redirect.github.com/i18next/i18next/pull/2457">#2457</a>).</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/i18next/i18next/commit/00b6a3f22771e50be732826014d49a6ae2647ef5"><code>00b6a3f</code></a>
26.5.10</li>
<li><a
href="https://github.com/i18next/i18next/commit/9bdd4f6567573e529b7d8088b4e74ec9f3aeef82"><code>9bdd4f6</code></a>
build</li>
<li><a
href="https://github.com/i18next/i18next/commit/fb168f3b2f81f46e64ffbdbde6b97f682a933dde"><code>fb168f3</code></a>
changelog for 26.5.10</li>
<li><a
href="https://github.com/i18next/i18next/commit/2584a56acf2aa2a9f723f0c5a97f8a95499a60ca"><code>2584a56</code></a>
fix: don't match a supported language that only starts with the same
letters ...</li>
<li><a
href="https://github.com/i18next/i18next/commit/6c98e55c7e08b510d705e7d618073997126a9636"><code>6c98e55</code></a>
build</li>
<li><a
href="https://github.com/i18next/i18next/commit/3465ae460a304294475839900d3a813c24a9c6b3"><code>3465ae4</code></a>
26.5.9</li>
<li><a
href="https://github.com/i18next/i18next/commit/5888c1635b27bb6282ef082ef8f59204cbfd695d"><code>5888c16</code></a>
changelog for 26.5.9</li>
<li><a
href="https://github.com/i18next/i18next/commit/db036c88cb58ef27b651ab3562e332dbc9819f97"><code>db036c8</code></a>
fix: don't walk into the prototype via <strong>proto</strong> in nested
lookups</li>
<li><a
href="https://github.com/i18next/i18next/commit/0815882cb34e3e2aab630544692c3be786daf5e0"><code>0815882</code></a>
fix: don't interpolate inherited methods like constructor from nested
values ...</li>
<li><a
href="https://github.com/i18next/i18next/commit/45ae264ad20c0faf7d5e19dd09f100f545c312cf"><code>45ae264</code></a>
26.5.8</li>
<li>Additional commits viewable in <a
href="https://github.com/i18next/i18next/compare/v26.5.6...v26.5.10">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=i18next&package-manager=npm_and_yarn&previous-version=26.5.6&new-version=26.5.10)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

package-lock.json

@@ -30,7 +30,7 @@
         "downshift": "^9.4.0",
         "events": "^3.3.0",
         "file-saver": "^2.0.5",
-        "i18next": "^26.5.6",
+        "i18next": "^26.5.10",
         "i18next-browser-languagedetector": "^8.2.1",
         "i18next-resources-to-backend": "^1.2.3",
         "json-stringify-pretty-compact": "^4.0.0",
@@ -6645,9 +6645,9 @@
       }
     },
     "node_modules/i18next": {
-      "version": "26.5.6",
-      "resolved": "https://registry.npmjs.org/i18next/-/i18next-26.5.6.tgz",
-      "integrity": "sha512-GFWrDwGmYhOQS3bKvjA2Ir2ob9ScEdyY1UbeQJ10jyVACGQ6XxmDYqC/lxEj/IPEJlPQYNRnYffDET6TM8mnFg==",
+      "version": "26.5.10",
+      "resolved": "https://registry.npmjs.org/i18next/-/i18next-26.5.10.tgz",
+      "integrity": "sha512-YS4EiLQhhk0wGThm4Zy+BL2c9rBNIK+kAbksi4l/B+D6kVRQLIFZgu2b/MU2LibJJHwWNTYoOYR52T+jfV8kPQ==",
       "funding": [
         {
           "type": "individual",