fintory / boot-next

Basic Next.js starter kit including the use of TypeScript, styled-components, mobx-state-tree and many more.
2 stars 0 forks source link

Usage of internationalization library: Which one to use? #12

Open iduuck opened 4 years ago

iduuck commented 4 years ago

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).

visualcookie commented 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.

iduuck commented 4 years ago

Also voting for next-translate!

chmtt commented 3 years ago

Since i made some bad experiences with next-i18next i vote for next-translate, too.