Nuxt i18n: How can I maintain the updated language prefix when using browser back?

Below is one approach to resolving a browser back–navigation issue with language prefixes in Nuxt with i18n. When you call setLocale, the module changes the URL (e.g. /en/about → /id/about) and updates the current locale, but if the page is cached in the history, navigating back can restore a route with the old locale prefix. You can solve this by ensuring that on route entry the locale is synchronized with the stored (or expected) value. Here are a few recommendations:

---

1. Use a Navigation Guard for Locale Synchronization

Create a middleware that on every route change reads the locale (from the URL or cookie) and calls setLocale if they do not match. For example, you could create a middleware (e.g. middleware/locale.js):

JSCopied
export default defineNuxtRouteMiddleware((to, from) => {
  const { locale, setLocale } = useI18n()
  // Assume your route param for language is called "lang" (if using i18n routing)
  const targetLocale = to.params.lang || 'en'

  if (locale.value !== targetLocale) {
    setLocale(targetLocale)
  }
})

Then register your middleware in your nuxt.config.ts:

TSCopied
export default defineNuxtConfig({
  router: {
    middleware: ['locale']
  },
  modules: ['@nuxtjs/i18n'],
  i18n: {
    lazy: true,
    strategy: 'prefix',
    locales: [
      { code: 'en', iso: 'en', name: 'English', file: 'en.json' },
      { code: 'id', iso: 'id', name: 'Indonesia', file: 'id.json' }
    ],
    defaultLocale: 'en',
    detectBrowserLanguage: {
      useCookie: true
    },
    vueI18n: './i18n.config.ts'
  }
})

With this middleware, whenever a route is entered—even via browser back—the locale will be updated and the translations will be correctly applied.

---

2. Force Re-render on URL Change

If the above isn’t sufficient (for example, if the component cache is causing stale content), you might consider forcing a re-render on route changes by using a unique key on your <router-view>:

HTMLCopied
<template>
  <router-view :key="$route.fullPath" />
</template>

Using the full path as a key ensures that even if a route returns to a previous URL, the component re-renders and re-applies the current locale.

---

3. Confirm Your Cookie & Detection Setup

Your configuration with detectBrowserLanguage using cookies is correct. However, keep in mind that browser back might not trigger a full reload, so the cookie might not force reinitialization as expected. That’s why handling route entry with middleware is usually a more reliable fix for language consistency.

---

Summary

The core issue is that the browser history can hold a cached version of the previous route (with the previous locale prefix) even after you’ve changed the locale via setLocale. Using a navigation guard ensures every route entry checks and updates the locale correctly. In addition, forcing a re-render or synchronizing the route parameters with the locale can help guarantee that the language prefix shown in the URL and the active locale always match.

Give this approach a try; it should help keep the language prefix consistent even when using the back button.