Comvi vs next-intl
next-intl is the go-to i18n library for the Next.js App Router. Comvi covers the same runtime ground across six frameworks — and keeps going where next-intl stops: managing and shipping the translations themselves.
If you only read one block, read this
- Choose next-intl if you are all-in on Next.js, want the deepest App Router integration (Server Components, static rendering, locale middleware), and are happy managing translation JSON in git.
- Choose Comvi if you also need the workflow after coding: an editor for non-developers, machine translation, review, and copy changes that go live without a redeploy — or if your stack is not only Next.js.
- Both speak ICU MessageFormat and both type-check translation keys. The runtime feature sets overlap heavily; the products diverge on everything around the runtime.
- next-intl's docs recommend wiring up an external TMS (e.g. Crowdin) for management — that's the slot Comvi fills natively.
01 What each one is
next-intl (MIT, ~2.3 M npm downloads a week) is an i18n library purpose-built for Next.js. It has first-class App Router support — getTranslations() renders messages in Server Components with no client JavaScript — plus locale routing middleware, localized pathnames, and navigation wrappers. Messages use ICU syntax, and keys can be type-checked by augmenting theIntlMessages type.
Comvi i18n (MIT) is a framework-agnostic ICU library (≤10 kB with a binding, zero dependencies) with a first-party Next.js integration alongside React, Vue, Svelte, Solid, and Nuxt. It connects to the Comvi platform for editing, review, machine translation, and edge delivery — all optional; the library also runs on plain JSON.
02 Side by side
| Capability | next-intl | Comvi |
|---|---|---|
| Scope | Next.js only | React, Vue, Svelte, Solid, Next.js, Nuxt, vanilla JS |
| ICU MessageFormat | Yes — plural, select, ordinals, rich text | Yes — plural, select, ordinals, tag interpolation |
| App Router / Server Components | First-class; server-rendered messages ship no client JS | Supported via the Next.js binding and SSR guide |
| Locale routing middleware | Built in — prefix strategies, detection, localized pathnames | Locale detection plugin; routing stays in your framework |
| Typed translation keys | Yes — augment IntlMessages manually | Yes — generated by CLI typegen, live-updated during dev |
| Client bundle | Vendor-stated ~2 kB; zero for server-only messages | ≤10 kB including the binding, zero dependencies |
| Translation editor / review | — docs recommend an external TMS (e.g. Crowdin) | Built into the platform, free tier included |
| Machine translation | — | Classical + LLM providers, with 3-level AI context |
| Updates without redeploy (OTA) | — messages live in the repo; changes ship with the next deploy | Native — publish to the edge CDN, live without a deploy |
| In-context editing on a live preview | — | In-context editor plugin |
figures verified july 2026 · next-intl bundle figure is the vendor's own claim
03 When next-intl is the right call
- Your product is Next.js, full stop. The App Router integration — static rendering, server-only messages, locale middleware — is the deepest available anywhere.
- Routing is your hard requirement. Localized pathnames and prefix strategies are built in; with Comvi you'd wire routing yourself.
- Developers own all the copy. If translations are edited by the same people who write the code, JSON in git plus PR review may be all the workflow you need.
04 When Comvi is the right call
- Non-developers touch the copy. Translators, marketers, or founders editing strings need an editor with review states — not a git client.
- You ship to more than one framework. Same keys, same ICU messages, same platform across a Next.js site, a Vue dashboard, and a Svelte widget.
- Copy iterations shouldn't wait for CI. With messages in the repo, every wording tweak is a commit, a review, and a deploy. Comvi publishes straight to the edge — no redeploy.
- You'd otherwise glue next-intl to a TMS. If the plan is "next-intl + Crowdin + OTA," Comvi collapses that stack into one tool with a free tier and plans from $14/month.
05 Using both
Because both sides speak ICU JSON, you can keep next-intl as the runtime and use Comvi as the management layer: edit and machine-translate in Comvi, then pull JSON via the CLI into your messages/ directory in CI. You keep next-intl's routing and Server Components; your team gets an editor, review workflow, and translation memory.