Bonnes pratiques de la balise hreflang pour les sites web mondiaux

Ce travail commence avant la traduction. L'internationalisation, ou i18n, élimine les hypothèses techniques qui rendent la localisation coûteuse par la suite. La localisation adapte ensuite le produit à la langue, aux conventions et à la culture d'un marché. La définition de la localisation du W3C comprend les formats, la devise, les symboles, les exigences légales, les coordonnées et la lisibilité propre à chaque écriture, et pas seulement les mots traduits.

La première décision d'architecture est le modèle de langues : une combinaison stable de langue, de région et parfois d'écriture qui régit le contenu et le comportement. Par exemple, en-CA, en-US, fr-CA et ar peuvent partager un système de marque tout en servant un contenu, des textes juridiques, une devise et un sens de lecture différents.

Consignez le modèle par écrit avant de créer les routes. Pour chaque langue, définissez :

• La balise de langue BCP 47 utilisée dans le HTML et les données de l'application.
• Le modèle d'URL, comme /en-ca/, un sous-domaine de langue ou un domaine national.
• La langue de repli lorsque du contenu est manquant.
• Les conventions de devise, de nombres, de dates, d'heure, d'adresse et de téléphone.
• Le responsable du contenu et le processus de traduction.
• Si le marché peut modifier la navigation, les produits, les formulaires ou l'imagerie.

Gardez la sélection de la langue distincte de la géolocalisation automatique. Un visiteur en France peut préférer l'anglais, un voyageur peut avoir besoin d'un autre marché, et un robot d'exploration ne devrait pas être piégé dans une boucle de redirection. Affichez un sélecteur de langue et de région clair, mémorisez le choix et permettez aux gens de le modifier plus tard.

Utilisez une stratégie d'URL prévisible. Les sous-répertoires sont simples à exploiter lorsqu'une seule plateforme dessert tous les marchés. Les sous-domaines peuvent séparer les déploiements ou les équipes. Les domaines nationaux peuvent envoyer un fort signal régional, mais ajoutent du travail de gestion de domaines et d'exploitation. Le choix compte moins que la cohérence, des URL canoniques stables et un modèle de pages capable de représenter les vraies différences entre les marchés.

Le routage détermine ce que reçoit un visiteur. hreflang indique aux moteurs de recherche quelle page équivalente dessert chaque langue ou région. Ils devraient être générés à partir de la même carte des langues, et non tenus à jour comme deux listes sans lien.

Google Search Central documente trois façons équivalentes de déclarer des pages alternatives : les liens HTML, les en-têtes HTTP et les plans de site XML. Choisissez une méthode principale que votre équipe peut garder complète. Ajouter les trois ne crée pas de valeur supplémentaire et vous donne trois endroits où introduire des écarts.

Chaque page localisée a besoin d'un ensemble complet et réciproque de variantes. Cet ensemble comprend la page elle-même, chaque variante prise en charge et une page x-default lorsque vous avez un sélecteur de langue ou de marché. Utilisez des URL HTTPS complètes. Si la page en anglais canadien pointe vers la page en français canadien, la page en français canadien doit pointer en retour.

Générez les liens à partir des fiches de contenu plutôt que de les écrire à la main dans les gabarits. Une structure de données simplifiée pourrait ressembler à ceci :

{
  "contentKey": "home",
  "locales": {
    "en-CA": "https://example.com/en-ca/",
    "fr-CA": "https://example.com/fr-ca/",
    "en-US": "https://example.com/en-us/"
  },
  "fallback": "https://example.com/"
}

Lors de la compilation ou de la publication, validez que chaque URL renvoie la page voulue, que chaque page se liste elle-même et que chaque paire réciproque concorde. Une traduction manquante ne devrait pas produire une fausse variante. Marquez plutôt la langue comme non disponible ou dirigez l'utilisateur vers un repli documenté.

