DEV Community

Cover image for next-export-i18n v1.3.0: respecing the user's default language
Martin Krause
Martin Krause

Posted on

next-export-i18n v1.3.0: respecing the user's default language

Today I released version 1.3.0 of next-export-i18n, the i18n module for Next.js which is fully compatible with next export.


Install next-export-i18n with $ npm i next-export-i18n or get next-export-i18n v1.3.0 from npm.js.


New feature: Respecting the user's default language

Starting with Version 1.3.0, next-export-i18nreads the user's default language settings from the browser. If this language is available as i18n it is automatically used as the default language.


About next-export-i18n

This npm module provides a simple solution for Internationalization (i18n) of projects using next export.

Next.js already has support for internationalized (i18n) routing out-of-the-box. You can provide a list of locales, a default as well as domain-specific locales and Next.js automatically handles the routing. It streamlines the touring and locale parsing for nearly all existing l18n library solutions available for Next.js such as react-intl, react-i18next, lingui, rosetta, next-intl.

Unfortunately, Next.js i18n-routing does not supports next export.
This means that none of the i18n-libraries (which are utilizing the build in i18n-routing) is able to support fully static sites which are generated with next export.

next-export-i18n provides a simple solution for Internationalization (i18n) when you want to generate a truly static website with next export.

Read the Introduction to next-export-i18n - next.js: i18n with static sites for more details.


Sample implementation

You can also take a look at the example implementation next-export-i18n-example.vercel.app and its source code at github: https://github.com/martinkr/next-export-i18n-example.


Links


Follow me on Twitter: @martinkr and consider to buy me a coffee


Photo by Jerry Zhang on Unsplash


Subscribe to the weekly modern frontend development newsletter


Oldest comments (5)

Collapse
 
jancizmar profile image
Jan Cizmar

Hey, the link to "Introduction to next-export-i18n" is broken. Why have you decided to implement whole i18n library and not only the part which is there in i18n-routing and not provided in the next export?

Collapse
 
martinkr profile image
Martin Krause

Hi Jan,

thank you for spotting the broken link. Fixed it to dev.to/martinkr/next-js-i18n-with-...

The build in internationalized (i18n) routing leverages the Next.js routing layer which is not available in states generated with next export.

I choose to implement a clean an simple approach to i18n compatible with next export instead of trying to work around the internal shortcomings of next.js.

If you start working on reimplementing the missingfunctionality by emulating the routing layer in exported sites, I would like to have a chat and see how we could collaborate.

Cheers!

Collapse
 
jancizmar profile image
Jan Cizmar

Hello,
actually, I work on Tolgee which is basically a combination of a localization platform and i18n libraries. We also support Next.js. I don't know why Next export doesn't work like gatsby-plugin-react-intl, which just generates static pages for each language. It would be great for us to be able to do the same thing with Next export.

For us it would be great to have the same support as provided in Next's i18n-routing but without the actual i18n library, since we just need to get the current language using some hook.

Thread Thread
 
martinkr profile image
Martin Krause • Edited

Nice work you're doing with tolgee.io!

"Next export doesn't work like gatsby-plugin-react-intl, which just generates static pages for each language" - this is what I expected as well. I was quite suprised when I saw the compiler error on generating the static files. I think for next.js we really need to see the difference between "their" static version (SSG etc) leveraging the build in express.js server and "true" static files with next export (which are more or less static) and least can run on any webserver.

If my work oes not fit your project, maybe take a look at this article: "dev.to/adrai/static-html-export-wi..." it's a approach which keeps the i18next compatibility.

Cheers!

Thread Thread
 
jancizmar profile image
Jan Cizmar

Thanks! I'll try to play with your solution and reuse the relevant part of it :)