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

Para iniciar un flujo multilingüe, genera HTML localizado desde las traducciones de un artículo representativo y revisa texto, title, description y enlaces internos. Relaciona solo versiones existentes según Google: Localized Versions; verifica por separado el éxito del servicio y las páginas públicas terminadas.

Actualización del 26 de septiembre de 2026: Los pasos con Copilot que siguen documentan la implantación de junio de 2026. La generación de traducciones pasó a OpenAI Batch. El japonés sigue siendo la fuente principal y las páginas estáticas traducidas siguen siendo el formato de publicación.

Flujo actual de traducción (septiembre de 2026)

Cuando cambia un artículo o texto de UI en japonés en main, se inicia el flujo de envío del Batch. Espera 15 minutos por cambios adicionales, comprueba el main actual y envía la traducción. El flujo de recogida compara los resultados con el sourceHash actual, descarta resultados antiguos y crea un PR de traducción. El flujo de integración activa la integración automática solo para PR que cumplen los requisitos. Aún hay que revisar términos, enlaces, hechos y naturalidad.

1. 1 Actualizar la fuente japonesa Un cambio de source en main activa un Batch de traducción.
2. 2 Comparar sourceHash Al recopilar, se descartan resultados que ya no coinciden con la fuente actual.
3. 3 Integrar el PR de traducción La validación puede activar la integración automática; el contenido requiere revisión aparte.

Registro de la implantación de junio de 2026

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

• Google Search Central: Localized Versions of your Pages
• Google Search Central: Managing Multi-Regional and Multilingual Sites
• Google Search Central: JavaScript SEO Basics
• Google Search Central: Spam Policies
• Guía de instalación de Sveltia CMS

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.