Internationalisation Next.js : Guide i18n complet avec next-intl

Plus de 75 % des internautes préfèrent naviguer dans leur langue maternelle, et les entreprises qui localisent voient des taux de conversion 70 % plus élevés sur les marchés non anglophones. Next.js combiné à next-intl fournit un cadre d'internationalisation robuste gérant le routage, les traductions, le formatage et le référencement dans un certain nombre de paramètres régionaux.

Points clés à retenir

• next-intl s'intègre parfaitement aux composants du routeur d'application Next.js et du serveur
• Le routage avec préfixe local maintient les URL en anglais propres tout en ajoutant des préfixes pour d'autres langues
• Les composants du serveur chargent les traductions sans surcharge du bundle JavaScript côté client
• Des balises hreflang appropriées et des plans de site multilingues sont essentiels pour le référencement international

---

Configuration du projet

Installez next-intl et organisez votre projet avec un répertoire i18n contenant router.ts, navigation.ts et request.ts. Placez votre application sous [locale] dans App Router. Stockez les fichiers JSON de traduction dans un répertoire de messages à la racine du projet.

Configuration du routage

Définissez le routage avec finishRouting() en spécifiant votre tableau de locales, vos paramètres régionaux par défaut et votre stratégie de préfixe de paramètres régionaux. La stratégie "selon les besoins" omet le préfixe de la langue par défaut (anglais) tout en ajoutant les préfixes /es/, /fr/, /ar/ pour les autres.

Créez des wrappers de navigation avec createNavigation(routing) pour obtenir les fonctions Link, useRouter, usePathname et de redirection tenant compte des paramètres régionaux. Utilisez-les à la place de la navigation native Next.js dans toute votre application.

Configuration du middleware