La meilleure architecture de site web multilingue repose sur une fondation commune et une couche par marché. La fondation contient les jetons, les composants, le comportement d'accessibilité, les budgets de performance, les conventions d'analytique et les schémas de contenu. La couche par marché contient le texte, les produits, les offres, les textes juridiques, l'imagerie, les libellés de navigation et les parcours qui diffèrent selon la langue.

Ne forcez pas chaque marché dans une arborescence de pages identique. Un composant commun peut prendre en charge différentes longueurs de contenu et des modules facultatifs. Un marché peut masquer un produit, ajouter un service local ou changer l'ordre des preuves sans scinder tout le front-end.

Modélisez les champs traduits comme du contenu lié, et non comme des copies collées dans une seule fiche géante. Chaque champ a besoin d'un état de la source, d'un état de la traduction, d'un réviseur et d'un état de publication. Les mises à jour partielles deviennent ainsi visibles. Cela empêche aussi qu'une nouvelle affirmation en anglais n'apparaisse sur une page française avant que son contenu justificatif soit prêt.

Gardez la construction de chaînes de caractères hors des fichiers de traduction. Concaténer des fragments comme Bonjour, plus un nom plus ! brise l'ordre des mots, le genre grammatical et la ponctuation dans de nombreuses langues. Donnez aux traducteurs des messages complets avec des variables nommées, comme {firstName}, et laissez la langue décider de la phrase.

Utilisez Unicode dans toute la pile technologique et testez les noms, les adresses, les termes de recherche et les saisies de formulaire avec des accents et des écritures non latines. Les recommandations du W3C sur l'internationalisation mentionnent expressément Unicode, le texte bidirectionnel, les formats locaux, le tri et la séparation du contenu localisable et du code source comme des éléments de l'internationalisation.

La livraison dynamique par CDN devrait varier selon les bonnes entrées, et non selon chaque en-tête de requête accessoire. Définissez quelles ressources sont communes à toutes les langues et lesquelles varient selon le marché. Une image de produit peut être partagée, tandis qu'une image de campagne, un badge juridique ou un texte intégré à une image peut être local.

Utilisez des ressources immuables adressées par contenu pour les fichiers communs. Pour les fichiers localisés, incluez la langue ou le marché dans la clé de la ressource et dans la politique de cache. Une requête vers /fr-ca/ ne devrait jamais recevoir une image anglaise parce qu'un CDN a mis en cache la première réponse sous une clé indifférente à la langue.

Une séquence de livraison pratique est la suivante :

1. Résoudre l'URL demandée en une langue et une version de contenu.
2. Produire le texte critique et le HTML structurel en périphérie ou à l'origine.
3. Sélectionner les variantes d'images adaptatives à partir du manifeste de ressources de la langue.
4. Mettre le résultat en cache en utilisant la langue, la version du contenu, la route indépendante de l'appareil et la clé d'expérimentation pertinente.
5. Charger en différé les médias sous la ligne de flottaison une fois le contenu principal utilisable.

Utilisez les clés de cache de façon délibérée. Ne faites pas varier la réponse complète selon Accept-Language lorsque l'URL identifie déjà la langue. Cela crée de nombreuses variantes de cache et rend le comportement difficile à inspecter. Utilisez l'en-tête comme indice pour la sélection à la première visite, puis redirigez une seule fois vers une URL stable, et seulement si vous avez une raison claire de le faire.

La performance exige des vérifications sur le terrain, et pas seulement sur un ordinateur portable local. Les recommandations de web.dev sur la performance conseillent de mesurer des indicateurs centrés sur l'utilisateur, de fixer des budgets de performance et de vérifier la livraison des ressources, les images, les polices et le code tiers. Faites ces vérifications pour chaque langue importante et sur des réseaux mobiles représentatifs. Un script, une police ou une image plus lourde dans un marché demeure un vrai problème d'expérience utilisateur.

La typographie fait partie de la localisation, parce que la langue change la géométrie. Les mots composés allemands peuvent allonger un bouton. Le français peut ajouter du texte à un titre. L'arabe et l'hébreu exigent une mise en page de droite à gauche et une police qui prend en charge les glyphes requis. Les interfaces CJC peuvent nécessiter des coupures de ligne et des choix de polices différents.

