@intlayer/docs 5.8.0-canary.0 → 5.8.0

package/blog/en-GB/react-i18next_vs_react-intl_vs_intlayer.md

@@ -1,8 +1,8 @@
 ---
 createdAt: 2025-01-02
 updatedAt: 2025-06-29
-title: react-i18n vs react-intl vs Intlayer
-description: Integrate react-i18next with next-intl and Intlayer for the internationalization (i18n) of a React app
+title: react-i18next vs react-intl vs Intlayer
+description: Integrate react-i18next with next-intl and Intlayer for the internationalisation (i18n) of a React app
 keywords:
   - next-intl
   - react-i18next
@@ -17,178 +17,128 @@ slugs:
   - react-i18next-vs-react-intl-vs-intlayer
 ---
 
-# React-Intl VS React-i18next VS Intlayer | React Internationalization (i18n)
+# react-Intl VS react-i18next VS intlayer | React Internationalisation (i18n)
 
-Below is a concise comparison of three popular i18n (internationalization) libraries for React: **React-Intl**, **React-i18next**, and **Intlayer**. Each library offers unique features and workflows for integrating multilingual support in your React application. After reading this, you should be able to decide which solution best meets your needs.
+This guide compares three established i18n options for **React**: **react-intl** (FormatJS), **react-i18next** (i18next), and **Intlayer**.
+We focus on **plain React** applications (e.g., Vite, CRA, SPA). If you’re using Next.js, see our dedicated Next.js comparison.
 
----
-
-## 1. Introduction
+We evaluate:
 
-Internationalization (i18n) in React applications can be achieved in multiple ways. The three libraries presented here have different design philosophies, sets of features, and community support:
+- Architecture & content organisation
+- TypeScript & safety
+- Missing translation handling
+- Rich content & formatting capabilities
+- Performance & loading behaviour
+- Developer experience (DX), tooling & maintenance
+- SEO/routing (framework-dependent)
 
-1. **React-Intl**
-2. **React-i18next**
-3. **Intlayer**
-
-Below, you’ll find an overview of each solution, followed by a feature comparison, pros & cons, and example use cases.
+> **tl;dr**: All three can localise a React app. If you want **component-scoped content**, **strict TypeScript types**, **build-time missing-key checks**, **tree-shaken dictionaries**, and built-in editorial tooling (Visual Editor/CMS + optional AI translation), **Intlayer** is the most complete choice for modular React codebases.
 
 ---
 
