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: trueon init and check the console log. There is rather sure a warning for unable to resolve the loadPath or invalid json. Check if the translation files are accessible via browser.
For a quick and dirty machine translation you may have a look at this free translator. But in general we suggest to use a smart Translation Management Service like locize to translate your i18next resources.
For professional translations we advice you to work with human translators. Or at least proofread the results coming from machine translations.
Or try translation-check, it shows an overview of your translations in a nice UI. It shows also the appropriate plural forms.
Are you seeing this warning in the development console?
i18next::pluralResolver: Your environment seems not to be Intl API compatible, use an Intl.PluralRules polyfill. Will fallback to the compatibilityJSON v3 format handling.
In environments where the Intl.PluralRules API is not available (like older Android devices), you may need to polyfill the Intl.PluralRules API. In case it is not available it will fallback to the i18next JSON format v3 plural handling. And if your json is already using the new suffixes, your plural keys will probably not be shown.
npm install intl-pluralrules
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 (BCP 47 language tag):
- en, en-US or en-GB
- zh, zh-HK or zh-Hant-HK
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.
For e2e tests a good tactic is to set language to
cimodeon init. This will set i18next to always return the key on calling
i18next.t. Want to add the namespace to returned value change
appendNamespaceToCIMode: trueon init.
Due to how serverless functions work, you cannot guarantee that a cached version of your data is available. Serverless functions are short-lived, and can shut down at any time, purging any in-memory or filesystem cache. This may be an acceptable trade-off, but sometimes it isn't acceptable.
Because of this we suggest to not use a remote backend and to download the translations and package them with your serverless function.