Comment choisir la bonne bibliothèque i18n pour Svelte

Svelte ne fournit rien pour l'i18n. Pas de $t, pas de primitive de locale, pas de format de message. Chaque option est un choix tiers, et l'écosystème Svelte est celui où l'i18n à la compilation est allée le plus loin, de sorte que les candidats diffèrent davantage les uns des autres que dans React ou Vue.

Ce guide liste les questions à se poser en premier, puis associe les réponses à svelte-i18n, Paraglide, typesafe-i18n, wuchale et Intlayer, pour Vite + Svelte et pour SvelteKit.

Table of Contents

Six questions à se poser avant de comparer les bibliothèques

1. SPA Vite ou SvelteKit ? Dans une SPA, un store au niveau du module est correct : un onglet, un utilisateur, une locale. Sur SvelteKit, ce même singleton est partagé entre les requêtes concurrentes sur le serveur, et la requête B s'affiche dans la langue de la requête A. La bibliothèque vous fournit soit une structure par requête (contexte, locals), soit vous laisse la gérer.
2. Qui rédige les traductions ? Les développeurs, un TMS, une agence fournissant des chaînes ICU, ou un pipeline IA. svelte-i18n utilise ICU. Paraglide et typesafe-i18n utilisent leur propre syntaxe. Adaptez-vous à vos prestataires.
3. Combien de locales et de pages ? Deux locales et cinq pages peuvent tout embarquer. Dix locales et quarante routes ne le peuvent pas, et la différence entre catalogues au runtime et messages compilés devient le coût principal.
4. Avez-vous besoin du typage sur les clés ? $_("cart.totl") est une erreur au runtime dans svelte-i18n. Les bibliothèques à la compilation en font une erreur de type par construction.
5. Stores Svelte 4 ou runes Svelte 5 ? Les runes changent la syntaxe de l'état de la locale, pas le problème de partage. Mais $state dans un fichier .ts compile en une simple variable, le runtime de la bibliothèque doit donc être compatible avec les runes si vous êtes sur Svelte 5.
6. Pouvez-vous accepter des fichiers générés dans le dépôt ? Paraglide et typesafe-i18n génèrent tous deux du JavaScript ou du TypeScript dans votre arborescence source. Certaines équipes s'en accommodent très bien, d'autres rencontrent des conflits de fusion sur chaque branche parallèle.

Notez vos réponses. Tout ce qui suit y fait référence.

Le paysage en une image

L'i18n dans Svelte est arrivée plus tard que dans React ou Vue, et est passée directement aux vagues de compilation.

L'histoire de l'i18n JavaScript détaille chaque vague.

La décision la plus importante : où vit le contenu et quand il se charge

Deux choix structurels expliquent la majeure partie des différences de taille de bundle entre les configurations :

• Contenu centralisé ou scopé. Un seul fichier locales/en.json pour l'application, ou une déclaration par composant.
• Import statique ou dynamique. Tout charger au démarrage, ou récupérer la locale active (et idéalement la route active) à la demande.

Le graphique estime la charge utile pour une application théorique de 1 à 10 pages, traduite en 1 à 10 locales, avec environ 30 Ko de texte par page.

