Localisation avec Next.js pour l'App Router et le Pages Router

Le routage par sous-chemin donne à chaque langue une URL visible, comme /en/pricing et /fr/pricing. Il fonctionne sur un seul domaine, se teste facilement et transforme le changement de langue en modification de chemin. Le routage par domaine, comme example.fr, peut répondre à des besoins de marque ou à des exigences juridiques propres à un marché, mais ajoute du travail en matière de DNS, de déploiement, d'analytique et de canonicalisation. Choisissez des domaines pour des raisons liées au produit, et non parce que la localisation les exige.

Dans l'App Router, placez toutes les pages localisées sous app/[locale]. Un Proxy peut examiner le chemin, le cookie ou l'en-tête Accept-Language au moment de la requête et rediriger une URL d'entrée neutre vers une langue. Next.js 16 a renommé middleware.ts en proxy.ts, bien que les anciennes applications utilisent encore le nom middleware. Considérez la négociation comme une commodité : chaque URL localisée doit rester directement accessible et le sélecteur doit utiliser des liens ordinaires explorables.

Un export entièrement statique ne peut pas exécuter Proxy, lire les cookies de la requête ni effectuer de redirections à la volée. Avec output: 'export', énumérez les segments de langue à l'aide de generateStaticParams et fournissez une page d'entrée statique, par exemple une page d'accueil dans la langue par défaut ou un sélecteur de langue visible. Ne promettez pas de détection automatique de la langue du navigateur dans un environnement dépourvu d'exécution au moment de la requête.

L'option i18n de next.config.js du Pages Router prend en charge les sous-chemins et domaines de langue dans les applications Next.js déployées. Elle n'est pas compatible avec output: 'export'. Si un projet Pages Router doit produire uniquement des fichiers statiques, représentez la langue par un segment dynamique explicite et générez ces routes plutôt que d'activer le champ i18n intégré. La génération statique et l'export statique sont liés, mais ne constituent pas le même mode de déploiement.

app/
  [locale]/
    layout.tsx
    page.tsx
    pricing/
      page.tsx
messages/
  en.json
  fr.json
  de.json

La séquence suivante utilise une application App Router, car elle met en évidence les décisions auxquelles font face la plupart des nouveaux projets. Les imports exacts varient selon la bibliothèque, mais les frontières restent stables : validez la langue au niveau de la route, chargez les messages côté serveur pour cette requête, fournissez uniquement ce dont les Client Components ont besoin et générez les langues connues pendant la compilation lorsque la page peut être statique.

1. Étape 1

   Ajouter le segment de route de langue

   Créez app/[locale] et placez-y les layouts et pages localisés. Validez les paramètres par rapport à une liste unique de langues prises en charge et renvoyez une réponse introuvable pour les valeurs inconnues.

2. Étape 2

   Définir la négociation et le repli

   Décidez du comportement à adopter pour une URL sans langue. Un environnement d'exécution des requêtes peut négocier et rediriger ; un export statique exige une page par défaut déterministe ou un sélecteur de langue. Préservez toujours l'accès direct aux URL localisées.

3. Étape 3

   Créer des catalogues de messages ciblés

   Organisez les messages par domaine produit ou par route au lieu de placer toute l'application dans un seul fichier. Conservez la même structure d'espaces de noms dans toutes les langues, validez les clés manquantes dans la CI et évitez d'importer toutes les langues dans un Client Component.

4. Étape 4

   Charger les messages sur le serveur

   Résolvez un catalogue validé pour chaque requête ou route générée. Lorsque la bibliothèque stocke l'état de la langue active, limitez les instances serveur à la requête afin d'empêcher les requêtes simultanées de se transmettre leur choix de langue.

5. Étape 5

   Séparer la traduction côté serveur et côté client

   Traduisez par défaut dans les Server Components. N'ajoutez un provider ou un hook client que sur la plus petite frontière interactive qui en a besoin, et transmettez des libellés traduits comme propriétés lorsque cette solution est plus simple.

6. Étape 6

   Générer les variantes linguistiques

   Renvoyez chaque langue prise en charge depuis generateStaticParams pour les pages statiques. Le contenu dynamique peut aussi exiger des combinaisons de slug et de langue. Relancez la compilation chaque fois que les catalogues ou la liste des langues changent.

import {NextIntlClientProvider} from 'next-intl';
import {getMessages} from 'next-intl/server';

