Comment ajouter plusieurs langues à votre application ou site web
Pour ajouter plusieurs langues à une application, déplacez tout le texte de l'interface dans des fichiers de traduction (un par langue), chargez-les avec une bibliothèque i18n et ajoutez un sélecteur de langue qui retient le choix. Pour les pages publiques que vous voulez voir dans la recherche, donnez à chaque langue sa propre URL, comme /fr/, et reliez les versions avec des balises hreflang. Ensuite, occupez-vous des éléments souvent oubliés : dates, nombres et devises, textes plus longs dans certaines langues, écritures de droite à gauche et contenu stocké dans votre base de données.
Termes à connaître
- Internationalisation (i18n) : préparer le code à prendre en charge n'importe quelle langue, sans chaînes codées en dur, avec un formatage adapté à la locale et des mises en page souples. Le « 18 » représente le nombre de lettres entre le i et le n.
- Localisation (l10n) : adapter l'application à une langue ou à un marché précis, surtout la traduction, parfois aussi la devise, les images et les textes juridiques.
- Locale : une langue et, éventuellement, une région, comme
en-GBoupt-BR.
Faites l'i18n une seule fois : ensuite, ajouter chaque nouvelle langue devient surtout un travail de traduction.
Options et compromis
| Approche | Fonctionnement | Idéal pour | Compromis |
|---|---|---|---|
| Bibliothèque i18n + fichiers de traduction (par ex. react-i18next, next-intl, vue-i18n) | Le texte est dans des fichiers JSON par locale ; les composants recherchent des clés | La plupart des applications | Refonte initiale ; traductions à maintenir |
| Système de gestion de traductions (par ex. Crowdin, Lokalise, Phrase) | Éditeur hébergé pour les traducteurs, synchronisé avec vos fichiers | Beaucoup de langues, plusieurs traducteurs | Payant ; un outil de plus à configurer |
| Traduction automatique ou par IA au moment de la compilation | Générer des ébauches de traduction avec une API, puis les relire | Obtenir rapidement beaucoup de langues | La qualité doit être vérifiée ; coûts d'API |
| Traduction automatique du navigateur ou d'un widget | Le navigateur du visiteur traduit la page à la volée | Rien à contrôler de votre côté | Aucun contrôle de la qualité ; les pages traduites ne sont pas indexées comme les vôtres |
| Sites distincts par langue | Dupliquer le site pour chaque marché | Marchés très différents | Tout est maintenu en double |
Pour la plupart des applications, une bibliothèque i18n standard avec des fichiers de traduction est la bonne base. Vous pouvez produire des ébauches avec la traduction automatique ou par IA, puis faire relire par des personnes qui maîtrisent bien la langue ce que les clients voient le plus.
Les éléments d'une application multilingue
Fichiers de traduction
Au lieu de <h1>Welcome back</h1>, le code contient t('dashboard.welcome'), et chaque locale dispose d'un fichier avec le texte :
{
"dashboard": {
"welcome": "Welcome back, {{name}}",
"items_one": "{{count}} item",
"items_other": "{{count}} items"
}
}
Utilisez des marqueurs pour les variables plutôt que de coller des fragments de phrase, car l'ordre des mots varie d'une langue à l'autre. Et utilisez les règles de pluriel de la bibliothèque : l'anglais a deux formes (1 item, 2 items), mais certaines langues en ont trois, quatre ou davantage.
Formater les dates, les nombres et l'argent
Ne formatez pas ces éléments à la main. L'API Intl intégrée au navigateur effectue le formatage pour n'importe quelle locale : 1 234,5 en français canadien s'écrit 1.234,5 en allemand; les dates passent de l'ordre jour-mois à l'ordre mois-jour selon la région; les symboles monétaires changent de place. Enregistrez les dates en UTC et les montants sous forme de nombres accompagnés d'un code de devise, et ne formatez qu'au moment de l'affichage.
Une mise en page qui s'adapte
Le texte traduit est souvent plus long que l'anglais, surtout en allemand et en finnois. Évitez les boutons à largeur fixe et les étiquettes tronquées, et testez avec votre langue la plus longue.
Langues de droite à gauche
L'arabe, l'hébreu, le persan et l'ourdou se lisent de droite à gauche. Définissez dir="rtl" sur la page pour ces locales et utilisez les propriétés logiques de CSS (margin-inline-start au lieu de margin-left; avec Tailwind, ms-4 au lieu de ml-4) pour que la mise en page se reflète d'elle-même. Les icônes qui indiquent une direction, comme les flèches, doivent aussi être inversées.
Sélecteur de langue et détection
Affichez un sélecteur sur chaque page, avec le nom de chaque langue dans cette langue (« Deutsch », « Français », « العربية ») plutôt que des drapeaux : les drapeaux représentent des pays, pas des langues. À la première visite, détectez la langue préférée du navigateur pour suggérer une version, mais laissez le choix explicite du visiteur l'emporter et retenez-le.
URL et référencement
Pour les pages que vous voulez voir dans les résultats de recherche, chaque langue a besoin de sa propre URL. En date de septembre 2026, les recommandations de Google pour les sites multilingues sont les suivantes :
- URL distinctes par langue : les sous-répertoires (
exemple.com/fr/) sont le choix le plus simple; les sous-domaines et les domaines par pays fonctionnent aussi. Les paramètres d'URL (?lang=fr) ne sont pas recommandés. - Ne changez pas de langue uniquement par témoin ou par paramètre du navigateur : le robot d'indexation de Google pourrait ne jamais voir les autres versions.
- Ne faites pas de redirection automatique selon la langue : reliez plutôt les versions entre elles.
- Utilisez hreflang pour indiquer à Google quelles pages sont des traductions les unes des autres. Chaque version doit se désigner elle-même et désigner toutes les autres, sans quoi les annotations peuvent être ignorées. Ajoutez
x-defaultpour la page de repli. - Google détecte la langue d'une page à partir de son contenu visible, et non à partir de
langou de hreflang : traduisez donc toute la page, et pas seulement le menu.
Définissez tout de même <html lang="fr"> sur chaque version : les lecteurs d'écran s'en servent pour choisir la bonne prononciation, ce qui relève de l'accessibilité.
Les écrans d'application réservés aux utilisateurs connectés n'ont pas besoin d'être indexés : pour ceux-ci, enregistrer la langue dans le profil de l'utilisateur suffit. Consultez le référencement des sites créés avec l'IA pour que vos pages publiques soient explorées en premier lieu.
Contenu dans votre base de données
Le texte de l'interface se trouve dans des fichiers; le contenu comme les noms de produits, les articles de blogue et les catégories se trouve dans la base de données. Deux modèles courants :
- Une table de traductions :
product_translations (product_id, locale, name, description). Propre et évolutive pour beaucoup de langues. - Une colonne JSON par champ :
name: {"en": "...", "fr": "..."}. Plus simple pour quelques langues.
Décidez quoi faire lorsqu'une traduction manque : en général, revenez à la langue par défaut plutôt que d'afficher un espace vide.
Courriels et notifications
Enregistrez la langue de chaque utilisateur et utilisez-la aussi pour les courriels, les notifications et les PDF. Il est facile de traduire l'application et d'oublier que le courriel de bienvenue arrive toujours en anglais.
Des requêtes qui fonctionnent
Ajoute l'internationalisation avec react-i18next. Déplace chaque texte visible par l'utilisateur dans locales/en.json avec des clés organisées par espace de noms, utilise l'interpolation et les règles de pluriel au lieu de la concaténation de chaînes, et formate les dates, les nombres et les prix avec Intl selon la locale active. Ne modifie pas encore le libellé.
Ajoute le français et l'allemand. Les pages marketing publiques reçoivent les préfixes d'URL /fr/ et /de/, l'anglais restant à la racine, des liens hreflang sur chaque page (y compris l'autoréférence et x-default), et html lang défini pour chaque page. Ajoute un sélecteur de langue qui affiche le nom natif de chaque langue. Pour les pages réservées aux utilisateurs connectés, enregistre la langue dans le profil de l'utilisateur.
Ajoute l'arabe avec la prise en charge de la droite à gauche : définis dir="rtl" pour l'arabe, remplace les marges et les espacements gauche/droite par des propriétés logiques, inverse les icônes directionnelles, et vérifie que les formulaires et les tableaux restent lisibles.
Étape par étape
- Choisissez votre première langue supplémentaire en fonction de la demande réelle : là où se trouvent vos visiteurs ou vos clients.
- Rendez le code internationalisable : déplacez les chaînes dans des fichiers, ajoutez les pluriels et le formatage
Intl. Livrez cette étape en anglais seulement et vérifiez que rien n'a changé. - Décidez de la structure des URL pour les pages publiques et ajoutez hreflang.
- Traduisez : produisez une ébauche avec la traduction automatique ou par IA, puis faites-la relire par une personne qui maîtrise bien la langue. Donnez du contexte aux traducteurs : un mot comme « Book » est un nom sur un écran et un verbe sur un autre.
- Traduisez le contenu de la base de données et définissez des replis.
- Localisez le reste : courriels, messages d'erreur, pages juridiques, images qui contiennent du texte.
- Testez chaque langue à la largeur d'un téléphone, et en écriture de droite à gauche si c'est pertinent.
- Mettez en place un processus pour que les nouvelles fonctionnalités soient livrées avec leurs traductions, et non des mois plus tard.
Erreurs courantes
- Concaténer des phrases (
"You have " + n + " messages"), ce qui casse dans les autres langues. - Laisser du texte codé en dur dans les composants, les messages d'erreur et les chaînes de validation.
- Formater les dates et les prix à la main.
- Utiliser des drapeaux pour désigner des langues, et des redirections automatiques qui piègent les gens dans la mauvaise version.
- Une seule URL pour toutes les langues sur les pages qu'on veut indexer.
- Oublier les liens de retour hreflang, ce qui fait que Google ignore les annotations.
- Traduire l'interface sans traduire le contenu, ou l'inverse.
- Une traduction automatique non relue sur les pages de prix, juridiques et de paiement.
Liste de contrôle multilingue
- Aucun texte visible par l'utilisateur n'est codé en dur; les règles de pluriel et les marqueurs sont utilisés
- Dates, nombres et devises formatés avec
Intl - Sélecteur de langue avec les noms natifs sur chaque page; choix retenu
- URL distinctes par langue pour les pages publiques; aucune redirection forcée
- hreflang sur chaque version, y compris l'autoréférence et x-default
-
html lang(etdir="rtl"si nécessaire) défini pour chaque page - Contenu de la base de données traduit, avec des replis sensés
- Courriels et notifications envoyés dans la langue de l'utilisateur
- Texte destiné aux clients relu par une personne qui maîtrise bien la langue
Plusieurs langues sur Mythex
Sur Mythex, vous ajoutez des langues en le demandant dans le clavardage : il n'existe pas de panneau de traduction distinct. Les requêtes ci-dessus fonctionnent donc telles quelles. Faites d'abord l'étape d'internationalisation et vérifiez-la dans l'aperçu avant d'ajouter des langues : c'est une refonte importante, et un point de contrôle dans le clavardage vous donne un point de retour si quelque chose casse (clavardage et points de contrôle). Si vous voulez que l'application traduise automatiquement le contenu avec une IA ou une API de traduction, cela utilise votre propre clé d'API, stockée dans les paramètres du projet (variables d'environnement et secrets); comment utiliser les API de LLM explique les coûts. Publiez de nouveau lorsque les nouvelles langues sont prêtes.
Questions
Quelle est la différence entre i18n et localisation?
L'internationalisation (i18n) consiste à préparer le code pour qu'il puisse prendre en charge plusieurs langues : aucun texte codé en dur, dates et nombres adaptés à la locale, mises en page capables de gérer des mots plus longs et les écritures de droite à gauche. La localisation (l10n) est le travail qui consiste à adapter l'application à une langue ou à un marché précis, surtout la traduction.
Puis-je simplement utiliser la traduction automatique ou l'IA pour traduire mon app?
Pour une première version, oui : la traduction automatique et par IA est bonne pour les textes d'interface. Faites relire tout ce que voient vos clients par une personne qui maîtrise bien la langue, surtout les textes juridiques, les prix et le contenu marketing, car le ton et les petites erreurs comptent là-dessus.
Chaque langue doit-elle avoir sa propre URL?
Pour les pages publiques que vous voulez voir dans les résultats de recherche, oui. Google recommande des URL distinctes par langue, comme /fr/ et /de/, plutôt que de changer de langue par témoin (cookie) ou par paramètre du navigateur, car son robot d'indexation pourrait sinon ne voir qu'une seule version.
Dois-je rediriger les visiteurs selon la langue de leur navigateur?
Suggérez, n'imposez pas. Google déconseille les redirections automatiques selon la langue, car elles peuvent empêcher les gens et les robots d'accéder aux autres versions. Affichez plutôt une petite invitation proposant la langue correspondante, ainsi qu'un sélecteur de langue visible sur chaque page.