Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locale prefix should be removed from Link href with 'as-needed' middleware #647

Closed
gkielwasser opened this issue Nov 18, 2023 · 4 comments
Closed
Labels
bug Something isn't working unconfirmed Needs triage.

Comments

@gkielwasser
Copy link

gkielwasser commented Nov 18, 2023

Description

Go on a page with a local that is not the default locale.
The Link href is not respecting setting 'as-needed' from middleware and therefore is displaying the local prefix from the default local.

Mandatory reproduction URL (CodeSandbox or GitHub repository)

sandbox

Reproduction description

Steps to reproduce:

  1. Click on "de" link
  2. check the link for "en" link
  3. See displayed href is '/en/about' instead of '/about'

Expected behaviour

Whatever the current local is, the Link href should not display the local prefix with 'as-needed' middleware.

@gkielwasser gkielwasser added bug Something isn't working unconfirmed Needs triage. labels Nov 18, 2023
@gkielwasser gkielwasser changed the title Localeprefix should be removed in Link href with 'as-needed' middleware Locale prefix should be removed from Link href with 'as-needed' middleware Nov 18, 2023
@amannn
Copy link
Owner

amannn commented Nov 20, 2023

The link points to /en/about only when you're on the de locale. This is required, because we don't know about the as-needed strategy of the middleware in this situation. However, clicking on the link will result in the correct URL.

Note that this only applies if you're switching the locale. If you're already on the en locale (i.e. no prefix in your case), then the link will point to /about. This optimization can be achieved because if we're on the client side, the current locale is en and we notice that it is not present in the URL, then the strategy must be as-needed.

I'm closing this since this is already working as intended. In 3.0 we've switched the default for localePrefix to always since it's a better default that avoids edge cases like this.

Hope this helps!

@amannn amannn closed this as completed Nov 20, 2023
@zipme
Copy link

zipme commented Nov 28, 2023

hi @amannn , because we are using domains setting and because one domain corresponds to one language so we set localePrefix: "never". However, when using the <Link> component from createLocalizedPathnamesNavigation, the ssr version of the <a>, the href is always prefixed with the locale, but once it's hydrated the prefix is gone, this would have certain impact on the SEO.

I forked the above sandbox and changed the localePrefix: "never", as you can see from this sandbox that the en link, when hovered, shows /about, but if you go check the source code it has locale prefix in it.

<a hrefLang="en" style="padding:4px;font-family:system-ui, sans-serif;line-height:1.5" href="[/en/about](https://ghtsqf-3000.csb.app/en/about)">en</a>

Besides this, is there a way to not auto redirect to the unprefixed version and localized path? Current if you visit /en/about-us it got redirected to /about-us, and if you have localized path and visiting a path from another language it got redirected to the path of the current language. Is there a way to just yield 404 instead of 307 redirect?

Thanks a bunch!

@amannn
Copy link
Owner

amannn commented Nov 28, 2023

@zipme This is discussed here: #444

@gkielwasser
Copy link
Author

as-needed

hi @amannn

I'm not sure to understand "because we don't know about the as-needed strategy of the middleware in this situation". LocalePrefix strategy isn't something decided at project layer ? Why it should be inferred from somewhere, appart from project config?

In the meantime to avoid all my pages not using the default languages, and that are pointing to the default locale, having a "known in advance" redirection, I had to use a wrapper arround next-intl Link to use either next-intl Link or Next default Link.

something like this

import NextLink from 'next/link'
import { Link as IntlLink } from "/utils/navigation"

const _Link = ({
   locale,
   ...props
}) => {
 const locale = useLocale()

 const isDefaultLocale = locale === DEFAULT_LOCALE
 const useNextLink = !isDefaultLocale && (props.locale === DEFAULT_LOCALE)
 const Link = useNextLink ? NextLink : IntlLink 
 
return <Link
  {...props}
 />
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working unconfirmed Needs triage.
Projects
None yet
Development

No branches or pull requests

3 participants