Guides

Comment ajouter plusieurs langues à votre application ou site web

Pour ajouter plusieurs langues à une application, déplacez chaque élément de 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 les moteurs de recherche, donnez à chaque langue sa propre URL, comme /fr/, et reliez les versions avec des balises hreflang. Traitez ensuite les points souvent oubliés : dates, nombres et devises, textes plus longs dans certaines langues, écritures de droite à gauche, et contenus stockés dans votre base de données.

Les termes que vous entendrez

  • Internationalisation (i18n) : préparer le code pour prendre en charge n'importe quelle langue : pas de chaînes écrites en dur, formatage adapté à la locale, mises en page souples. Le « 18 » correspond au 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-GB ou pt-BR.

Faites l'i18n une seule fois, et l'ajout de chaque nouvelle langue devient surtout un travail de traduction.

Options et compromis

ApprocheFonctionnementIdéal pourCompromis
Bibliothèque i18n + fichiers de traduction (par ex. react-i18next, next-intl, vue-i18n)Le texte se trouve dans des fichiers JSON par locale ; les composants recherchent des clésLa plupart des applicationsRefactorisation initiale ; traductions à maintenir
Outil de gestion de traductions (par ex. Crowdin, Lokalise, Phrase)Éditeur hébergé pour les traducteurs, synchronisé avec vos fichiersBeaucoup de langues, plusieurs traducteursPayant ; un outil de plus à configurer
Traduction automatique ou par IA au moment du buildGénère des brouillons de traduction via une API, puis relectureAtteindre vite de nombreuses languesLa qualité doit être vérifiée ; coûts d'API
Traduction automatique du navigateur ou widgetLe navigateur du visiteur traduit la page à la voléeRien que vous contrôliezAucun contrôle de la qualité ; les pages traduites ne sont pas indexées comme les vôtres
Sites séparés par langueUn site dupliqué par marchéMarchés très différentsTout est maintenu deux fois

Pour la plupart des applications, une bibliothèque i18n standard avec des fichiers de traduction constitue la bonne base. Préparez des brouillons par traduction automatique ou par IA si vous le souhaitez, puis faites relire par des locuteurs courants ce que voient le plus les clients.

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": "Bon retour, {{name}}",
    "items_one": "{{count}} élément",
    "items_other": "{{count}} éléments"
  }
}

Utilisez des marqueurs pour les variables plutôt que d'assembler des fragments de phrases, car l'ordre des mots diffère selon les langues. 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 les formatez pas à la main. L'API Intl intégrée au navigateur formate pour toute locale : 1,234.5 en anglais s'écrit 1.234,5 en allemand ; les dates passent du jour-mois-année au mois-jour-année ; les symboles monétaires changent de place. Stockez les dates en UTC et les montants sous forme de nombres accompagnés d'un code de devise, et ne formatez que pour l'affichage.

Une mise en page qui s'adapte

Un texte traduit est souvent plus long que l'anglais, surtout en allemand et en finnois. Évitez les boutons à largeur fixe et les libellés tronqués, et testez avec votre langue la plus longue.

Les 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 s'inverse d'elle-même. Les icônes qui indiquent une direction, comme les flèches, doivent aussi être retournées.

Sélecteur de langue et détection

Affichez un sélecteur sur chaque page, avec le nom de chaque langue dans sa propre langue (« Deutsch », « Français », « العربية ») plutôt que des drapeaux : les drapeaux représentent des pays, pas des langues. Détectez la langue préférée du navigateur lors de la première visite pour suggérer une version, mais laissez le choix explicite du visiteur prévaloir 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 septembre 2026, les recommandations de Google pour les sites multilingues sont les suivantes :

  • URL séparées par langue : les sous-répertoires (example.com/fr/) sont 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 cookie ou par paramètre du navigateur ; le robot de Google risque de ne jamais voir les autres versions.
  • Ne redirigez pas automatiquement selon la langue ; créez plutôt des liens entre les versions.
  • Utilisez hreflang pour indiquer à Google quelles pages sont des traductions les unes des autres. Chaque version doit se citer elle-même et citer toutes les autres, sinon les annotations peuvent être ignorées. Ajoutez x-default pour la page de repli.
  • Google détecte la langue d'une page à partir de son contenu visible, et non à partir de lang ou de hreflang : traduisez donc la page entière, pas seulement le menu.

Définissez quand 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, stocker la langue dans le profil de l'utilisateur suffit. Voir SEO pour les sites créés avec l'IA pour faire explorer vos pages publiques par les moteurs de recherche.

Contenu dans votre base de données

Le texte de l'interface se trouve dans des fichiers ; les contenus comme les noms de produits, les articles de blog et les catégories se trouvent dans la base de données. Deux schémas courants :

  • Une table de traductions : product_translations (product_id, locale, name, description). Propre et extensible à de nombreuses langues.
  • Une colonne JSON par champ : name: {"en": "...", "fr": "..."}. Plus simple pour quelques langues.

