Front matter

La section entre les marqueurs --- au début d’un fichier de contenu s’appelle le front matter. Il contient les métadonnées qui décrivent ou augmentent le contenu: le titre, les dates, l’état brouillon, les alias, l’URL et d’autres valeurs qui contrôlent comment Hugo place la page dans le site. Hugo accepte trois formats — YAML avec ---, TOML avec +++, JSON avec {} — et les pages d’ici utilisent YAML.

---
title: "Front matter"
date: 2026-05-10
lastmod: 2026-08-15
description: "The metadata contract for content files"
---

Les clés#

Omettez les champs qui répètent seulement les valeurs par défaut. N’ajoutez pas draft: false, sitemap_exclude: false, description: "", tags: [] ou aliases: vide. Réservez draft: false aux exemples qui montrent explicitement les états de brouillon de Hugo.

Dates#

• date: date de première publication
• lastmod: mise à jour éditoriale ou de contenu significative

Le front matter est la source de vérité pour les dates, pas Git. Les dates Git peuvent changer pendant les migrations, rebases, formatages en masse, déplacements de fichiers ou clones de déploiement; l’information Git ne sert que de solution de repli ou de signal d’audit. Le front matter est intentionnel et plus clair pour la publication bilingue.

Slugs et URL#

Les dates de publication restent hors des URL. Les URL datées conviennent aux nouvelles et au contenu lié à un moment précis; les notes de travail evergreen sont mises à jour, et une date dans le chemin donne l’impression que le contenu à jour est périmé. La règle pour la permanence: garder des slugs stables, éviter de les changer sans raison, et ajouter des alias chaque fois qu’un slug change. On obtient ainsi des URL durables sans verrouiller la date de publication dans le chemin.

slug change le dernier segment de l’URL d’une page régulière. Sur un site multilingue, cela permet à une traduction d’avoir un permalien localisé sans briser le lien de traduction:

# content/about.en.md
---
title: "About"
translationKey: "about"
---

# content/about.fr.md
---
title: "À propos"
slug: "a-propos"
translationKey: "about"
---

Avec defaultContentLanguageInSubdir = true, Hugo génère /en/about/ et /fr/a-propos/. Sans ce réglage, l’URL de la langue par défaut peut plutôt être /about/. Le lien de traduction fonctionne quand même parce que les deux pages partagent le même translationKey.

Le slug localisé devient l’URL principale de la page. Hugo ne transforme pas automatiquement /fr/about/ en alias de /fr/a-propos/. Ajoutez un alias explicitement si l’ancien chemin doit rediriger:

aliases:
  - "/fr/about/"

Pour les pages de section comme _index.md, slug peut localiser le chemin de section tout en conservant la structure de contenu partagée:

# content/legal/_index.fr.md
---
title: "Mentions légales"
slug: "mentions-legales"
aliases:
  - "/fr/legal/"
---

Utilisez url seulement lorsque slug et l’emplacement du fichier ne peuvent pas exprimer la route proprement. url remplace le chemin complet et a priorité sur slug, donc il faut l’utiliser délibérément.

Traductions#

Pour des pages bilingues, des noms de fichiers identiques lient les traductions automatiquement:

content/docs/site-governance/content/example.en.md
content/docs/site-governance/content/example.fr.md

Si les noms de fichiers, titres ou slugs sont différents, utilisez le même translationKey dans les deux fichiers:

# content/docs/site-governance/content/hello.en.md
---
title: "Hello World"
translationKey: "hello-post"
---

# content/docs/site-governance/content/bonjour.fr.md
---
title: "Bonjour le monde"
translationKey: "hello-post"
---

Les valeurs de translationKey doivent correspondre exactement. Cela remplace le lien basé sur le nom de fichier, donc Hugo peut relier comme traductions deux fichiers aux noms sans rapport.

Alias#

Sur un site multilingue, incluez le préfixe de langue lorsque l’ancienne URL est propre à une langue:

aliases:
  - "/en/hello/"
  - "/fr/bonjour/"

Utilisez un alias racine comme /hello/ seulement si cette ancienne URL existait réellement à la racine ou doit rediriger depuis la racine. Si la page vit sous /en/hello/, préférez /en/hello/ pour les redirections propres à une langue.

related#

related: liste des chemins indépendants de la langue, affichés en liste liée après le contenu. La liste identique va dans les deux fichiers de langue. Le rendu, les avertissements à la compilation et le choix entre related: et les autres mécanismes de renvoi sont couverts dans Renvois.

Pages de motifs#

Les pages de motifs utilisent les champs pattern_* seulement sous docs/site-implementation/patterns/. Elles consignent la catégorie, le statut, la composition de composants, les exigences de contenu ou de données, les attentes d’accessibilité au niveau de la composition, les preuves d’implémentation vérifiées et les motifs liés d’une tâche récurrente. Gardez la composition et les chemins de preuves identiques dans les deux fichiers de langue; traduisez les listes destinées à la lecture sur le contenu et l’accessibilité.

Utilisez Bibliothèque de motifs pour décider si une tâche mérite un motif. Utilisez Bibliothèque de motifs pour le contrat de champs complet et la commande de validation.

Portée de la documentation de marque#

Utilisez docs_metadata_scope lorsqu’une page de documentation de marque est la surface de consultation publique d’une règle qui possède aussi une page de gouvernance, une page d’implémentation, ou les deux. Le bloc de titre des docs rend la date de la page avec des liens compacts vers ces pages compagnons.

docs_metadata_scope:
  governance: /docs/site-governance/glossary
  implementation: /docs/site-implementation/architecture/glossary-generation

N’utilisez pas ce champ pour de simples lectures connexes. Réservez-le aux pages liées qui définissent la responsabilité ou les détails d’implémentation de la page courante.