Nuxt.js internationalization: i18n vs automatic translation (2026)

Setting up @nuxtjs/i18n: what is actually involved

A minimal nuxt-i18n setup for three languages requires these pieces:

1. 1Install the module and register it in nuxt.config.ts under modules.
2. 2Declare locales, the default locale, and the lazy-loading strategy in the i18n config block.
3. 3Create per-locale JSON files: locales/en.json, locales/fr.json, locales/de.json — one per supported language, updated with every new UI string.
4. 4Replace every hardcoded string in every component with a $t('key') or t('key') call — touching every .vue file in the project.
5. 5Add a locale-switcher component to the navigation; update routing logic for any custom slug pages (e.g. a blog post at /blog/[slug] becomes /fr/blog/[slug] with Nuxt i18n routing).

A minimal nuxt.config.ts i18n block:

And a corresponding locales/en.json:

Every key must be duplicated and translated in fr.json and de.json — and kept in sync forever as the product evolves.

The compounding maintenance cost

The per-string overhead is small in isolation. The aggregate cost across a real product compounds quickly:

When @nuxtjs/i18n is the right choice

There are specific situations where the full module stack is clearly justified:

Adding Lingvit to a Nuxt 3 app

The alternative is a script tag — no module installation, no locale files, no component changes. For Nuxt 3, add the script via the app.head property in nuxt.config.ts:

Alternatively, use the useHead composable inside your root app.vue if you prefer component-level control:

That is the entire integration. Lingvit's widget uses a MutationObserver to watch the DOM after Nuxt renders and hydrates. It handles:

• Server-rendered HTML streamed from Nuxt's SSR engine — translated immediately once hydration is complete.
• Reactive Vue updates — content revealed by v-if, rendered by v-for, or loaded via async data fetching is translated as new nodes appear in the DOM.
• Vue Router navigation — Nuxt's client-side route transitions trigger the observer for the newly rendered page content.
• RTL layout — document.documentElement.dir is set automatically when switching to Arabic, Hebrew, or another RTL language.

Setup comparison

When automatic translation is enough

For many Nuxt projects, DOM-based translation is not a compromise — it is the right engineering decision:

What automatic translation does not cover

DOM-based translation has real limits. Understand them before choosing:

Frequently asked questions

Does Lingvit work with Nuxt 3 and Nuxt 4?

+

Yes. Lingvit is framework-agnostic and operates at the DOM level. Both Nuxt 3 and Nuxt 4 produce standard HTML that the widget observes via MutationObserver. Add the script via app.head.script in nuxt.config.ts with tagPosition: 'bodyClose' and it works out of the box.

Does Lingvit work with Nuxt SSR?

+

Yes. Nuxt's server-rendered HTML is sent to the browser, then Vue hydrates it. Lingvit initialises after hydration is complete and picks up all text nodes from the rendered DOM — whether they came from the server or from client-side state changes.

Will Lingvit interfere with Vue hydration?

+

No. The Lingvit script loads asynchronously after the DOM is ready and waits for the page to stabilise before translating. It does not touch the virtual DOM, does not modify component state, and does not trigger Vue reactivity — it only modifies rendered text nodes.

Can I use @nuxtjs/i18n alongside Lingvit?

+

Yes. If you already have @nuxtjs/i18n for some content and want automatic translation for the rest, the two can coexist. Lingvit translates whatever text nodes are in the DOM at render time, including strings already translated by nuxt-i18n.