Español
English
Català
FrançaisUn site traduit a besoin de plus qu’un sélecteur de langue. Chaque page doit avoir une URL qui existe, afficher le contenu correspondant et proposer des liens vers ses traductions. Si vous passez au français depuis « À propos du projet », arriver sur la page d’accueil française fait perdre le contexte, même si le lien renvoie un code 200.
Ce diagnostic utilise un exemple original de site Astro statique comportant deux pages en espagnol, anglais, français et catalan. L’essai local vérifie l’artefact avant le choix d’un hébergement ; il ne démontre ni une livraison native sur Hostbrid ni la prise en charge du SSR. Il ne comprend ni formulaires, ni comptes, ni API, ni traduction ou détection de langue automatiques, ni contenu généré pendant une requête.
Définir les pages équivalentes avant de générer les URL
Notre table utilise une identité de page indépendante de la langue et du slug. La page d’accueil possède quatre adresses : /es/, /en/, /fr/ et /ca/. La seconde page utilise /es/sobre/, /en/about/, /fr/a-propos/ et /ca/sobre/.
Le changement de langue doit conserver l’identité de la page. Depuis /es/sobre/, le lien français pointe vers /fr/a-propos/ ; remplacer simplement le préfixe pour produire /fr/sobre/ ne suffit pas. Cette adresse ne figure pas dans la table. Une règle de repli qui renvoie n’importe quel HTML ne suffit pas non plus : il faut vérifier quelle page a été reçue.
Une question du 17 janvier 2025 demande de conserver la page en passant de l’anglais à l’espagnol ; elle illustre un besoin de navigation, pas un diagnostic de l’API actuelle.
Dans cet exemple, les routes sont générées avec getStaticPaths et une table explicite. Cela décrit l’implémentation de l’exemple, pas une nouvelle option de configuration d’Astro ni une obligation d’utiliser un middleware. Si votre projet adopte une autre stratégie, examinez les routes générées et leur comportement réel. Consultez aussi la documentation officielle sur l’internationalisation d’Astro pour comparer la stratégie de votre projet.
Distinguer canonical et alternates
Le canonical de /fr/a-propos/ doit identifier cette version française. Les liens hreflang décrivent les autres versions équivalentes, y compris la page elle-même. Toutes les versions du groupe doivent renvoyer le même ensemble d’équivalences et se relier de manière réciproque.
Dans l’exemple, x-default pointe vers la version anglaise équivalente. C’est un choix éditorial de l’exemple, pas une obligation d’utiliser l’anglais ni une promesse de classement. Vous pouvez choisir une autre version ou une page de sélection si elle existe et convient à votre site. Consultez la documentation de Google sur les versions localisées.
L’attribut lang et le contenu visible doivent correspondre à la langue de la page. Un lien intitulé « Français » ne rend pas française une page qui conserve le texte espagnol. Vérifiez aussi la navigation, les textes alternatifs des images et les pages intérieures.
Vérifier les fichiers que vous publierez
Avant de choisir un hébergement, déterminez si Astro produit des fichiers statiques ou nécessite un serveur. Cet exemple utilise une sortie statique : les pages sont calculées pendant la compilation. Cela ne démontre pas qu’un autre projet avec des sessions, une API ou un rendu à chaque requête puisse être publié de la même façon.
L’essai local a vérifié les huit pages servies en HTTP et 16 rendus Chrome : chaque page à 390 et 1280 pixels, avec un DPR de 2, un accès direct et un rechargement récupérant un nouveau document. Les contrôles portaient sur le CSS, l’image, les polices prêtes, les liens vers la version linguistique équivalente et l’absence de débordement horizontal.
Pour le contrôle négatif, nous avons modifié uniquement le HTML généré de la page espagnole « À propos » : son alternate catalan pointait vers /ca/absent/. La destination a renvoyé un véritable 404 et le vérificateur a rejeté cette relation. Nous avons ensuite restauré les octets d’origine et le contrôle a de nouveau réussi. Le vérificateur utilise un contrat d’URL indépendant de la table qui génère l’application.
L’exemple fixe Astro 7.3.7, Node 22.23.3 et npm 10.9.9. Son README explique comment exécuter l’essai dans une copie propre avec Chrome sur macOS. L’origine des canonical utilisée pendant le test est https://atlas.example.invalid : elle est volontairement fictive. Avant une publication réelle, il faut configurer le domaine prévu et vérifier à nouveau les destinations publiques ; ce nom d’hôte n’est pas une démonstration accessible.
Ce que démontre l’artefact local
Le test local vérifie les fichiers et les relations entre les versions. Il ne valide ni le domaine final ni une configuration d’hébergement. Lors de la publication de votre projet, vérifiez à nouveau les huit routes correspondant à votre table, l’identité de chaque page, ses ressources et les réponses 404.
Si votre site comporte des fonctions dynamiques, gardez un inventaire distinct du serveur et des services externes avant de souscrire. Les articles sur la publication d’Astro statique et le choix d’un hébergement aident à distinguer ces décisions.
Reproduisez l’exemple examiné
Le dépôt original sous licence MIT contient le code et le vérificateur. Ces commandes fixent la révision examinée. L’expérience nécessite Node 22.23.3, npm 10.9.9 inclus dans sa distribution et Chrome sur macOS ; consultez le README avant de l’exécuter. Utilisez un nouveau répertoire pour conserver les preuves.
git clone https://github.com/ocentelles/hostbrid-example-astro-i18n.git
cd hostbrid-example-astro-i18n
git checkout 8c6ad19b60fcd67318b4c312ddfac852f146863d
node --version
node scripts/run-essay.mjs /tmp/my-astro-i18n-evidence