Décidez ce qui se passe lorsqu'une traduction manque : en général, revenez à la langue par défaut plutôt que d'afficher un espace vide.

E-mails et notifications

Stockez la langue de chaque utilisateur et utilisez-la aussi pour les e-mails, les notifications et les PDF. Il est facile de traduire l'application et d'oublier que l'e-mail de bienvenue arrive encore en anglais.

Des requêtes qui fonctionnent

Ajoute l'internationalisation avec react-i18next. Déplace chaque chaîne visible par l'utilisateur dans locales/en.json avec des clés organisées en espaces de noms, utilise l'interpolation et les règles de pluriel au lieu de concaténer des chaînes, et formate les dates, nombres et prix avec Intl selon la locale courante. Ne modifie pas encore le moindre 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'auto-référence et x-default), et html lang défini par page. Ajoute un sélecteur de langue affichant le nom natif de chaque langue. Pour les pages connectées, 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 paddings gauche/droite par des propriétés logiques, retourne les icônes directionnelles et vérifie que les formulaires et tableaux restent lisibles.

Étape par étape

  1. Choisissez votre première langue supplémentaire en fonction de la demande réelle : là où se trouvent vos visiteurs ou clients.
  2. Internationalisez le code : déplacez les chaînes dans des fichiers, ajoutez les pluriels et le formatage Intl. Livrez cela en anglais seulement et vérifiez que rien n'a changé.
  3. Définissez la structure des URL pour les pages publiques et ajoutez hreflang.
  4. Traduisez : préparez un brouillon par traduction automatique ou par IA, puis faites relire par un locuteur courant. Donnez du contexte aux traducteurs : un mot comme « Book » est un nom sur un écran et un verbe sur un autre.
  5. Traduisez le contenu de la base de données et définissez des solutions de repli.
  6. Localisez le reste : e-mails, messages d'erreur, pages juridiques, images contenant du texte.
  7. Testez chaque langue à la largeur d'un téléphone, et en droite à gauche si nécessaire.
  8. 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.
  • Texte écrit en dur dans les composants, messages d'erreur et chaînes de validation.
  • Formater les dates et les prix à la main.
  • Des drapeaux pour désigner les langues, et des redirections automatiques qui enferment les gens dans la mauvaise version.
  • Une seule URL pour toutes les langues sur les pages que vous voulez indexer.
  • Liens de retour hreflang manquants, si bien que Google ignore les annotations.
  • Traduire l'interface sans le contenu, ou l'inverse.
  • Une traduction automatique non relue sur les pages de prix, juridiques et de paiement.

Liste de contrôle multilingue

  • Aucune chaîne visible par l'utilisateur écrite en dur ; règles de pluriel et marqueurs utilisés
  • Dates, nombres et devises formatés avec Intl
  • Sélecteur de langue avec les noms natifs sur chaque page ; choix retenu
  • URL séparées par langue pour les pages publiques ; pas de redirection forcée
  • hreflang sur chaque version, y compris l'auto-référence et x-default
  • html lang (et dir="rtl" si nécessaire) défini par page
  • Contenu de la base de données traduit, avec des solutions de repli adaptées
  • E-mails et notifications envoyés dans la langue de l'utilisateur
  • Textes destinés aux clients relus par un locuteur courant

Plusieurs langues sur Mythex

Sur Mythex, vous ajoutez des langues en le demandant dans le chat : il n'existe pas de panneau de traduction distinct, donc les requêtes ci-dessus fonctionnent telles quelles. Faites d'abord l'étape d'internationalisation et vérifiez-la dans l'aperçu avant d'ajouter des langues ; c'est un refactoring important, et un point de sauvegarde dans le chat vous permet de revenir en arrière si quelque chose casse (chat et points de sauvegarde). 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 LLM explique les coûts. Republiez une fois les nouvelles langues 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 de nombreuses langues : pas de texte écrit 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 d'adaptation à une langue ou à un marché donné, surtout la traduction.

Puis-je simplement utiliser la traduction automatique ou l'IA pour traduire mon application ?

Pour un premier jet, oui : la traduction automatique et par IA actuelle est de bonne qualité pour les textes d'interface. Faites relire tout ce qui est destiné aux clients par un locuteur courant, surtout les textes juridiques, les prix et le contenu marketing, car le ton et les petites erreurs comptent dans ces cas-là.

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 via un cookie ou le paramètre du navigateur, car son robot risque sinon de ne voir qu'une seule version.

Faut-il rediriger les visiteurs selon la langue de leur navigateur ?

Proposez, n'imposez pas. Google déconseille les redirections automatiques de langue, car elles peuvent empêcher les internautes et les robots d'atteindre les autres versions. Affichez une petite invitation proposant la langue correspondante ainsi qu'un sélecteur de langue visible sur chaque page.

Mythex · Pricing · Créez tout avec l'IA · Modèles de sites et d'applications · Mythex comparé · Glossaire de la création d'applications avec l'IA · Outils gratuits pour créer des applications avec l'IA · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)