svelte-i18n se situe en haut à gauche par défaut : register("fr", () => import("./fr.json")) permet un chargement dynamique par locale, mais un catalogue de locale est un objet unique et son chargement charge le texte de chaque page. Paraglide représente le cas intéressant : comme chaque message est son propre export, le tree-shaking prend en charge l'axe des pages sans surcoût, et le benchmark Svelte confirme qu'il fonctionne comme annoncé sur Vite + Svelte (ce n'était pas le cas dans les benchmarks React et Next.js). Intlayer atteint le même résultat grâce aux déclarations par composant.

Si votre réponse à la question 3 était "beaucoup de pages", accordez plus de poids à cette section qu'à n'importe quelle préférence d'API. L'article sur l'i18n par composant vs centralisée aborde l'aspect maintenance de ce même compromis.

Les candidats

Les tailles des bibliothèques sont issues du benchmark Svelte : store plus accesseur dans un composant vide, après bundling, tree-shaking et minification, sur une application de 10 pages et 10 locales. Le contenu est mesuré séparément.

Les chiffres sont un aperçu des versions testées lors du benchmark. Exécutez-le sur votre propre application avant de décider uniquement sur la base de la taille.

La taille quasi nulle de la bibliothèque Paraglide est obtenue par construction : le runtime est généré dans votre dépôt. Intlayer nécessite vite-intlayer, il ne peut donc pas fonctionner sans étape de build.

Associer vos réponses à une bibliothèque

Où chaque bibliothèque montre ses limites

• svelte-i18n : la plus lourde de l'ensemble, aucun type sur les clés, aucun découpage par route, store au niveau du module qui fuit entre les requêtes sur SvelteKit à moins de configurer le contexte vous-même.
• typesafe-i18n : un processus de surveillance (watcher), des fichiers générés dans le dépôt, et un projet qui a peu évolué récemment.
• Paraglide : fichiers générés commités dans le dépôt et régénérés avant chaque push, conflits de fusion sur les branches parallèles, et locale lue depuis un cookie ou le storage à chaque appel de message plutôt que depuis un store, ce qui demande du travail lors du changement de locale.
• wuchale : idée d'extraction intéressante, encore jeune. Le benchmark React a rencontré des problèmes de réactivité nécessitant de forcer des re-renders de provider, et la documentation est succincte.
• Intlayer : plugin de build obligatoire, écosystème plus restreint, support partiel d'ICU, et contenu réparti dans la codebase par conception, de sorte que l'exportation d'un JSON unique pour un traducteur nécessite des outils spécifiques.

À quoi ressemble chaque option en code

Le même composant, un récapitulatif de panier avec un titre et un pluriel, écrit avec chaque candidat. La partie intéressante n'est pas le balisage, c'est l'emplacement du contenu, la façon dont la locale est stockée et ce que sait le vérificateur de types.

{
  "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({ fr: "Votre panier", en: "Your cart", es: "Tu carrito" }),
    items: t({
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      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>

Vous utilisez déjà svelte-i18n ? L'adaptateur de compatibilité @intlayer/svelte-i18n crée un alias pour le package au niveau du bundler afin que $_, $date, $number et vos clés plates continuent de fonctionner pendant qu'Intlayer gère le contenu.

Avant de vous engager

Un tableau de fonctionnalités indique ce qu'une bibliothèque fait aujourd'hui. Ces points montrent ce que sera son utilisation au quotidien.

Vérifiez l'activité du dépôt.

Les commits, le temps de réponse aux issues, et si la dernière release mineure a eu lieu cette année. Une conception solide sans mainteneur est une future migration programmée.

Ne choisissez pas en fonction des téléchargements npm.

La bibliothèque la plus installée est celle qui est sortie en premier, pas celle qui convient à une codebase Svelte en 2026. Les téléchargements mesurent l'histoire, pas l'adéquation.

Renseignez-vous sur qui finance le mainteneur, et ce qu'il vend.

svelte-i18n est soutenu par Crowdin, comme next-intl et vue-i18n. i18next est soutenu par Locize. Tolgee, Paraglide (inlang) et Intlayer exploitent chacun leur propre plateforme. Un fournisseur dont les revenus dépendent d'une traduction hébergée a peu d'intérêt à rendre la traduction gratuite au sein de votre chaîne d'outils. Intlayer est le seul de la sélection à proposer la traduction par IA via la CLI avec votre propre clé d'API, ainsi qu'un CMS auto-hébergeable.

Est-elle prête pour les agents IA ?

Les agents rencontrent encore des difficultés avec l'i18n : ils oublient des locales, inventent des clés et mélangent les syntaxes de messages. La bibliothèque propose-t-elle des Agent Skills ou un serveur MCP pour que l'agent puisse lister, compléter et tester le contenu ? Et le chargement du contenu est-il optimisé par défaut, ou faut-il revoir les namespaces et les lazy imports chaque trimestre ?

Sécurité de typage prête à l'emploi.

Pas "pouvant être typé avec de la configuration supplémentaire", mais "une mauvaise clé échoue à tsc sur une installation neuve". Vérifiez ce qui se passe avec une clé inexistante, ou avec une locale à laquelle il manque une traduction.

Détection du contenu inutilisé.

Les catalogues ne font que grossir. Le build d'Intlayer purge les champs inutilisés et les consigne (build.purge). Paraglide y parvient par architecture, puisqu'une fonction de message non appelée est éliminée par tree-shaking. Tout le reste vous laisse le soin du nettoyage.

Expérience développeur.

Le temps nécessaire pour afficher la première chaîne traduite, un LSP ou une extension VS Code qui affiche la traduction au survol et renvoie à la déclaration, une CLI pour compléter, tester et déployer, ainsi qu'un moyen pour les non-développeurs d'éditer le contenu (éditeur visuel ou CMS) sans pull request.

Foire aux questions

Pour aller plus loin

• Benchmark i18n Svelte : bundle size, fuites et temps de changement de locale
• i18n Svelte : stores, runes et le piège du niveau module et i18n SvelteKit : routage, SSR et état partagé
• Adaptateur de compatibilité svelte-i18n
• L'histoire de l'i18n JavaScript
• i18n à la compilation vs i18n déclarative
• i18n par composant vs centralisée
• Comment fonctionne l'optimisation de bundle au build
• Configurer l'i18n dans une application Vite + Svelte et dans une application SvelteKit
• Même guide pour React, Vue et Solid