[examples, react-intl] Application cannot be deployed using serverless target (Vercel, Netlify)

[thuringia]

Bug report

The current version of the react-intl example was simplified by @longlho in #16215 but it keeps the usage of a custom server

Describe the bug

The custom server prevents usage of the serverless build target, which also prevents it from using it with Vercel.

I'm currently running a version of the previous example without the custom server by moving all the detection logic client-side.
This works but sacrifices UX by reloading languages and rerendering when loading a page.

I would prefer to find a solution using react-intl as I find it's API to be better than what next/react-i18next offer.

To Reproduce

not applicable

Expected behavior

Ideally we reach a similar solution to next-i18next which makes this possible across all targets supported by Next.js

Screenshots

not applicable

System information

• Version of Next.js: 9.5.2
• Version of Node.js: 14 (development), 12 (Netlify functions)

Additional context

I'm currently researching solutions to this problem for a project that might move to blitz-js, and found this to be an open issue there, blitz-js/blitz#279

[longlho]

Just so I understand what you're trying to achieve: You want locale detection w/o custom server or are you ok w/ doing it purely client side (no SSR).

Locale negotiation can be achieved with several means:

• Accept-Language header (or navigator.languages): The former is the reason why a custom server is needed, without that, the latter would work but u cannot use SSR.
• geoip locale detection: This is what most companies do/use for region locking/locale detection, which would most certainly require custom server.

[thuringia]

I'd prefer the first option. That way you could use localization using react-intl regardless of the deployment type while ensuring the best user experience and performance. It would also be possible to use react-intl for pre-generation of CMS-type pages to have proper formatting of number, etc.

I think next-i18next is using some kind of middleware for Next.js to make this work.
That might be the reason they are using locale-paths, e.g. example.com/en/welcome vs. example.com/de/welcome.
At least that seems to be the compromise they are offering.

In my current case the default locale is the same as the primary market,
so doing the negotiation client side is not a big issue as it is rarely used.
Though, I got some feedback from testers using an en-type locale for their system that the switching is interesting, as in "cool you support multiple languages", but the flashing and rerendering of the application is not good.

If we cannot make this work nicely without the custom server, we would have to make the client-side negotiation smoother. That might be unrelated to the Next.js example though.

As far as the negotiation itself is concerned, sticking to Accept-Language or navigator.languages is preferable.
I'm not a fan of overriding user settings based on a geofance, I've seen this go wrong too many times.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.