Advanced i18n

[eric-burel]

Update based on Next improvements

Future version of Next (9.6 most probably) will include a smarter setup for i18n, that we should include into Vulcan when it's more mature.

We already support basic i18n features.

Something to dig for the key extraction workflow: https://formatjs.io/

Update 2021 10

A big players:

• https://github.com/vinissimus/next-translate
• https://github.com/isaachinman/next-i18next

For both, we will probably lose next export, though that's acceptable as there is no real use case for it as soon as you use dynamic routes (Next.js cannot handle dynamic routes in exported app automatically, you need a gateway to handle them)

They however sound quite over-engineered...

Playing around with rewrites and an URL parameters might help simplifying this setup?

Old issue

i18n is now working ok, using next-i18next, but we need to test in more contexts to confirm:

• [X] i18n with SSR in dynamic mode => OK, and tests with Cypress
• [ ] Route based i18n ("vulcan/fr/foobar")
• [ ] i18n in static mode
• [ ] i18n when deploying to Vercel #36
• [ ] i18n in API routes, GraphQL queries like in Vulcan

Other features:

• [ ] Powerful language detection like in Vulcan
• [ ] Package based expansion of locales (using namespaces?)

Older issue (for reference)

Next-i18next: currently does not support Serverless mode, as it needs a custom server. But maybe that's overkill?

Next Right Now seems to have achieved i18n without custom server, by simply using react-i18n. To my best knowledge, Vulcan is also able to do that without actually using any kind of specific Express middleware. In NRN, see src/middlewares/localeMiddleware.ts

• [X] e2e test of i18n https://glebbahmutov.com/blog/cypress-tips-and-tricks/#control-navigatorlanguage, https://stackoverflow.com/questions/54671266/setting-the-browser-language-in-cypress
• [ ] Route based i18n ("vulcan/fr/foobar")
• [ ] i18n basic client side
• [ ] i18n SSR https://react.i18next.com/latest/ssr
• [ ] i18n in static mode
• [ ] i18n in dynamic mode

Step 1: clarify why "next-i18n" chose to rely on a custom server

We need to fully know the technical limitations of a serverless approach, at least to document it.

https://github.com/isaachinman/next-i18next/issues/274

Answer to this probably lies into i18next-http-middleware. It used to be bound to Express, but the "http" version is agnostic: it's probably usable directly in Next _app? It seems to handle language detection in requests for instance.

Step 2: figure out how i18n work in Vulcan

Provider and language detection is done in: packages/vulcan-core/lib/modules/components/App.jsx

Intl Provider is defined here: packages/vulcan-i18n/lib/modules/provider.js

Step 2: implement a serverless i18n version

We can tolerate to have limitations in the first implementation, as they will probably mostly affect advanced i18n patterns for static application, eg adding the locale in the URL.

https://github.com/i18next/react-i18next/issues/715 https://gist.github.com/odensc/216288159aaa2cb41fc924774fce5859 https://github.com/borispoehland/next-i18next-boilerplate/blob/master

git checkout feature/29-i18n

[eric-burel]

@SachaG I don't see any dependency to i18next or similar, you add a full custom implementation in Vulcan?