next-i18next VS next-intl VS intlayer | Internationalisation (i18n) Next.js

Examinons les similitudes et différences entre trois options i18n pour Next.js : next-i18next, next-intl, et Intlayer.

Ce n’est pas un tutoriel complet. C’est une comparaison pour vous aider à choisir.

Nous nous concentrons sur Next.js 13+ App Router (avec React Server Components) et évaluons :

1. Architecture et organisation du contenu
2. TypeScript et sécurité
3. Gestion des traductions manquantes
4. Routage et middleware
5. Performance et comportement de chargement
6. Expérience développeur (DX), outils et maintenance
7. SEO et évolutivité pour les grands projets

En résumé : Les trois solutions peuvent localiser une application Next.js. Si vous souhaitez un contenu scoped par composant, des types TypeScript stricts, des vérifications des clés manquantes à la compilation, des dictionnaires optimisés par tree-shaking, ainsi que des helpers de premier ordre pour App Router et SEO, Intlayer est le choix le plus complet et moderne.

Une confusion fréquente chez les développeurs est de penser que next-intl est la version Next.js de react-intl. Ce n'est pas le cas — next-intl est maintenu par Amann, tandis que react-intl est maintenu par FormatJS.

En bref

• next-intl - Formatage de messages léger et simple avec un bon support Next.js. Les catalogues centralisés sont courants ; l'expérience développeur (DX) est simple, mais la sécurité et la maintenance à grande échelle restent principalement de votre responsabilité.
• next-i18next - i18next habillé pour Next.js. Écosystème mature et fonctionnalités via des plugins (par exemple, ICU), mais la configuration peut être verbeuse et les catalogues ont tendance à se centraliser à mesure que les projets grandissent.
• Intlayer - Modèle de contenu centré sur les composants pour Next.js, typage strict en TS, vérifications à la compilation, tree-shaking, middleware intégré et aides SEO, éditeur visuel/CMS optionnel, et traductions assistées par IA.

Move

Library	GitHub Stars	Total Commits	Last Commit	First Version	NPM Version	NPM Downloads
aymericzip/intlayer				April 2024
amannn/next-intl				Nov 2020
i18next/i18next				Jan 2012
i18next/next-i18next				Nov 2018

Les badges se mettent à jour automatiquement. Les instantanés peuvent varier dans le temps.

Comparaison des fonctionnalités côte à côte (axée sur Next.js)

Introduction

Next.js offre un support intégré pour le routage internationalisé (par exemple, les segments de locale). Mais cette fonctionnalité ne réalise pas les traductions par elle-même. Vous avez toujours besoin d'une bibliothèque pour afficher du contenu localisé à vos utilisateurs.

De nombreuses bibliothèques i18n existent, mais dans l’univers Next.js aujourd’hui, trois gagnent en popularité : next-i18next, next-intl, et Intlayer.

Architecture & évolutivité

• next-intl / next-i18next : Par défaut, utilisent des catalogues centralisés par locale (plus des espaces de noms dans i18next). Cela fonctionne bien au début, mais devient souvent une grande surface partagée avec un couplage croissant et une forte rotation des clés.
• Intlayer : Encourage des dictionnaires par composant (ou par fonctionnalité) co-localisés avec le code qu’ils servent. Cela réduit la charge cognitive, facilite la duplication/migration des éléments d’interface utilisateur, et diminue les conflits entre équipes. Le contenu inutilisé est naturellement plus facile à repérer et à supprimer.

Pourquoi c’est important : Dans les grandes bases de code ou les configurations de systèmes de design, le contenu modulaire évolue mieux que les catalogues monolithiques.

Tailles des bundles & dépendances

Après la compilation de l'application, le bundle correspond au JavaScript que le navigateur chargera pour afficher la page. La taille du bundle est donc importante pour la performance de l'application.

Deux composants sont importants dans le contexte d'un bundle d'application multilingue :

• Le code de l'application
• Le contenu chargé par le navigateur

Code de l'application

L'importance du code de l'application est minimale dans ce cas. Les trois solutions sont "tree-shakables", ce qui signifie que les parties inutilisées du code ne sont pas incluses dans le bundle.

