Comparison to others
You now might expect we compare eg. react-i18next to react-intl but that won't happen ;). But we will list why you should trust i18next to be the best choice for internationalization.
i18next was created in late 2011. What does that mean? It's older than most of the libraries you will use nowadays, including your main frontend tech (react, vue, ...).
Believe it or not but by the time of writing, the v11.x.x can be dropped in as a replacement for v1 by just adding a minimal compatibility layer. It's important to us not breaking things just for the sake of using new fancy stuff (which does not mean we do not keep up with latest possibilities of development).
Based on how long i18next already is available open source, there is no real i18n case that could not be solved with i18next.
With v2 of i18next we completely rebuild i18next to be as extensible as possible. Doing this i18next can be used in any javascript (and a few non-javascript - .net, elm, iOS, android, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless.
Just have a look at what the community built around the i18next core:
The regular i18n frameworks work like this:
- 1.You pass in all translations and the used language
- 2.You call a function that returns the correct translation based on the translations you passed in and provided values for plural and interpolation.
What you don't get by others - but get with i18next
- Splitting translations into multiple files. Only load translations needed.
- There are plugins to detect languages for most environments (browser, native, server). This enables to set priority of where to detect and even enables to cache set languages over requests / visits.
- There are endless plugins to load translation from server, filesystem, ... these backends also assert that loading gets retried on failure, or that a file does not get loaded twice and callbacks of success are only called once. Those backends can even provide an additional layer for local caching eg. in localStorage.
- Options what to load and how to fallback depending on language.
- Full control over management of the translations stored.
- Rich system of events to react on changes important to your application.
True, i18next's documentation is bigger than that of other i18n frameworks - but that's also a tribute to offering a lot more features that you would have to build yourself otherwise (language detection, translation loading, ...).
If you do not need that i18next is as simple as any other i18n framework:
import i18next from 'i18next';
i18next.init({
lng: 'de',
resources: {
de: {
translation: {
"hello world": "hallo Welt"
}
}
}
});
i18next.t('hello world'); // hallo Welt
Hm... ask this in one year again. When your i18n framework needs to catch up with the needs of production systems.
We work hard on keeping the code base clean and readable. We add new features which might help a lot of users and not based on we think it's easy to solve.
Yes, a size of 33kb minified and 9kb gzipped is huge. But like you saw before there is a lot more inside than just the basic i18n functionality.
But you could make this smaller by precompiling the translations. We could bring down i18next to 4kb gzipped (good to advertise) but on the other hand your translation files would grow significantly.
Just two samples of extended functionality you can get:
translation.json
{
"error": {
"unspecific": "Something went wrong.",
"404": "The page was not found."
}
}
Sample
const error = '404';
i18next.t([`error.${error}`, 'error.unspecific']) // -> "The page was not found"
const error = '502';
i18next.t([`error.${error}`, 'error.unspecific']) // -> "Something went wrong"
- many goodies still available
- just a few goodies remaining...
- no goodies remaining...sorry you're too late
{
key_interval: '(0){no goodies remaining...sorry you`re too late};(1-100){just a few goodies remaining...};(100-inf){many goodies still available};'
}
While some other i18n frameworks run on serverside too there are not many optimized for it. Loading translations only once (think of a render to string in react.js where you create a new instance and inject translations over and over). Also does it keep the set language during async requests or do simultaneous requests create race conditions in setting the right language?
Overview of what technologies i18next will integrate with. Some listed are: Electron, Phaser, iOS, Android, Aurelia, Meteor, React Native, Knockout, React, Next.js, Remix, Angular, Ember, jQuery, Vue, Grunt, IntelliJ IDEA, Webpack, NodeJS, Express, Django, Koa, Microsoft .NET, PHP, Ruby Rails, Couchbase, MongoDB, Redis, Firebase, Locize.
Should speak for itself.
Being honest, internationalization is the smaller pain in getting a site translated. Localization and the translation process are where the real hard work starts.
Last modified 9mo ago