Sélecteur de langue du site web : Bonnes pratiques de conception

Je ne sais pas pour vous, mais il y a quelque chose de tellement satisfaisant dans un sélecteur de langue clair et parfaitement assorti à la marque.

Peut-être que cela me démasque comme un passionné de localisation. Mais écoutez-moi jusqu'au bout.

Ce petit bouton renferme un pouvoir immense. Un seul clic suffit pour qu'un visiteur passe de la lecture difficile d'une page en langue étrangère à la navigation dans sa propre langue, sans jamais quitter votre site.

Le sélecteur de langue est le point de rencontre entre design et fonctionnalité. Si c'est bien fait, cela correspond à votre marque, c'est facile à trouver et cela montre aux visiteurs du monde entier qu'ils sont les bienvenus. Si c'est mal fait, c'est caché dans un pied de page, mal étiqueté, ou tellement maladroit que les visiteurs quittent le site avant même de voir votre contenu traduit.

Alors, qu'est-ce qui les différencie ?

La plupart des guides s'en tiennent aux principes de base : rendre le sélecteur facile à trouver, utiliser les noms dans la langue maternelle et éviter les drapeaux pour les symboles. Nous aborderons également ces points. Mais nous voulons aussi répondre aux questions plus difficiles, comme par exemple comment classer par ordre alphabétique une liste déroulante qui mélange le japonais, l'arabe et le portugais ? Et pourquoi la moitié d'Internet associe-t-elle votre langue à votre localisation géographique, alors que c'est si souvent une erreur ?

Dans ce guide, vous apprendrez quel modèle d'interface utilisateur convient à votre site, quelles sont les meilleures pratiques qui résistent à l'épreuve du temps et comment gérer les deux défis que presque personne ne relève correctement : l'ordre de tri et la répartition langue-pays-devise.

Entrons dans le vif du sujet.

