Comvi vs nuxt-i18n
@nuxtjs/i18n is the official i18n module for Nuxt, built on vue-i18n. Comvi brings a lighter ICU runtime with generated key types — plus the translation platform the module leaves you to find elsewhere.
If you only read one block, read this
- Choose @nuxtjs/i18n if you want the official module's locale routing strategies and
useLocaleHeadSEO output, or you're invested in vue-i18n message syntax and per-component<i18n>blocks. - Choose Comvi if you want strictly typed keys (nuxt-i18n's types don't reject unknown keys), real ICU, a lighter runtime, and translation updates that don't require a rebuild.
- @nuxtjs/i18n handles routing and SEO well, but translation management is out of scope — editing, review, MT, and delivery are yours to assemble.
- Comvi's Nuxt module covers auto-imports, lazy loading, locale routing, and SSR — with the platform attached when you want it.
01 What each one is
@nuxtjs/i18n (MIT, v10 targeting Nuxt 4 with Nuxt 3 support) is the official Nuxt module built on top of vue-i18n. It adds locale routing strategies (prefix,prefix_except_default, and friends), browser detection with cookie persistence, lazy-loading of locale files, per-component <i18n> blocks, and SEO helpers —useLocaleHead emits hreflang alternates, og:locale, and canonicals.
Comvi i18n (MIT) is a zero-dependency ICU library (≤10 kB with the binding) with a first-party Nuxt module: auto-imports, lazy loading, locale routing, and SSR support. Types for every translation key are generated from your project and update in real time during development. It pairs — optionally — with the Comvi platformfor editing, review, machine translation, and edge delivery.
02 Side by side
| Capability | @nuxtjs/i18n | Comvi |
|---|---|---|
| Foundation | vue-i18n + Nuxt layer | Standalone core, zero dependencies |
| Message format | vue-i18n syntax (pipe plurals); ICU not native | Real ICU MessageFormat — plural, select, ordinals |
| Typed translation keys | Autocomplete only — unknown keys are not rejected (open issues #3782, #1817) | Strict — generated types fail the build on bad keys, live-updated in dev |
| Locale routing strategies | Built in — four strategies, detection, cookie persistence | Locale routing in the Nuxt module; detection via plugin |
| SEO head output (hreflang, og:locale) | useLocaleHead built in | Manual via your head config |
| Lazy loading of locales | Yes | Yes |
| Build/bundle overhead at scale | Criticized on large projects — heavy enough that nuxt-i18n-micro exists as a community rewrite (its own benchmarks claim order-of-magnitude gains) | ≤10 kB runtime; translations load from CDN or JSON, not the bundle |
| Translation editor / review | — out of scope | Built into the platform, free tier included |
| Machine translation | — | Classical + LLM providers with 3-level AI context |
| Updates without rebuild (OTA) | — locale files ship with the build | Native — publish to the edge CDN, live without a deploy |
figures verified july 2026 · nuxt-i18n-micro numbers are that project's own benchmark, not independent
03 When @nuxtjs/i18n is the right call
- You want the official module. Deep Nuxt integration, a huge community, and first-party docs coverage count for a lot.
- SEO head management out of the box.
useLocaleHeademitting hreflang/canonical automatically is genuinely convenient for content-heavy sites. - You're invested in vue-i18n. Existing message files, per-component
<i18n>blocks, and team familiarity are real switching costs.
04 When Comvi is the right call
- You want the compiler to catch bad keys. nuxt-i18n autocompletes keys but accepts any string; Comvi's generated types make a typo a build error.
- Your locale files are getting heavy. Comvi keeps translations out of the bundle — loaded lazily from the edge or your own JSON — so builds don't grow with word count.
- Translators shouldn't open pull requests. The platform gives them an editor with review states, machine translation drafts, and translation memory.
- Copy fixes shouldn't wait for a rebuild. Publish in Comvi and the CDN serves the new strings — no redeploy.
05 Migrating or mixing
Comvi imports standard JSON, so moving vue-i18n messages over is mostly a syntax pass on plurals (pipe syntax → ICU plural). You can also adopt the platform first — manage and machine-translate in Comvi, pull JSON in CI into your existing @nuxtjs/i18n setup — and switch the runtime later. TheNuxt integration guide shows the target setup end to end.