Associez les pages de documents traduits selon leur contenu et leur objectif communs, puis consignez l’URL exacte de chaque langue. Des slugs différents ne posent aucun problème. Ce flux de travail sur Mac aide un éditeur de documents publics à établir cette correspondance et à préparer des liens linguistiques et des annotations de recherche exacts.

Pourquoi des slugs identiques ne sont pas nécessaires

Supposons qu’un document en anglais explique comment disposer une grille de carrés colorés. Sa traduction française explique la même tâche, mais les deux adresses se terminent différemment. Google autorise explicitement l’emploi de mots localisés dans les URL et recommande des URL distinctes pour les différentes versions linguistiques. Vous n’avez pas besoin de renommer les traductions pour faire correspondre leurs chemins. Gérer les sites multirégionaux et multilingues.

Il faut répondre à deux questions distinctes : « Ces URL sont-elles identiques ? » et « Ces documents sont-ils des traductions l’un de l’autre ? » Le standard URL du WHATWG définit l’égalité des URL par la comparaison de leurs URL sérialisées. Cette comparaison n’établit pas de relation de traduction entre des adresses différentes. Pour ce flux de travail, déterminez la relation à partir des documents, puis consignez-la explicitement. Standard URL, équivalence des URL.

Les exemples ci-dessous sont des adresses synthétiques de documents publics sous example.com ; ils illustrent une correspondance proposée, et non des pages consultées en direct. La tâche consiste à relier des instructions équivalentes en anglais et en français tout en conservant l’adresse existante de chaque page.

Créer une fiche de correspondance sur votre Mac

Commencez par une paire de documents. Gardez la page source et sa traduction proposée ouvertes dans des onglets Safari distincts, ainsi qu’un document de correspondance local. Vous avez besoin du texte intégral des deux versions et, pour la mise en œuvre éventuelle, d’un accès aux paramètres de publication qui gèrent les relations entre langues ou les métadonnées des pages.

Relever les adresses exactes

Dans Safari, appuyez sur Command-L pour sélectionner le champ de recherche intelligente, puis sur Command-C pour copier l’adresse. Répétez l’opération pour la traduction une fois son chargement terminé. Apple documente ces deux raccourcis. Le fait de noter l’adresse obtenue après la navigation vous permet aussi de repérer une destination inattendue. Raccourcis clavier et gestes dans Safari sur Mac.

Pour un petit ensemble, TextEdit suffit. Créez un document, choisissez Format > Convertir au format texte, puis enregistrez-le sous translation-map.txt. La conversion d’un document RTF existant supprime sa mise en forme ; utilisez donc un nouveau document pour cette fiche. Ces opérations suivent les instructions d’Apple pour TextEdit. Créer, ouvrir et convertir des documents dans TextEdit sur Mac.

Utilisez un identifiant de document stable qui décrit la tâche sous-jacente. Voici une fiche illustrative complète, et non un fichier de configuration qu’un système de publication lirait automatiquement :

Document ID: tile-grid
Reader task: Arrange a four-column grid of colored squares
English URL: https://example.com/en/docs/arrange-tiles
French URL: https://example.com/fr/guides/disposer-les-carres
English language code: en
French language code: fr
Scope check: Same instructions, diagram, and document edition
Mapping decision: Translation pair

L’identifiant vous sert de point d’ancrage lorsque les titres ou les slugs changent. Conservez les adresses dans des champs distincts au lieu de déduire l’une de l’autre. Remplacer /en/ par /fr/ dans cet exemple produirait une adresse non vérifiée et ne tiendrait pas compte du véritable chemin de la traduction.

Vérifier que les documents permettent d’accomplir la même tâche

Comparez l’introduction, les instructions, les légendes du schéma, les exemples et l’édition. Il n’est pas nécessaire que les titres traduits se ressemblent mot pour mot. Demandez-vous plutôt si un lecteur choisissant l’autre langue trouverait des instructions équivalentes pour la même activité.

Avant d’ajouter une page à la correspondance, utilisez ce tableau de décision. Il s’agit d’un outil éditorial fondé sur la nécessité d’identifier les différentes versions d’un même contenu :

Ce que vous constatez Décision de correspondance
Mêmes instructions pour la grille et même édition, avec un texte traduit Consigner une paire de traductions
Une page traite des grilles ; l’autre du choix des couleurs Conserver des documents distincts
Une traduction décrit une édition antérieure Résoudre la différence d’édition avant de les regrouper
Seule la navigation est traduite Ne pas considérer le document principal comme entièrement traduit
Aucun document correspondant n’existe Ne pas inclure cette langue dans la correspondance du document

Par exemple, une présentation générale en français qui renvoie vers plusieurs activités de dessin ne remplace pas les instructions précises en anglais sur la grille. Consignez l’absence de traduction comme une tâche de contenu en attente. Une page de destination générale peut être utile pour la navigation, mais elle ne fournit pas le document équivalent requis pour cette correspondance.

Relier les pages associées pour les lecteurs et Google

Votre fiche locale est la source éditoriale de cette relation. Les pages publiées doivent également pouvoir l’exprimer. Commencez par des liens linguistiques visibles qui conduisent directement les lecteurs vers la page correspondante. Google recommande des liens entre les versions linguistiques pour permettre aux lecteurs de choisir, et déconseille de rediriger automatiquement les visiteurs en fonction de leur langue présumée. Gérer les sites multirégionaux et multilingues.

Pour les annotations destinées aux moteurs de recherche, Google prend en charge trois méthodes équivalentes : les éléments HTML, les en-têtes de réponse HTTP et les plans de site XML. Choisissez une méthode que vous pourrez maintenir. Chaque version linguistique doit s’identifier et répertorier ses versions alternatives à l’aide d’URL complètes, avec des liens réciproques. Indiquer à Google les versions localisées de votre page.

