Usage of internationalization library: Which one to use?

[iduuck]

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.
• 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 #13).

[visualcookie]

@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]

Also voting for next-translate!

[chmtt]

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