Client-side i18n routing not working

[delucca]

Bug report

Describe the bug

While testing the new i18n routing, I stumbled upon a major issue regarding client-side navigation. Although we can use rewrite rule to create a proper link with localized pages (for example, mapping /day to open when the user types /pt-BR/dia on her/his browser), we can't preserve this feature with the next/link Link component.

As soon as a user clicks on a link that goes to /day, it goes to the original page route (/day) instead of the rewritten route. I assume this happens because rewrites and redirects only happens on the server-side.

To Reproduce

You can see a working example here: https://codesandbox.io/s/nextjs-1002-intl-client-bug-nty4r

You need to access that page with a pt-BR locale on your browser. After doing so, if you navigate to https://localhost:3000/pt-BR/dia the /day page loads as expected, but if you navigate to the same page by clicking the index route Test client route Link it goes to /day route instead.

Expected behavior

To support i18n, we must allow users while navigation on the client-side to /day (for example) be mapped to /pt-BR/dia on the client-side (or the locale relative path).

Also, it is not suitable for an i18n application to handle mapping path logic based on locale. Since NextJS already has all the required pieces (and also has a way to solve it on the server-side), we should resolve this on the Link component.

Suggestion: In my opinion, we should find a way to map the route alternatives (based on locale) directly in the page itself (avoiding using the next.config.js).

[timneutkens]

Rewrites are applied client-side, redirects however are not because they're generally a large list which can't be shipped to the browser without affecting performance, so this seems like expected behavior.

[delucca]

@timneutkens so, I would need to resolve the link path for given locale at my own application? (Meaning to have a single route logic for each URL)

What is the point of supporting i18n since this basic feature (localized routing) is not supported?

[timneutkens]

What is the point of supporting i18n since this basic feature (localized routing) is not supported?

You can read the RFC: #17078. it was intentionally not added initially given that it would increase the complexity of the solution.

[delucca]

@timneutkens thanks for sharing the RFC

There are any plans to support localized routes in the near future at next/router? I ask so to prevent me from writing a complex Link component that is sensitive to locale.

Also, any suggestions on how to handle this? There are any way to append possible route alternatives at the page level?

[timneutkens]

There are any plans to support localized routes

There are but I can't give you a timeline of when that will land.

Also, any suggestions on how to handle this? There are any way to append possible route alternatives at the page level?

That is exactly what we didn't add as per the RFC to reduce complexity. Currently it can be handled using rewrites and keeping a list of alternative routes client-side (beware this could be a growing list with every route added similar to rewrites)

[timneutkens]

Closing this in favor of feature request #18485

[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.