lazy load files not working

[userquin]

Environment

npx nuxi info
Nuxi 3.6.1                                                                                                                                                                18:48:21
                                                                                                                                                                          18:48:21
RootDir: D:/work/projects/userquin/GitHub/userquin/vuetify-nuxt-module-main                                                                                               18:48:21
Nuxt project info:                                                                                                                                                        18:48:21

------------------------------
- Operating System: Windows_NT
- Node Version:     v18.16.0
- Nuxt Version:     3.6.1
- Nitro Version:    2.5.2
- Package Manager:  pnpm@8.6.5
- Builder:          vite
- User Config:      -
- Runtime Modules:  -
- Build Modules:    -
------------------------------

Reproduction

Fork https://github.com/userquin/vuetify-nuxt-module/ and then chekout feat-add-i18n-support branch:
https://github.com/userquin/vuetify-nuxt-module/tree/userquin/feat-add-i18n-support (I'm working in the PR to add i18n support to Vuetify 3)

Run pnpm install, and then you can run:

• nr dev:prepare && nr dev: for single json file per locale
• nr dev:prepare:multiple-json && nr dev:multiple-json: for multiple json files per locale

Describe the bug

Cannot load lazy translation files other than the default/fallback locale.

Additional context

I'm preparing a PR to fix the error, PR in a few minutes.

Logs

No response

[agracia-foticos]

with new beta 13 not runs yet :(

[kazupon]

I've reverted #2193

@userquin
I’m sorry for the issue you are going through.
Could you please give a reproduction again?

[userquin]

@kazupon you can clone the repo, remove the pnpm patch and update manually the i18 module: remove this 3 lines https://github.com/userquin/vuetify-nuxt-module/blob/main/playground/pages/index.vue#L61-L63

[userquin]

@kazupon it seems we've a problem using i18n to get old locale when calling loadAndSetLocale in the locale-changing middleware, the old locale always gets the new locale.

I guess we need to calculate the old and the new locales from the to and from routes in the middleware; if I enable alwaysRedirect: true and redirectOn: 'all' there is no way to switch the locale: the call to detectLocale in the middleware will always return the first lang matched in the browser.

I'm using a v-select component to swtich the locale in my vuetify nuxt playground (a selector) and I need to use this logic to switch the locale:

    const route = useRoute()
    const router = useRouter()
    const switchLocalePath = useSwitchLocalePath({ route, router, i18n })
    watch(current, (l) => {
      router.push({ path: switchLocalePath(l) })
    }, { immediate: true })

If I hack the old locale in the browser dev tools inside the loadAndSetLocale, it is working, the new locale json file is there.

[userquin]

This is the i18n configuration:

i18n: {
    locales: availableLocales,
    lazy: true,
    strategy: 'prefix',
    detectBrowserLanguage: {
      fallbackLocale: 'en-US',
      useCookie: false,
      // alwaysRedirect: true,
      // redirectOn: 'all',
    },
    langDir,
    defaultLocale: 'en-US',
    // types: 'composition',
    // pages: undefined,
    dynamicRouteParams: true,
    skipSettingLocaleOnNavigate: false,
    debug: true,
    vueI18n: './config/i18n.config.ts',
  },

[userquin]

I'll check it in the playground here...

in the playground seems to be working, but getting missing japanese entry:

[userquin]

about the null and missing entries, I can see this weird encodings using this middleware:

nuxt.hook('vite:serverCreated', viteServer => {
      viteServer.middlewares.stack.unshift({
        route: '',
        // @ts-expect-error just ignore
        handle: (req, res, next) => {
          const url = req.url
          let idx = url?.indexOf('@nuxtjs/i18n/')
          if (idx > -1) {
            console.log('url', { url, idx })
          }
          next()
        }
      })
    })

[kazupon]

@userquin

Thank you for your working which find out cause!
I’ve also confirmed your repo.

The reason for the lazy loading not working is that the oldLocale obtained with getLocale(i18n) has already changed at the time of loadAndSetLocale.
getLocale(i18n) gets the locale from the vue-i18n instance.

If we are using the no_prefix strategy, you must change the locale manually with setLocale.

I tried using setLocale in your reproduction repo, but the value retrieved with getLocale(i18n) had already changed.
This is not expected behavior for a nuxt i18n module.

I seem that the useLocale behavior provided by vuetify is affecting the vue-i18n side.
I think we need to understand vuetify's i18n behavior in order for it to work properly with the vuetify nuxt module.

[userquin]

So, we cannot use the locale as model from useI18n. I also test it using prefix, and prefix except default.

I will change the logic and update the documentation.

[userquin]

I seem that the useLocale behavior provided by vuetify is affecting the vue-i18n side.
I think we need to understand vuetify's i18n behavior in order for it to work properly with the vuetify nuxt module.

I have a custom module for it, check src/runtime/plugins/i18n.ts module, current vuetify i18n integration is broken since it is using i18n.global and cannot be used with i18n nuxt module.

You can test my repo exposing a new ref and changing the value (also add the import import type { Locale } from 'vue-i18n' ):

// src/runtime/plugins/i18n.ts
  const messages = i18n.messages 
// add this in L22
  
  const currentLocale = ref<Locale>(current.value)
  const route = useRoute()
  const router = useRouter()
  const switchLocalePath = useSwitchLocalePath({ route, router, i18n })

  watch(currentLocale, (l) => {
    // i18n.setLocale(locale)
    router.push({ path: switchLocalePath(l) })
  }, { immediate: true })

then replace current with currentLocale in the adapter:

vuetifyOptions.locale.adapter = {
    name: 'nuxt-vue-i18n',
    current: currentLocale, // <=== we can use it in the index.vue page
    fallback,
    messages,
    t: (key, ...params) => i18n.t(key, params),
    n: i18n.n,
    provide: createProvideFunction({ current, fallback, messages }),
  }

// src/pages/index.vue
  <v-select
      v-model="current" // <=== change the locale to use it from `useLocale`
      :items="locales"
      item-title="name"
      item-value="code"
      outlined
    />

[userquin]

@kazupon it seems to be working using edge version in my local, I'll send an update to my vuetify repo: added a few changes to avoid changing i18n local directly using setLocale and listening to changes viai18n:localeSwitched hook.

[kazupon]

@userquin
Thanks for your sharing.
I hope your nuxt module works well :)

