Por que o conteúdo multilíngue pertence ao git

A maioria dos sites multilíngues acaba com três fontes de verdade: o conteúdo em um CMS hospedado, as traduções em uma plataforma de tradução e o código no git. Cada uma tem seu próprio versionamento, seu próprio controle de acesso e sua própria definição do que significa "atual". Manter tudo isso sincronizado dá trabalho, e o desencontro de informações é a regra. 

Existe um modelo mais simples: colocar tudo no repositório.

## O que o git já resolve

Seu fluxo de trabalho de código já lida com os problemas difíceis do gerenciamento de conteúdo:

- Revisão. Uma alteração de conteúdo é um pull request. Alguém lê o diff antes de ir para produção.
- Reversão. Uma edição ruim se resolve com um revert, não com um chamado de suporte.
- Atomicidade. O conteúdo e o código que o renderiza são implantados juntos. Uma mudança de esquema e a migração de conteúdo correspondente entram em um único commit.
- Histórico. O comando git log responde "quem alterou isso e quando" sem precisar de plugins.

Um CMS baseado em arquivos ganha tudo isso de graça. A questão é o que acontece quando você multiplica cada página por dez idiomas.

## O problema da tradução

A abordagem mais ingênua é ter um arquivo por idioma: about.en.mdx, about.fr.mdx, about.ja.mdx. Isso desmorona rapidamente. Dez idiomas transformam um site de 50 páginas em 500 arquivos, a revisão se torna impossível para idiomas que ninguém na equipe lê, e não há como saber se about.fr.mdx reflete o texto atual em inglês ou a versão de três meses atrás.

O Scribe separa as duas preocupações:

- O conteúdo em inglês fica em arquivos MDX. Um arquivo por documento, validado contra um esquema Zod. Essa é a parte que os humanos escrevem e revisam.
- As traduções vivem em um único arquivo SQLite, commitado junto com os arquivos MDX. Cada tradução é vinculada a um hash de sua fonte em inglês, junto com um registro de como essa fonte era na época.

O hash é o que acaba com o desencontro. Se você editar um parágrafo em inglês, exatamente um documento se tornará desatualizado em todos os idiomas, de forma visível. Rode scribe translate e apenas aquele documento será retraduzido. Nada fica para trás silenciosamente, e o comando scribe status mostra a cobertura exata em qualquer commit.

## Sem servidor, por definição

Como tudo se resume a arquivos no repositório, não há nada para hospedar. O ambiente de execução lê o MDX e o SQLite do disco no momento da compilação e entrega ao seu framework documentos totalmente tipados: listas, pesquisas, relações, alternativas hreflang e entradas de sitemap. Não há API de CMS para chamar no momento da requisição, nem tokens para rotacionar, nem falhas de provedores que possam tirar seu conteúdo do ar. Veja a API de runtime para entender como as leituras funcionam.

## Arquivos são o melhor ambiente para agentes de IA

Existe um argumento mais recente para esse modelo, e talvez seja o mais forte de todos: agentes de IA lidam muito bem com repositórios. Um agente de programação já sabe como pesquisar arquivos, ler MDX como texto simples, editá-lo em uma branch e abrir um pull request. Se você direcionar um agente para um CMS hospedado, precisará configurar APIs, tokens e integrações personalizadas antes que ele consiga alterar um título.

As barreiras de segurança também se aplicam. O frontmatter é validado pelo seu esquema Zod e todo o corpo do texto precisa compilar como MDX, impedindo que um agente salve um documento malformado (o comando scribe validate detecta o erro antes do build). E como cada edição é um commit, as alterações feitas por IA recebem o mesmo tratamento das edições humanas: um diff, uma revisão, uma aprovação. Este site funciona exatamente assim. A maior parte da manutenção de documentação e changelog é feita por agentes, enquanto humanos revisam os diffs.

## Onde este modelo não é para você

Sessão de honestidade. Um CMS baseado em git pressupõe que as pessoas que editam o conteúdo estão confortáveis com arquivos e pull requests, ou que há alguém técnico entre elas e o repositório. Se seus editores precisam de uma interface WYSIWYG e um botão de publicar, um CMS hospedado é a escolha certa. O Scribe inclui um estúdio local para navegar, pesquisar e inspecionar traduções, mas a criação de conteúdo acontece no seu próprio editor de código.

Porém, se sua equipe já vive no git, adicionar um segundo e um terceiro sistema para conteúdo e traduções só aumenta a complexidade. Um repositório, um fluxo de revisão, um deploy.

## Experimente

Toda a configuração se resume a um arquivo de configuração e uma pasta de MDX:

bash
pnpm add scribe-cms zod better-sqlite3


Comece com o guia de introdução ou leia como a tradução funciona nos bastidores.