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 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.
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.
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.
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.
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.
With v21 we streamlined the suffix with the one used in the Intl API.
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.
tldr;
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):
lng-(script)-REGION-(extensions)
i.e.
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/
As soon as you use the dash character - the language codes are tried to be formatted with Intl.getCanonicalLocales.
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.
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.
Read more about this topic, here.
