---
title: Почему многоязычный контент должен храниться в git
description: >-
  Облачные CMS и платформы переводов создают три источника истины, которые со
  временем рассинхронизируются. Хранение английских MDX-файлов, переводов и
  истории изменений в одном репозитории решает эту проблему. Вот как устроена
  архитектура Scribe.
publishedAt: '2026-07-08'
updatedAt: '2026-07-08'
noindex: false
canonicalPath: /ru/blog/why-multilingual-content-belongs-in-git
---
Большинство многоязычных сайтов в итоге имеют три источника истины: контент в облачной CMS, переводы на платформе для локализации и код в git. У каждого из них своя система версионирования, свой контроль доступа и свое понимание того, что считается актуальным. Поддерживать их синхронизацию сложно, а рассинхронизация становится состоянием по умолчанию.  Существует более простая модель: хранить всё в репозитории.  ## Что уже решает git  Ваш рабочий процесс с кодом уже справляется со сложными задачами управления контентом:  - **Ревью.** Изменение контента оформляется как pull request. Кто-то проверяет отличия перед публикацией. - **Откат.** Ошибочная правка отменяется через revert, а не через обращение в поддержку. - **Атомарность.** Контент и код для его отображения развертываются вместе. Изменение схемы и соответствующая миграция контента попадают в один коммит. - **История.** Команда `git log` отвечает на вопрос о том, кто и когда внес изменения, без необходимости устанавливать плагины.  Файловая CMS получает всё это бесплатно. Вопрос лишь в том, что произойдет при умножении каждой страницы на десять языков.  ## Проблема переводов  Самый простой подход подразумевает создание отдельного файла для каждого языка: `about.en.mdx`, `about.fr.mdx`, `about.ja.mdx`. Эта система быстро рушится. Десять языков превращают сайт из 50 страниц в 500 файлов. Проверка становится невозможной для языков, которые никто в команде не знает. При этом невозможно понять, отражает ли файл `about.fr.mdx` текущий английский текст или версию трехмесячной давности.  [Scribe](/docs/getting-started) разделяет эти две задачи:  - **Английский контент хранится в файлах MDX.** Один файл на документ, который проходит валидацию по схеме Zod. Именно эту часть пишут и проверяют люди. - **Переводы находятся в одном файле SQLite, который коммитится рядом с ними.** Каждый перевод привязан к хешу своего английского исходника вместе со снимком того, как этот исходник выглядел.  Именно хеш устраняет проблему рассинхронизации. Измените один абзац на английском языке, и ровно один документ станет неактуальным во всех локализациях, причем это будет сразу заметно. Запустите [`scribe translate`](/docs/translation), и будет заново переведен только этот документ. Ничего не устаревает незаметно, а команда `scribe status` показывает точное покрытие на любом коммите.  ## Отсутствие сервера по дизайну  Поскольку всё представляет собой файлы в репозитории, вам нечего хостить. Во время сборки среда выполнения читает MDX и SQLite с диска и передает вашему фреймворку полностью типизированные документы: списки, справочники, связи, альтернативные ссылки hreflang и элементы карты сайта. Нет API CMS, к которому нужно обращаться при запросе. Нет токенов, которые нужно обновлять. И нет сбоев на стороне поставщика, способных сделать ваш контент недоступным. Ознакомьтесь с [API среды выполнения](/docs/runtime-api), чтобы узнать, как работает чтение.  ## Файлы идеально подходят для ИИ-агентов  У этой модели есть более новый и, возможно, самый весомый аргумент: ИИ-агенты отлично работают с репозиториями. Агент для написания кода уже умеет искать файлы, читать MDX как обычный текст, редактировать его в ветке и открывать pull request. Направьте его на облачную CMS, и вам придется настраивать API, токены и кастомные интеграции, прежде чем он сможет изменить хотя бы один заголовок.  Меры безопасности также сохраняются. Метаданные проверяются по вашей схеме Zod, а тело каждого документа должно компилироваться как MDX. Поэтому агент не сможет сохранить некорректный документ. Команда [`scribe validate`](/docs/cli) обнаружит ошибку еще до начала сборки. А поскольку каждая правка является коммитом, изменения от ИИ проходят ту же процедуру, что и человеческие: просмотр отличий, ревью, утверждение. Этот сайт работает именно так. Большую часть документации и списка изменений обновляют агенты, а люди лишь проверяют разницу.  ## Кому эта модель не подойдет  Раздел честности. CMS на базе git предполагает, что люди, редактирующие контент, уверенно работают с файлами и pull request-ами, либо между ними и репозиторием стоит технический специалист. Если вашим редакторам нужен WYSIWYG-интерфейс и кнопка публикации, лучше выбрать облачную CMS. Scribe включает локальную [студию](/docs/studio) для просмотра, поиска и изучения переводов, но само создание контента происходит в вашем редакторе.  Однако, если ваша команда уже живет в git, добавление второй и третьей системы для контента и переводов лишь усложнит инфраструктуру. Один репозиторий, один процесс ревью, один деплой.  ## Попробуйте  Вся настройка сводится к одному конфигурационному файлу и папке с MDX:  ```bash pnpm add scribe-cms zod better-sqlite3 ```  Начните с [руководства по началу работы](/docs/getting-started) или прочитайте, как [перевод](/docs/translation) устроен под капотом.