Dans Next.js 16, créez un fichier proxy.ts (en remplacement de l'ancien modèle middleware.ts). Exportez une fonction proxy créée par createMiddleware(routing). Configurez le comparateur pour exclure les routes API, les fichiers statiques et les chemins _next.

---

Fichiers de traduction

Structure JSON (imbriquée, non plate)

Utilisez des clés imbriquées organisées par espace de noms. N'utilisez jamais de clés plates séparées par des points comme "home.title" - elles brisent la résolution de l'espace de noms next-intl. Structurez les traductions comme :

• commun : termes partagés (boutons, étiquettes, états de chargement)
• nav : éléments de navigation
• accueil : contenu de la page d'accueil
• à propos : à propos du contenu de la page
• admin.common : termes d'administration partagés
• admin.products : page de gestion des produits

Composants du serveur

Utilisez getTranslations("namespace") dans les composants du serveur asynchrone. Cela charge les traductions sur le serveur sans aucun impact sur le bundle client. Appelez t("key") pour les traductions de chaînes, t.rich("key", { bold: (chunks) => ... }) pour le texte enrichi.

Composants clients

Utilisez le hook useTranslations("namespace") dans les composants clients marqués par "use client". Le hook fournit la même fonction t(). Seules les traductions de l'espace de noms actif sont incluses dans le bundle client.

---

Prise en charge RTL (de droite à gauche)

Pour l'arabe, l'hébreu, l'ourdou et d'autres langues RTL, définissez dir="rtl" sur l'élément HTML en fonction des paramètres régionaux actuels. Dans la disposition des paramètres régionaux, vérifiez si les paramètres régionaux se trouvent dans votre tableau rtlLocales et définissez la direction en conséquence.

Utilisez les propriétés logiques CSS de Tailwind (ps, pe, ms, me au lieu de pl, pr, ml, mr) pour les mises en page qui s'inversent automatiquement en mode RTL. Chargez les polices appropriées pour les scripts RTL (par exemple, Noto Sans Arabic pour l'arabe et l'ourdou).

---

SEO : Métadonnées et Hreflang

Métadonnées dynamiques

Chaque page doit utiliser generateMetadata() (jamais d'exportation statique de métadonnées const) pour les titres, les descriptions et les alternatives hreflang tenant compte des paramètres régionaux. Créez un objet alternates.linguals mappant chaque paramètre régional à son chemin d'URL, plus une entrée x-default pointant vers la version anglaise.

Plan du site multilingue

Générez des entrées de plan de site pour chaque page dans chaque région. Chaque entrée doit inclure alternates.langues mappant toutes les variantes de paramètres régionaux. Cela permet aux moteurs de recherche de proposer la version linguistique correcte sur chaque marché.

Balise méta contenu-langage

Définissez la balise méta contenu-langue dans la disposition de vos paramètres régionaux pour aider les moteurs de recherche et les robots d'exploration IA à identifier la langue de la page. Ceci est particulièrement important pour Bing et les moteurs de recherche émergents d’IA.

---

Flux de travail de traduction

1. Modifiez en.json comme source unique de vérité pour toutes les chaînes traduisibles
2. Exécutez le script de traduction pour propager les nouvelles clés à tous les fichiers de paramètres régionaux (en utilisant l'API Google Translate ou DeepL pour les versions initiales)
3. Réviser les traductions avec des locuteurs natifs pour en vérifier la qualité et l'adéquation culturelle
4. Testez minutieusement les langages RTL : vérifiez l'inversion de la mise en page, l'alignement du texte et les entrées de formulaire.
5. Vérifiez le référencement avec les outils de validation hreflang et le ciblage international de Google Search Console

Gestion des fichiers de traduction volumineux

Pour les applications comportant plus de 5 000 clés de traduction, organisez les fichiers JSON par espace de noms pour améliorer la maintenabilité. next-intl charge uniquement les espaces de noms nécessaires à la page actuelle, conservant ainsi des performances optimales.

---

Considérations sur les performances

• Rendu serveur : Les traductions se chargent sur le serveur. Aucun JSON de traduction n'est expédié au client sauf si le composant est un composant client.
• Répartition de l'espace de noms : seuls les espaces de noms actifs sont chargés par page, pas l'intégralité du fichier de traduction.
• Génération statique : les pages utilisant getTranslations() peuvent être générées statiquement au moment de la construction pour toutes les locales.
• Taille du bundle : les composants clients incluent uniquement leurs traductions d'espace de noms. Une page utilisant useTranslations("home") ne contient que l'espace de noms "home".

---

Pièges courants

1. Clés plates : l'utilisation de "home.title" comme clé au lieu de { "home": { "title": "..." } } interrompt la résolution de l'espace de noms
2. Traductions manquantes : fournissez toujours un comportement de secours -- next-intl affiche le nom de la clé si une traduction est manquante, mais cela semble erroné aux utilisateurs
3. Chaînes codées en dur : auditez votre base de code pour détecter toute chaîne en dehors du système de traduction
4. Formatage de date/nombre : utilisez les formateurs next-intl au lieu de toLocaleDateString() pour un comportement cohérent
5. Métadonnées statiques : l'utilisation des métadonnées export const au lieu de generateMetadata() empêche les titres et les descriptions tenant compte des paramètres régionaux.

---

Questions fréquemment posées

Q : Combien de paramètres régionaux next-intl peut-il gérer ?

Il n’y a pas de limite pratique. Les applications avec plus de 11 paramètres régionaux et plus de 7 000 clés de traduction s'exécutent sans problèmes de performances. Le rendu côté serveur signifie que les traductions ne gonflent pas les bundles clients.

Q : i18n affecte-t-il les performances de chargement des pages ?

Avec les composants serveur, le chargement de la traduction s'effectue sur le serveur. L’impact sur les performances est négligeable. Les composants clients incluent uniquement leurs traductions d'espace de noms, généralement quelques Ko.

Q : Comment gérons-nous le contenu de la base de données dynamique dans plusieurs langues ?

Le texte statique de l'interface utilisateur utilise des fichiers JSON. Le contenu de la base de données (articles de blog, descriptions de produits) nécessite de stocker les traductions dans des colonnes ou des tableaux dédiés, ou d'utiliser un CMS avec un workflow de traduction intégré. Certaines équipes utilisent un hybride : JSON pour l'interface utilisateur, base de données pour le contenu.

Q : Qu'en est-il du formatage des nombres et des dates ?

next-intl fournit useFormatter() pour le formatage des nombres, des devises, des dates et des heures relatives en fonction des paramètres régionaux. Tout le formatage suit la norme Intl et respecte automatiquement les conventions locales.

---

Quelle est la prochaine étape

L’internationalisation est un investissement qui rapporte des dividendes sur tous les marchés non anglophones. Commencez par vos paramètres régionaux les plus intéressants et développez-les à partir de là.

Contactez ECOSIRE pour obtenir de l'aide sur la mise en œuvre d'i18n, ou explorez nos services de mise en œuvre Odoo pour le déploiement d'un ERP multilingue.

---

Publié par ECOSIRE – aider les entreprises à évoluer grâce à des solutions logicielles d'entreprise.