You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
• The default locale (en) should not show the "/en" prefix in server‐rendered HTML (SSR).
• When browsing in the browser’s DevTools Elements tab, we indeed see links like href="/book-a-demo" for English.
Actual behavior:
• In “View Page Source” (or if we do curl https://www.example.com), the SSR HTML has href="/en/book-a-demo" for English pages.
• This means search engine crawlers (Ahrefs, etc.) detect "/en/..." and flag them as redirects.
• After hydration on the client, the final DOM changes them to "/book-a-demo", but the raw SSR output still has "/en/".
We’ve verified there are no explicit references to "/en/" in our code (we searched the repo). Our localePrefix: "as-needed" is supposed to hide the default-locale prefix. However, SSR is still injecting "/en/".
Verifications
I've verified that the problem I'm experiencing isn't covered in the docs.
Unfortunately, we don’t currently have a public minimal repo reproducing this. But here are some relevant code snippets from our real project. We can try to create a smaller reproduction if needed
• We do not have a built-in Next.js i18n block in next.config.mjs.
• Screenshot of “View Page Source” with /en/book-a-demo (attached).
• Screenshot of “Elements tab” showing "/book-a-demo" (attached).
Expected behaviour
We believe localePrefix: "as-needed" should prevent "/en/" from appearing at SSR for the default locale. Yet the SSR HTML still includes "/en", while the client re-hydrates to the correct "/". Any guidance on how to ensure the SSR output fully omits "/en/" for English would be very appreciated!
Thank you for your time!
The text was updated successfully, but these errors were encountered:
Description
We’re using Next-Intl in our Next.js 14.2.13 project to support multiple locales. Our default locale is English (en), and in routing.ts we set:
Expected behavior:
• The default locale (en) should not show the "/en" prefix in server‐rendered HTML (SSR).
• When browsing in the browser’s DevTools Elements tab, we indeed see links like href="/book-a-demo" for English.
Actual behavior:
• In “View Page Source” (or if we do curl https://www.example.com), the SSR HTML has href="/en/book-a-demo" for English pages.
• This means search engine crawlers (Ahrefs, etc.) detect "/en/..." and flag them as redirects.
• After hydration on the client, the final DOM changes them to "/book-a-demo", but the raw SSR output still has "/en/".
We’ve verified there are no explicit references to "/en/" in our code (we searched the repo). Our localePrefix: "as-needed" is supposed to hide the default-locale prefix. However, SSR is still injecting "/en/".
Verifications
Mandatory reproduction URL
Unfortunately, we don’t currently have a public minimal repo reproducing this. But here are some relevant code snippets from our real project. We can try to create a smaller reproduction if needed
Reproduction description
<a href="/en/book-a-demo" class="...">Discover our Global Benefits</a>
That’s not what we expect for the default English locale.
<a href="/book-a-demo" class="...">Discover our Global Benefits</a>
which is correct.
Expected Behaviour
• The server‐rendered HTML should show href="/book-a-demo" for the default locale, matching localePrefix: "as-needed".
Additional Details / Screenshots
• Our next.config.mjs:
• We do not have a built-in Next.js i18n block in next.config.mjs.
• Screenshot of “View Page Source” with /en/book-a-demo (attached).
• Screenshot of “Elements tab” showing "/book-a-demo" (attached).
Expected behaviour
We believe localePrefix: "as-needed" should prevent "/en/" from appearing at SSR for the default locale. Yet the SSR HTML still includes "/en", while the client re-hydrates to the correct "/". Any guidance on how to ensure the SSR output fully omits "/en/" for English would be very appreciated!
Thank you for your time!
The text was updated successfully, but these errors were encountered: