Hot reloading not working

[Fusseldieb]

Don't know if a bug or a question, but when I configure Nuxt with i18n, despite me changing the language file, I need to restart the whole server in order for it to update.

I also tried another solution who mentioned something about "lazy: true" and including langDir inside modules @ nuxt.config.js, to no avail. Now the page reloads only once and also doesn't update.

What am I doing wrong? Is Hot Reloading functional inside Nuxt-i18n?

Thanks in advance!

[rchl]

It works for me when using lazy and locale files as jSON files.
Maybe it's specific to your setup. You'd need to provide a reproducible repo.

[Fusseldieb]

It works for me when using lazy and locale files as jSON files.

I jumped over to JS because JSON doesn't allow multilines or line concatinations, and I'm using those to keep thing tidy and organized. And also because it does allow comments, which add further clarity.

My revelant section of nuxt.config.js:

  modules: [
    [
      "nuxt-i18n",
      {
        locales: [
          {
            code: "de",
            name: "Deutsch",
            file: "de.js"
          }
        ],
        // lazy: true,
        langDir: "locales/",
        detectBrowserLanguage: {
          useCookie: false,
          cookieKey: "i18n_redirected"
        }
      }
    ]
  ],
  i18n: {
    locales: ["de"],
    defaultLocale: "de",
    vueI18n: {
      fallbackLocale: "de",
      messages: {
        de: require("./locales/de.js")
      }
    }
  }

(Heavily simplified) de.js:

module.exports = {
"translationKey":"Translation",
"translationKey2":"Translation 2",
...
}

I updated everything using npm update and it still doesn't work. (And honestly, I wasn't expecting it to)

Furthermore, the project also doesn't reflect CSS changes inside .vue files and requires a full page reload, but that's for another question on another repo :)

Thanks in advance

[rchl]

I wouldn't expect the configuration you are using to work with HMR.
You are requiring the file at nuxt config level so it will only be evaluated once and won't be watched.
The solution using lazy should work though.

[rchl]

Can you create a repro repo? Otherwise, I would have to and I don't have time for it :)

[Fusseldieb]

I wouldn't expect the configuration you are using to work with HMR.
You are requiring the file at nuxt config level so it will only be evaluated once and won't be watched.
The solution using lazy should work though.

What should I use instead of require()?

Lazy imo is not made for that particular purpose, it's meant to load translations in chunks when necessary.

Can you create a repro repo? Otherwise, I would have to and I don't have time for it :)

I understand that perfectly, I'll make one later, if we can't solve it ;)

[rchl]

What should I use instead of require()?

It's not so much what you are using but where. nuxt.config is not processed by webpack so imports references there won't be watched.

While I believe there is way to tell Nuxt manually what files to watch, that wouldn't be ideal as it would most likely do a hard reload of the project rather than incremental HMR.

Basically you should try lazy and if that doesn't work then we can go from there.
But another approach that might work is to have a custom plugin that would load the messages manually.

[Fusseldieb]

Basically you should try lazy and if that doesn't work then we can go from there.

I tried lazy to no avail. It refreshes once, but without any noticeable change.

[rchl]

Then create a reproducible repo. It could be that you are using strings in a way that makes reactivity not work.

[Fusseldieb]

Then create a reproducible repo. It could be that you are using strings in a way that makes reactivity not work.

Just created a repo with those exact configurations: https://github.com/Fusseldieb/testi18n

In this repo at least it updates the translations on page reload, but doesn't do on its own.

[rchl]

Do this:

diff --git a/nuxt.config.js b/nuxt.config.js
index 83bd4b4..58c230d 100644
--- a/nuxt.config.js
+++ b/nuxt.config.js
@@ -64,16 +64,16 @@ export default {
       }
     ]
   ],
-  i18n: {
-    locales: ["en"],
-    defaultLocale: "en",
-    vueI18n: {
-      fallbackLocale: "en",
-      messages: {
-        en: require("./locales/en.js")
-      }
-    }
-  },
+  // i18n: {
+  //   locales: ["en"],
+  //   defaultLocale: "en",
+  //   vueI18n: {
+  //     fallbackLocale: "en",
+  //     messages: {
+  //       en: require("./locales/en.js")
+  //     }
+  //   }
+  // },
   /*
    ** Build configuration
    ** See https://nuxtjs.org/api/configuration-build/

The i18n overrides the module configuration as it's an alternative way to configure the module.

[Fusseldieb]

The i18n overrides the module configuration as it's an alternative way to configure the module.

Tried it out and confirmed working, that's awesome, but now I have another problem:

When I access the main page (which has rootDir: "test"), it goes to:
http://localhost:3000/test/de
But when I try to navegate into any of the nuxt-links, it goes to:
http://localhost:3000/test/contact
and gives an 404 error.

If I manually reload that same 404 page mentioned above, it jumps to:
http://localhost:3000/test/de/contact
and works.

My nuxt-links are written that way:
<nuxt-link class="p-4 nuxtlink" to="/contact">{{ $t("header.menu.contact") }}</nuxt-link>

Any help would be greatly appreciated :)

[rchl]

:to="localePath('/contact')" or better :to="localePath('contact')" (a route name rather than the path).

This is documented: https://i18n.nuxtjs.org/basic-usage.html#nuxt-link

[Fusseldieb]

:to="localePath('/contact')" or better :to="localePath('contact')" (a route name rather than the path).

This is documented: https://i18n.nuxtjs.org/basic-usage.html#nuxt-link

Oh wow! Thanks, works just fine! Don't know how I missed that!

I used :to="localePath('/contact')" with the slash instead of the route name alone, because I've seen that it handles it as if it were a relative path, so at one point I got into the path "/contact/contact" and it 404'd.

With the slash I can guarantee that it's absolute and not relative.

Thanks so much for your time. It helped a ton!

[rchl]

I would still suggest using route names instead (even though the path variant is supported) as there are cases where former works when latter doesn't.