export default async function LocaleLayout({children, params}: Props) {
  const {locale} = await params;
  const messages = await getMessages();

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

const locales = ['en', 'fr', 'de'] as const;

export function generateStaticParams() {
  return locales.map((locale) => ({locale}));
}

Confiez au layout racine de la langue les responsabilités transversales : validation des paramètres, chargement du catalogue, définition de html lang et dir, et mise en place de tout provider côté client. Les pages doivent demander les messages par espace de noms sans savoir où résident les catalogues. Cette séparation permet de remplacer les imports JSON locaux par un téléchargement à la compilation ou un processus adossé à un CDN sans réécrire chaque composant.

Pour le Pages Router, transposez ces mêmes responsabilités dans le routage de langue de next.config.js, le chargement des messages via getStaticProps ou getServerSideProps, et getStaticPaths pour les pages localisées dynamiques. Les API des routeurs diffèrent, mais les couches de catalogues et de composants peuvent rester cohérentes. Lors d'une migration, prenez délibérément en charge les deux routeurs et vérifiez que la navigation ne supprime jamais le préfixe de langue.

Le HTML rendu n'est que le point de départ du SEO multilingue. Les moteurs de recherche ont besoin d'une URL distincte et stable pour chaque version linguistique, ainsi que de liens clairs entre les variantes. Dans l'App Router, generateMetadata peut produire des titres et descriptions localisés, ainsi que alternates.canonical et alternates.languages. Un sitemap peut également répertorier les variantes linguistiques. Appliquez une stratégie d'URL cohérente afin que les métadonnées, la navigation et les entrées du sitemap ne se contredisent jamais.

Chaque page localisée doit faire référence à elle-même et à toutes les langues équivalentes au moyen d'annotations hreflang réciproques. Utilisez des URL absolues en production et ajoutez x-default lorsqu'un sélecteur neutre ou une expérience par défaut est utile. En règle générale, l'URL canonique pointe vers la version dans la langue actuelle, et non automatiquement vers l'anglais. Lorsqu'une page n'est pas disponible dans une langue, omettez cette variante non prise en charge au lieu d'envoyer les robots vers un contenu sans rapport.

Ne dépendez pas uniquement d'Accept-Language. Googlebot explore souvent sans préférence linguistique utile, et un contenu adapté à la langue sur une URL unique peut masquer des variantes. Veillez à ce que les pages de chaque langue restent accessibles par des liens ordinaires. Définissez html lang pour les navigateurs et les technologies d'assistance, mais gardez à l'esprit que Google détermine surtout la langue à partir du contenu visible : la traduction elle-même doit donc être substantielle et cohérente.

• ✓ Renvoyez un HTML localisé complet à une URL stable et explorable.
• ✓ Localisez le titre, la description, les titres de section et le corps visible, pas uniquement l'enveloppe de navigation.
• ✓ Émettez une URL canonique pour la page actuelle et des liens hreflang réciproques pour chaque langue disponible.
• ✓ Incluez les URL localisées dans le sitemap et utilisez x-default pour un repli neutre lorsque cela convient.
• ✓ Conservez un sélecteur de langue explorable et évitez les redirections forcées qui enferment les utilisateurs ou les robots dans une seule langue.

Une bibliothèque Next.js détermine comment l'application sélectionne et affiche les messages. Une plateforme de localisation prend en charge le cycle de vie qui les entoure : collecte des clés, traduction des valeurs, révision des modifications, alignement des catalogues de langues et diffusion du contenu approuvé. Ces besoins apparaissent dès que les textes changent plus souvent que les déploiements ou que les contributeurs ne se limitent plus à un seul développeur.

Translatable est conçu autour de fichiers de localisation JSON. Les équipes peuvent importer leurs catalogues existants, les modifier ou les traduire avec l'aide de l'IA, les synchroniser via des fournisseurs Git et distribuer les mises à jour par un CDN. L'application conserve la maîtrise de son routage et de sa bibliothèque i18n, ce qui permet de faire évoluer la diffusion des messages sans lier les composants d'interface à un environnement d'exécution propriétaire.

Commencez par des catalogues versionnés avec le code et un processus exécuté à la compilation. N'introduisez la diffusion à distance que lorsque des mises à jour de texte plus rapides apportent une réelle valeur, et conservez une solution de repli intégrée pour les pages critiques. Cette évolution progressive maintient le rendu statique déterministe tout en offrant aux équipes de contenu un chemin plus simple vers la production à mesure que le produit grandit.