fix: Handle inconsistency in Next.js when using usePathname with custom prefixes, localePrefix: 'as-needed' and static rendering

[amannn]

Fixes #1568

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
next-intl-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 25, 2024 6:41pm
next-intl-example-app-router	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 25, 2024 6:41pm
next-intl-example-app-router-without-i18n-routing	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 25, 2024 6:41pm

[amannn]

One rare case where this behavior might not be wanted is this:

const routing = defineRouting({
  locales: ['en'],
  defaultLocale: 'en',
  localePrefix: {
    mode: 'as-needed',
    prefixes: {
      en: '/uk'
    }
  }
});

… and then having a path like /[locale]/en/page.tsx.

In this case, when Next.js prerenders with a pathname set to /en/en, we end up with /en as the unprefixed pathname—that's fine. However, in production, the Next.js pathname will be /en after the rewrite and we'll unprefix this to /.

A potential workaround could be based on useParams(), useSelectedLayoutSegments() etc., but I believe a static path like /en can still not be detected due to only the locale segment being returned from these hooks. So what would be necessary is a hook that returns the actual, internal pathname, but Next.js currently doesn't support that.

So I think for the time being this is a tradeoff that we have to live with.

Therefore to summarize: If you're using a localePrefix mode of as-needed with custom prefixes, make sure you don't use the default locale as a pathname at the root (e.g. /uk/en is unsafe, /uk/english is fine).