Ask your question and get a summary of the document by referencing this page and the AI provider of your choice
By integrating the Intlayer MCP Server to your favourite AI assistant can retrieve all the doc directly from ChatGPT, DeepSeek, Cursor, VSCode, etc.
See MCP Server docIf you have an idea for improving this documentation, please feel free to contribute by submitting a pull request on GitHub.
GitHub link to the documentationCopy doc Markdown to clipboard
vue-i18n VS Intlayer | Vue Internationalization (i18n)
This guide compares two popular i18n options for Vue 3 (and Nuxt): vue-i18n and Intlayer. We focus on modern Vue tooling (Vite, Composition API) and evaluate:
- Architecture & content organization
- TypeScript & safety
- Missing translation handling
- Routing & URL strategy
- Performance & loading behavior
- Developer experience (DX), tooling & maintenance
- SEO & large-project scalability
tl;dr: Both can localize Vue apps. If you want component-scoped content, strict TypeScript types, build-time missing-key checks, tree-shaken dictionaries, and batteries-included router/SEO helpers plus Visual Editor & AI translations, Intlayer is the more complete, modern choice.
High-level positioning
- vue-i18n - The de-facto i18n library for Vue. Flexible message formatting (ICU-style), SFC <i18n> blocks for local messages, and a big ecosystem. Safety and large-scale maintenance are mostly on you.
- Intlayer - Component-centric content model for Vue/Vite/Nuxt with strict TS typing, build-time checks, tree-shaking, router & SEO helpers, optional Visual Editor/CMS, and AI-assisted translations.
Side-by-Side Feature Comparison (Vue-focused)
Feature | Intlayer | vue-i18n |
---|---|---|
Translations near components | ✅ Yes, content collocated per component (e.g., MyComp.content.ts) | ✅ Yes, via SFC <i18n> blocks (optional) |
TypeScript integration | ✅ Advanced, auto-generated strict types & key autocompletion | ✅ Good typings; strict key safety requires additional setup/disciplines |
Missing translation detection | ✅ Build-time warnings/errors and TS surfacing | ⚠️ Runtime fallbacks/warnings |
Rich content (components/Markdown) | ✅ Direct support for rich nodes and Markdown content files | ⚠️ Limited (components via <i18n-t>, Markdown via external plugins) |
AI-powered translation | ✅ Built-in workflows using your own AI provider keys | ❌ Not built-in |
Visual Editor / CMS | ✅ Free Visual Editor & optional CMS | ❌ Not built-in (use external platforms) |
Localized routing | ✅ Helpers for Vue Router/Nuxt to generate localized paths, URLs, and hreflang | ⚠️ Not core (use Nuxt i18n or custom Vue Router setup) |
Dynamic route generation | ✅ Yes | ❌ Not provided (Nuxt i18n provides) |
Pluralization & formatting | ✅ Enumeration patterns; Intl-based formatters | ✅ ICU-style messages; Intl formatters |
Content formats | ✅ .ts, .js, .json, .md, .txt (YAML WIP) | ✅ .json, .js (plus SFC <i18n> blocks) |
ICU support | ⚠️ WIP | ✅ Yes |
SEO helpers (sitemap, robots, metadata) | ✅ Built-in helpers (framework-agnostic) | ❌ Not core (Nuxt i18n/community) |
SSR/SSG | ✅ Works with Vue SSR and Nuxt; does not block static rendering | ✅ Works with Vue SSR/Nuxt |
Tree-shaking (ship only used content) | ✅ Per-component at build time | ⚠️ Partial; requires manual code-splitting/async messages |
Lazy loading | ✅ Per-locale / per-dictionary | ✅ Async locale messages supported |
Purge unused content | ✅ Yes (build-time) | ❌ Not built-in |
Large-project maintainability | ✅ Encourages modular, design-system-friendly structure | ✅ Possible, but needs strong file/namespace discipline |
Ecosystem / community | ⚠️ Smaller but growing fast | ✅ Large and mature in the Vue ecosystem |
Deep-dive comparison
1) Architecture & scalability
- vue-i18n: Common setups use centralized catalogs per locale (optionally split into files/namespaces). SFC <i18n> blocks allow local messages but teams often revert to shared catalogs as projects grow.
- Intlayer: Promotes per-component dictionaries stored next to the component they serve. This reduces cross-team conflicts, keeps content discoverable, and naturally limits drift/unused keys.
Why it matters: In large Vue apps or design systems, modular content scales better than monolithic catalogs.
2) TypeScript & safety
- vue-i18n: Good TS support; strict key typing typically needs custom schemas/generics and careful conventions.
- Intlayer: Generates strict types from your content, giving IDE autocompletion and compile-time errors for typos/missing keys.
Why it matters: Strong typing catches issues before runtime.
3) Missing translation handling
- vue-i18n: Runtime warnings/fallbacks (e.g., fall back locale or key).
- Intlayer: Build-time detection with warnings/errors across locales and keys.
Why it matters: Build-time enforcement keeps production UI clean and consistent.
4) Routing & URL strategy (Vue Router/Nuxt)
- Both can work with localized routes.
- Intlayer provides helpers to generate localized paths, manage locale prefixes, and emit <link rel="alternate" hreflang> for SEO. With Nuxt, it complements the framework’s routing.
Why it matters: Fewer custom glue layers and cleaner SEO across locales.
5) Performance & loading behavior
- vue-i18n: Supports async locale messages; avoiding over-bundling is on you (split catalogs carefully).
- Intlayer: Tree-shakes at build and lazy-loads per dictionary/locale. Unused content doesn’t ship.
Why it matters: Smaller bundles and faster startup for multi-locale Vue apps.
6) Developer experience & tooling
- vue-i18n: Mature docs and community; you’ll typically rely on external localization platforms for editorial workflows.
- Intlayer: Ships a free Visual Editor, optional CMS (Git-friendly or externalized), a VSCode extension, CLI/CI utilities, and AI-assisted translations using your own provider keys.
Why it matters: Lower ops cost and a shorter dev–content loop.
7) SEO, SSR & SSG
- Both work with Vue SSR and Nuxt.
- Intlayer: Adds SEO helpers (sitemaps/metadata/hreflang) that are framework-agnostic and play nicely with Vue/Nuxt builds.
Why it matters: International SEO without bespoke wiring.
Why Intlayer? (Problem & approach)
Most i18n stacks (including vue-i18n) start from centralized catalogs:
Copy the code to the clipboard
.├── locales│ ├── en.json│ ├── es.json│ └── fr.json└── src └── components └── MyComponent.vue
Or with per-locale folders:
Copy the code to the clipboard
.├── locales│ ├── en│ │ ├── footer.json│ │ └── navbar.json│ ├── fr│ │ ├── footer.json│ │ └── navbar.json│ └── es│ ├── footer.json│ └── navbar.json└── src └── components └── MyComponent.vue
This often slows development as apps grow:
- For a new component you create/edit remote catalogs, wire namespaces, and translate (often via manual copy/paste from AI tools).
- When changing components you hunt down shared keys, translate, keep locales in sync, remove dead keys, and align JSON structures.
Intlayer scopes content per-component and keeps it next to the code, like we already do with CSS, stories, tests, and docs:
Copy the code to the clipboard
.└── components └── MyComponent ├── MyComponent.content.ts └── MyComponent.vue
Content declaration (per component):
Copy the code to the clipboard
import { t, type Dictionary } from "intlayer";const componentExampleContent = { key: "component-example", content: { greeting: t({ en: "Hello World", es: "Hola Mundo", fr: "Bonjour le monde", }), },} satisfies Dictionary;export default componentExampleContent;
Usage in Vue (Composition API):
Copy the code to the clipboard
<script setup lang="ts">import { useIntlayer } from "vue-intlayer"; // Vue integrationconst { greeting } = useIntlayer("component-example");</script><template> <span>{{ greeting }}</span></template>
This approach:
- Speeds development (declare once; IDE/AI autocompletes).
- Cleans the codebase (1 component = 1 dictionary).
- Eases duplication/migration (copy a component and its content together).
- Avoids dead keys (unused components don’t import content).
- Optimizes loading (lazy-loaded components bring their content with them).
Additional features of Intlayer (Vue-relevant)
- Cross-framework support: Works with Vue, Nuxt, Vite, React, Express, and more.
- JavaScript-powered content management: Declare in code with full flexibility.
- Per-locale declaration file: Seed all locales and let tooling generate the rest.
- Type-safe environment: Strong TS config with autocompletion.
- Simplified content retrieval: A single hook/composable to fetch all content for a dictionary.
- Organized codebase: 1 component = 1 dictionary in the same folder.
- Enhanced routing: Helpers for Vue Router/Nuxt localized paths and metadata.
- Markdown support: Import remote/local Markdown per locale; expose frontmatter to code.
- Free Visual Editor & optional CMS: Authoring without a paid localization platform; Git-friendly sync.
- Tree-shakable content: Ships only what’s used; supports lazy loading.
- Static rendering friendly: Does not block SSG.
- AI-powered translations: Translate to 231 languages using your own AI provider/API key.
- MCP server & VSCode extension: Automate i18n workflows and authoring inside your IDE.
- Interoperability: Bridges with vue-i18n, react-i18next, and react-intl when needed.
When to choose which?
- Choose vue-i18n if you want the standard Vue approach, you’re comfortable managing catalogs/namespaces yourself, and your app is small to mid-size (or you already rely on Nuxt i18n).
- Choose Intlayer if you value component-scoped content, strict TypeScript, build-time guarantees, tree-shaking, and batteries-included routing/SEO/editor tooling-especially for large, modular Vue/Nuxt codebases, design-systems, etc.
Interoperability with vue-i18n
intlayer can also help to manage your vue-i18n namespaces.
Using intlayer, you can declare your content in the format of your favorite i18n library, and intlayer will generate your namespaces in the location of your choice (example: /messages/{{locale}}/{{namespace}}.json).
Refer to dictionaryOutput and i18nextResourcesDir options for more details.
GitHub STARs
GitHub stars are a strong indicator of a project's popularity, community trust, and long-term relevance. While not a direct measure of technical quality, they reflect how many developers find the project useful, follow its progress, and are likely to adopt it. For estimating the value of a project, stars help compare traction across alternatives and provide insights into ecosystem growth.
Conclusion
Both vue-i18n and Intlayer localize Vue apps well. The difference is how much you must build yourself to achieve a robust, scalable setup:
- With Intlayer, modular content, strict TS, build-time safety, tree-shaken bundles, and router/SEO/editor tooling come out of the box.
- If your team prioritizes maintainability and speed in a multi-locale, component-driven Vue/Nuxt app, Intlayer offers the most complete experience today.
Refer to 'Why Intlayer?' doc for more details.