-## 2. React-Intl
-
-### Overview
-
-[**React-Intl**](https://formatjs.io/docs/react-intl/) is part of the [FormatJS](https://formatjs.io/) suite. It provides a powerful set of **APIs and components** to handle message formatting, pluralization, date/time, and number formatting. React-Intl is widely used in enterprise applications, mainly because it is part of an ecosystem that standardizes message syntax and formatting.
-
-### Key Features
-
-- **ICU Message Syntax**: Offers a comprehensive syntax for message interpolation, pluralization, and more.
-- **Localized Formatting**: Built-in utilities to format dates, times, numbers, and relative times based on locale.
-- **Declarative Components**: Exposes `<FormattedMessage>`, `<FormattedNumber>`, `<FormattedDate>`, etc., for seamless usage in JSX.
-- **Rich Ecosystem**: Integrates well with the FormatJS tooling (e.g., [babel-plugin-react-intl](https://formatjs.io/docs/tooling/babel-plugin/)) for extracting, managing, and compiling messages.
+## High-level positioning
 
-### Typical Workflow
-
-1. **Define message catalogs** (usually JSON files per locale).
-2. **Wrap your app** in `<IntlProvider locale="en-GB" messages={messages}>`.
-3. **Use** `<FormattedMessage id="myMessage" defaultMessage="Hello world" />` or the `useIntl()` hook to access translation strings.
-
-### Pros
-
-- Well-established and used in many production environments.
-- Advanced message formatting, including pluralization, gender, time zones, and more.
-- Strong tooling support for message extraction and compilation.
-
-### Cons
-
-- Requires familiarity with the **ICU message format**, which can be verbose.
-- Not as straightforward to handle dynamic or complex translations that are more than just string-based.
+- **react-intl** - ICU-first, standards-aligned formatting (dates/numbers/plurals) with a mature API. Catalogues are typically centralised; key safety and build-time validation are largely your responsibility.
+- **react-i18next** - Extremely popular and flexible; namespaces, detectors, and many plugins (ICU, backends). Powerful, but configuration can become sprawling as projects scale.
+- **Intlayer** - Component-centric content model for React, **strict TS typing**, **build-time checks**, **tree-shaking**, plus **Visual Editor/CMS** and **AI-assisted translations**. Works with React Router, Vite, CRA, etc.
 
 ---
 
-## 3. React-i18next
-
-### Overview
+## Feature matrix (React focus)
+
+| Feature                                       | `react-intlayer` (Intlayer)                                                                                                         | `react-i18next` (i18next)                                                                                | `react-intl` (FormatJS)                                                                     |
+| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
+| **Translations Near Components**              | ✅ Yes, content collocated with each component                                                                                      | ❌ No                                                                                                    | ❌ No                                                                                       |
+| **TypeScript Integration**                    | ✅ Advanced, auto-generated strict types                                                                                            | ⚠️ Basic; extra config for safety                                                                        | ✅ Good, but less strict                                                                    |
+| **Missing Translation Detection**             | ✅ TypeScript error highlight and build-time error/warning                                                                          | ⚠️ Mostly fallback strings at runtime                                                                    | ⚠️ Fallback strings                                                                         |
+| **Rich Content (JSX/Markdown/components)**    | ✅ Direct support                                                                                                                   | ⚠️ Limited / interpolation only                                                                          | ⚠️ ICU syntax, not real JSX                                                                 |
+| **AI-powered Translation**                    | ✅ Yes, supports multiple AI providers. Usable using your own API keys. Considers the context of your application and content scope | ❌ No                                                                                                    | ❌ No                                                                                       |
+| **Visual Editor**                             | ✅ Yes, local Visual Editor + optional CMS; can externalise codebase content; embeddable                                            | ❌ No / available via external localisation platforms                                                    | ❌ No / available via external localisation platforms                                       |
+| **Localised Routing**                         | ✅ Yes, supports localised paths out of the box (works with Next.js & Vite)                                                         | ⚠️ No built-in, requires plugins (e.g. `next-i18next`) or custom router config                           | ❌ No, only message formatting, routing must be manual                                      |
+| **Dynamic Route Generation**                  | ✅ Yes                                                                                                                              | ⚠️ Plugin/ecosystem or manual setup                                                                      | ❌ Not provided                                                                             |
+| **Pluralisation**                             | ✅ Enumeration-based patterns                                                                                                       | ✅ Configurable (plugins like i18next-icu)                                                               | ✅ (ICU)                                                                                    |
+| **Formatting (dates, numbers, currencies)**   | ✅ Optimised formatters (Intl under the hood)                                                                                       | ⚠️ Via plugins or custom Intl usage                                                                      | ✅ ICU formatters                                                                           |
+| **Content Format**                            | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml WIP)                                                                                    | ⚠️ .json                                                                                                 | ✅ .json, .js                                                                               |
+| **ICU support**                               | ⚠️ WIP                                                                                                                              | ⚠️ Via plugin (i18next-icu)                                                                              | ✅ Yes                                                                                      |
+| **SEO Helpers (hreflang, sitemap)**           | ✅ Built-in tools: helpers for sitemap, robots.txt, metadata                                                                        | ⚠️ Community plugins/manual                                                                              | ❌ Not core                                                                                 |
+| **Ecosystem / Community**                     | ⚠️ Smaller but growing fast and reactive                                                                                            | ✅ Largest and mature                                                                                    | ✅ Large                                                                                    |
+| **Server-side Rendering & Server Components** | ✅ Yes, streamlined for SSR / React Server Components                                                                               | ⚠️ Supported at page level but need to pass t-functions on component tree for children server components | ❌ Not supported, need to pass t-functions on component tree for children server components |
+| **Tree-shaking (load only used content)**     | ✅ Yes, per-component at build time via Babel/SWC plugins                                                                           | ⚠️ Usually loads all (can be improved with namespaces/code-splitting)                                    | ⚠️ Usually loads all                                                                        |
+| **Lazy loading**                              | ✅ Yes, per-locale / per-dictionary                                                                                                 | ✅ Yes (e.g., backends/namespaces on demand)                                                             | ✅ Yes (split locale bundles)                                                               |
+| **Purge unused content**                      | ✅ Yes, per-dictionary at build time                                                                                                | ❌ No, only via manual namespace segmentation                                                            | ❌ No, all declared messages are bundled                                                    |
+| **Management of Large Projects**              | ✅ Encourages modularity, suited for design systems                                                                                 | ⚠️ Requires good file discipline                                                                         | ⚠️ Central catalogues can become large                                                      |
 
-[**React-i18next**](https://react.i18next.com/) is a React extension of [i18next](https://www.i18next.com/), one of the most popular JavaScript i18n frameworks. It offers **extensive features** for runtime translations, lazy loading, and detection of language, making it extremely flexible for a wide variety of use cases.
-
-### Key Features
-
-- **Flexible Translation Structure**: Not tied to a single format like ICU. You can store translations in JSON, use interpolation, pluralization, etc.
-- **Dynamic Language Switching**: Built-in language detector plugins and runtime updates.
-- **Nested & Structured Translations**: You can nest translations easily within JSON.
-- **Extensive Plugin Ecosystem**: For detection (browser, path, subdomain, etc.), resource loading, caching, and more.
-
-### Typical Workflow
-
-1. **Install `i18next` & `react-i18next`.**
-2. **Configure i18n** to load translations (JSON) and set up language detection or fallback.
-3. **Wrap your app** in `I18nextProvider`.
-4. **Use the `useTranslation()` hook** or `<Trans>` component to display translations.
+---
 
-### Pros
+## Deep-dive comparison
 
-- Highly **flexible** and feature-rich.
-- Very active community and large ecosystem of plugins.
-- Ease of **dynamic loading** of translations (e.g., from a server, on demand).
+### 1) Architecture & scalability
 
-### Cons
+- **react-intl / react-i18next**: Most setups maintain **centralised locale folders** per language, sometimes split by **namespaces** (i18next). Works well early on but becomes a shared surface area as apps grow.
+- **Intlayer**: Promotes **per-component (or per-feature) dictionaries** **co-located** with the UI they serve. This keeps ownership clear, eases duplication/migration of components, and reduces cross-team key churn. Unused content is easier to identify and remove.
 
-- **Configuration can be verbose**, especially if you have more advanced needs.
-- If you prefer strongly typed translations, you may need additional TypeScript setups.
+**Why it matters:** Modular content mirrors modular UI. Large React codebases remain cleaner when translations reside with the components they belong to.
 
 ---
 
-## 4. Intlayer
+### 2) TypeScript & safety
 
-### Overview
+- **react-intl**: Solid typings, but **no automatic key typing**; you enforce safety patterns yourself.
+- **react-i18next**: Strong typings for hooks; **strict key typing** typically requires extra configuration or generators.
+- **Intlayer**: **Auto-generates strict types** from your content. IDE autocomplete and **compile-time errors** catch typos and missing keys before runtime.
 
-[**Intlayer**](https://github.com/aymericzip/intlayer) is a newer, open-source i18n library focused on **component-level content declarations**, type safety, and **dynamic routing**. It is designed for modern React workflows, supporting both **Create React App** and **Vite** setups. It also includes advanced features like **locale-based routing** and **auto-generated TypeScript types** for translations.
+**Why it matters:** Shifting failures **left** (to build/CI) reduces production issues and speeds developer feedback loops.
 
-### Key Features
+---
 
-- **Declarative Content Files**: Each component or module can declare its translations in dedicated `.content.tsx` or `.content.json` files, keeping content close to where it’s used.
-- **Built-in Routing & Middleware**: Optional modules for localized routing (e.g., `/en-GB/about`, `/fr/about`) and server middleware for detecting user locale.
-- **Auto-generated TypeScript Types**: Ensures type safety with features like autocompletion and compile-time error detection.
-- **Dynamic & Rich Translations**: Can include JSX/TSX in translations for more complex use cases (e.g., links, bold text, icons in translations).
+### 3) Missing translation handling
 
-### Typical Workflow
+- **react-intl / react-i18next**: Default to **runtime fallbacks** (key echo or default locale). You can add linting/plugins, but it’s not guaranteed at build.
+- **Intlayer**: **Build-time detection** with warnings or errors when required locales/keys are missing.
 
-1. **Install `intlayer` and `react-intlayer`.**
-2. **Create `intlayer.config.ts`** to define available locales and default locale.
-3. **Use the Intlayer CLI** or plugin to **transpile** content declarations.
-4. **Wrap your app** in `<IntlayerProvider>` and retrieve content with `useIntlayer("keyName")`.
+**Why it matters:** CI failing on missing strings prevents “mystery English” leaking into non-English UIs.
 
-### Pros
+---
 
-- **TypeScript-friendly** with built-in type generation and error-checking.
-- **Rich content** possible (e.g., passing React nodes as translations).
-- **Localized Routing** out-of-the-box.
-- Integrated with popular build tools (CRA, Vite) for easy setup.
+### 4) Rich content & formatting
 
-### Cons
+- **react-intl**: Excellent **ICU** support for plurals, selects, dates/numbers, and message composition. JSX can be used, but the mental model remains message-centric.
+- **react-i18next**: Flexible interpolation and **`<Trans>`** for embedding elements/components; ICU available via a plugin.
+- **Intlayer**: Content files can include **rich nodes** (JSX/Markdown/components) and **metadata**. Formatting uses Intl under the hood; plural patterns are ergonomic.
 
-- Still **relatively new** compared to React-Intl or React-i18next.
-- Heavier focus on a “component-level content declaration” approach, may be a shift from typical .json catalogs.
-- Smaller ecosystem and community compared to the more established libraries.
+**Why it matters:** Complex UI texts (links, bold sections, inline components) are easier when the library embraces React nodes cleanly.
 
 ---
 
-## 5. Feature Comparison
+### 5) Performance & loading behaviour
 
-| **Feature**                    | **React-Intl**                                                        | **React-i18next**                                                                                   | **Intlayer**                                                                                                               |
-| ------------------------------ | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
-| **Primary Use Case**           | String-based translations, date/number formatting, ICU message syntax | Full-featured i18n with easy dynamic switching, nesting, plugin ecosystem                           | Type-safe translations with focus on declarative content, localized routing, & optional server middleware                  |
-| **Approach**                   | Utilize `<IntlProvider>` & FormatJS message components                | Utilize `I18nextProvider` & `useTranslation()` hook                                                 | Utilize `<IntlayerProvider>` & `useIntlayer()` hook with content declarations                                              |
-| **Localization Format**        | ICU-based strings (JSON or JavaScript catalogs)                       | JSON resource files (or custom loaders). ICU format optional via i18next plugin                     | `.content.[ts/js/tsx]` or JSON declarations; can contain strings or React components                                       |
-| **Routing**                    | Handled externally (no built-in localized routing)                    | Handled externally with i18next plugins (path, subdomain detection, etc.)                           | Built-in localized routing support (e.g., `/en-GB/about`, `/fr/about`), plus optional server middleware (for SSR/Vite)     |
-| **TypeScript Support**         | Good (typings for official packages)                                  | Good but extra config for typed translations if you want strict checking                            | Excellent (auto-generated type definitions for content keys and translations)                                              |
-| **Pluralization & Formatting** | Advanced: Built-in date/time/number formatting, plural/gender support | Configurable pluralization. Date/time formatting typically done via external libs or i18next plugin | Can rely on standard JavaScript Intl or embed logic in content. Not as specialized as FormatJS, but handles typical cases. |
-| **Community & Ecosystem**      | Large, part of FormatJS ecosystem                                     | Very large, highly active, lots of plugins (detection, caching, frameworks)                         | Smaller but growing; open-source, modern approach                                                                          |
-| **Learning Curve**             | Moderate (learning ICU message syntax, FormatJS conventions)          | Low to moderate (straightforward usage, but advanced config can get verbose)                        | Moderate (concept of content declarations and specialized build steps)                                                     |
+- **react-intl / react-i18next**: You typically manage **catalogue splitting** and **lazy loading** manually (namespaces/dynamic imports). Effective but requires discipline.
+- **Intlayer**: **Tree-shakes** unused dictionaries and supports **per-dictionary/per-locale lazy loading** out-of-the-box.
 
----
-
-## 6. When to Choose Each
-
-1. **React-Intl**
+**Why it matters:** Smaller bundles and fewer unused strings improve startup and navigation performance.
 
-   - You need **powerful formatting** for dates/times/numbers and strong **ICU message syntax**.
-   - You prefer a more “**standards-based**” approach to translations.
-   - You don’t require localized routing or strongly typed translation keys.
+---
 
-2. **React-i18next**
+### 6) DX, tooling & maintenance
 
-   - You need a **flexible, established** solution with **dynamic** and **on-demand** translation loading.
-   - You want **plugin-based** language detection (e.g., from URL, cookies, local storage) or advanced caching.
-   - You need the largest ecosystem, with many existing integrations for various frameworks (Next.js, React Native, etc.).
+- **react-intl / react-i18next**: Broad community ecosystem; for editorial workflows you usually adopt external localisation platforms.
+- **Intlayer**: Ships a **free Visual Editor** and **optional CMS** (keep content in Git or externalise it). Also offers a **VSCode extension** for content authoring and **AI-assisted translation** using your own provider keys.
 
-3. **Intlayer**
-   - You want **strong TypeScript** integration with _autogenerated types_, ensuring you rarely miss a translation key.
-   - You prefer **declarative content** close to the component, possibly including React nodes or advanced logic in translations.
-   - You require **built-in localized routing** or want to easily incorporate it into your SSR or Vite setup.
-   - You desire a modern approach or simply want a single library that covers both **content management** (i18n) and **routing** in a type-safe way.
+**Why it matters:** Built-in tooling shortens the loop between developers and content authors - less glue code, fewer vendor dependencies.
 
 ---
 
-## 7. Conclusion
-
-Each library offers a robust solution for internationalizing a React application:
-
-- **React-Intl** excels at message formatting and is a popular choice for enterprise solutions focusing on ICU message syntax.
-- **React-i18next** provides a highly flexible, plugin-driven environment for advanced or dynamic i18n needs.
-- **Intlayer** offers a **modern, strongly typed** approach that merges content declarations, advanced localized routing, and plugin-based (CRA, Vite) integrations.
+## When to choose which?
 
-Your choice largely depends on project requirements, desired developer experience (DX), and how important typed translations or advanced routing are. If you value built-in localized routing and TypeScript integration, **Intlayer** may be most appealing. If you want a battle-tested, ecosystem-rich solution, **React-i18next** is a great choice. For straightforward ICU-based formatting needs, **React-Intl** is a reliable option.
+- **Choose react-intl** if you want **ICU-first** message formatting with a straightforward, standards-aligned API and your team is comfortable maintaining catalogues and safety checks manually.
+- **Choose react-i18next** if you need the **breadth of i18next’s ecosystem** (detectors, backends, ICU plugin, integrations) and accept more configuration to gain flexibility.
+- **Choose Intlayer** if you value **component-scoped content**, **strict TypeScript**, **build-time guarantees**, **tree-shaking**, and **batteries-included** editorial tooling - especially for **large, modular** React apps, design-systems, etc.
 
 ---
 
-### Further Reading
+## Conclusion
 
-- [React-Intl Documentation](https://formatjs.io/docs/react-intl/)
-- [React-i18next Documentation](https://react.i18next.com/)
-- [Intlayer + CRA Getting Started Guide](/#) (from your doc)
-- [Intlayer + Vite & React Getting Started Guide](/#) (from your doc)
+All three libraries localise React effectively. The differentiator is how much **infrastructure** you must build to reach a **safe, scalable** setup:
 
-Feel free to mix and match approaches to suit your requirements, there is no “one-size-fits-all” solution, and each library continues to evolve to address new use cases in the React ecosystem.
+- With **Intlayer**, **modular content**, **strict TS typing**, **build-time safety**, **tree-shaken bundles**, and **editorial tooling** are defaults - not chores.
+- If your team prizes **maintainability and speed** in multi-locale, component-driven React apps, Intlayer offers the **most complete** developer and content workflow today.

package/blog/en-GB/vue-i18n_vs_intlayer.md

@@ -0,0 +1,258 @@
+---
+createdAt: 2024-08-11
+updatedAt: 2025-08-23
+title: vue-i18n vs Intlayer
+description: Compare vue-i18n with Intlayer for internationalisation (i18n) in Vue/Nuxt apps
+keywords:
+  - vue-i18n
+  - Intlayer
+  - Internationalisation
+  - i18n
+  - Blog
+  - Vue
+  - Nuxt
+  - JavaScript
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer
+---
+
+# vue-i18n VS Intlayer | Vue Internationalisation (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:
+
+1. **Architecture & content organisation**
+2. **TypeScript & safety**
+3. **Missing translation handling**
+4. **Routing & URL strategy**
+5. **Performance & loading behaviour**
+6. **Developer experience (DX), tooling & maintenance**
+7. **SEO & large-project scalability**
+
+> **tl;dr**: Both can localise 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 large ecosystem. Safety and large-scale maintenance are mostly your responsibility.
+- **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)                                     |
+| **Localised routing**                       | ✅ Helpers for Vue Router/Nuxt to generate localised paths, URLs, and `hreflang` | ⚠️ Not core (use Nuxt i18n or custom Vue Router setup)                       |
+| **Dynamic route generation**                | ✅ Yes                                                                           | ❌ Not provided (Nuxt i18n provides)                                         |
+| **Pluralisation & 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 requires 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 **centralised catalogues** per locale (optionally split into files/namespaces). SFC `<i18n>` blocks allow local messages but teams often revert to shared catalogues 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 catalogues.
+
+---
+
+### 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, providing **IDE autocompletion** and **compile-time errors** for typos or missing keys.
+
+**Why it matters:** Strong typing catches issues **before** runtime.
+
+---
+
+### 3) Missing translation handling
+
+- **vue-i18n**: **Runtime** warnings/fallbacks (e.g., fallback locale or key).
+- **Intlayer**: **Build-time** detection with warnings/errors across locales and keys.
+
+**Why it matters:** Build-time enforcement keeps the production UI clean and consistent.
+
+---
+
+### 4) Routing & URL strategy (Vue Router/Nuxt)
+
+- **Both** can work with localised routes.
+- **Intlayer** provides helpers to **generate localised 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 behaviour
+
+- **vue-i18n**: Supports async locale messages; avoiding over-bundling is your responsibility (split catalogues carefully).
+- **Intlayer**: **Tree-shakes** at build and **lazy-loads per dictionary/locale**. Unused content isn’t shipped.
+
+**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 localisation platforms** for editorial workflows.
+- **Intlayer**: Ships a **free Visual Editor**, optional **CMS** (Git-friendly or externalised), 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 **centralised catalogues**:
+
+```bash
+.
+├── locales
+│   ├── en.json
+│   ├── es.json
+│   └── fr.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+Or with per-locale folders:
+
+```bash
+.
+├── 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:
+
+1. **For a new component** you create/edit remote catalogues, wire namespaces, and translate (often via manual copy/paste from AI tools).
+2. **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**, as we already do with CSS, stories, tests, and docs:
+
+```bash
+.
+└── components
+    └── MyComponent
+        ├── MyComponent.content.ts
+        └── MyComponent.vue
+```
+
+**Content declaration** (per component):
+
+```ts fileName="./components/MyComponent/MyComponent.content.ts"
+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):
+
+```vue fileName="./components/MyComponent/MyComponent.vue"
+<script setup lang="ts">
+import { useIntlayer } from "vue-intlayer"; // Vue integration
+const { greeting } = useIntlayer("component-example");
+</script>
+
+<template>
+  <span>{{ greeting }}</span>
+</template>
+```
+
+This approach:
+
+- **Speeds up development** (declare once; IDE/AI autocompletes).
+- **Cleans the codebase** (1 component = 1 dictionary).
+- **Facilitates duplication/migration** (copy a component and its content together).
+- **Avoids dead keys** (unused components don’t import content).
+- **Optimises 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.
+- **Organised codebase**: 1 component = 1 dictionary in the same folder.
+- **Enhanced routing**: Helpers for **Vue Router/Nuxt** localised paths and metadata.
+- **Markdown support**: Import remote/local Markdown per locale; expose frontmatter to code.
+- **Free Visual Editor & optional CMS**: Authoring without a paid localisation 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 catalogues/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.
+
+---
+
+## Conclusion
+
+Both **vue-i18n** and **Intlayer** localise 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 prioritises **maintainability and speed** in a multi-locale, component-driven Vue/Nuxt app, Intlayer offers the **most complete** experience today.
+
+Refer to ['Why Intlayer?' doc](https://intlayer.org/doc/why) for more details.

package/blog/es/intlayer_with_next-i18next.md

@@ -1,6 +1,6 @@
 ---
-createdAt: 2024-08-11
-updatedAt: 2025-06-29
+createdAt: 2025-08-23
+updatedAt: 2025-08-23
 title: Intlayer y next-i18next
 description: Integra Intlayer con next-i18next para una aplicación Next.js
 keywords: