There are a lot of ways to support us. Make a PR for a feature requested. Improve the documentation. Help others to get started. Spread the word.
Further you could try locize.com - our localization as a service offering. It's like donating to i18next but with additional benefits for you - like saving hours of time translating your project.
debug: true on init and check the console log. There rather sure is a warning for unable to resolve the loadPath or invalid json. Check if the translation files are accessible via browser.
On the plural page there is a tool to get them.
Or try translation-check, it shows an overview of your translations in a nice UI. It shows also the appropriate plural forms.
Or you use a smart translation management system, like locize.
Theoretically, you're not bound to any specific language code format, but if you want to make use of all the in built language features, like proper pluralization and correct fallback resolution, we strongly suggest to use the following iso norm:
en, en-US or en-GB
zh, zh-HK or zh-hant-HK
Other examples are listed here: https://www.iana.org/assignments/language-tags/language-tags.xhtml
And more information about the format can be found here: https://www.w3.org/International/articles/language-tags/
Try translation-check, it shows an overview of your translations in a nice UI. Check which keys are not yet translated.
If you need more, it might be time to use a translation management tool.
For e2e tests a good tactic is to set language to
cimode on init. This will set i18next to always return the key on calling
i18next.t. Want to add the namespace to returned value change
appendNamespaceToCIMode: true on init.