How to pick the right Svelte i18n library

Svelte ships nothing for i18n. No $t, no locale primitive, no message format. Every option is a third-party choice, and the Svelte ecosystem is where compile-time i18n has gone furthest, so the candidates differ more from each other than in React or Vue.

This guide lists the questions to answer first, then maps the answers to svelte-i18n, Paraglide, typesafe-i18n, wuchale and Intlayer, for Vite + Svelte and for SvelteKit.

Table of Contents

Six questions to answer before comparing libraries

1. Vite SPA or SvelteKit? In an SPA a module-level store is correct: one tab, one user, one locale. On SvelteKit that same singleton is shared across concurrent requests on the server, and request B renders in request A's language. The library either gives you a per-request shape (context, locals) or leaves it to you.
2. Who writes the translations? Developers, a TMS, an agency delivering ICU strings, or an AI pipeline. svelte-i18n speaks ICU. Paraglide and typesafe-i18n use their own syntax. Match the vendor.
3. How many locales and pages? Two locales and five pages can ship everything. Ten locales and forty routes cannot, and the difference between runtime catalogues and compiled messages becomes the main cost.
4. Do you need types on keys? $_("cart.totl") is a runtime failure in svelte-i18n. Compile-time libraries make it a type error by construction.
5. Svelte 4 stores or Svelte 5 runes? Runes change the syntax of the locale state, not the sharing problem. But $state in a .ts file compiles to a plain variable, so the library's runtime has to be rune-aware if you are on Svelte 5.
6. Can you live with generated files in the repo? Paraglide and typesafe-i18n both generate JavaScript or TypeScript into your source tree. Some teams are fine with that, others get merge conflicts on every parallel branch.

Write the answers down. Everything below refers back to them.

The landscape in one picture

Svelte i18n arrived later than React or Vue, and skipped straight to the compile-time waves.

The history of JavaScript i18n covers each wave in detail.

The decision that matters most: where content lives and when it loads

Two structural choices explain most of the bundle difference between setups:

• Centralised or scoped content. One locales/en.json for the app, or one declaration per component.
• Static or dynamic import. Everything at startup, or the active locale (and ideally the active route) fetched on demand.

The graph estimates the payload for a theoretical app of 1 to 10 pages, translated into 1 to 10 locales, with about 30 KB of text per page.

svelte-i18n sits in the top-left by default: register("fr", () => import("./fr.json")) gives you dynamic loading per locale, but a locale catalogue is one object and loading it loads every page's copy. Paraglide is the interesting case: because every message is its own export, tree-shaking gives you the page axis for free, and the Svelte benchmark confirms it works as advertised on Vite + Svelte (it did not in the React and Next.js benchmarks). Intlayer gets to the same corner through per-component declarations.

If your answer to question 3 was "many pages", weigh this section more than any API preference. The per-component vs centralised i18n post covers the maintenance side of the same trade-off.

The candidates

Library sizes are from the Svelte benchmark: store plus accessor in an empty component, after bundling, tree-shaking and minification, on a 10-page, 10-locale app. Content is measured separately.

Numbers are a snapshot at the benchmark's versions. Run it on your own app before deciding on size alone.

Paraglide's near-zero library size is by construction: the runtime is generated into your repository. Intlayer needs vite-intlayer, so it cannot run without a build step.

Match your answers to a library

Where each library falls short

• svelte-i18n: heaviest of the set, no key types, no per-route splitting, module-level store that leaks across requests on SvelteKit unless you wire context yourself.
• typesafe-i18n: a watcher process, generated files in the repo, and a repository that has not moved much recently.
• Paraglide: generated files committed to the repo and regenerated before every push, merge conflicts on parallel branches, and the locale is read from cookie or storage on each message call rather than from a store, which costs work on locale change.
• wuchale: interesting extraction idea, still early. The React benchmark hit reactivity issues that required forcing provider re-renders, and the documentation is thin.
• Intlayer: mandatory build plugin, smaller ecosystem, partial ICU support, and content spread across the codebase by design, so exporting one JSON for a translator needs tooling.