Voici une comparaison de la taille du bundle JavaScript chargé par le navigateur pour une application multilingue avec les trois solutions.

Si aucun formateur n'est nécessaire dans l'application, la liste des fonctions exportées après tree-shaking sera :

• next-intlayer : useIntlayer, useLocale, NextIntlClientProvider, (La taille du bundle est de 180,6 kB -> 78,6 kB (gzip))
• next-intl : useTranslations, useLocale, NextIntlClientProvider, (La taille du bundle est de 101,3 kB -> 31,4 kB (gzip))
• next-i18next : useTranslation, useI18n, I18nextProvider, (La taille du bundle est de 80,7 kB -> 25,5 kB (gzip))

Ces fonctions ne sont que des wrappers autour du contexte/état React, donc l'impact total de la bibliothèque i18n sur la taille du bundle est minimal.

Intlayer est légèrement plus volumineux que next-intl et next-i18next car il inclut plus de logique dans la fonction useIntlayer. Cela est lié à l'intégration de markdown et de intlayer-editor.

Contenu et traductions

Cette partie est souvent ignorée par les développeurs, mais considérons le cas d'une application composée de 10 pages en 10 langues. Supposons que chaque page intègre un contenu 100 % unique pour simplifier le calcul (en réalité, beaucoup de contenu est redondant entre les pages, par exemple, le titre de la page, l'en-tête, le pied de page, etc.).

Un utilisateur souhaitant visiter la page /fr/about chargera le contenu d'une page dans une langue donnée. Ignorer l'optimisation du contenu reviendrait à charger inutilement 8 200 % ((1 + (((10 pages - 1) × (10 langues - 1)))) × 100) du contenu de l'application. Voyez-vous le problème ? Même si ce contenu reste du texte, et alors que vous préférez probablement penser à optimiser les images de votre site, vous envoyez du contenu inutile à travers le monde et faites traiter cela aux ordinateurs des utilisateurs pour rien.

Deux problèmes importants :

• Fractionnement par route :

  Si je suis sur la page /about, je ne veux pas charger le contenu de la page /home

• Fractionnement par locale :

  Si je suis sur la page /fr/about, je ne veux pas charger le contenu de la page /en/about

Encore une fois, les trois solutions sont conscientes de ces problèmes et permettent de gérer ces optimisations. La différence entre les trois solutions réside dans l'expérience développeur (DX).

next-intl et next-i18next utilisent une approche centralisée pour gérer les traductions, permettant de fractionner les fichiers JSON par locale et par sous-fichiers. Dans next-i18next, nous appelons ces fichiers JSON des « namespaces » ; next-intl permet de déclarer des messages. Dans intlayer, nous appelons ces fichiers JSON des « dictionnaires ».

• Dans le cas de next-intl, comme pour next-i18next, le contenu est chargé au niveau de la page/layout, puis ce contenu est chargé dans un fournisseur de contexte. Cela signifie que le développeur doit gérer manuellement les fichiers JSON qui seront chargés pour chaque page.

En pratique, cela implique que les développeurs sautent souvent cette optimisation, préférant charger tout le contenu dans le fournisseur de contexte de la page pour plus de simplicité.

• Dans le cas de intlayer, tout le contenu est chargé dans l'application. Ensuite, un plugin (@intlayer/babel / @intlayer/swc) s'occupe d'optimiser le bundle en ne chargeant que le contenu utilisé sur la page. Le développeur n'a donc pas besoin de gérer manuellement les dictionnaires qui seront chargés. Cela permet une meilleure optimisation, une meilleure maintenabilité, et réduit le temps de développement.

À mesure que l'application grandit (surtout lorsque plusieurs développeurs travaillent sur l'application), il est courant d'oublier de supprimer le contenu qui n'est plus utilisé dans les fichiers JSON.

Notez que tous les JSON sont chargés dans tous les cas (next-intl, next-i18next, intlayer).

C'est pourquoi l'approche d'Intlayer est plus performante : si un composant n'est plus utilisé, son dictionnaire n'est pas chargé dans le bundle.