Ce que contrôle un sélecteur de langue (et ce qu'il ne contrôle pas)

Un sélecteur de langue a une seule fonction : afficher la page dans une autre langue. Il ne définit ni la devise, ni les frais de livraison, ni la localisation du visiteur. Il ne s'agit pas d'un panneau de paramètres ni d'un localisateur de magasins, et malgré la fréquence à laquelle les sites le présentent comme tel, il ne remplace pas un sélecteur de pays.

Ici, la simplicité est de mise. Un sélecteur de langue qui essaie d'en faire trop échoue souvent dans sa fonction première : aider les visiteurs à comprendre votre site.

Une étude du Nielsen Norman Group sur la localisation du commerce électronique a révélé que les acheteurs internationaux s'attendent à ce que la langue du site soit modifiée indépendamment du lieu de livraison ou de la devise de paiement. Cela paraît logique lorsqu'on examine les marchés réels. Au Canada, certains consommateurs préfèrent l'anglais et d'autres le français, mais tous s'attendent à payer en dollars canadiens. En Espagne, tout le monde paie en euros, mais certains clients préfèrent faire leurs achats en catalan plutôt qu'en espagnol.

En résumé, un sélecteur de langue qui modifie de manière inattendue la devise ou les règles d'expédition impose une modification que personne n'a demandée, et cela peut aliéner les clients internationaux que vous essayez justement d'accueillir.

Types de sélecteurs de langue

La plupart des sélecteurs se répartissent en quatre formats. Au lieu de se demander lequel est le meilleur, la question plus productive est de savoir lequel correspond à votre nombre de langues et à l'espace visuel que vous pouvez lui consacrer.

• Les menus déroulants s'adaptent le mieux à la taille de l'écran. Ce sont les paramètres par défaut les plus sûrs une fois que vous utilisez plus de trois ou quatre langues.
• Les rangées de boutons donnent une impression plus de confiance et de réactivité. C’est pourquoi les sites disposant d’un nombre restreint et fixe de langues ont tendance à les privilégier, comme un site gouvernemental bilingue ou un produit SaaS desservant deux marchés.
• Les liens textuels sont particulièrement adaptés aux pieds de page, où un composant complet serait trop imposant.
• Les fenêtres modales mettent le choix de la langue au premier plan, ce qui les rend utiles pour une suggestion ponctuelle du type « Il semblerait que vous préfériez le français ? », mais elles deviennent vite agaçantes si elles apparaissent à chaque chargement de page.

Retour aux fondamentaux

En tenant compte des différents formats, examinons les meilleures pratiques classiques et voyons lesquelles restent pertinentes en 2026 ans.

• Utilisez les noms en langue maternelle . « Deutsch » et « Español » indiquent immédiatement au visiteur que sa langue figure sur la liste. Les termes « allemand » et « espagnol » incitent une personne ne parlant pas anglais à parcourir une liste écrite dans une langue qu'elle ne maîtrise peut-être pas.
• Oubliez les drapeaux . Elles représentent des pays, pas des langues, et la cartographie est constamment interrompue. L'espagnol est une langue officielle dans environ 20 pays, l'anglais n'est associé à aucun drapeau en particulier, et la Suisse, à elle seule, compte quatre langues nationales sous un même drapeau. Une icône de langue universelle, un globe, un glyphe de bulle de dialogue, une simple marque « A/文 », sont lisibles correctement quel que soit l'endroit où se trouve le visiteur.
• Facilitez sa recherche . Pour la plupart des sites, cela correspond au coin supérieur droit de l'en-tête. Les sites riches en contenu ou les sites éditoriaux, où l'espace d'en-tête est précieux, peuvent utiliser le pied de page. Sur mobile, intégrez-le au même menu que votre navigation plutôt que de créer une interaction séparée uniquement pour la langue.
• Veillez à ce que vos visiteurs aient la même information. Lorsqu'un utilisateur change de langue sur une page produit, il devrait arriver sur cette même page produit dans la nouvelle langue, et non être renvoyé à la page d'accueil. Obliger les visiteurs à rebrousser chemin est un moyen rapide de les perdre, surtout s'ils étaient sur le point d'acheter.
• Suggérer, ne pas imposer. La redirection automatique des visiteurs en fonction de leur adresse IP ou des paramètres de leur navigateur, sans possibilité de la désactiver, est l'une des critiques les plus fréquentes concernant les sites multilingues. Les VPN, les ordinateurs partagés et les voyageurs sont autant de facteurs qui compliquent cette estimation. Si vous détectez une préférence probable, proposez-la comme suggestion et offrez toujours aux visiteurs un moyen clair et permanent de revenir en arrière.
• N'oubliez pas leur choix. Une fois qu'un visiteur a choisi une langue, conservez-la sur toutes les pages et lors de ses visites ultérieures. Un choix effectué délibérément par une personne devrait toujours primer sur ce que votre site déduit de sa localisation ou de son navigateur.

Au-delà des bases : ordre de tri et distinction langue-pays-devise

Ces fondamentaux constituent une base solide. Mais dès que l'on commence à construire un sélecteur, deux questions plus difficiles se posent, et la plupart des guides de bonnes pratiques les négligent.

1. Comment trier une liste contenant des lettres de l'alphabet mélangées ?

Il n'existe pas d'ordre alphabétique unique qui couvre l'allemand, le japonais et l'arabe, car ces systèmes d'écriture ne partagent pas le même alphabet. Même au sein des langues à écriture latine, un simple tri informatique se trompe : il place « Čeština » après « Türkçe » car il lit le « Č » accentué comme un caractère distinct au lieu d’une sorte de « C ».

Pour la plupart des sites, c'est-à-dire ceux qui prennent en charge jusqu'à quelques dizaines de langues, la solution pratique consiste à :

1. Regrouper les langues par système d'écriture. Latin, cyrillique, arabe, CJK (chinois, japonais, coréen), etc.
2. Disposez les groupes dans un ordre fixe de votre choix. Une approche courante consiste à commencer par le script que la plupart de votre public utilise.
3. Effectuez un tri au sein de chaque groupe en utilisant les règles propres à ce script. Pour le latin, cela signifie que le Čeština se trouve à côté du Dansk et du Deutsch, et non à la fin de la liste.

Le résultat ressemble à ceci : Čeština, Deutsch, English, Español, Français, Português → Русский, Українська → العربية → 中文, 日本語, 한국어 .

Si votre liste comprend des centaines de langues, le tri manuel devient impraticable et vous aurez besoin d'outils de tri prenant en compte les spécificités régionales pour chaque groupe de langues.

2. La langue, le pays et la devise doivent-ils constituer un seul choix ou trois ?

Vous vous souvenez des acheteurs canadiens et espagnols dont nous parlions tout à l'heure ? C'est là que cette idée devient concrète.

De nombreux grands sites de commerce électronique combinent la langue, le pays et la devise dans un seul sélecteur de « marché ». Pour un détaillant, la raison est simple : les règles d’expédition, les taxes et les modes de paiement varient selon les pays, donc une option unique simplifie le processus de paiement. C'est un compromis raisonnable.

C'est un mauvais compromis pour les produits où les trois éléments n'ont pas besoin d'être liés, comme les outils SaaS, les sites médias ou tout produit numérique utilisé par les expatriés, les télétravailleurs ou toute personne dont la langue préférée ne correspond pas à son pays de facturation. Un germanophone vivant au Brésil souhaite des textes en allemand et des prix en reais brésiliens, et non une combinaison forcée des deux.

La règle générale :

• La langue modifie le texte de la page.
• Les variations de devise modifient l'affichage des prix.
• Le pays ou la région va au-delà des différences linguistiques et peut offrir différents degrés de localisation.

Conservez-les comme trois commandes distinctes, sauf si votre produit ne peut pas fonctionner sans les relier.

Détection, redirections et ajout de langues ultérieurement

Utilisez la détection pour suggérer, et non pour décider.

Vous vous souvenez du principe « suggérer, ne pas forcer » ? Voici comment bien faire.

Le meilleur signal de première visite est la langue du navigateur ou de l'appareil du visiteur (envoyée dans l'en-tête Accept-Language ou lue avec navigator.language en JavaScript). Contrairement à la géolocalisation par adresse IP, elle reflète la langue réellement définie par la personne.

