Por qué el contenido multilingüe debería estar en git

La mayoría de los sitios multilingües acaban con tres fuentes de la verdad: el contenido en un CMS alojado, las traducciones en una plataforma especializada y el código en git. Cada sistema tiene su propio control de versiones, sus propios permisos de acceso y su propia definición de lo que está "actualizado". Mantenerlos sincronizados es un trabajo constante y la desincronización es el estado por defecto.

Existe un modelo más sencillo: ponerlo todo en el repositorio.

Lo que git ya soluciona

Tu flujo de trabajo de código ya resuelve los problemas más difíciles de la gestión de contenidos:

• Revisión. Un cambio de contenido es un pull request. Alguien revisa el diff antes de publicarlo.
• Reversión. Una mala edición se soluciona con un revert, no abriendo un ticket de soporte.
• Atomicidad. El contenido y el código que lo renderiza se despliegan juntos. Un cambio de esquema y la migración de su contenido se integran en un solo commit.
• Historial. El comando git log responde a "quién cambió esto y cuándo" sin necesidad de plugins.

Un CMS basado en archivos obtiene todas estas ventajas de forma gratuita. La pregunta es qué pasa cuando multiplicas cada página por diez idiomas.

El problema de la traducción

El enfoque ingenuo es usar un archivo por idioma: about.en.mdx, about.fr.mdx, about.ja.mdx. Esta idea se desmorona rápidamente. Diez idiomas convierten un sitio de 50 páginas en 500 archivos. Además, la revisión resulta imposible para aquellos idiomas que nadie en el equipo domina y no hay forma de saber si about.fr.mdx refleja el texto actual en inglés o la versión de hace tres meses.

Scribe separa estas dos responsabilidades:

• El contenido en inglés son archivos MDX. Un archivo por documento, validado contra un esquema de Zod. Esta es la parte que los humanos escriben y revisan.
• Las traducciones viven en un archivo SQLite, commiteado junto a ellos. Cada traducción está vinculada al hash de su fuente en inglés, junto con una captura de cómo era dicha fuente.

El hash es lo que elimina la desincronización. Si editas un párrafo en inglés, exactamente un documento queda obsoleto de forma visible en cada idioma. Al ejecutar scribe translate, solo se vuelve a traducir ese documento en particular. Nada se queda atrás en silencio y scribe status muestra la cobertura exacta en cualquier commit.

Sin servidor desde su diseño

Como todo son archivos en el repositorio, no hay nada que alojar. El runtime lee los MDX y la base de datos SQLite directamente del disco en el momento de compilación y entrega a tu framework documentos completamente tipados: listas, búsquedas, relaciones, alternativas hreflang y entradas de sitemap. No hay ninguna API de CMS a la que llamar en cada petición, ni tokens que rotar, y ninguna caída de un proveedor externo puede tumbar tu contenido. Consulta la runtime API para ver cómo funcionan las lecturas.

Los archivos son el entorno ideal para los agentes de IA

Hay un argumento más reciente a favor de este modelo, y podría ser el más fuerte: los agentes de IA son expertos en repositorios. Un agente de programación ya sabe cómo buscar archivos, leer MDX como texto plano, editarlo en una rama y abrir un pull request. Si en su lugar lo apuntas a un CMS alojado, tendrás que configurar APIs, tokens e integraciones personalizadas antes de que pueda cambiar un simple titular.

Las barreras de seguridad también se mantienen. El frontmatter se valida contra tu esquema de Zod y cada cuerpo de texto tiene que compilar como MDX, así que un agente no puede guardar un documento mal formado; scribe validate lo detecta antes que el propio proceso de build. Y como cada edición es un commit, los cambios de la IA reciben el mismo trato que los humanos: un diff, una revisión y una aprobación. Este sitio funciona exactamente de esa manera; gran parte del mantenimiento de su documentación y changelog lo realizan agentes, mientras que los humanos revisan los diffs.

Cuándo este modelo no es para ti

Momento de sinceridad. Un CMS basado en git asume que las personas que editan el contenido se sienten cómodas con archivos y pull requests, o que hay un perfil técnico entre ellos y el repositorio. Si tus editores necesitan una interfaz WYSIWYG y un botón de publicar, un CMS alojado es la opción correcta. Scribe incluye un studio local para navegar, buscar e inspeccionar traducciones, pero la creación de contenido se realiza en tu editor de código.

Sin embargo, si tu equipo ya vive en git, añadir un segundo y tercer sistema para el contenido y las traducciones solo aumenta la superficie de trabajo. Un único repositorio, un solo flujo de revisión y un único despliegue.

Pruébalo

Toda la configuración se reduce a un archivo de configuración y una carpeta de archivos MDX:

pnpm add scribe-cms zod better-sqlite3

Comienza con la guía de inicio, o lee cómo funciona la traducción a nivel interno.