La manière dont la bibliothèque gère les valeurs de repli (fallbacks) est également importante. Considérons que l'application est en anglais par défaut, et que l'utilisateur visite la page /fr/about. Si des traductions manquent en français, nous considérerons le repli en anglais.

Dans le cas de next-intl et next-i18next, la bibliothèque nécessite de charger le JSON lié à la locale actuelle, mais aussi à la locale de secours. Ainsi, en supposant que tout le contenu a été traduit, chaque page chargera 100 % de contenu inutile. En comparaison, intlayer traite la locale de secours lors de la construction du dictionnaire. Ainsi, chaque page ne chargera que le contenu utilisé.

Voici un exemple de l'impact de l'optimisation de la taille du bundle en utilisant intlayer dans une application vite + react :

Move

Bundle optimisé	Bundle non optimisé

TypeScript & sécurité

Pourquoi c’est important : Un typage fort déplace les erreurs vers la gauche (CI/build) au lieu de la droite (exécution).

Gestion des traductions manquantes

next-intl

• S’appuie sur des solutions de secours à l’exécution (par exemple, afficher la clé ou la locale par défaut). La compilation ne plante pas.

next-i18next

• S’appuie sur des solutions de secours à l’exécution (par exemple, afficher la clé ou la locale par défaut). La compilation ne plante pas.

intlayer

• Détection à la compilation avec avertissements/erreurs pour les locales ou clés manquantes.

Pourquoi c’est important : Détecter les lacunes lors de la compilation évite les « chaînes mystères » en production et s’aligne avec des règles strictes de publication.

Routage, middleware & stratégie d’URL

Pourquoi c’est important : Moins de couches de liaison personnalisées ; expérience utilisateur cohérente et SEO propre à travers les locales.

Alignement avec les Server Components (RSC)

Pourquoi c'est important : Modèle mental plus clair et moins de cas particuliers dans les arbres hybrides.

DX, outils & maintenance

Pourquoi c’est important : Réduit les coûts opérationnels et raccourcit la boucle entre les développeurs et les auteurs de contenu.

Intégration avec les plateformes de localisation (TMS)

Les grandes organisations s’appuient souvent sur des systèmes de gestion de traduction (TMS) comme Crowdin, Phrase, Lokalise, Localizely ou Localazy.

• Pourquoi les entreprises s’en soucient

  • Collaboration & rôles : Plusieurs acteurs sont impliqués : développeurs, chefs de produit, traducteurs, relecteurs, équipes marketing.
  • Échelle & efficacité : localisation continue, relecture en contexte.

• next-intl / next-i18next

  • Utilisent généralement des catalogues JSON centralisés, ce qui rend l’export/import avec un TMS simple.
  • Écosystèmes matures et exemples/intégrations pour les plateformes mentionnées ci-dessus.

• Intlayer

  • Encourage les dictionnaires décentralisés par composant et supporte du contenu TypeScript/TSX/JS/JSON/MD.
  • Cela améliore la modularité dans le code, mais peut rendre l’intégration plug-and-play avec un TMS plus difficile lorsqu’un outil attend des fichiers JSON centralisés et plats.
  • Intlayer propose des alternatives : traductions assistées par IA (en utilisant vos propres clés de fournisseur), un éditeur visuel/CMS, et des workflows CLI/CI pour détecter et préremplir les lacunes.

Remarque : next-intl et i18next acceptent également les catalogues TypeScript. Si votre équipe stocke les messages dans des fichiers .ts ou les décentralise par fonctionnalité, vous pouvez rencontrer des frictions similaires avec le TMS. Cependant, de nombreuses configurations next-intl restent centralisées dans un dossier locales/, ce qui est un peu plus facile à refactoriser en JSON pour le TMS.

Expérience développeur

Cette partie fait une comparaison approfondie entre les trois solutions. Plutôt que de considérer des cas simples, comme décrit dans la documentation « démarrage » de chaque solution, nous allons considérer un cas d'utilisation réel, plus proche d'un vrai projet.

Structure de l'application

La structure de l'application est importante pour assurer une bonne maintenabilité de votre base de code.

