i18next-resources-to-backend :
charger les traductions à la demande
i18next-resources-to-backend est un plugin i18next qui charge les ressources de traduction via une fonction — souvent un import dynamique — au lieu d'un serveur HTTP. Chaque couple langue/namespace devient ainsi un fragment chargé à la demande.
i18next-resources-to-backend répond à une question précise : comment donner ses traductions à i18next sans tout charger d’un coup, ni monter un serveur dédié ?
Une simple fonction remplace le backend HTTP, et chaque langue devient un fragment chargé à la demande.
Principe et usage
Le plugin fournit à i18next une fonction qui retourne les ressources pour une langue et un namespace donnés — le plus souvent un import dynamique. Aucune requête HTTP, aucun serveur dédié. Les traductions vivent dans le code source et sont fragmentées au build.
i18next
.use(resourcesToBackend(
(language, namespace) => import(`./locales/${language}/${namespace}.json`)
))
.init({ lng: 'fr', fallbackLng: 'fr' })Avec Next.js, chaque instance i18next est créée par requête pour le rendu serveur, évitant les conflits de langue. Les traductions alimentent aussi bien les Server Components que le SSR classique, sans infrastructure HTTP séparée.
Points clés
Attention au chemin d’import : les bundlers ont besoin d’un préfixe littéral pour découper les fragments. Côté serveur, isolez l’instance par requête. L’initialisation est asynchrone, il faut l’attendre avant d’afficher du texte.
Besoin d’une internationalisation robuste pour votre projet ? Demandez un devis ou appelez-nous au 0476 07 23 28.
Notions liées.
Le réseau de notions autour de cette fiche — chaque entrée renvoie vers sa propre définition.
Next.js, le framework React full-stack
Le contexte où ce plugin brille : App Router, SSR et Server Components.
React, la brique d'interface
react-i18next s'appuie sur le même moteur pour traduire les composants.
JavaScript, le langage du web
Les imports dynamiques et les promesses qui font tourner le plugin.
TypeScript pour un typage sûr
Typer ses clés de traduction pour éviter les libellés manquants.
Front-end : la partie visible
Où s'inscrit l'internationalisation dans une interface soignée.
Ce qu'on nous demande souvent.
Une question qui n'est pas ici ? Écrivez-nous : on répond en clair, sans jargon, sous 24 h.
Poser votre questionÀ quoi sert i18next-resources-to-backend ?
C'est un plugin (un « backend » au sens d'i18next) qui indique au moteur comment récupérer les traductions. Plutôt que de tout charger d'un bloc au démarrage, ou d'aller chercher chaque fichier via une requête HTTP, il délègue le chargement à une fonction que vous écrivez.
Cette fonction reçoit une langue et un namespace, et renvoie les ressources correspondantes — le plus souvent au moyen d'un import dynamique JavaScript. Résultat : chaque fichier de langue est découpé en fragment et n'est téléchargé que lorsqu'il est réellement nécessaire.
Quelle différence avec i18next-http-backend ?
i18next-http-backend va chercher les fichiers de traduction sur un serveur via des requêtes HTTP, à l'exécution. i18next-resources-to-backend, lui, ne fait aucune requête réseau explicite : il exécute votre fonction, qui retourne les données. Quand cette fonction est un import dynamique, c'est le bundler (webpack ou Turbopack) qui gère le découpage en fragments et leur chargement.
On garde donc le lazy-loading, mais les traductions sont intégrées au build plutôt que servies par un backend séparé. Plus simple à déployer, et compatible avec le rendu côté serveur.
Est-il adapté à Next.js et à l'App Router ?
Oui, c'est même l'un de ses usages les plus répandus. Dans l'App Router, on crée une instance i18next par requête pour le rendu serveur, et ce plugin fournit les traductions sans dépendre d'un serveur HTTP dédié.
Il fonctionne aussi bien côté serveur (Server Components, SSR) que côté client, ce qui évite d'écrire deux mécaniques de chargement différentes. C'est pour cela qu'on le retrouve dans la plupart des exemples d'internationalisation modernes avec Next.js.
Comment s'installe-t-il et se configure-t-il ?
On l'installe avec son gestionnaire de paquets (npm install i18next-resources-to-backend), puis on l'enregistre sur l'instance i18next avec .use().
Le plugin est un export par défaut : on l'appelle en lui passant une fonction (langue, namespace) qui retourne une promesse de ressources — typiquement import(`./locales/${langue}/${namespace}.json`). i18next appelle ensuite cette fonction automatiquement dès qu'il a besoin d'un couple langue/namespace non encore chargé.
Quels sont les pièges les plus courants ?
Le premier concerne le chemin d'import : les bundlers ont besoin d'une partie littérale (un préfixe de dossier fixe) pour créer les fragments ; un chemin entièrement variable peut échouer. Le deuxième est le partage d'instance : côté serveur, réutiliser une même instance globale entre plusieurs requêtes peut mélanger les langues — il faut en créer une par requête.
Enfin, l'import de fichiers JSON suppose une configuration adéquate du projet, et l'initialisation étant asynchrone, il faut l'attendre avant d'afficher du texte traduit.
Faut-il un serveur ou une API pour l'utiliser ?
Non, c'est justement son intérêt. Les traductions vivent dans votre code source et sont empaquetées au build sous forme de fragments.
Aucune API dédiée aux libellés n'est nécessaire. Si vos contenus proviennent d'un back-office, vous pouvez toujours faire renvoyer par la fonction des données issues d'une API, mais ce n'est pas requis pour un site dont les traductions sont versionnées avec le code.