[UPCOMING RFC IN PROGRESS] I18n - Change implementation to use Next.js native i18n

[Vadorequest]

Today, Next.js released a new official (core team) RFC regarding built-in i18n.

vercel/next.js#17078

The way this RFC implements i18n is very similar to the way it's implemented within NRN, and that's great! I expect very little changes to a NRN codebase to adopt the future i18n built-in feature.

vercel/next.js#17078 (comment)

Note that the current RFC only does the following:

• Detect the language being used by the user (browser, server)
• Automatically redirect to default language (fallback) on /
• Provide the locale and locales to every Next.js pages (whether SSG or SSR)
• Native i18n routing (browser, server)

It does not provide anything regarding localization (l10n), the implementation details rests in our hands. (disk-based, 3rd party, etc.)

[samuelcastro]

For i10n I'm using https://ipdata.co, it has a limited free version, it'd be great to see your idea on it, if we could create some sort of disk-based solution that would be really great. These are the 3rd party solutions I investigated:

• https://getjsonip.com/
• https://ipinfo.io/ip-geolocation-api
• http://www.geoplugin.com
• https://ipwhois.io
• https://ip-geolocation.whoisxmlapi.com

[Vadorequest]

I think it's unrelated to the current topic, geolocalisation isn't strongly related to i18n. Also, it's not part of the mentioned RFC, for now.

But I like the idea of providing such service. I could be used for I18n, it could also be used for GDPR-related issues, like cookie behaviors and such that depends on where the user actually lives, not what language they want the site be displayed on.

I missed your point on the "disk-based solution", I don't see how that relates to geolocation.

Also, the RFC isn't about "translations", it's really all about locale detection and routing and passing down i18n-related data to pages, that's really all there is, for now. It's not about what you do with those information, neither how you actually translate the app.

[samuelcastro]

Sorry I meant L10N not i18n.

The disk-based solution came from your original quote, I thought you meant the creation of some sort of api service to enable geo localization.

It does not provide anything regarding localization (l10n), the implementation details rests in our hands. (disk-based, 3rd party, etc.)

[Vadorequest]

Actually, I mentioned "disk-based implementation" because I was thinking of fetching a 3rd party API to fetch sentences, and then store them on disk for actual usage. But it's out of the scope of the official RFC (and this issue too, therefore).

[Vadorequest]

Closing this in favor of #194.