I18n (Internationalization)
Internationalization, often abbreviated as i18n, is the process through which products can be prepared to be taken to other countries. It doesn’t just mean being able to change languages. Instead, it means being able to accept different forms of data, different settings to match local customs and different strings of data and process it correctly.
Localization (l10n) is simply the act of changing a piece of software to suit a different locale.
In many ways, internationalization can be thought of as building the structure of a piece of software so that it can be adjusted for different markets, and localization is the process of actually doing so for a specific market.
Table of contents
- Understanding the differences between “Dynamic” and “Static” i18n
- A few words on “static i18n”
- A few words on “dynamic i18n”
- Personal note
Understanding the differences between “Dynamic” and “Static” i18n
We will only mention i18n with NRN, not l10n. Both are very similar and can be grouped together as i18n, because l10n relies on i18n capabilities.
The content displayed on NRN is translated using different ways, depending on where the translations are stored:
- Dynamic i18n - Content-related (e.g: Post title in FR + EN). It will depend on your data and how you fetch those data (real-time SSR, SSG, etc.)
- Static i18n - Everything that isn’t related to dynamic content (e.g: Site links, any static content not related to dynamic data). It will depend on how you fetch those data (vendor (API), i18n static files, etc.)
It is possible, although very rare, to use the same system/vendor for both “dynamic” and “static” i18n.
For instance, one could imagine storing all its static content within it’s dynamic i18n content.
This design would have a few pros/cons:
- Content would be available online (CMS/back office) and may be updated by non-IT teams
- Content would need to be fetched for each request (when using SSR), but that could be mitigated by using SSG
- For example, replacing Locize by GraphCMS would allow storing all content at the same place, but would lack i18n-specific features offered by Locize.
A few words on “static i18n”
I18n with Next.js isn’t an easy topic, and many smart people have tried to provide a solution about it.
Unfortunately, there are no magic solution out there.
- Next.js thread about i18n
next-i18nextisn’t compatible with the Next.js 9.3+ version- It requires an additional Express server, there are extra complication due to the Serverless nature of Next.js apps (no proper local storage)
- The official next example relies on a
_pageshack folder- Feels hacky, and I’ve got no idea what drawbacks this could create in the future, as it’s not the way the
pagesfolder is meant to be used
- Feels hacky, and I’ve got no idea what drawbacks this could create in the future, as it’s not the way the
How we do
Our way works with SSG and SSR. We strongly recommend using SSG whenever possible, because it’ll increase the speed of pages rendering, reduce costs, and more.
Using SSG, we fetch i18n content at build time and generate static pages. This avoids over-fetching your i18n provider for each end-user request, and remove this vendor from the potential list of threats of your app. (even if your vendor API goes down, it won’t affect your end-users because you only use its API at build time)
Such design also has various benefits and limitations. For example, you can’t change static content without rebuilding your app, but it also increases the speed of your pages because you don’t have to fetch static content anymore.
Using SSR, we fetch i18n content for every end-user request, in real time. Of course, there are a few optimisations, such as browser/server caching, but they’re not as efficient as statically generated pages.
A few words on “dynamic i18n”
Dynamic i18n is a bit easier in our opinion. If you need those data dynamically, then you’ll have to use your vendor API to fetch the i18n content, the same way you’re using its API to fetch non-i18n data.
SSG is becoming very attractive in 2020, and most sites don’t actually need to perform real-time requests to fetch up-to-date content. But, that’s quite a change of thinking/designing web apps, and it may not fit your business requirements.
We recommend to use SSG whenever possible, and build your static pages at build time. If you need to rebuild your pages based on CMS changes and such, you should take a look at the newer incremental static regeneration feature.
There is no bullet-proof-fit-them-all solution on this, it depends on your requirements and limitations.
Personal note
Our personal advice on this is to keep an eye on the RFC: Incremental Static Regeneration because it should soon yield some very interesting and powerful features to help us keep our statically generated apps up-to-date based on complex workflows.
Keep in mind that i18n depends on how your render your app, and this has many, complex implications. (SSR, SSG, etc.)