Чи застарів vue-i18n у 2026 році?

У спільноті Vue небагато бібліотек мають настільки високий рівень використання, як vue-i18n. Підтримуваний Kazupon ще з часів Vue 2, він забезпечує роботу @nuxtjs/i18n і слугує рішенням за замовчуванням практично для кожного багатомовного Vue-проєкту.

Однак наші бенчмарки 2026 року показали несподіваний результат: vue-i18n виявився найважчим runtime локалізації серед усіх протестованих фронтенд-фреймворків.

На чистій базі Vite + Vue розміром 31.5 КБ додавання vue-i18n збільшило середній обсяг JavaScript на сторінку до 136.4 КБ, більш ніж учетверо перевищивши початковий розмір.

Як інструмент для фреймворку, відомого компактністю, отримав настільки важкий стек інтернаціоналізації? І чи має сенс класична модель часу виконання сьогодні?

Головні висновки

Найважчий протестований runtime:

З вагою 24.3 КБ gzipped (83.2 КБ minified) до додавання будь-яких перекладів vue-i18n приблизно в 9 разів важчий за рушій intlayer (2.7 КБ).

Збільшення ваги сторінки на 330%:

vue-i18n збільшив базову сторінку Vue з 31.5 КБ до 136.4 КБ. Intlayer забезпечив 59.3 КБ, тобто на 56% менший обсяг.

Прихований компілятор у браузері:

За замовчуванням, без створення спеціальних аліасів у збирачі, vue-i18n відправляє повний компілятор повідомлень у браузер для розбору рядків на льоту.

Темпи підтримки:

За минулий рік vue-i18n зафіксував ~259 комітів, спрямованих на виправлення помилок та сумісність із версіями Vue.

Відсутність рідних сучасних інструментів:

Немає офіційної підтримки Language Server (LSP), MCP-серверів для ШІ або автоматизованих CLI-команд перекладу.

Підтримка проти сучасного інструментарію

Показати весь вміст таблиці

Показати весь вміст таблиці

Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані

Репозиторій	Зірки	Всього комітів	Комітів / рік	Останній коміт
intlify/vue-i18n
aymericzip/intlayer

Показники за останні 12 місяців:

• intlify/vue-i18n: 259 комітів (регулярні виправлення для Vue 3 і Nuxt).
• aymericzip/intlayer: 4 343 коміти (активна розробка оптимізацій компілятора, LSP-інструментів та інтеграцій для ШІ).

Зріла бібліотека забезпечує передбачуваність. Проте сучасні фронтенд-рішення застосовують AST-трансформації на етапі збірки, очищення мертвого коду та автоматизацію за допомогою ШІ. Системі, орієнтованій виключно на виконання у браузері, складно переймати ці переваги.

Тестування продуктивності у Vite + Vue

Бенчмарк застосунку на 10 сторінок та 10 мов із використанням Vite та Vue 3:

Вимірювання у реальних браузерах зі стисненням gzip. Вичерпні дані наведено в документації бенчмарка Vue.

Початковий оверхед бібліотек

Вага до додавання файлів перекладу:

Runtime vue-i18n сам по собі важить 24.3 КБ gzipped, що майже дорівнює вазі всього ядра Vue. Intlayer додає лише 2.7 КБ.

Вага сторінок та витік перекладів

Головні підсумки

Значне пропорційне зростання:

Оскільки база Vue дуже легка (~31 КБ), підключення vue-i18n збільшує вагу сторінки більш ніж у чотири рази.

Витік на інші маршрути:

За замовчуванням 90% тексту, що передається на сторінку, стосується інших розділів. Intlayer повністю прибирає зайві дані, зменшуючи показник до 0.0%.

Вага окремих компонентів:

Компоненти з локальними областями видимості досягали в середньому 196 КБ у vue-i18n через дублювання каталогів, проти лише 6.5 КБ в Intlayer.

Чому vue-i18n важкий?

Компілятор AST у браузері користувача

vue-i18n містить власний компілятор повідомлень. Правила множини та підстановки інтерпретуються як дерева AST безпосередньо у браузері під час роботи.

Щоб запобігти цьому, потрібно прописувати спеціальні аліаси до vue-i18n/dist/vue-i18n.runtime.esm-bundler.js і прекомпілювати файли через @intlify/unplugin-vue-i18n. Багато команд пропускають цей крок.

Монолітний набір функцій

