Zadaj pytanie i otrzymaj streszczenie dokumentu, odwołując się do tej strony i wybranego dostawcy AI
Dzięki integracji serwera Intlayer MCP z ulubionym asystentem AI możesz uzyskać dostęp do całej dokumentacji bezpośrednio z ChatGPT, DeepSeek, Cursor, VSCode itp.
Zobacz dokumentację serwera MCPTreść tej strony została przetłumaczona przy użyciu sztucznej inteligencji.
Zobacz ostatnią wersję oryginalnej treści w języku angielskimJeśli masz pomysł na ulepszenie tej dokumentacji, zachęcamy do przesłania pull requesta na GitHubie.
Link do dokumentacji na GitHubieKopiuj dokument Markdown do schowka
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:
.├── locales│ ├── en.json│ ├── es.json│ └── fr.json└── src └── components └── MyComponent.vueOr with per-locale folders:
.├── locales│ ├── en│ │ ├── footer.json│ │ └── navbar.json│ ├── fr│ │ ├── footer.json│ │ └── navbar.json│ └── es│ ├── footer.json│ └── navbar.json└── src └── components └── MyComponent.vueThis 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:
.└── components └── MyComponent ├── MyComponent.content.ts └── MyComponent.vueContent declaration (per component):
Skopiuj kod do schowka
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):
Skopiuj kod do schowka
<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.