.├── i18n.config.ts└── src    ├── locales    │   ├── en    │   │  ├── common.json    │   │  └── about.json    │   └── fr    │      ├── common.json    │      └── about.json    ├── app    │   ├── i18n    │   │   └── server.ts    │   └── [locale]    │       ├── layout.tsx    │       └── about.tsx    └── components        ├── I18nProvider.tsx        ├── ClientComponent.tsx        └── ServerComponent.tsx

.├── i18n.ts├── locales│   ├── en│   │  ├── home.json│   │  └── navbar.json│   ├── fr│   │  ├── home.json│   │  └── navbar.json│   └── es│      ├── home.json│      └── navbar.json└── src    ├── middleware.ts    ├── app    │   ├── i18n    │   │   └── server.ts    │   └── [locale]    │       └── home.tsx    └── components        └── Navbar            └── index.tsx

.├── intlayer.config.ts└── src    ├── middleware.ts    ├── app    │   └── [locale]    │       ├── layout.tsx    │       └── home    │           ├── index.tsx    │           └── index.content.ts    └── components        └── Navbar            ├── index.tsx            └── index.content.ts

Comparaison

• next-intl / next-i18next : Catalogues centralisés (JSON ; espaces de noms/messages). Structure claire, s'intègre bien avec les plateformes de traduction, mais peut entraîner plus de modifications croisées entre fichiers à mesure que les applications grandissent.
• Intlayer : Dictionnaires .content.{ts|js|json} par composant, co-localisés avec les composants. Facilite la réutilisation des composants et la réflexion locale ; ajoute des fichiers et repose sur des outils au moment de la compilation.

Configuration et Chargement du Contenu

Comme mentionné précédemment, vous devez optimiser la manière dont chaque fichier JSON est importé dans votre code. La façon dont la bibliothèque gère le chargement du contenu est importante.

module.exports = {  i18n: {    locales: ["en", "fr", "es"],    defaultLocale: "en",  },};

import { appWithTranslation } from "next-i18next";const MyApp = ({ Component, pageProps }) => <Component {...pageProps} />;export default appWithTranslation(MyApp);

