Improve fallback language handling

[chrilis]

We currently have the use case to provide multiple locales (de, de-AT, de-DE, de-CH) for one language (de) without the need for individual translations. Preferably we would like to use a function for fallbackLng, like (code) => code.split('-')[0], as we need to support a wide range of locales.

When using fallbackLng like this, we still need to provide JSON files for each locale, although the translations for de-AT are no different than for de. This PR is an attempt to fix this and I think it is related to #1652, #1649 and #1465.

Depending on the setup, the changes of this PR might add multiple fallback locales to window.__NEXT_DATA__. This could lead to increased page size. Should we add a notice about this in the docs?

Additionally we could utilize the config nonExplicitSupportedLngs to automatically add fallbacks per locale (e.g. de for de-AT). If understood correctly, this would reduce setup complexity and remove the need of serializeConfig: false - because a function for fallbackLng would no longer be necessary. Do you think this would be the expected behavior @adrai? Otherwise we could add a short notice to the docs, that this option is currently not supported with next-i18next as this was my first (incorrect) assumption. This might be related to #1412.

I‘m quite new to the code base and very happy about feedback, alternative solutions or improvement suggestions for this PR. Thank you!

Checklist

• only relevant code is changed (make a diff before you submit the PR)
• run tests npm run test
• tests are included
• commit message and code follows the Developer's Certification of Origin

[adrai]

I‘m also relatively new ;-)

lgtm

Regarding nonExplicitSupportedLngs I think this could be part of a separate PR, what do you think?

[chrilis]

Yes, I'll be happy to write a separate PR for nonExplicitSupportedLngs. I guess I will start working on it after this PR is merged.

[adrai]

included in v12.0.0