[sauravbv]

Following, have the same issue

All locale files are loading even though the lazy option is set true. Below is my i18n config.
Using version 8.0.0-beta.13

i18n: {
    vueI18n: 'i18n.config.ts',
    strategy: 'no_prefix',
    detectBrowserLanguage: {
      useCookie: false
    },
    locales: [
      {
        code: 'da',
        file: 'da.json'
      },
      {
        code: 'en',
        file: 'en_US.json'
      },
      .
      .
 // some more locales all in .json files
    ],
    lazy: true,
    langDir: 'locales',
    defaultLocale: 'en',
    experimental: {
      jsTsFormatResource: true
    }
  }

[kazupon]

@sauravbv
It has fixed nuxt i18n edge channel latest version.
You can try to install 8.0.0-beta.13-28175294.3a94c60

[BobbieGoede]

This issue is still present in builds, it looks like lazy loaded locales are all loaded on page load as prefetch scripts (this can be confirmed by building playground and checking page source).

I think the discussion in issue #1875 is on the right track, and nuxt-contrib/vue-bundle-renderer#50 could make it possible to prevent prefetching/preloading, but I think Nuxt needs to include this change first.

In the meantime I will look into making the lazy loading tests more robusts, right now they only test whether lazy loaded files are loaded, not whether they are loaded on demand.

[sauravbv]

Yes, recently tried with edge versions and the latest 8.0.0-rc-2 have the same issue.

I am trying a lot to optimise page load performance. Translations are being used only in some components and these components are not being used always as my page is dynamic. Is there a way to load the i18n module only when that component is used? Right now I have added nuxtjs/i18n part of modules in nuxt.config and it's contributing to the size of the entry file, trying to reduce the entry.js file size. Any suggestion/help is appreciated.
Thank you :)

[kazupon]

I’m back from short vacation.

nuxt-contrib/vue-bundle-renderer#50 could make it possible to prevent prefetching/preloading, but I think Nuxt needs to include this change first.

I checked nuxt v3.7 PR.
As far as I can see, that PR does not seem to included the vue-bundle-renderer resolved issue. /cc @danielroe
nuxt/nuxt#22222

[danielroe]

Have you tested with the edge channel? We should have updated to v2 of vue-bundle-renderer there. You can hook into the build:manifest hook and add .prefetch = false to the manifest to disable resource hints being rendered in the HTML.

(It's also possible that vite injects prefetch links on the client-side in some situations.)

[kazupon]

Thank you for your mention about it.

We have already PR that can confirm it.
#2294

@BobbieGoede
Could you update #2294 please?

[BobbieGoede]

@kazupon @danielroe
Can confirm that the Nuxt edge channel includes vue-bundle-renderer: 2.0.0, updated #2294.

After installing the edge version I did run into a different issue and had to add an override for h3 to set it to 1.8.0-rc.3 as it kept throwing errors, I think this may be related to vitest or the test-utils, not sure.

[danielroe]

@BobbieGoede Yes, this is the case at the moment as edge channel currently relies on prerelease versions of both nitro/h3. Your workaround is correct, and won't be needed once next nitro version is released.