[feature] Custom Locale Routes in i18nConfig

[iRajatDas]

The current architecture effectively serves its purpose, but I propose an enhancement to grant users more control over locale accessibility via routes. This enhancement would allow users to customize how locales are accessed via routes, offering greater flexibility and control.

Proposed Solution

I suggest implementing a new key-value pair within the i18nConfig file specifically for defining custom paths for each locale.

Example:

const i18nConfig = {
  locales: [
    { locale: "en", route: "en-908" }, // domain.com/en-908,
    { locale: "it", route: "it-138" }, // domain.com/it-138,
    { locale: "hi" }, // domain.com/hi,
  ],
  defaultLocale: "en",
  prefixDefault: true,
} as const;

export default i18nConfig;

Use case

This feature is particularly beneficial for SEO purposes, as it allows for quick adjustments to routes, such as addressing copyright infringement issues.

[i18nexus]

Thanks for reaching out. This is the first time we've received a request for this. Can you explain the use case further? I'm not sure I understand. How would this be beneficial for SEO and copyright infringement issues?

[iRajatDas]

For example when changing the language on the site y2mate.com, you may notice that the URLs contain a numeric suffix after the locale, like https://domain.com/hi922.

This practice is common among content downloading sites due to copyright claims and DMCA strikes. In response to such complaints, these sites often implement URL redirects, leading from the previous URL to a new one, like https://domain.com/hi923.

While this may not be a preference for most users, it highlights the need for flexibility in defining path names for each route. By introducing an option to modify the path name for each route, we can cater to such use cases effectively.

[Flavien-Pensato]

Can't you do "/it/138" or "/it/it-138" ?

[iRajatDas]

Can't you do "/it/138" or "/it/it-138" ?

I have already tried that, but doing this would not be a good idea because of the following:

Example Routes:

Hindi -> /hi/100 Italian -> /it/201

In this case, users can also visit the 201 page via /hi/201 or vice versa.

[Flavien-Pensato]

I understand but isn't the same as "Italian -> /it-201 or Hindi -> /hi-201". In my opinion and with your context, I suggest to not even use [next-i18n-router]. You can easily implement a local detection https://nextjs.org/docs/app/building-your-application/routing/internationalization by your own and I don't think you need a default locale either (like /201 to /hi-201)

[i18nexus]

@iRajatDas I agree that you should simply use paths like /hi/100 and /it/201.

If you're worried about users visiting /hi/201 all you need to do is add something like this to the top of your 201 page component:

if (locale !== 'it') {
  notFound();
}

If we get more requests for this, we'll consider implementing it. This is a very unique use case. This feature would add complexity that will have to be maintained and dealt with for all future updates to next-i18n-router. In the meantime I'm going to mark this issue as Not Planned. Thanks for your feedback though.