Pour les pages HTML, préparer les liens vers les versions alternatives

Le standard HTML du WHATWG définit alternate avec une valeur hreflang différente comme indiquant une traduction. Voici un fragment de métadonnées HTML pour la paire synthétique ; il doit figurer dans l’élément head existant de chaque page. Ce n’est pas un document HTML complet. Standard HTML, type de lien « alternate ».

<link rel="alternate" hreflang="en" href="https://example.com/en/docs/arrange-tiles">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/guides/disposer-les-carres">

Ajoutez la même paire sur les deux pages. Les URL de destination restent différentes, y compris leurs slugs. La documentation de Google exige des liens de retour et prend en charge des codes limités à la langue comme en et fr. Indiquer à Google les versions localisées de votre page.

Pour les PDF, utiliser une méthode de publication prise en charge

Un PDF ne peut pas recevoir le fragment précédent dans un head HTML. Google documente les en-têtes de réponse HTTP Link pour les fichiers non HTML. Pour une paire de PDF synthétique, le champ d’en-tête complet serait : Indiquer à Google les versions localisées de votre page.

Link: <https://example.com/en/files/tile-grid.pdf>; rel="alternate"; hreflang="en", <https://example.com/fr/fichiers/grille-de-carres.pdf>; rel="alternate"; hreflang="fr"

Configurez ce champ dans la réponse de chaque PDF. La RFC 8288 définit la syntaxe de liaison HTTP, notamment la cible entre chevrons et le paramètre hreflang. Il s’agit de paramètres de réponse ; écrire l’en-tête dans le texte visible du PDF ne les configure pas. RFC 8288 : liens Web.

Si votre système de publication ne permet pas de modifier les métadonnées HTML ou les en-têtes de réponse, Google prend également en charge un plan de site avec des annotations linguistiques. Chaque entrée d’URL répertorie toutes les versions, y compris elle-même. Utilisez la structure de plan de site documentée par l’intermédiaire de votre système de publication ou de la personne qui le gère. Un fichier de correspondance local ne met en œuvre à lui seul aucune de ces méthodes. Indiquer à Google les versions localisées de votre page.

Distinguer les relations de traduction des redirections et des URL canoniques

Une version alternative dans une autre langue, une URL de référence pour un doublon et une page déplacée représentent des relations différentes. Cette distinction évite qu’une modification de correspondance bien intentionnée détourne les lecteurs du document qu’ils ont choisi.

Mécanisme Objectif documenté Application à cette tâche
rel="alternate" avec hreflang Identifier les versions linguistiques alternatives Relier les traductions associées
rel="canonical" Indiquer une URL de référence parmi des pages en double ou très similaires Gérer les adresses dupliquées au sein de la langue concernée
Location dans une réponse de redirection Indiquer la destination de la redirection Gérer une adresse qui a changé
Content-Language Décrire le public visé par la représentation dans cette langue Indiquer le public visé par la réponse
Content-Location Identifier la ressource correspondant à la représentation incluse Décrire l’emplacement de la représentation

Google recommande une URL canonique dans la même langue lors de l’utilisation de hreflang, ou le meilleur substitut s’il n’en existe aucune. Pour ces documents traduits distincts, une URL canonique autoréférente sur chaque URL linguistique de référence constitue une mise en œuvre simple. Évitez de faire pointer l’URL canonique du français vers l’anglais au seul motif que le texte anglais a été rédigé en premier. Comment spécifier une URL canonique avec rel="canonical" et d’autres méthodes.

La RFC 9110 définit séparément Location dans les réponses de redirection, Content-Language et Content-Location. Ce dernier est une métadonnée de représentation, et non un remplacement de l’URL cible. Aucun de ces champs n’énumère à lui seul la paire de traductions de ce document ; conservez les liens vers les versions alternatives pour exprimer cette relation. RFC 9110 : sémantique HTTP.

Vérifier chaque sens de navigation et tenir la correspondance à jour

Avant de transmettre la correspondance pour mise en œuvre, effectuez les vérifications suivantes. Répétez-les sur le contenu public après toute modification ultérieure de la publication ; une fiche correcte et des métadonnées publiées correctes sont deux choses distinctes.

  1. Ouvrez les deux adresses consignées et comparez le contenu réel des documents.
  2. Suivez le lien linguistique visible de l’anglais au français, puis en sens inverse. Vérifiez que chaque destination correspond au document précis attendu.
  3. Comparez les URL alternatives configurées avec la fiche de correspondance, caractère par caractère.
  4. Vérifiez que les deux versions désignent le même ensemble de traductions, y compris elles-mêmes.
  5. Vérifiez séparément les paramètres d’URL canonique de chaque langue.
  6. Si une adresse change, mettez à jour la fiche et toutes les références à cette adresse dans la paire.

Nettoyez les URL avec prudence. La RFC 9110 considère que le schéma et l’hôte ne sont pas sensibles à la casse, tandis que les autres composants sont comparés en tenant compte de la casse conformément à ses règles de normalisation. Ne mettez pas un chemin en minuscules et ne supprimez pas une barre oblique finale simplement pour uniformiser deux fiches ; conservez la destination vérifiée. RFC 9110, normalisation et comparaison HTTP(S).

Pour la paire synthétique, le résultat utile est une fiche stable tile-grid reliant deux adresses exactes, avec un contenu équivalent et des liens fonctionnels dans les deux sens. Conservez cette fiche avec les notes de maintenance du document afin de pouvoir mettre à jour la relation de façon délibérée lors d’une future traduction ou d’un changement de slug.

Sources