Insights / Artículos técnicos

Cómo gestionar un blog multilingüe con Sveltia CMS

Flujo práctico para editar artículos fuente en japonés con Sveltia CMS, generar PRs de traducción con GitHub Actions y GitHub Copilot, y publicar páginas estáticas localizadas con ventajas frente a la traducción solo en la UI.

  • Tecnología
  • GitHub Copilot
  • i18n
  • CMS
  • SEO
Cómo gestionar un blog multilingüe con Sveltia CMS
Contenido
  1. Estructura usada
  2. Cuándo sirve la traducción de UI
  3. Ventajas SEO de las páginas estáticas localizadas
  4. 1. Cada idioma se puede rastrear directamente
  5. 2. Los metadatos se traducen
  6. 3. hreflang puede conectar variantes
  7. 4. RSS y sitemap también son multilingües
  8. Papel de Sveltia CMS
  9. Reglas para Copilot
  10. Lecciones de los PRs
  11. Referencias
  12. Resumen

Acecore edita su contenido principalmente en japonés, pero publica el blog en 9 idiomas. La diferencia importante es que traducir texto en la pantalla y publicar páginas localizadas no son lo mismo.

La traducción del navegador o un widget puede ayudar al lector. Pero no genera /en/blog/.../, /es/blog/.../, metadatos localizados, RSS, sitemap ni enlaces hreflang.

Si el objetivo incluye tráfico de búsqueda, la traducción debe formar parte del proceso de publicación, no solo de la capa visual.

Estructura usada

El sitio sigue esta convención:

  • Fuente japonesa: src/content/blog/{slug}.md
  • Traducciones: src/content/blog/{locale}/{slug}.md
  • URLs: /blog/{slug}/, /en/blog/{slug}/, /es/blog/{slug}/, etc.
  • Edición: Sveltia CMS
  • Traducción: PRs de GitHub Copilot
  • Publicación: build y revisión

Sveltia CMS es la entrada para editar el contenido japonés. Las traducciones se gestionan como pull requests para conservar historial, revisión y CI.

Cuándo sirve la traducción de UI

La traducción de UI es suficiente para lectura interna, consultas puntuales, pantallas de administración, páginas que no buscan SEO o contenidos cuya calidad de traducción no se mantiene como parte del sitio.

Es ligera porque no crea archivos traducidos. Justamente por eso tampoco crea páginas indexables por idioma.

Ventajas SEO de las páginas estáticas localizadas

Los buscadores y las previsualizaciones sociales trabajan principalmente con URLs y HTML.

Si solo existe la página japonesa, el title, description, datos estructurados, RSS y sitemap seguirán perteneciendo a esa página, aunque el navegador traduzca el texto al usuario.

Con páginas estáticas localizadas, cada idioma tiene una URL:

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

1. Cada idioma se puede rastrear directamente

Google puede procesar JavaScript, pero su documentación también explica que JavaScript tiene limitaciones y recomienda renderizado estático o del lado servidor como opciones más estables. Además, otros crawlers, lectores RSS o vistas previas pueden ser menos capaces.

2. Los metadatos se traducen

El frontmatter también puede localizarse:

title: "Cómo gestionar un blog multilingüe con Sveltia CMS"
description: "Flujo para generar PRs de traducción con GitHub Copilot."

Esto afecta resultados de búsqueda, OGP, tarjetas relacionadas y RSS.

3. hreflang puede conectar variantes

Google recomienda hreflang cuando diferentes URLs representan diferentes idiomas o regiones. Con solo traducción de UI no hay URL localizada que conectar.

4. RSS y sitemap también son multilingües

Al existir archivos por idioma, el sitio puede generar /es/rss.xml y entradas localizadas en sitemap. Esto ayuda a buscadores, lectores RSS y servicios externos.

Papel de Sveltia CMS

Sveltia CMS no es el motor de traducción. En este flujo, mantiene limpio el punto de edición del contenido japonés:

  • artículos japoneses
  • autores
  • etiquetas
  • JSON fuente en japonés
  • imágenes
  • frontmatter como fecha, FAQ y linkCards

La instalación de CMS está explicada en Guía de instalación de Sveltia CMS.

Reglas para Copilot

La tarea de traducción debe separar qué se traduce y qué se conserva.

Keep:

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

Localize:

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

Markdown mezcla texto, URLs, código y frontmatter. Sin reglas, se rompen enlaces o taxonomías.

Lecciones de los PRs

  • El sitio ya usaba Sveltia CMS, pero artículos antiguos seguían mencionando Pages CMS.
  • Si date queda viejo, el artículo no sube al inicio del blog aunque se reescriba.
  • El slug traducido debe coincidir con el original.
  • Los enlaces internos en una traducción deben apuntar al locale correcto.
  • La IA acelera, pero la revisión humana sigue siendo necesaria.

Referencias

Resumen

La traducción de UI ayuda a leer una página. Las páginas estáticas localizadas convierten cada idioma en un activo real del sitio.

La separación es sencilla: Sveltia CMS edita el japonés, Copilot genera PRs de traducción y Astro build verifica que las páginas localizadas funcionen.

Translation Workflow

Flujo desde Sveltia CMS hasta la PR de traducción

El japonés se mantiene como source of truth y la traducción se separa en el flujo de PR de GitHub.

  1. Editar solo japonés

    Actualizar `src/content/blog/{slug}.md` mediante Sveltia CMS o Markdown.

  2. Detectar el commit del CMS

    Convertir el prefix `cms:` y el path modificado en el contrato del lado de GitHub Actions.

  3. Crear una PR de traducción

    Entregar a Copilot el source path, el locale y las reglas de traducción para que genere los archivos traducidos.

  4. Aplicar después del build

    Incorporar a main solo las PR que superen Astro build, Pagefind y la comprobación de enlaces.

Diferencia entre traducir la interfaz y generar páginas específicas por idioma

Traducción de la interfaz

  • El navegador o widget de traducción del usuario traduce al mostrar la página
  • La URL, title, description y OGP suelen permanecer en el idioma original
  • Es difícil incluir páginas específicas por idioma en sitemap, RSS y hreflang
  • El texto mostrado en URL compartidas y resultados de búsqueda se inclina al idioma original

Páginas multilingües estáticas

  • Se pueden publicar URL por idioma como `/{locale}/blog/{slug}/`
  • title, description, cuerpo, FAQ y datos estructurados pueden mantenerse por idioma
  • hreflang comunica a los buscadores la relación entre las versiones lingüísticas
  • RSS, sitemap, enlaces internos y Search Console pueden revisarse por idioma

Decisiones que deben tomarse al adoptar el flujo

  • Tratar el artículo japonés como fuente de traducción
  • Mantener el slug de los archivos traducidos igual al del artículo japonés
  • Fijar las condiciones de activación del workflow, como los commits `cms:`
  • No romper URL, path de imágenes, bloques de código ni ID de etiquetas al traducir
  • Comprobar en el build la salida de hreflang, canonical, RSS y sitemap

Preguntas frecuentes

¿Basta con traducir la interfaz?

Sirve para que una persona lea la página, pero no crea activos SEO por idioma. Si necesitas URLs, metadatos, RSS, sitemap y enlaces internos localizados, necesitas páginas traducidas reales.

¿La traducción con IA perjudica el SEO?

El problema no es usar IA, sino publicar muchas páginas sin valor. Hay que revisar terminología, enlaces, datos y naturalidad antes de publicar.

¿Las páginas traducidas son contenido duplicado?

Google indica que las versiones localizadas solo son duplicadas si el contenido principal no está traducido. Mantén las variantes conectadas con hreflang.