Construisez des composants qui tolèrent la croissance du texte. Testez la navigation, les boutons, les cartes, les tableaux, les messages d'erreur, les étapes de paiement et les boîtes de dialogue de consentement avec de longues traductions. Évitez les hauteurs fixes autour du texte. Laissez les libellés passer à la ligne et réservez assez d'espace pour la plus longue chaîne prise en charge plutôt que pour la source anglaise.

Définissez la langue du document avec une balise BCP 47 valide. La référence lang de MDN précise que l'attribut prend en charge l'identification de la langue et l'accessibilité, y compris la prononciation correcte par les lecteurs d'écran. Marquez aussi les passages en ligne qui changent de langue.

Définissez la direction du texte de façon sémantique. La référence dir de MDN définit ltr, rtl et auto, et explique pourquoi l'attribut lang seul ne définit pas la direction. Utilisez des propriétés CSS logiques comme margin-inline-start, padding-inline et inset-inline-end pour que le composant puisse s'inverser en miroir sans seconde feuille de style.

N'inversez pas tout automatiquement. Une flèche de retour, une ligne de temps média, une carte ou une marque peut nécessiter un traitement délibéré. Testez les icônes, les nombres, la ponctuation, les noms à écritures mixtes et les messages de validation de formulaire dans les deux directions. Enveloppez le texte utilisateur inconnu avec dir="auto" ou isolez-le avec bdi lorsque c'est approprié.

L'UX localisée change le chemin qu'une personne emprunte dans le site. Étudiez le marché avant de choisir l'imagerie, les exemples, les appels à l'action, les modes de paiement, les signaux de confiance et les champs de formulaire. Un titre traduit ne peut pas corriger un parcours qui demande le mauvais identifiant, utilise un format de date inhabituel ou cache la zone de service régionale.

Commencez par la tâche et ses contraintes locales. Une marque mondiale peut avoir besoin de points d'entrée différents pour la découverte de produits, le soutien, le recrutement ou l'achat. Laissez la couche par marché changer l'ordre de ces tâches pendant que le système commun préserve la qualité d'interaction et l'accessibilité.

Rendez explicites les commandes de langue et de région. Libellez-les dans la langue courante, distinguez la langue du pays lorsque les deux comptent et montrez la destination avant le changement. N'utilisez jamais des drapeaux comme seuls libellés de langue. Un drapeau représente un lieu, et non une langue, et une même langue peut servir de nombreux pays.

Localisez la gouvernance du contenu aussi soigneusement que l'interface. Désignez des responsables de la traduction, de la révision juridique, des métadonnées SEO, des données structurées et de l'expiration des campagnes. Ajoutez une vérification de publication qui compare les pages sources et localisées, signale les champs manquants, vérifie les liens et confirme que l'analytique enregistre la langue sélectionnée sans exposer de renseignements personnels inutiles.

Les tests de lancement devraient couvrir tout le parcours, de l'URL jusqu'au contenu, aux ressources, à l'interaction et à la mesure. Une page qui semble correcte dans une langue peut échouer lorsque sa traduction est plus longue ou que son écriture se lit dans l'autre sens.

Utilisez cette liste de vérification de publication :

Exécutez des tests automatisés sur le HTML généré et sur le plan de site produit. Ajoutez des cas de régression visuelle pour les longs libellés et les pages RTL. Gardez un petit ensemble de tâches de révision humaine pour le ton culturel, l'imagerie, le langage juridique et pour vérifier que l'expérience semble native plutôt que traduite mécaniquement.

• Google Search Central : versions localisées : hreflang, liens réciproques, formats d'URL et options de plan de site.
• W3C Internationalization : localisation et internationalisation : adaptation à la langue, Unicode, formats, direction et séparation du contenu.
• MDN : attribut HTML lang : métadonnées de langue et accessibilité.
• MDN : attribut HTML dir : direction du texte et mise en page bidirectionnelle.
• web.dev : temps de chargement rapides : budgets de performance, mesure et livraison des ressources.