Recently I had a client who wanted a fast single-page-application (SPA) with an outstanding lighthouse score and multiple languages hosted on a cheap shared hosting solution only accessible by FTP … and of course they wanted it to be build with
From the initial requirements and the following discussion we decided to have a local build step which would generate static files and transfer them to the web server.
Given their limited expertise and the specific requirements I was suggesting a static-site-generator with a custom headless setup for their content. The client was happy with the proposed architecture. I was looking into the possibility of using
next.js and the two major requirements: a static page served by apache and internationalization (i18n).
Next.js provides a true out-of-the-box static sites generator. The
next export command generates a set of fully optimized static HTML files. This export can thus be served without any dependencies by any web-server. No need to run
node.js etc – a regular nginx or apache installation is completely sufficient.
Next.js also provides an amazing out-of-the-box support for internationalized (i18n) routing and a decent ecosystem for i18n-solutions
The i18n routing support is currently meant to complement existing i18n library solutions like react-intl, react-i18next, lingui, rosetta, next-intl and others by streamlining the routes and locale parsing.
Sounds nice and being a fan of
react-i18next I looked into
next-i18next and was quite happy to see that they support Static Generation (SSG).
To complement this, next-i18next (….) fully supporting SSG/SSR, multiple namespaces, codesplitting, etc.
Production ready: next-i18next supports passing translations and configuration options into pages as props with SSG/SSR support.
Upon closer inspection, I figured: they’re only supporting Static Generation (SSG) with
next start not
next export. (About the differences, read my article The two and a half + one flavors of next.js’s pre-rendering).
next start spins up the
next.js web-server and requires
node.js – which was a problem for the hosting solutions.
I needed an export which would run on a basic nginx.
From the next.js documentation:
Note that Internationalized Routing does not integrate with next export as next export does not leverage the Next.js routing layer. Hybrid Next.js applications that do not use next export are fully supported.
Well, we’re just going to create our own custom i18n solution
Let’s collect the requirements:
The custom solution must:
- have full support for
The custom solution should:
- load the translations files from a folder with minimal configuration
- provide a hook with the same interface as
- provide a stateful-hook for the current language
- set / retrieve the selected language to / from the GET-parameters
- fallback to the default language if no GET-parameter is present
- set the GET-parameter on internal links and preserve existing GET-parameters
- provide a sample component for selecting the language
So, if you need an i18n solution which has full support for
next export and minimal configuration effort use the next-export-i18n npm-module.
- Example implementation: https://next-export-i18n-example.vercel.app
- Github for the npm-module: https://github.com/martinkr/next-export-i18n
- Github for the example: https://github.com/martinkr/next-export-i18n-example.
Follow me on Twitter: @martinkr