Traduire ton site : URL, hreflang et relecture

Une adresse par langue

Donne à chaque version linguistique d’une page sa propre URL, par exemple example.com/de/ et example.com/pl/. Google recommande des URL distinctes plutôt que de changer la langue sur la même adresse avec des cookies ou les réglages du navigateur. Sous-dossiers, sous-domaines ou domaines nationaux fonctionnent tous ; les paramètres d’URL comme ?lang=de ne sont pas recommandés. Google déduit la langue d’une page de son contenu visible : garde donc le texte et la navigation d’une page dans une seule langue.

hreflang : relier les versions

Avec hreflang, tu indiques aux moteurs de recherche quelles pages vont ensemble : par des éléments link dans le head de la page, un en-tête HTTP ou le sitemap. Pour Google, les trois méthodes se valent, une seule suffit donc. Un exemple pour une page en anglais, allemand et polonais :

<link rel="alternate" hreflang="en" href="https://example.com/en/prices/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/ceny/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/prices/" />

• Le même bloc figure sur les trois pages. Chaque version se cite elle-même et toutes les autres ; si B ne renvoie pas vers A, Google ignore les balises.
• Utilise des adresses complètes avec https://, pas seulement /de/preise/.
• Le code de langue suit l’ISO 639-1 (de, pl), éventuellement avec une région selon l’ISO 3166-1 Alpha 2, comme de-AT. Un code de pays seul n’est pas valide.
• x-default désigne la page pour les visiteurs dont la langue ne correspond à aucune de tes versions. Google l’a conçu pour les pages de choix de langue ; beaucoup de sites y mettent leur version principale.

L’attribut lang

Indique la langue de la page sur l’élément html, par exemple lang="fr". Un passage dans une autre langue reçoit son propre attribut lang sur l’élément qui l’entoure. Selon le W3C, la synthèse vocale, la transcription en braille, les correcteurs orthographiques, le choix de la police et la césure utilisent cette information. Google, en revanche, écrit qu’il n’utilise ni hreflang ni l’attribut lang pour détecter la langue d’une page. L’attribut sert donc aux navigateurs et aux technologies d’assistance, et le texte visible doit être dans la bonne langue.

Ce qu’il ne faut pas traduire

• Les balises et attributs HTML : un nom de classe ou un href traduit casse la mise en page ou le lien.
• Les espaces réservés comme {name}, {{count}}, %s ou %1$d. Ils restent exactement tels quels et apparaissent exactement une fois.
• Les URL, noms de fichiers, adresses e-mail, le code et les shortcodes comme [contact-form].
• Les clés des fichiers de langue, comme checkout.button.pay. Seules les valeurs sont traduites.
• Les noms de marques et de produits, sauf si tu as choisi exprès un nom local.

Fichiers de langue : .po, JSON et XLIFF

Les applis, thèmes et plugins gardent leurs textes dans des fichiers de langue. Dans les fichiers gettext .po, chaque entrée a un msgid (la source) et un msgstr (la traduction) ; l’en-tête Plural-Forms indique combien de formes plurielles la langue possède. Le polonais en demande trois, l’anglais deux. Dans les fichiers JSON i18n, les clés restent et seules les valeurs changent. XLIFF garde source et cible côte à côte, avec des identifiants et des notes qui doivent rester.

Un glossaire pour les termes de marque et de produit

Avant la première traduction, décide quels termes restent tels quels (noms de marque, de produit et de forfait) et lesquels reçoivent toujours la même traduction. Ajoute la forme d’adresse : du ou Sie en allemand, ty ou Pan/Pani en polonais. Boutons, fiches produit et e-mails restent ainsi cohérents.

Traduction automatique : un brouillon, puis un locuteur natif

La traduction automatique te donne un premier jet rapide, pas un texte fini. Les règles de Google sur le spam citent le contenu récupéré et transformé en de nombreuses pages par traduction automatique, avec peu de valeur pour les utilisateurs, comme exemple d’abus de contenu à grande échelle. Le problème, ce sont les pages produites en masse sans valeur, pas la traduction en soi. Google écrit aussi que traduire seulement le menu et le pied de page alors que le contenu principal reste dans une langue donne une mauvaise expérience. Prévois une relecture par un locuteur natif :

1. 1Lis le texte sur la page, pas seulement dans un tableau. Le contexte change le sens.
2. 2Vérifie les nombres, dates, prix, unités et coordonnées.
3. 3Vérifie les termes du glossaire et la forme d’adresse.
4. 4Vérifie les textes courts : boutons, entrées de menu et messages d’erreur deviennent souvent plus longs ou ambigus.

Ne redirige pas les visiteurs automatiquement

Google déconseille les redirections automatiques fondées sur la langue ou la localisation supposée d’un visiteur, comme l’adresse IP ou la langue du navigateur : elles peuvent empêcher les personnes et les moteurs de recherche de voir toutes les versions. Place sur chaque page un sélecteur de langue visible qui renvoie vers la même page dans les autres langues, et laisse les gens choisir.

Travailler avec Do4U

Traduire l’HTML garde les balises, liens, attributs et espaces réservés inchangés, puis vérifie la structure ; le glossaire de ton compte garde les noms de marques et de produits comme tu les veux. L’outil Fichiers de langue fait de même pour les fichiers .po, JSON et XLIFF et construit les formes plurielles de la langue cible. L’outil Traduire traite le texte brut et liste les passages peu clairs sous forme de notes.

Do4U prépare le brouillon, tu vérifies et tu décides. Fais-le lire par un locuteur natif avant de publier. Une traduction n’est pas une promesse de visiteurs supplémentaires.