vulcan-next
vulcan-next copied to clipboard
Advanced i18n
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, seesrc/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
@SachaG I don't see any dependency to i18next or similar, you add a full custom implementation in Vulcan?