Migration Guide
There should not be any breaking change, but regarding of some misuse of i18next that pop up in last minor releases, we opted for a major version this time. The relevant change behind the scene for this major version was ignoreJSONStructure.
Typescript use export default for esm-first approach 1352. No API changes.
When calling
i18next.changeLanguage()bothi18next.languageandi18next.languageswill be set to the new language after callingloadResources-> means when accessingtfunction meanwhile you will get still the translations for the previous language instead of the fallback.When is this breaking? this does not break any current test - but if you depend on accessing i18next.language or i18next.dir during language change and expect the new language this will break your app.
Reasoning: In react-i18next we get in a not ready state for loaded translations while we would prefer just waiting for the new language ready and trigger a rerender then - also a triggered rerender outside of the bound events would end in Suspense...
How can I get the language i18next will be set to?
i18next.isLanguageChangingTois set to the language called
removes named exports in index.js to avoid issues in bundlers
Build process was updated - no API changes
note: dist/es -> dist/esm, dist/commonjs -> dist/cjs (individual files -> one bundled file)
Build process was updated - no API changes
Breaking changes in typescript typings for details have a look at this pull request.
typescript definitions now can directly be used from the i18next module - no longer needed to get them from DefinitelyTyped
functions used to return a callback (eg. init, changeLanguage, loadNamespaces) now also return a Promise - while this enables easier handling using async await this also means eg. i18next.init does not return this anylonger and therefore you can't chain calls like
i18next.init().on()anylonger.
plural form for hebrew was updated to latest CLDR. Before it had one plural form. You will have to update your JSON files containing hebrew plurals. Or patch back the plural form to: https://github.com/i18next/i18next/blob/master/src/PluralResolver.js#L43 using the addRule function. Learn more about plurals: https://www.i18next.com/translation-function/plurals​
removes plugin of type cache. Can be replace by i18next-chained-backend example cache for localStorage i18next-localstorage-backend​
removes the support for multiload (multiRead) in backends - will just use read per language-namespace. You can enable multiRead support in backends again by using i18next-multiload-backend-adapter​
brings pt, pt-PT, pt-BR plurals in line with, new pt reflects pt-BR and pt-PT gets a special case for plural handling http://www.unicode.org/cldr/charts/26/supplemental/language_plural_rules.html​
code | locale | rule |
pt-PT | Portugal Portuguese | nplurals=2; plural=(n != 1); |
pt_BR | Brazilian Portuguese | plurals=2; plural=(n > 1); |
pt | Portuguese | plurals=2; plural=(n > 1); |
With v9 we removed the compatibility for the v1 API. So the compatibilityAPI: 'v1' flag won't do anything anymore.
You still can append this manually as we do for our old v1 tests - learn more.
The nonExplicitWhitelist flag was changed to be used in user detected language too, before it was restricted to defined fallback languages only.
i18next.init({fallbackLng: 'en',whitelist: ['de', 'en', 'zh'],nonExplicitWhitelist: true});​// eg. `de-AT` will now pass the whitelist check
We used to resolve nb-NO, nn-NO to no as language part mainly because there was no way to proper define per local fallbacks. With v7.0.0 we removed that to enable default behaviour also for norwegian language. To get back the old behaviour you can define multiple fallbacks like:
fallbackLng: {'nb': ['no', 'en'],'nn': ['no', 'en'],'default': ['en']}
Additional starting from 7.0.0 you could use named exports:
import { init, t } from 'i18next';
Return namespace in cimode with appendNamespaceToCIMode option (default now will only return key without namespace - independent of call to t function) #863​
This change might break your e2e tests if your depending on the cimode (the returned value can now be set to return always only key or ns+key)
Nested keys should not be escaped #854​
i18next.cloneInstance() calls now init() (before it depended on having called that function with a callback) #860​
There is only a small change for webpack2 builds which now targets es build with import/export in place to enable treeshaking (module entrypoint in package.json).
Nothing breaking for non webpack2 users.
There is one breaking change regarding suffixing plurals in cases a language has multiple plural forms. Eg. arabic suffixes are now 0, 1, 2, 3, 4, 5 instead of 0, 1, 2, 3, 11, 100.
This change streamlines the suffix with the one used in gettext.
To enforce old behaviour you can enable compatibilityJSON = 'v2' on i18next init call.
import i18next from 'i18next';​i18next.init({compatibilityJSON: 'v2'}, (err, t) => { /* resources are loaded */ });
While v2.0.0 is a full rewrite of the old codebase it should be possible to run in your app without completely rewrite your integration.
The new version does not come with backend, cache and user language detection built in. i18next is more a core library that can be extended with modules on demand. This way it can be seamlessly used in browser, node.js or other javascript runtimes.
Modules are available on npm, via bower or on github to download.
import i18next from 'i18next';import XHR from 'i18next-xhr-backend';import Cache from 'i18next-localstorage-cache';import sprintf from 'i18next-sprintf-postprocessor';import LanguageDetector from 'i18next-browser-languagedetector';​i18next.use(XHR).use(Cache).use(LanguageDetector).use(sprintf).init(options, callback);
hint for jquery user: use additional jquery-i18next​
var i18next = require('i18next'),FilesystemBackend = require('i18next-node-fs-backend'),sprintf = require('i18next-sprintf-postprocessor');​i18next.use(FilesystemBackend).use(sprintf).init(options, callback);
var express = require('express');i18next = require('i18next'),FilesystemBackend = require('i18next-node-fs-backend'),sprintf = require('i18next-sprintf-postprocessor'),i18nextMiddleware = require('i18next-express-middleware');​i18next.use(i18nextMiddleware.LanguageDetector).use(FilesystemBackend).use(sprintf).init(options, callback);​var app = express();​app.use(i18nextMiddleware.handle(i18next)); // expose req.t with fixed lngapp.post('/locales/add/:lng/:ns', i18nextMiddleware.missingKeyHandler(i18next)); // serves missing key route for consumers (browser)app.get('/locales/resources.json', i18nextMiddleware.getResourcesHandler(i18next)); // serves resources for consumers (browser)​app.listen(3000);
Version 2.0.0 has a compatibility layer built in which allows to run it like v1.11.x. Keep in mind this layer will be removed in future version.
import i18next from 'i18next';​i18next.init({compatibilityAPI: 'v1',compatibilityJSON: 'v1',// ...old options from v1}, (err, t) => { /* resources are loaded */ });
option | description |
compatibilityAPI | Will convert init and t options and expose old API functions. Will be removed with future update. |
compatibilityJSON | Will allow to use JSON files in v1 format. Using old interpolation prefix, suffix and no need for singular suffix [0] for singular in languages with more then just 1 plural form. |
support for older browsers:
Beginning with v2 we target only modern browsers (Chrome, Firefox, ... and IE >= 10).
For IE9 you will need to add a es5 shim
jquery:
use additional jquery-i18next​
synchronous loading:
i18next.init({ getAsync: false });is not supported any longer - as not encouraged by browsers.
no conflict:
i18n.noConflict();was removed as i18next registers to window.i18next and no longer to window.i18n
indefinite article:
i18n.t('myKey', { indefinite_article: true })was removed - as the solution was too limited - reconsidering adding a better solution in a future v2 release
