New beta localised pathnames feedback/possible bug report

[agustif]

Is your feature request related to a problem? Please describe.

Hi aman! Impressive work, I would like to report I've been having some trouble where I think the new implementation is assuming defaultLocale is english. I want to use my defaultLocale as another language (spanish) but the routes are not working if they're on the /root so I can make /login -> /cuenta/registro but !!-> /registro with defaultLocale es

I also think the current implementation assumes the name of the default filename/path is in the defaultLocale, but I would like to name my page login.tsx, and have it defaultLocale to /entrar in spanish.

I also think it's a bit wonky anything that's not 'always' in locale-prefix, both never and as-needed don't seem to work on similar cases.

Anyways all workable with work arounds but wanted to report my (findings?) happy to help debug or put up a reproduction repo if that's more useful.

Describe the solution you'd like

Be able to use different defaultLocale than english, and decouple file naming from defaultLocale

Describe alternatives you've considered

Working around using always prefix (I'd rather not use it if Im localising all paths.

Another one is with always I cannot tell in navigation that the base path should not get it, so the hompeage remains .com/ sans locale regardless of the language. Worried about not having anything on the homepage and always redirecting to a locale path being bad for SEO on the long term?

[amannn]

Thank you for trying out the new pathnames localization and reporting your initial findings! The pathnames are designed to support internal pathnames that are different from the default locale, so this should work in theory.

Can you share your exact configuration and the requests which don't seem to work for you?

There's quite an extensive test suite for the feature, if you feel like it, you can also directly submit a failing test case:

• Middleware (localized pathnames for localePrefix: 'as-necessary')
• createLocalizedPathnamesNavigation

I also think it's a bit wonky anything that's not 'always' in locale-prefix, both never and as-needed don't seem to work on similar cases.

There are test cases for these (also in middleware.test.tsx), but I might have missed something. It should definitely work!

not having anything on the homepage and always redirecting to a locale path being bad for SEO on the long term?

That should be fine!

[agustif]

I will make sure to try and take a look at the codebase/tests and reproduce there, I might be also using it wrong and have already worked my way around some things.

Btw it's working wonderfully for translating MDX based content too just having several files/folders for each locale. with contentlayer (using taxonomy/shadcn as base for it)

So I can translate pages, docs, guides, and it's pathnames too ;)

For example to whitelist all i18n pathnames with next-auth I do it like this:

import {  pathnames } from './navigation';

// const locales = ['en', 'de'];

const publicPages = [
  '/',
  '/login',
  '/privacy',
  '/register',
  '/blog',
  '/docs',
  '/guides',
  '/terms',
  '/privacy',
];

// add all pathnames that are translations and should be public by matchin the ones from pathnames and public Pages


const allPublic = [...publicPages, ...Object.values(pathnames).map((value: any)  => {
  if(typeof value === 'string') {
    return value;
  } else {
    return Object.values(value);
  }
}
).flat()];

so it also gets the translations of whitelisted key public pages.

Then for the latest point and being able to link to the translated path I require it when building the links and call it with current locale for the path I need like this:

import { pathnames } from "@/navigation"

...
  const { locale } = useParams();

 <Link href={pathnames['/terms']?.[locale]}>

Which returns the fully localised path like /es/terminos or /en/terms or whatever.

So far have been a really smooth experience to set up so thank you for this!

[amannn]

Btw it's working wonderfully for translating MDX based content too just having several files/folders for each locale. with contentlayer (using taxonomy/shadcn as base for it)

Super cool, that's a nice use case!

Then for the latest point and being able to link to the translated path I require it when building the links and call it with current locale for the path I need like this:

import { pathnames } from "@/navigation"

...
  const { locale } = useParams();

 <Link href={pathnames['/terms']?.[locale]}>

Which returns the fully localised path like /es/terminos or /en/terms or whatever.

That should be automatically handled by the new localized navigation APIs with something like this:

import { Link } from "@/navigation"

...

 <Link href="/terms">

So far have been a really smooth experience to set up so thank you for this!

That's so nice to hear! 🙌

---

I'll add the reproduction missing label for now. I've just added a new "App Router (RSC beta)" issue reproduction template, please feel free to submit a reproduction in case you're experiencing something that doesn't behave as intended!

[github-actions]

Thank you for your report.

Unfortunately, the reproduction is missing or incomplete, and as such we cannot investigate this issue. Please add a reproduction to the issue, otherwise it will be closed automatically.

Templates:

• CodeSandbox (app directory)
• CodeSandbox (app directory, RSC beta)
• CodeSandbox (pages directory)

Creating a good bug report takes time.

To help us resolve the issue quickly, please simplify the reproduction as much as possible by removing any unnecessary code, files, and dependencies that are not directly related to the problem. The easier it is for us to see the issue, the faster we can help you.

Apart from the reproduction, make sure to include the precise steps on how to reproduce the issue, e.g.:

1. Open reproduction
2. Click on …
3. See error: …

Thank you for your understanding!

FAQ

"I've included a reproduction, what is missing?"

This comment might have been added because your reproduction doesn't point to either a CodeSandbox or a public GitHub repository where the issue can be reproduced.

Please make sure:

1. If you've linked to a CodeSandbox, make sure to save the latest changes.
2. If you've linked to a GitHub repository, make sure that you've committed and pushed the latest changes.
3. Linking to other resources, e.g. to the docs, unfortunately doesn't help to reproduce your issue.

[jokull]

Not sure if this is related but it looks like my default locale is included when using next-intl/link in the initial server response - but when viewing the DOM they have been properly rendered without my default locale prefix. This is causing some warnings in my Semrush SEO reports. Not a huge issue but would be great to fix.

[amannn]

@jokull This is discussed in #444

[github-actions]

This issue has been automatically closed because it is missing a reproduction and there hasn't been any activity for 7 days. If the problem persists, please create a new bug report.