Почему многоязычный контент должен храниться в 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 разделяет эти две задачи: - Английский контент хранится в файлах MDX. Один файл на документ, который проходит валидацию по схеме Zod. Именно эту часть пишут и проверяют люди. - Переводы находятся в одном файле SQLite, который коммитится рядом с ними. Каждый перевод привязан к хешу своего английского исходника вместе со снимком того, как этот исходник выглядел. Именно хеш устраняет проблему рассинхронизации. Измените один абзац на английском языке, и ровно один документ станет неактуальным во всех локализациях, причем это будет сразу заметно. Запустите scribe translate, и будет заново переведен только этот документ. Ничего не устаревает незаметно, а команда scribe status показывает точное покрытие на любом коммите. ## Отсутствие сервера по дизайну Поскольку всё представляет собой файлы в репозитории, вам нечего хостить. Во время сборки среда выполнения читает MDX и SQLite с диска и передает вашему фреймворку полностью типизированные документы: списки, справочники, связи, альтернативные ссылки hreflang и элементы карты сайта. Нет API CMS, к которому нужно обращаться при запросе. Нет токенов, которые нужно обновлять. И нет сбоев на стороне поставщика, способных сделать ваш контент недоступным. Ознакомьтесь с API среды выполнения, чтобы узнать, как работает чтение. ## Файлы идеально подходят для ИИ-агентов У этой модели есть более новый и, возможно, самый весомый аргумент: ИИ-агенты отлично работают с репозиториями. Агент для написания кода уже умеет искать файлы, читать MDX как обычный текст, редактировать его в ветке и открывать pull request. Направьте его на облачную CMS, и вам придется настраивать API, токены и кастомные интеграции, прежде чем он сможет изменить хотя бы один заголовок. Меры безопасности также сохраняются. Метаданные проверяются по вашей схеме Zod, а тело каждого документа должно компилироваться как MDX. Поэтому агент не сможет сохранить некорректный документ. Команда scribe validate обнаружит ошибку еще до начала сборки. А поскольку каждая правка является коммитом, изменения от ИИ проходят ту же процедуру, что и человеческие: просмотр отличий, ревью, утверждение. Этот сайт работает именно так. Большую часть документации и списка изменений обновляют агенты, а люди лишь проверяют разницу. ## Кому эта модель не подойдет Раздел честности. CMS на базе git предполагает, что люди, редактирующие контент, уверенно работают с файлами и pull request-ами, либо между ними и репозиторием стоит технический специалист. Если вашим редакторам нужен WYSIWYG-интерфейс и кнопка публикации, лучше выбрать облачную CMS. Scribe включает локальную студию для просмотра, поиска и изучения переводов, но само создание контента происходит в вашем редакторе. Однако, если ваша команда уже живет в git, добавление второй и третьей системы для контента и переводов лишь усложнит инфраструктуру. Один репозиторий, один процесс ревью, один деплой. ## Попробуйте Вся настройка сводится к одному конфигурационному файлу и папке с MDX: bash pnpm add scribe-cms zod better-sqlite3 Начните с руководства по началу работы или прочитайте, как перевод устроен под капотом.