--- title: Por que o conteúdo multilíngue pertence ao git description: >- Bancos de dados de CMS hospedados e plataformas de tradução criam três fontes de verdade que acabam se desencontrando. Manter o MDX em inglês, as traduções e o histórico em um único repositório resolve isso. Conheça o modelo por trás do Scribe. publishedAt: '2026-07-08' updatedAt: '2026-07-08' noindex: false canonicalPath: /pt-BR/blog/why-multilingual-content-belongs-in-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](/docs/getting-started) 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`](/docs/translation) 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](/docs/runtime-api) 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`](/docs/cli) 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](/docs/studio) 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](/docs/getting-started) ou leia como a [tradução](/docs/translation) funciona nos bastidores.