🐛 Bug Report

Using the 'otherNamespace:my.key' syntax with a getFixedT() function bound to a namespace works at runtime, but leads to TS type errors in the editor.

The problem is related to #1887, but instead of less prefixed keys, I want more prefixed ones. 😄

To Reproduce

I created a minimal reproducible example commit based on the existing i18next "customtypes" tests.

The repository itself is not "minimal", because it is i18next master plus the commit linked above.

Running

npm run test:typescript:customtypes

will fail to typecheck for the lines with a // TS error, but works ok comment. I also included these below:

const t8 = i18next.getFixedT('en', 'alternate');
// this is not the most useful call, but maybe there are use-cases for prefixing everything:
t8('alternate:foobar.barfoo'); // TS error, but works ok
// other namespaces should be available via a key prefix:
t8('custom:foo'); // TS error, but works ok

In my mind, getFixedT() should allow the keys for the "fixed" namespace(s) without a prefix (as we currently do), but also allow the keys of all other namespaces available in i18next with the respective namespace prefix. This would match the current runtime behavior of getFixedT(). I understand, that in the IDE this would suggest a lot of keys that are not helpful in most cases, because one usually would only want to work with the "fixed" namespace's keys.

As an alternative, we might also keep basically the current behavior, but add another generic fallback overload to the TFunction definition, that just allows keys matching the type `existing-ns-prefixes:${string}`, i.e. not generating every possible prefixed key, but just allowing any key with the correct prefix for any of the namespaces known to i18next. This cannot suggest existing prefixed keys or detect misspelled namespace-prefixed keys, but would not produce a giant list of possible keys.

I'm not a typescript expert, so I'll leave the judging to you. :)

Expected behavior

The code above should typecheck just fine.

Your Environment

• runtime version: Node.js v14.21.1, npm 9.2.0
• i18next version: 22.4.5 / master
• os: Windows