Install and Setup

@the-i18n-kit/nuxt is the kit's fourth surface, alongside the CLI, the MCP server and the CI action. It does one thing: during a Nuxt build it writes down the layer graph and the locale table Nuxt resolved, so the CLI can read them instead of reconstructing them from outside. A layer here is a scoped locale directory — a Nuxt layer, a workspace package, a shared UI library, or one app in a monorepo. See Layers for the vocabulary the rest of this section uses.

1. Install the Package

pnpm add -D @the-i18n-kit/nuxt

The module declares compatibility with Nuxt >=3.0.0, and it is a dev dependency: nothing it writes is shipped to the browser or read at runtime.

2. Register It in nuxt.config.ts

export default defineNuxtConfig({
  modules: ['@nuxtjs/i18n', '@the-i18n-kit/nuxt'],
})

Module order does not matter — the module reads what @nuxtjs/i18n normalized, regardless of which module ran first.

@nuxtjs/i18n has to be installed and configured. Without an i18n block on the resolved Nuxt options the module logs No i18n configuration found, so nothing was published and stops — the build still succeeds, and the CLI behaves as it does without the module.

3. Remove the Keys the Module Derives

Delete locales, localeDirs and defaultLocale from i18n-kit.config.ts or .i18n-mcp.json if you have them. The module derives all three from your Nuxt config, and from now on declaring them by hand fails the build rather than silently taking or losing precedence. See What It Validates for the exact diagnostics.

Everything else in those files stays where it is. The module carries no kit policy: no glossary, no context, no protectedLocales, no orphanScan. Those are read straight from disk by the CLI, which is what makes them apply in a checkout that has never built. See Where Configuration Lives.

4. Build Once and Check the Artifact

The module writes on any Nuxt command that runs modules — nuxt prepare, nuxt dev, nuxt build:

npx nuxt prepare
cat .nuxt/i18n-kit.json

A successful run logs how much it published, for example Published 30 locale(s) across 4 layer(s) to <buildDir>/i18n-kit.json.

The path is fixed at <app>/.nuxt/i18n-kit.json and is not configurable. The CLI looks there without loading your Nuxt config — that is the point of the artifact — so it cannot follow a renamed file or a custom buildDir.

5. Confirm the CLI Reads It

Run any command that resolves the project and read the log line:

the-i18n-cli status

When the artifact is used, the CLI logs Using the layer graph published by @the-i18n-kit/nuxt@<version>. When it is not, the CLI either logs a warning naming the reason and loads the app through Nuxt instead, or — for an artifact that is absent — loads the app with no message at all. Both cases are covered in Limits.

In a Monorepo

Install and register the module in every Nuxt app. Each app publishes its own artifact describing its own layer graph, and the CLI merges the apps exactly as it merges them today. An app without the module is loaded through Nuxt as before, so you can adopt it one app at a time.

Next

• What It Publishes — the artifact's contents, and the hand-written config it replaces.
• What It Validates — the build-time checks.
• Layer-Aware Missing Keys — the ESLint blocks the module contributes to withNuxt() when @nuxt/eslint and the lint peers are installed.