Vue i18n vs automatic translation: choosing the right approach for your Vue app (2026)

Vue's i18n story

vue-i18n (created by kazupon, now maintained under the @intlify organisation as @intlify/vue-i18n-next) is the de facto standard for Vue internationalization. It has first-class support for both Vue 2 (vue-i18n v8) and Vue 3 (vue-i18n v9+).

The API is clean and well-documented. In a Vue 3 app with the Composition API:

// main.ts
import { createI18n } from 'vue-i18n'

const i18n = createI18n({
  legacy: false,
  locale: 'en',
  fallbackLocale: 'en',
  messages: { en, fr, de },
})

app.use(i18n)

Inside components you use the useI18n composable and the t() function:

<script setup lang="ts">
const { t } = useI18n()
</script>

<template>
  <h1>{{ t('home.title') }}</h1>
  <p>{{ t('home.description') }}</p>
</template>

In Vue 2 or the Options API, the same string is accessed as $t('home.title') in templates. The library is battle-tested, has an active community, and supports everything from simple string lookups to complex number/date formatting via the ECMAScript Internationalization API.

The maintenance burden

vue-i18n is powerful — but that power comes with a maintenance cost that compounds as your application grows:

• →JSON locale files per language. Every string in your app must be extracted into a key-value file for each supported language. A typical SaaS product has hundreds to thousands of keys. Each new feature means new keys in every locale file.
• →Keeping files in sync. When a developer adds a new UI string and forgets to update the French locale file, the fallback locale shows English to French users — often silently. Tooling like vue-i18n-extract helps but adds setup overhead.
• →Bundle size and lazy-loading. Shipping all locale JSON upfront bloats the initial bundle. Lazy-loading per locale requires Vite/webpack async chunk configuration and handling the loading state during locale switches.
• →Plural rules per language. English has two plural forms; Russian has four; Arabic has six. vue-i18n handles this with ICU message syntax, but someone must write and verify the plural strings for each language.
• →Date and number formatting. Locale-aware formatting requires explicit datetimeFormats and numberFormats configuration per locale — hours of setup work before a user sees a correctly formatted date.

For a team without dedicated i18n engineers, this burden often means translation falls behind the product — shipping English strings to international users despite having “support” for their language.

When vue-i18n is the right choice

When automatic translation wins

How Lingvit works with Vue

Lingvit's widget is framework-agnostic — it operates at the DOM level, not the framework level. For Vue apps:

• →Add the script tag to your index.html before </body>. Vue mounts after the script is parsed, and the widget initialises once the DOM is populated.
• →A MutationObserver handles Vue's reactive rendering. When v-if reveals a section, v-for renders a list, or a component mounts after an async operation, the new DOM nodes are translated immediately.
• →Works with Vue 2 and Vue 3. The rendering internals differ, but the output is always DOM nodes — which is all the widget needs.
• →Nuxt.js is supported. For Nuxt 3 (server-rendered), add the script via Nuxt's app.head.script in nuxt.config.ts with tagPosition: 'bodyClose'. For Nuxt 2 use the head property in nuxt.config.js.

Setup comparison

Frequently asked questions