Cela en fait un indice bien plus pertinent, mais cela doit rester un indice et non une décision que vous prenez à leur place. Ainsi, rien ne change tant que le visiteur n'a pas donné son accord ; il passe donc l'appel au lieu d'être automatiquement redirigé.

Compilez pour les langues que vous ajouterez ultérieurement.

De nombreux sites ne conservent pas le même nombre de langues qu'à leur lancement. Que faire alors une fois que vous avez dépassé la liste initiale de votre sélecteur actuel ?

La solution est simple : générez automatiquement la liste des langues du sélecteur à partir des langues que vous avez déjà publiées, et générez vos balises hreflang de la même manière au lieu de les gérer manuellement. Bablic , par exemple, le fait automatiquement. Si les balises hreflang et x-default vous sont inconnues, notre explication de hreflang x-default en couvre les mécanismes.

Créer son propre sélecteur

La façon dont vous construisez un sélecteur dépend de la configuration de votre site multilingue.

Si chaque langue possède sa propre URL (sous-répertoires comme /es/ , sous-domaines comme es.example.com ou paramètre d'URL), le sélecteur le plus simple est une liste de liens, chacun pointant vers la même page dans une autre langue :

html

<nav aria-label="Langue">

<a href="/en/pricing/" hreflang="en" lang="en">anglais</a>

<a href="/es/pricing/" hreflang="es" lang="es" aria-current="page">Espagnol</a>

<a href="/ja/pricing/" hreflang="ja" lang="ja">日本語</a>

</nav>

Chaque détail contribue à quelque chose d'important :

• L'attribut lang indique aux lecteurs d'écran comment prononcer correctement le nom de chaque langue.
• aria-current="page" indique aux technologies d'assistance quelle langue est actuellement active.
• Chaque lien pointe vers la même page dans une autre langue (ici, la page des tarifs), et non vers la page d'accueil, afin que les visiteurs ne perdent pas leur chemin.

Vos balises hreflang dans la balise <head> de la page (ou dans votre sitemap) doivent correspondre exactement à cette structure d'URL, car c'est ce que les moteurs de recherche utilisent pour afficher la bonne version au bon utilisateur. Google recommande les sous-répertoires ou les sous-domaines plutôt que les paramètres d'URL pour les versions linguistiques.

Si la langue est stockée dans un cookie ou dans le navigateur au lieu de l'URL, il n'y a pas d'URL de langue auxquelles se référer, donc les liens simples ne fonctionneront pas. Votre sélecteur doit mettre à jour la langue enregistrée et recharger la page.

Afficher ces éléments sous forme de menu déroulant, de rangée de boutons ou de simples liens est un choix de conception. Ce qui compte davantage, c'est la structure de l'URL sous-jacente. La plupart des sites utilisent des sous-répertoires (/es/) ou des sous-domaines (es.example.com). Les paramètres de requête (?lang=es) fonctionnent, mais Google les déconseille pour les versions linguistiques. Quel que soit votre choix, vos balises hreflang dans la page <head> (ou votre sitemap) doivent correspondre exactement à cette structure. C'est ce que les moteurs de recherche utilisent pour proposer la bonne version au bon internaute.

Si votre site est traduit avec Bablic , vous pouvez choisir la voie qui convient le mieux à votre équipe :

• Utilisez le sélecteur intégré. Choisissez un style prédéfini dans Projet → Sélecteur du tableau de bord Bablic et ajustez-le à votre marque. Aucun code requis.
• Personnalisez-le avec du CSS personnalisé. Conservez le sélecteur de Bablic , mais ajustez ses couleurs, ses polices, son espacement et ses icônes pour qu'il corresponde exactement à votre système de conception.
• Créez le vôtre avec la bibliothèque de sélecteurs Bablic : le package @ bablic -io/selector vous fournit deux fonctions : getLanguages() renvoie les langues publiées de votre projet et marque la langue actuelle, et setLanguages() change de langue en utilisant la méthode utilisée par votre projet (dossier, sous-domaine, paramètre d'URL, cookie ou stockage du navigateur). Vous concevez l'interface tandis que Bablic gère la commutation.

Les équipes qui souhaitent un lancement rapide peuvent conserver les paramètres par défaut, tandis que celles qui veulent une identité visuelle parfaitement cohérente ont la possibilité de personnaliser chaque détail.

Quel que soit le chemin que vous empruntiez, seules vos propres données pourront vous indiquer quel modèle fonctionne le mieux auprès de votre public. Si vous hésitez entre deux modèles, vous pouvez effectuer un test simple. Suivez la fréquence à laquelle les visiteurs changent de langue et s'ils restent après avoir changé de langue.

Choisir ce qui se trouve derrière votre sélecteur

Un excellent sélecteur n'a d'importance que si la traduction qui le sous-tend est de qualité. Bablic combine la traduction automatique avec un éditeur contextuel, permettant ainsi à un membre de votre équipe maîtrisant la langue de relire et de corriger des passages spécifiques directement sur la page, au lieu de devoir traduire de zéro. Si vous vous demandez si la traduction automatique est suffisamment performante pour être publiée telle quelle, notre analyse de la fiabilité de Google Traduction est un bon point de départ.

Comparer les outils ? Consultez notre comparatif Bablic ou lisez la documentation sur le fonctionnement Bablic pour en savoir plus sur la configuration. Vous pouvez également l'essayer gratuitement pendant 30 jours, sans carte bancaire .

FAQ