What each option looks like in code

The same component, a cart summary with a title and a plural, written with each candidate. The interesting part is not the markup, it is where the content lives, how the locale is stored, and what the type checker knows.

{
  "cart": {
    "title": "Your cart",
    "items": "{count, plural, one {# item} other {# items}}"
  }
}

<script lang="ts">
  import { _ } from "svelte-i18n";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{$_("cart.title")}</h2>
  <p>{$_("cart.items", { values: { count } })}</p>
</section>

{
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}

<script lang="ts">
  import { m } from "$lib/paraglide/messages.js";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{m.cart_title()}</h2>
  <p>{m.cart_items({ count })}</p>
</section>

import type { BaseTranslation } from "../i18n-types";

const en = {
  cart: {
    title: "Your cart",
    items: "{count} item{{s}}",
  },
} satisfies BaseTranslation;

export default en;

<script lang="ts">
  import LL from "$i18n/i18n-svelte";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{$LL.cart.title()}</h2>
  <p>{$LL.cart.items({ count })}</p>
</section>

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

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({ en: "Your cart", fr: "Votre panier", es: "Tu carrito" }),
    items: t({
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
    }),
  },
} satisfies Dictionary;

export default cartSummaryContent;

<script lang="ts">
  import { useIntlayer } from "svelte-intlayer";

  let { count }: { count: number } = $props();
  const content = useIntlayer("cart-summary");
</script>

<section>
  <h2>{$content.title}</h2>
  <p>{$content.items(count)}</p>
</section>

Already on svelte-i18n? The @intlayer/svelte-i18n compat adapter aliases the package at the bundler level so $_, $date, $number and your flat keys keep working while Intlayer serves the content.

Before you commit

A feature table tells you what a library does today. These points tell you what living with it will be like.

Check repository activity.

Commits, issue response time, and whether the last minor release was this year. A sound design with no maintainer is a migration in waiting.

Do not pick by npm downloads.

The most installed library is the one that shipped first, not the one that fits a 2026 Svelte codebase. Downloads measure history, not fit.

Ask who pays the maintainer, and what they sell.

svelte-i18n is backed by Crowdin, like next-intl and vue-i18n. i18next is backed by Locize. Tolgee, Paraglide (inlang) and Intlayer each run their own platform. A vendor whose revenue is hosted translation has little reason to make translation free inside your toolchain. Intlayer is the only one of the set that ships AI translation through the CLI with your own API key, and a CMS you can self-host.

Is it AI-agent ready?

Agents still struggle with i18n: they forget locales, invent keys, and mix message syntaxes. Does the library ship Agent Skills or an MCP server so the agent can list, fill and test content? And is content loading optimised by default, or does someone have to review namespaces and lazy imports every quarter?

Type safety out of the box.

Not "can be typed with extra wiring" but "a wrong key fails tsc on a fresh install". Check what happens with a key that does not exist, and with a locale that is missing one translation.

Detection of unused content.

Catalogues only grow. Intlayer's build purges unused fields and logs them (build.purge). Paraglide gets there by architecture, since an uncalled message function is tree-shaken. Everything else leaves the sweep to you.

Developer experience.

Setup time to first translated string, an LSP or VS Code extension that shows the translation on hover and jumps to the declaration, a CLI for fill, test and push, and a way for non-developers to edit content (visual editor or CMS) without a pull request.

Frequently Asked Questions

Going further

• Svelte i18n benchmark: bundle size, leakage and locale-switch timings
• Svelte i18n: stores, runes and the module-level trap and SvelteKit i18n: routing, SSR and shared state
• Drop-in svelte-i18n compat adapter
• The history of JavaScript i18n
• Compiler vs declarative i18n
• Per-component vs centralised i18n
• How bundle optimisation works at build time
• Set up i18n in a Vite + Svelte app and in a SvelteKit app
• Same guide for React, Vue and Solid