vue-i18n включає модулі форматування чисел і дат, зв'язані повідомлення, мости для застарілого Options API ($t, v-t) та реактивні проксі. Навіть для виведення простих рядків у <script setup> завантажується весь комплекс.

Динамічні ключі блокують tree-shaking

Оскільки "home.hero.title" обчислюється під час виконання, збирачі не можуть перевірити реальне використання ключів. Зайві тексти залишаються в коді.

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("home.hero.title") }}</h1>
</template>

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

Компілятор Intlayer бачить використані поля та прибирає зайвий контент до створення клієнтських чанків. Детальніше в розділі оптимізація бандла.

Досвід розробника

Окремі каталоги проти спільного розміщення

У vue-i18n переклади зберігаються в окремій папці locales/. Intlayer розміщує типізовані файли контенту поруч із компонентами:

{
  "hero": {
    "title": "Ship in every language"
  }
}

{
  "hero": {
    "title": "Запускайте будь-якою мовою"
  }
}

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("hero.title") }}</h1>
</template>

import { t, type Dictionary } from "intlayer";

export default {
  key: "hero",
  content: {
    title: t({
      en: "Ship in every language",
      uk: "Запускайте будь-якою мовою",
    }),
  },
} satisfies Dictionary;

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

При видаленні чи перейменуванні Hero.vue його файл контенту переміщується або видаляється одночасно.

Автодоповнення проти суворої перевірки повноти

DefineLocaleMessage забезпечує автодоповнення в IDE на основі базової схеми. Проте воно не гарантує повноту всіх мов. Пропуск ключа в uk.json не викликає помилки під час збірки TypeScript.

В Intlayer словники перевіряються суворо. Активація strictMode призводить до зупинки збірки при відсутності перекладу в будь-якій мові.

Інструменти для IDE та ШІ

Процеси перекладу

vue-i18n не містить вбудованих інструментів перекладу. Зазвичай команди передають файли зовнішнім сервісам на кшталт Crowdin або Phrase.

Intlayer пропонує вбудовані засоби:

Локальний автопереклад за допомогою ШІ (intlayer fill):

Заповнює відсутні ключі з використанням ваших особистих ключів OpenAI, Anthropic, Mistral чи Gemini.

Автономна візуальна CMS:

Розгортайте Intlayer CMS, щоб редактори могли змінювати тексти візуально зі збереженням безпосередньо в Git.

Відкрита ліцензія:

Усі інструменти ліцензовано під Apache 2.0.

Коли vue-i18n все ще актуальний?

Як поліпшити поточну конфігурацію vue-i18n?

Intlayer пропонує готові пакети сумісності, які точно відтворюють сигнатури функцій vue-i18n та @nuxtjs/i18n (useI18n, $t, <i18n-t>). Вам не потрібно переписувати шаблони чи composables, щоб скористатися перевагами легкої архітектури на базі компілятора.

Налаштування виконується однією командою:

npx intlayer init --interactive

Цей інтерактивний CLI:

1. Встановлює пакет сумісності @intlayer/vue-i18n або @intlayer/nuxt-i18n.
2. Налаштовує аліаси бандлера (Vite чи Nuxt), щоб наявні імпорти та директиви шаблонів автоматично перенаправлялися на Intlayer, дозволяючи прибрати vue-i18n з package.json.
3. Миттєво підключає діагностику мовного сервера (LSP), видаляє 24-кілобайтний AST-парсер із клієнтського бандла та відкриває локальні робочі процеси ШІ-перекладу без суттєвого рефакторингу.

Детальні інструкції дивіться у наших посібниках:

• Швидка сумісність: Залишайте наявні шаблони за допомогою адаптера для vue-i18n чи @nuxtjs/i18n.
• Покрокові інструкції: Перетворіть JSON-файли на типізовані словники за нашими посібниками: з vue-i18n або з @nuxtjs/i18n.
• Гібридний підхід: Залиште vue-i18n у runtime, підключивши Intlayer до vue-i18n для суворої типізації та локального ШІ-перекладу.

Перевірте ваш сайт за допомогою безкоштовного SEO-сканера i18n:

Корисні матеріали

• Бенчмарк Vue & Vite i18n: повний аналіз продуктивності
• vue-i18n проти Intlayer: детальне порівняння
• Чи застарів next-intl у 2026 році?
• Інтернаціоналізація на базі компілятора проти декларативної