FAQ
Last updated
Last updated
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 - 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.
Try setting debug: true
on 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.
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.
tldr;
lng-(script)-REGION-(extensions)
i.e.
en, en-US or en-GB
zh, zh-HK or zh-Hant-HK
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.
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.
For a quick and dirty machine translation you may have a look at . But in general we suggest to use a smart Translation Management Service like to translate your i18next resources.
For professional translations we advice you to work with . Or at least proofread the results coming from machine translations.
On the there is a tool to get them.
Or try , 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 .
With v21 we streamlined the suffix with the one used in the .
In environments where the API is not available (like older Android devices), you may need to the API. In case it is not available it will fallback to the plural handling. And if your json is already using the new suffixes, your plural keys will probably not be shown.
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 and correct , we strongly suggest to use the following iso norm (BCP 47 language tag):
Other examples are listed here:
And more information about the format can be found here:
Try , 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 .
Read more about this topic, .