nuxt-modules / i18n

I18n module for Nuxt
https://i18n.nuxtjs.org
MIT License
1.72k stars 477 forks source link

detectBrowserLanguage and alwaysRedirect unclear routing logic (reopened) #3154

Open BobbieGoede opened 2 days ago

BobbieGoede commented 2 days ago

Originally #3048 by @spiritius - was incorrectly converted to a discussion by me 😬

Environment

- Operating System: Darwin
- Node Version:     v22.3.0
- Nuxt Version:     3.12.4
- CLI Version:      3.12.0
- Nitro Version:    2.9.7
- Package Manager:  npm@10.8.1
- Builder:          -
- User Config:      compatibilityDate, runtimeConfig, srcDir, dir, app, css, modules, i18n, vite
- Runtime Modules:  @nuxtjs/tailwindcss@6.12.1, @nuxtjs/i18n@8.3.3
- Build Modules:    -

Reproduction

Describe the bug

Hi!

When using the prefix_and_default strategy and the detectBrowserLanguage option, the redirect logic is unclear.

Current behavior:

site.com/ β†’ click NL β†’ site.com/nl β†’ change url manually to site.com/ β†’ get site.com/nl

What I expected from the parameter alwaysRedirect: false:

site.com/ β†’ click NL β†’ site.com/nl β†’ change url manually to site.com/ β†’ get site.com/

Am I doing something wrong? Is there any way to fix this in nuxt.config.ts?

Additional context

// nuxt.config.ts
i18n: {
  vueI18n: '~/app/i18n/i18n.config.ts',
  baseUrl: process.env.BASE_URL,
  locales: [
    { code: 'en', iso: 'en-US', name: 'English' },
    { code: 'nl', iso: 'nl-NL', name: 'Nederlands' }
  ],
  defaultLocale: 'en',
  strategy: 'prefix_and_default',
  detectBrowserLanguage: {
    fallbackLocale: 'en',
    useCookie: true,
    cookieKey: 'lang',
    alwaysRedirect: false,
    redirectOn: 'all'
  }
}

// i18n.config.ts
import en from './locales/en.json'
import nl from './locales/nl.json'

export default defineI18nConfig(() => ({
  legacy: false,
  locale: 'en',
  fallbackLocale: 'en',
  globalInjection: true,
  messages: {
    en,
    nl
  },
  missingWarn: false, 
  fallbackWarn: false,
}))

Logs

No response

BobbieGoede commented 2 days ago

Honestly not entirely sure whether this is a bug as the documentation does not describe the intended behavior in a very clear way.. Will need to look into this further.