Removing [locale] route at root

[sshmaxime]

Is your feature request related to a problem? Please describe. I'd like to get rid of the [locale] folder.

Describe the solution you'd like Being able to define routes normally without the extra [locale] folder.

Describe alternatives you've considered This library does it https://github.com/i18nexus/next-i18n-router but I haven't checked what's happening under the hood.

[QuiiBz]

That's something I want to get rid of too, thanks for opening a feature request. It's currently only used for translating in Client Components, more precisely inside useCurrentLocale() (which uses useParams()). We could theoretically retrieve the locale from the cookie instead of the route segment, but I haven't got the time yet to test this.

[gustaveWPM]

That's something I want to get rid of too, thanks for opening a feature request. It's currently only used for translating in Client Components, more precisely inside useCurrentLocale() (which uses useParams()). We could theoretically retrieve the locale from the cookie instead of the route segment, but I haven't got the time yet to test this.

Hello, What if we have some server components which use locale from params? Better should use getCurrentLocale?

In some situations (like this), it does not seem possible.

export default async function Page({ params }: BlogCategoryPageProps) {
  const lng = params[i18nTaxonomy.LANG_FLAG];
  setStaticParamsLocale(lng);
  const scopedT = await getScopedI18n(i18ns.blogCategories);

( This snippet is inspired of: https://next-international.vercel.app/docs/app-static-rendering#static-rendering-1 )

[QuiiBz]

Indeed, this part will have to be updated to also retrieve the locale from the cookie, instead of the route params. I'm not aware of how to achieve this without opting-out of Static Rendering, so not really sure how this could be solved.

Does https://github.com/i18nexus/next-i18n-router supports Static Rendering? I couldn't find any documentation about it.

[radumkc]

next-i18n-router Does it by checking for a cookie that they set. If the cookie is there the locale can be determined in the middleware.

If the cookie is not there they use @formatjs/intl-localematcher and negotiator to autodetect and then they set the cookie.

It is fairly easy to understand I think, and the principle is simple to implement. The challenge is the detection as different websites have different settings.

[QuiiBz]

That's unfortunately not as easy. Using cookie() will opt-out of Static Rendering and force Dynamic Rendering instead (see my comment above: https://github.com/QuiiBz/next-international/issues/188#issuecomment-1730859664)

next-i18n-router also requires a dynamic segment ([locale]) to support Static Rendering:

[radumkc]

Yes of course, I should have been more specific. You can't do it for static unless you have a route I guess.

Not sure how it might work if you have domain level localisation instead of route based.

Might be that we can have an option that will remove the route but with a disclaimer that states that SSG will not work.

[gustaveWPM]

Not sure how it might work if you have domain level localisation instead of route based.

You mean subdomains? I don't know if it's changed since then, but it can be catastrophic in terms of SEO.

• https://www.semrush.com/blog/subdomain-vs-subdirectory/
• https://twitter.com/stekenwright/status/1318417365831385091
• https://twitter.com/digitalquokka/status/1321875238594949127

(It remains to be seen if this impact is as dramatic for internationalisation purposes.)

This could be an additional option in Next International, although what I've mentioned above suggests that it's not necessarily a good idea to use this practice. This is something that exists in the industry and is practised by many people. However, basing everything on this does not seem to me to be a good option.

Additionally, in terms of virtual DOM optimizations and proper redirections, I wonder if we could have a page reload as lazy as it is at the moment with this strategy. This also introduce more and more issues related to Next.js: https://medium.com/@jfbaraky/using-subdomains-as-paths-on-next-js-e5aab5c28c28

It seems to me to be a path full of workarounds and hacks, so I'm not sure it's a good idea to explore it... In the end, I think that Next International could probably be used in this realm of hacks and workarounds of workarounds, without needing to change a single line of code internally (apart for DX purposes).

I will make a new issue to discuss about it. EDIT : https://github.com/QuiiBz/next-international/issues/241

[Bluzzi]

👋 Also interested in this feature! For a dashboard requiring a connection, it's not relevant to have a [locale] folder, glad this package takes this into consideration

[gustaveWPM]

👋 Also interested in this feature! For a dashboard requiring a connection, it's not relevant to have a [locale] folder, glad this package takes this into consideration

Maybe you don't need SSG at all in your app too... Sooo, I think you could omit the [locale] folder if you're never using SSG in your app, nope?

I'm not sure about that... But I think the [locale] folder is mandatory only for SSG purposes?

[Bluzzi]

Maybe you don't need at all SSG in your app too... Sooo, I think you could omit the [locale] folder if you're never using SSG in your app, nope?

I'm not sure about that... But I think the [locale] folder is mandatory only for SSG purposes?

I've just done a small test without the [locale] folder and it seems to work very well.

But what exactly is the purpose of this ticket if it's already possible? To be able to do it with SSG support? Is it really possible without any information in the URL?

[gustaveWPM]

Maybe you don't need at all SSG in your app too... Sooo, I think you could omit the [locale] folder if you're never using SSG in your app, nope? I'm not sure about that... But I think the [locale] folder is mandatory only for SSG purposes?

I've just done a small test without the [locale] folder and it seems to work very well.

But what exactly is the purpose of this ticket if it's already possible? To be able to do it with SSG support? Is it really possible without any information in the URL?

Idk if it's possible. 😅 Glad to know that I could help a bit.