Support multiple languages

[BIA3IA]

As codeRabbit suggested, maybe consider introducing an i18n solution compatible with Next.js, such as next-intl ori18next + react-i18next to support both italian and english

[toto04]

Probably next-intl is the best solution for a full Next.js website like this one

We should decide sooner rather than later how to handle internationalization as a whole
Many websites (including our own right now) treat the locale as a route param, which is a well documented feature of next-intl (docs) but we might consider other options like storing the locale as a local setting while querying user preference from the browser settings like we would with dark/light mode preferences

We should also establish some sort of general consensus about how we want to handle the translated sources – i.e where to put the JSON files and how to split them up – keeping in mind that we might want to crowdsource translation efforts to Admins to avoid taking up too much development time

I want to wait to hear what others think about this before making any calls on the issue
@lorenzocorallo @Diubii @viganogabriele and others feel free to share your opinions!

[viganogabriele]

Hi Tommaso, it makes sense to settle this now. I trust your choice of next-intl. Personally, I’d prefer a single URL for the site, but please go with whatever is best for SEO and development time.
JSON is fine for UI strings as long as it’s easy for admins to manage. Let’s focus strictly on Italian and English for now. Let me know how you want to proceed.

[Diubii]

next-intl looks pretty straightforward, so I agree with its usage. We could implement the structure suggested by the docs, i.e. creating a messages folder at the website root directory and splitting the json files by language. If these become too long, we could consider further splitting by page for each locale (if possible), like:

 ├── messages
 |  ├── en
 |  |  └── index.json
 |  |  └── ...
 |  └── it
 |     └── index.json
 |     └── ...
 ├── next.config.ts
 └── src
    └── ...

Regarding @viganogabriele's SEO concerns, I would suggest treating the locale as a route parameter in combination with server-side rendering.

[lorenzocorallo]

I would go with path params, but for italian language do not put anything so https://domain.com/..., while for english (and other languages) we put the lang code like https://domain.com/en/...

We still can read browser's locale on the default route langcode and eventually redirect to /en

[Diubii]

I would go with path params, but for italian language do not put anything so https://domain.com/..., while for english (and other languages) we put the lang code like https://domain.com/en/...

It is possible