Open iduuck opened 4 years ago
@iDuuck We should also add next-translate
. It's waaay easier to set this one up and also comes with hooks.
Only caveat of using next-translate
would be browser detection. I've only found a hacky way of checking the navigatior.language
and navigation.userLanguage
and according to those it should utilize next/router
for the redirect to the users browser language.
But maybe we could write a not so hacky "workaround" / hook to use right inside the _app.tsx
.
Thus I would say we should focus on next-i18next
and next-translate
and basically provide ONLY a guide on how to set this up the "right" way.
Also voting for next-translate
!
Since i made some bad experiences with next-i18next
i vote for next-translate
, too.
I am thinking about adding a internationalization library for supporting i18n right from the start.
Canditates
react-intl
**Pros:** - Easy to set up - Easy to integrate with `locize`. **Cons:** - No support for `getStaticProps`. ---
next-i18next
**Pros:** - Easy to set up - Easy to integrate with `locize` **Cons:** - No support for `getStaticProps`, [yet](https://github.com/isaachinman/next-i18next/issues/652). - Need to setup multiple packages (`react-i18next`, `next-i18next`, ...) ---
Rolling our own implementation
**Pros:** - Full flexibility. **Cons:** - **Can** be a pain in the ass. ---
Ahead of this, we might need to discuss, if we are going with implementing the library into the boilerplate directly or implementing a page into the documentation on how to easily set up the library (See https://github.com/fintory/boot-next/issues/13).