Multiple issues related to ii18n (redirects, localeDetection)

[suckydev]

next.config.js:

module.exports = {
  trailingSlash: true,
  i18n: {
    locales: ["en", "de"],
    defaultLocale: "en",
  },
  async redirects() {
    return [
      {
        source: "/en/:path*",
        destination: "/:path*",
        permanent: true,
      },
    ];
  },
}

1st Issue
the issue I mentioned in #20165 is still not working for me (upgraded to 10.0.4). only the issue related to the trailingSlash seems to be fixed for me.

Examples:

• I go to /en/, I am not redirected to /, instead I stay on /en/
• I go to /en/some-page/, I am not redirected to /some-page/, instead I stay on /en/some-page/

2nd Issue
In my opinion, localeDetection is not working properly, when it includes a region.

Example:

• I set the browser language to "de-at" in FF
• I go to /, I am not redirected to /de/, instead I stay on /

however, it works when the browser language is explicitly set to "de" only. but when it includes a region (e.g. Austria) like in the example above, it is not working.

3rd Issue
In my opinion, localeDetection also creates a bad user experience.

Example:

• I set the browser language to "de" in FF
• I go to / it redirects to /de/ (this is fine)
• I click the link "Go to EN", I am redirected to / (this is fine, as I explicitly want to browse the EN version)
• I refresh the browser (for whatever reason), I get redirected back to /de/ instead of staying on /

<Link href="/" locale="en">Go to EN version</Link>

is this intended?

I feel like when a user explicitly decides to navigate to a different locale, localeDetection should be deactivated during that session, or preferably even set a cookie that prevents localeDetection when the user comes back to the site in the future. this also shouldn't be any issue for SEO.

[iduuck]

Regarding first issue: This goes in one with the third issue you are talking about. So, you tell in the third issue, that there is a "bad user experience". But the first issue states the complete opposite (as far as I understand your issues). If you are explicitly navigating to the "/en" route, I – as a user – don't want to be redirected to the "de" route. Instead, it would be nice by you to create something like a banner, and tell the user "Hey, we saw that you are german, would you like to view the page in german".

apple.com has a client-side detection which then shows a message asking if you want to change to a different locale. If there's enough interest in this type of solution we can provide tools for this approach as well.

– Quote from I18n RFC

Regarding second issue: I suppose (as far as I can read from the official specs – since Next.js is using the @hapi/accept package for leveraging the Accept-Language header) that this is indeed the right behavior. However, I am completely with you, that this should not be the case.
I don't know completely how the browsers treat the headers explicitly, but normally browsers like Chrome and Firefox should also send the "de" flag as a lower quality to the user agent. So it would look somehow like this:

de-AT,de;q=0.9,en-US;q=0.8,en;q=0.8

Regarding your third issue: Indeed there is a cookie, that should be set, when the user visits a locale specifically. However, I am also not able to make it work for me on my application.

Added with Edit 2: The cookie cannot properly work (or at least, is only working for custom domains for each locale right now), because this commit just ticked the variable which causes the cookie to be set to "false"

---

Edit 1: Add a reference to @hapi/accept package.

Edit 2: Add reference why cookie is not working to third issue.

[suckydev]

hi iDuuck,

thanks for your response & help! :)

Regarding first issue: the first issue and the third issue are not related. the first issue says /en/ should default to /, because "en" is set as the defaultLocale, so there's no need to have:

• /en/ and /, or
• /en/some-page/ and /some-page/

because they all serve the same language version.

Regarding second issue: hmm, not sure then, to be honest. I just set the browser language to "de-at" in FF and it did not work, only when I added "de" as well.

Regarding third issue: I think I'll just set localeDetection to false for now, and simply show a banner to the user notifying them that they can browse the site in a different locale, providing them a link.

[suckydev]

hi, thanks for the message. issue still persists, though. not sure if it will ever be fixed. I’ll just avoid the issue for now by setting the correct canonical tag in order to avoid duplicate content. cheers

…

On 12.01.2021, at 7:02 AM, kiriorange ***@***.***> wrote:  Hey regarding issue 1, I saw that ijjk fixed it 2 weeks ago and should be resolved in v10.0.5-canary.3 #18335 (comment) I've tested and it works for me. See if it fixes your problem! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[strangedev]

We're also experiencing problems related to the locale detection.
In our example, our content is in de-de and we request de-LI,de. According to RFC 4647 this should match de-de, because de is a prefix of de-de.
It seems, however, that only exact matches work at the moment.

Our next.config.js looks like this:

// eslint-disable-next-line strict
'use strict';

const { processenv } = require('processenv');
const trailingSlash = processenv('TRAILING_SLASH', false);
const i18n = {
  locales: [ 'en-us', 'de-de' ],
  defaultLocale: 'en-us'
};

const configuration = {
  trailingSlash,
  i18n
};

module.exports = configuration;

Our accept-language header looks like this:

de-LI,de;q=0.9,en-US;q=0.8,en;q=0.7

[strangedev]

There's now a PR in hapijs/accept#64 which fixes matching of a more specific language tag if a less specific one is requested 🎉

[dotKuro]

The Problem is now fixed in @hapi/accept v5.0.2. Updating the dependency should fix the faulty detection, when only requesting a prefix. i.e: When requesting de your page will now also ship de-de.

[chrillep]

any update on this? "next": "^10.1.3" using "@hapi/accept": "5.0.1",

[chrillep]

next v10.2.0 still "@hapi/accept": "5.0.1", 😊 6b97bce#diff-9c1a3867443c54525b4f24ef171f231a6e8bb065ffc8b7b62c4843d5ff62dd42L66

[timneutkens]

next v10.2.0 still "@hapi/accept": "5.0.1", 😊 6b97bce#diff-9c1a3867443c54525b4f24ef171f231a6e8bb065ffc8b7b62c4843d5ff62dd42L66

Feel free to open a PR

[Lunnatica]

@timneutkens there seem to be two PRs already created for this: #24283 and #23142

I can open a new one if these are outdated.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.