Acecore SystemsSite institutionnel Acecore
Français
Contact
Menu

Insights / Articles techniques

Comment gérer un blog multilingue avec Sveltia CMS

Un flux pratique pour modifier les articles source en japonais dans Sveltia CMS, générer des PR de traduction avec GitHub Actions et GitHub Copilot, et publier des pages statiques localisées plus utiles pour le SEO qu'une simple traduction d'interface.

Gui
  • Technologie
  • GitHub Copilot
  • i18n
  • CMS
  • SEO
Comment gérer un blog multilingue avec Sveltia CMS
Sommaire
  1. Structure utilisée
  2. Quand la traduction d’interface suffit
  3. Bénéfices SEO des pages localisées
  4. 1. Chaque langue est directement crawlable
  5. 2. Les métadonnées sont localisées
  6. 3. hreflang relie les variantes
  7. 4. RSS et sitemap deviennent multilingues
  8. Rôle de Sveltia CMS
  9. Règles pour Copilot
  10. Leçons des PR
  11. Références
  12. Résumé

Acecore édite principalement ses contenus en japonais, mais publie le blog en 9 langues. Le point essentiel est que traduire le texte affiché et publier de vraies pages localisées sont deux choses différentes.

La traduction du navigateur ou d’un widget peut aider le lecteur. Mais elle ne génère pas d’URL /fr/blog/.../, de métadonnées localisées, de RSS, de sitemap ou de liens hreflang.

Si le multilingue vise aussi la recherche organique, la traduction doit faire partie du processus de publication.

Structure utilisée

  • Source japonaise : src/content/blog/{slug}.md
  • Traductions : src/content/blog/{locale}/{slug}.md
  • URLs : /blog/{slug}/, /en/blog/{slug}/, /fr/blog/{slug}/
  • Édition : Sveltia CMS
  • Traduction : PR GitHub Copilot
  • Publication : build et revue

Sveltia CMS sert d’interface d’édition pour la source japonaise. Les traductions passent par des pull requests afin de garder un historique, une revue et une validation CI.

Quand la traduction d’interface suffit

Elle convient pour une lecture interne, une consultation ponctuelle, des écrans d’administration, ou des pages qui ne visent pas de trafic de recherche.

Ce modèle est léger, car aucun fichier traduit n’est maintenu. Mais il ne crée pas non plus de pages indexables par langue.

Bénéfices SEO des pages localisées

Les moteurs de recherche, les aperçus sociaux et les lecteurs RSS travaillent avec des URLs et du HTML.

Si seule la page japonaise existe, le navigateur peut la traduire pour l’utilisateur, mais le title, la description, le RSS et le sitemap restent ceux de la page japonaise.

Avec des pages statiques, chaque langue a sa propre URL.

/blog/copilot-translation-pipeline/
/en/blog/copilot-translation-pipeline/
/fr/blog/copilot-translation-pipeline/
/de/blog/copilot-translation-pipeline/

1. Chaque langue est directement crawlable

Google peut traiter JavaScript, mais sa documentation rappelle aussi les limites de JavaScript et recommande le rendu statique ou côté serveur comme solution plus stable. Pour les autres crawlers et lecteurs RSS, le HTML initial traduit est encore plus important.

2. Les métadonnées sont localisées

Le frontmatter peut être traduit :

title: "Comment gérer un blog multilingue avec Sveltia CMS"
description: "Flux avec Sveltia CMS et GitHub Copilot pour créer des PR de traduction."

Cela influence les résultats de recherche, l’OGP, les cartes liées et le RSS.

3. hreflang relie les variantes

Google recommande hreflang lorsque différentes URLs correspondent à différentes langues ou régions. Avec une traduction seulement côté interface, il n’existe pas d’URL localisée à relier.

4. RSS et sitemap deviennent multilingues

Des fichiers traduits permettent de générer /fr/rss.xml et des URLs localisées dans le sitemap.

Rôle de Sveltia CMS

Sveltia CMS ne traduit pas. Il garde simple l’édition de la source japonaise :

  • articles japonais
  • auteurs
  • tags
  • JSON source japonais
  • images
  • frontmatter comme date, FAQ et linkCards

La mise en place du CMS est détaillée dans le Guide d’installation de Sveltia CMS.

Règles pour Copilot

La PR de traduction doit préserver les identifiants et localiser le texte.

Keep:

- slug
- image path
- author id
- tag ids
- external URLs
- code blocks

Localize:

- title
- description
- FAQ
- body text
- internal blog URLs when locale-specific URLs exist

Leçons des PR

  • Les anciens articles mentionnaient encore Pages CMS après la migration vers Sveltia CMS.
  • Si date reste ancien, l’article ne remonte pas en tête du blog.
  • Le slug doit rester identique entre les langues.
  • Les liens internes doivent respecter la locale du lecteur.
  • L’IA accélère la traduction, mais la relecture reste nécessaire.

Références

Résumé

La traduction d’interface aide à lire une page. Les pages statiques localisées transforment chaque langue en véritable contenu du site.

Sveltia CMS gère le japonais, GitHub Copilot crée les PR de traduction, et Astro build valide le résultat avant publication.

Translation Workflow

Flux de Sveltia CMS jusqu’à la PR de traduction

Le japonais reste la source of truth et la traduction est séparée dans le processus de PR GitHub.

  1. Modifier uniquement le japonais

    Mettre à jour `src/content/blog/{slug}.md` avec Sveltia CMS ou Markdown.

  2. Détecter le commit du CMS

    Faire du prefix `cms:` et du path modifié le contrat côté GitHub Actions.

  3. Créer une PR de traduction

    Transmettre à Copilot le source path, la locale et les règles de traduction afin qu’il génère les fichiers traduits.

  4. Appliquer après le build

    Intégrer dans main uniquement les PR qui passent Astro build, Pagefind et la vérification des liens.

Différence entre traduction de l’interface et génération de pages propres à chaque langue

Traduction de l’interface

  • Le navigateur ou le widget de traduction de l’utilisateur traduit au moment de l’affichage
  • L’URL, title, description et OGP restent souvent dans la langue source
  • Il est difficile de publier des pages par langue dans sitemap, RSS et hreflang
  • Le texte des URL partagées et des résultats de recherche reste proche de la langue source

Pages multilingues statiques

  • Des URL par langue comme `/{locale}/blog/{slug}/` peuvent être publiées
  • title, description, corps, FAQ et données structurées peuvent être propres à chaque langue
  • hreflang indique aux moteurs de recherche la relation entre les versions linguistiques
  • RSS, sitemap, liens internes et Search Console peuvent être gérés par langue

Décisions à prendre lors de l’adoption

  • Traiter l’article japonais comme source de traduction
  • Conserver le même slug pour les fichiers traduits et l’article japonais
  • Fixer les conditions de déclenchement du workflow, comme les commits `cms:`
  • Ne pas casser les URL, path d’images, blocs de code ni ID de tags pendant la traduction
  • Vérifier au build les sorties hreflang, canonical, RSS et sitemap

FAQ

La traduction d'interface suffit-elle ?

Elle est utile pour lire une page, mais elle ne crée pas d'actifs par langue pour le SEO, les flux RSS, les sitemaps et les liens internes.

La traduction par IA est-elle mauvaise pour le SEO ?

Le problème n'est pas l'IA elle-même, mais la publication massive de pages sans valeur. Terminologie, faits, liens et naturel doivent être relus.

Les pages traduites sont-elles du contenu dupliqué ?

Google indique que des pages localisées ne sont considérées comme doublons que si le contenu principal n'est pas traduit. Il faut relier les variantes avec hreflang.