import type { GetStaticProps } from "next";import { serverSideTranslations } from "next-i18next/serverSideTranslations";import { useTranslation } from "next-i18next";import { I18nextProvider, initReactI18next } from "react-i18next";import { createInstance } from "i18next";import { ClientComponent, ServerComponent } from "@components";export default function HomePage({ locale }: { locale: string }) {  // Déclarez explicitement le namespace utilisé par ce composant  const resources = await loadMessagesFor(locale); // votre chargeur (JSON, etc.)  const i18n = createInstance();  i18n.use(initReactI18next).init({    lng: locale,    fallbackLng: "en",    resources,    ns: ["common", "about"],    defaultNS: "common",    interpolation: { escapeValue: false },  });  const { t } = useTranslation("about");  return (    <I18nextProvider i18n={i18n}>      <main>        <h1>{t("title")}</h1>        <ClientComponent />        <ServerComponent />      </main>    </I18nextProvider>  );}export const getStaticProps: GetStaticProps = async ({ locale }) => {  // Ne préchargez que les namespaces nécessaires à CETTE page  return {    props: {      ...(await serverSideTranslations(locale ?? "en", ["common", "about"])),    },  };};

import { getRequestConfig } from "next-intl/server";import { notFound } from "next/navigation";// Peut être importé depuis une configuration partagéeconst locales = ["en", "fr", "es"];export default getRequestConfig(async ({ locale }) => {  // Valider que le paramètre `locale` reçu est valide  if (!locales.includes(locale as any)) notFound();  return {    messages: (await import(`../messages/${locale}.json`)).default,  };});

import { NextIntlClientProvider } from "next-intl";import { getMessages, unstable_setRequestLocale } from "next-intl/server";import pick from "lodash/pick";export default async function LocaleLayout({  children,  params,}: {  children: React.ReactNode;  params: { locale: string };}) {  const { locale } = params;  // Définir la locale de requête active pour ce rendu serveur (RSC)  unstable_setRequestLocale(locale);  // Les messages sont chargés côté serveur via src/i18n/request.ts  // (voir la documentation next-intl). Ici, nous ne transmettons qu'un sous-ensemble au client  // nécessaire pour les composants client (optimisation de la charge utile).  const messages = await getMessages();  const clientMessages = pick(messages, ["common", "about"]);  const rtlLocales = ["ar", "he", "fa", "ur"];  return (    <html lang={locale} dir={rtlLocales.includes(locale) ? "rtl" : "ltr"}>      <body>        <NextIntlClientProvider locale={locale} messages={clientMessages}>          {children}        </NextIntlClientProvider>      </body>    </html>  );}

import { getTranslations } from "next-intl/server";import { ClientComponent, ServerComponent } from "@components";export default async function LandingPage({  params,}: {  params: { locale: string };}) {  // Chargement strictement côté serveur (pas hydraté au client)  const t = await getTranslations("about");  return (    <main>      <h1>{t("title")}</h1>      <ClientComponent />      <ServerComponent />    </main>  );}

export default {  internationalization: {    locales: ["en", "fr", "es"],    defaultLocale: "en",  },};

import { getHTMLTextDir } from "intlayer";import {  IntlayerClientProvider,  generateStaticParams,  type NextLayoutIntlayer,} from "next-intlayer";export const dynamic = "force-static";const LandingLayout: NextLayoutIntlayer = async ({ children, params }) => {  const { locale } = await params;  return (    <html lang={locale} dir={getHTMLTextDir(locale)}>      <IntlayerClientProvider locale={locale}>        {children}      </IntlayerClientProvider>    </html>  );};export default LandingLayout;

import { PageContent } from "@components/PageContent";import type { NextPageIntlayer } from "next-intlayer";import { IntlayerServerProvider, useIntlayer } from "next-intlayer/server";import { ClientComponent, ServerComponent } from "@components";const LandingPage: NextPageIntlayer = async ({ params }) => {  const { locale } = await params;  const { title } = useIntlayer("about", locale);  return (    <IntlayerServerProvider locale={locale}>      <main>        <h1>{title}</h1>        <ClientComponent />        <ServerComponent />      </main>    </IntlayerServerProvider>  );};export default LandingPage;

Comparaison

Les trois prennent en charge le chargement de contenu par locale et les fournisseurs.

• Avec next-intl/next-i18next, vous chargez généralement les messages/namespaces sélectionnés par route et placez les providers là où c'est nécessaire.

• Avec Intlayer, une analyse au moment de la compilation est ajoutée pour déduire l'utilisation, ce qui peut réduire le câblage manuel et permettre un provider racine unique.

Choisissez entre un contrôle explicite et l'automatisation selon la préférence de l'équipe.

Utilisation dans un composant client

Prenons un exemple d'un composant client affichant un compteur.

{  "counter": {    "label": "Counter",    "increment": "Increment"  }}

{  "counter": {    "label": "Compteur",    "increment": "Incrémenter"  }}

"use client";import React, { useMemo, useState } from "react";import { useTranslation } from "next-i18next";const ClientComponentExample = () => {  const { t, i18n } = useTranslation("about");  const [count, setCount] = useState(0);  // next-i18next n'expose pas useNumber ; utilisez Intl.NumberFormat  const numberFormat = new Intl.NumberFormat(i18n.language);  return (    <div>      <p>{numberFormat.format(count)}</p>      <button        aria-label={t("counter.label")}        onClick={() => setCount((count) => count + 1)}      >        {t("counter.increment")}      </button>    </div>  );};

{  "counter": {    "label": "Counter",    "increment": "Increment"  }}

{  "counter": {    "label": "Compteur",    "increment": "Incrémenter"  }}

"use client";import React, { useState } from "react";import { useTranslations, useFormatter } from "next-intl";const ClientComponentExample = () => {  // Portée directement sur l'objet imbriqué  const t = useTranslations("about.counter");  const format = useFormatter();  const [count, setCount] = useState(0);  return (    <div>      <p>{format.number(count)}</p>      <button        aria-label={t("label")}        onClick={() => setCount((count) => count + 1)}      >        {t("increment")}      </button>    </div>  );};

import { t, type Dictionary } from "intlayer";const counterContent = {  key: "counter",  content: {    label: t({ en: "Counter", fr: "Compteur" }),    increment: t({ en: "Increment", fr: "Incrémenter" }),  },} satisfies Dictionary;export default counterContent;

"use client";import React, { useState } from "react";import { useNumber, useIntlayer } from "next-intlayer";const ClientComponentExample = () => {  const [count, setCount] = useState(0);  const { label, increment } = useIntlayer("counter"); // retourne des chaînes de caractères  const { number } = useNumber();  return (    <div>      <p>{number(count)}</p>      <button aria-label={label} onClick={() => setCount((count) => count + 1)}>        {increment}      </button>    </div>  );};

Comparaison

• Formatage des nombres

  • next-i18next : pas de useNumber ; utilise Intl.NumberFormat (ou i18next-icu).
  • next-intl : useFormatter().number(value).
  • Intlayer : useNumber() intégré.

• Clés

  • Gardez une structure imbriquée (about.counter.label) et adaptez la portée de votre hook en conséquence (useTranslation("about") + t("counter.label") ou useTranslations("about.counter") + t("label")).

• Emplacements des fichiers

  • next-i18next attend des JSON dans public/locales/{lng}/{ns}.json.
  • next-intl est flexible ; chargez les messages comme vous le configurez.
  • Intlayer stocke le contenu dans des dictionnaires TS/JS et résout par clé.

Utilisation dans un composant serveur

Nous prendrons le cas d'un composant UI. Ce composant est un composant serveur, et doit pouvoir être inséré en tant qu'enfant d'un composant client. (page (composant serveur) -> composant client -> composant serveur). Comme ce composant peut être inséré en tant qu'enfant d'un composant client, il ne peut pas être asynchrone.

import type { GetStaticProps } from "next";import { useTranslation } from "next-i18next";type ServerComponentProps = {  count: number;};const ServerComponent = ({ count }: ServerComponentProps) => {  const { t, i18n } = useTranslation("about");  const formatted = new Intl.NumberFormat(i18n.language).format(count);  return (    <div>      <p>{formatted}</p>      <button aria-label={t("counter.label")}>{t("counter.increment")}</button>    </div>  );};

type ServerComponentProps = {  count: number;  t: (key: string) => string;  formatter: Intl.NumberFormat;};const ServerComponent = ({ t, count, formatter }: ServerComponentProps) => {  const formatted = formatter.format(count);  return (    <div>      <p>{formatted}</p>      <button aria-label={t("label")}>{t("increment")}</button>    </div>  );};

import { useIntlayer, useNumber } from "next-intlayer/server";const ServerComponent = ({ count }: { count: number }) => {  const { label, increment } = useIntlayer("counter");  const { number } = useNumber();  return (    <div>      <p>{number(count)}</p>      <button aria-label={label}>{increment}</button>    </div>  );};

Intlayer expose des hooks sécurisés pour le serveur via next-intlayer/server. Pour fonctionner, useIntlayer et useNumber utilisent une syntaxe de type hooks, similaire aux hooks côté client, mais dépendent en interne du contexte serveur (IntlayerServerProvider).

Métadonnées / Sitemap / Robots

Traduire le contenu est excellent. Mais les gens oublient souvent que le but principal de l'internationalisation est de rendre votre site web plus visible dans le monde. L'i18n est un levier incroyable pour améliorer la visibilité de votre site web.

Voici une liste de bonnes pratiques concernant le SEO multilingue.

• définir les balises meta hreflang dans la balise <head> > Cela aide les moteurs de recherche à comprendre quelles langues sont disponibles sur la page
• lister toutes les traductions des pages dans le sitemap.xml en utilisant le schéma XML http://www.w3.org/1999/xhtml >
• ne pas oublier d'exclure les pages préfixées du robots.txt (par exemple /dashboard, et /fr/dashboard, /es/dashboard) >
• utiliser un composant Link personnalisé pour rediriger vers la page la plus localisée (par exemple en français <a href="/fr/about">À propos</a>) >

Les développeurs oublient souvent de référencer correctement leurs pages selon les locales.

export const locales = ["en", "fr"] as const;export type Locale = (typeof locales)[number];export const defaultLocale: Locale = "en";export function localizedPath(locale: string, path: string) {  return locale === defaultLocale ? path : "/" + locale + path;}const ORIGIN = "https://example.com";export function abs(locale: string, path: string) {  return ORIGIN + localizedPath(locale, path);}

import type { Metadata } from "next";import { locales, defaultLocale, localizedPath } from "@/i18n.config";export async function generateMetadata({  params,}: {  params: { locale: string };}): Promise<Metadata> {  const { locale } = params;  // Importer dynamiquement le fichier JSON correct  const messages = (    await import("@/../public/locales/" + locale + "/about.json")  ).default;  const languages = Object.fromEntries(    locales.map((locale) => [locale, localizedPath(locale, "/about")])  );  return {    title: messages.title,    description: messages.description,    alternates: {      canonical: localizedPath(locale, "/about"),      languages: { ...languages, "x-default": "/about" },    },  };}export default async function AboutPage() {  return <h1>À propos</h1>;}

import type { MetadataRoute } from "next";import { locales, defaultLocale, abs } from "@/i18n.config";export default function sitemap(): MetadataRoute.Sitemap {  const languages = Object.fromEntries(    locales.map((locale) => [locale, abs(locale, "/about")])  );  return [    {      url: abs(defaultLocale, "/about"),      lastModified: new Date(),      changeFrequency: "monthly",      priority: 0.7,      alternates: { languages },    },  ];}

import type { MetadataRoute } from "next";import { locales, defaultLocale, localizedPath } from "@/i18n.config";const ORIGIN = "https://example.com";const expandAllLocales = (path: string) => [  localizedPath(defaultLocale, path),  ...locales    .filter((locale) => locale !== defaultLocale)    .map((locale) => localizedPath(locale, path)),];export default function robots(): MetadataRoute.Robots {  const disallow = [    ...expandAllLocales("/dashboard"),    ...expandAllLocales("/admin"),  ];  return {    rules: { userAgent: "*", allow: ["/"], disallow },    host: ORIGIN,    sitemap: ORIGIN + "/sitemap.xml",  };}

import type { Metadata } from "next";import { locales, defaultLocale } from "@/i18n";import { getTranslations } from "next-intl/server";function localizedPath(locale: string, path: string) {  return locale === defaultLocale ? path : "/" + locale + path;}export async function generateMetadata({  params,}: {  params: { locale: string };}): Promise<Metadata> {  const { locale } = params;  const t = await getTranslations({ locale, namespace: "about" });  const url = "/about";  const languages = Object.fromEntries(    locales.map((locale) => [locale, localizedPath(locale, url)])  );  return {    title: t("title"),    description: t("description"),    alternates: {      canonical: localizedPath(locale, url),      languages: { ...languages, "x-default": url },    },  };}// ... Le reste du code de la page

import type { MetadataRoute } from "next";import { locales, defaultLocale } from "@/i18n";const origin = "https://example.com";const formatterLocalizedPath = (locale: string, path: string) =>  locale === defaultLocale ? origin + path : origin + "/" + locale + path;export default function sitemap(): MetadataRoute.Sitemap {  const aboutLanguages = Object.fromEntries(    locales.map((l) => [l, formatterLocalizedPath(l, "/about")])  );  return [    {      url: formatterLocalizedPath(defaultLocale, "/about"),      lastModified: new Date(),      changeFrequency: "monthly", // fréquence de modification      priority: 0.7, // priorité dans le sitemap      alternates: { languages: aboutLanguages }, // versions alternatives par langue    },  ];}

import type { MetadataRoute } from "next";import { locales, defaultLocale } from "@/i18n";const origin = "https://example.com";const withAllLocales = (path: string) => [  path,  ...locales    .filter((locale) => locale !== defaultLocale)    .map((locale) => "/" + locale + path),];export default function robots(): MetadataRoute.Robots {  const disallow = [    ...withAllLocales("/dashboard"),    ...withAllLocales("/admin"),  ];  return {    rules: { userAgent: "*", allow: ["/"], disallow },    host: origin,    sitemap: origin + "/sitemap.xml",  };}

import { getIntlayer, getMultilingualUrls } from "intlayer";import type { Metadata } from "next";import type { LocalPromiseParams } from "next-intlayer";export const generateMetadata = async ({  params,}: LocalPromiseParams): Promise<Metadata> => {  const { locale } = await params;  const metadata = getIntlayer("page-metadata", locale);  const multilingualUrls = getMultilingualUrls("/about");  return {    ...metadata,    alternates: {      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],      languages: { ...multilingualUrls, "x-default": "/about" },    },  };};// ... Reste du code de la page

import { getMultilingualUrls } from "intlayer";import type { MetadataRoute } from "next";const sitemap = (): MetadataRoute.Sitemap => [  {    url: "https://example.com/about",    alternates: {      languages: { ...getMultilingualUrls("https://example.com/about") },    },  },];

import { getMultilingualUrls } from "intlayer";import type { MetadataRoute } from "next";const getAllMultilingualUrls = (urls: string[]) =>  urls.flatMap((url) => Object.values(getMultilingualUrls(url)) as string[]);// Règles pour le fichier robots.txtconst robots = (): MetadataRoute.Robots => ({  rules: {    userAgent: "*",    allow: ["/"],    disallow: getAllMultilingualUrls(["/dashboard"]), // Interdire l'accès à toutes les URLs multilingues du dashboard  },  host: "https://example.com",  sitemap: "https://example.com/sitemap.xml",});export default robots;

Intlayer fournit une fonction getMultilingualUrls pour générer des URLs multilingues pour votre sitemap.

Et le gagnant est…

Ce n’est pas simple. Chaque option a ses compromis. Voici comment je le vois :

Si vous préférez une configuration minimale et acceptez un certain câblage manuel, next-intl est un bon choix. Si vous avez besoin de toutes les fonctionnalités et que la complexité ne vous dérange pas, next-i18next fonctionne. Mais si vous voulez une solution moderne, évolutive, modulaire avec des outils intégrés, Intlayer vise à vous offrir cela prêt à l’emploi.

Alternative pour les équipes d'entreprise : Si vous avez besoin d'une solution éprouvée qui fonctionne parfaitement avec des plateformes de localisation établies comme Crowdin, Phrase, ou d'autres systèmes professionnels de gestion de traduction, considérez next-intl ou next-i18next pour leur écosystème mature et leurs intégrations éprouvées.

Feuille de route future : Intlayer prévoit également de développer des plugins qui fonctionneront par-dessus les solutions i18next et next-intl. Cela vous offrira les avantages d'Intlayer pour l'automatisation, la syntaxe et la gestion de contenu tout en conservant la sécurité et la stabilité fournies par ces solutions établies dans votre code applicatif.

Étoiles GitHub (GitHub STARs)

Les étoiles GitHub sont un indicateur fort de la popularité d’un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu’elles ne mesurent pas directement la qualité technique, elles reflètent combien de développeurs trouvent le projet utile, suivent son évolution et sont susceptibles de l’adopter. Pour estimer la valeur d’un projet, les étoiles aident à comparer la traction entre différentes alternatives et fournissent des informations sur la croissance de l’écosystème.

Conclusion

Les trois bibliothèques réussissent la localisation de base. La différence réside dans la quantité de travail que vous devez fournir pour obtenir une configuration robuste et évolutive dans Next.js moderne :

• Avec Intlayer, le contenu modulaire, TypeScript strict, la sécurité à la compilation, les bundles optimisés par tree-shaking, et un App Router de première classe avec des outils SEO sont des paramètres par défaut, et non des corvées.
• Si votre équipe valorise la maintenabilité et la rapidité dans une application multi-langues pilotée par composants, Intlayer offre aujourd’hui l’expérience la plus complète.

Consultez la documentation 'Pourquoi Intlayer ?' pour plus de détails.