Warum mehrsprachige Inhalte in Git gehören

Die meisten mehrsprachigen Websites haben am Ende drei Wahrheitsquellen: Inhalte in einem gehosteten CMS, Übersetzungen auf einer Plattform und den Code in Git. Jede Plattform hat ihre eigene Versionierung, eigene Zugriffsrechte und eine eigene Vorstellung davon, was "aktuell" bedeutet. Diese Systeme synchron zu halten, ist harte Arbeit. Abweichungen sind der Normalzustand.

Es gibt ein einfacheres Modell: Packen Sie einfach alles in das Repository.

Was Git ohnehin schon löst

Ihr Code-Workflow bewältigt die kompliziertesten Probleme im Content-Management bereits:

Review. Eine Inhaltsänderung ist ein Pull Request. Jemand liest das Diff, bevor es live geht.
Rollback. Eine fehlerhafte Bearbeitung wird mit einem Revert behoben, nicht mit einem Support-Ticket.
Atomarität. Inhalt und der Code, der ihn rendert, werden gemeinsam bereitgestellt. Eine Schema-Änderung und die zugehörige Inhaltsmigration landen in einem einzigen Commit.
Historie. git log beantwortet die Frage, wer was wann geändert hat, ganz ohne Plugin.

Ein dateibasiertes CMS bekommt all das völlig kostenlos. Die Frage ist nur, was passiert, wenn man jede Seite mit zehn Sprachen multipliziert.

Das Übersetzungsproblem

Der naive Ansatz lautet, eine Datei pro Sprache anzulegen: about.en.mdx, about.fr.mdx, about.ja.mdx. Das scheitert jedoch schnell. Bei zehn Sprachen wird aus einer Website mit 50 Seiten schnell ein Berg von 500 Dateien. Code-Reviews werden unmöglich für Sprachen, die niemand im Team spricht. Zudem gibt es keine Möglichkeit herauszufinden, ob about.fr.mdx den aktuellen englischen Text oder eine Version von vor drei Monaten widerspiegelt.

Scribe trennt diese beiden Anliegen voneinander:

Englische Inhalte sind MDX-Dateien. Eine Datei pro Dokument, validiert gegen ein Zod-Schema. Das ist der Teil, den Menschen schreiben und überprüfen.
Übersetzungen leben in einer einzigen SQLite-Datei, die direkt daneben versioniert wird. Jede Übersetzung ist mit einem Hash ihres englischen Ursprungstextes verknüpft, zusammen mit einem Snapshot, wie diese Quelle damals aussah.

Dieser Hash macht Schluss mit asynchronen Inhalten. Wenn Sie einen englischen Absatz ändern, veraltet exakt ein Dokument in jeder Sprache, und das wird sofort sichtbar. Führen Sie scribe translate aus, wird auch nur dieses eine Dokument neu übersetzt. Nichts gerät unbemerkt in den Rückstand. Mit scribe status sehen Sie bei jedem Commit die genaue Abdeckung.

Konstruktionsbedingt kein Server

Da alles als Datei im Repository liegt, gibt es auch nichts zu hosten. Die Laufzeitumgebung liest MDX und SQLite zur Build-Zeit von der Festplatte und übergibt Ihrem Framework vollständig typisierte Dokumente: Listen, Lookups, Relationen, Hreflang-Alternativen und Sitemap-Einträge. Es gibt keine CMS-API, die zur Laufzeit aufgerufen werden muss. Sie müssen keine Tokens rotieren und kein Ausfall eines Anbieters kann Ihre Inhalte offline nehmen. Wie Lesezugriffe funktionieren, erfahren Sie in der Laufzeit-API.

KI-Agenten arbeiten am besten mit Dateien

Es gibt noch ein neueres Argument für dieses Modell, und es ist vielleicht das stärkste: KI-Agenten kommen hervorragend mit Repositories zurecht. Ein Coding-Agent weiß bereits, wie man Dateien durchsucht, MDX als Klartext liest, auf einem Branch bearbeitet und einen Pull Request öffnet. Lässt man ihn stattdessen auf ein gehostetes CMS los, müssen erst APIs, Tokens und individuelle Integrationen eingerichtet werden, bevor auch nur eine einzige Überschrift geändert werden kann.

Auch die Leitplanken bleiben erhalten. Das Frontmatter wird gegen Ihr Zod-Schema validiert und jeder Body muss als gültiges MDX kompilierbar sein. Ein Agent kann also gar kein fehlerhaftes Dokument speichern. Der Befehl scribe validate fängt solche Fehler ab, noch bevor der Build startet. Da jede Änderung ein Commit ist, werden KI-Änderungen genauso behandelt wie menschliche Anpassungen: mit einem Diff, einem Review und einer Freigabe. Genau so funktioniert auch diese Website. Die Pflege der Dokumentation und des Changelogs wird größtenteils von Agenten erledigt, während Menschen die Diffs überprüfen.

Für wen dieses Modell nicht geeignet ist

Zeit für Ehrlichkeit. Ein Git-basiertes CMS setzt voraus, dass die Personen, die Inhalte bearbeiten, gut mit Dateien und Pull Requests umgehen können (oder dass jemand mit technischem Hintergrund zwischen ihnen und dem Repository sitzt). Wenn Ihre Redakteure eine WYSIWYG-Oberfläche und einen Veröffentlichen-Button benötigen, ist ein gehostetes CMS die richtige Wahl. Scribe bietet zwar ein lokales Studio zum Durchsuchen und Überprüfen von Übersetzungen, aber das eigentliche Schreiben findet in Ihrem Editor statt.

Wenn Ihr Team aber ohnehin schon in Git lebt, vergrößert ein zweites und drittes System für Inhalte und Übersetzungen nur die Angriffsfläche. Ein Repo, ein Review-Prozess, ein Deployment.

Ausprobieren

Das gesamte Setup besteht aus einer einzigen Konfigurationsdatei und einem Ordner mit MDX-Dateien:

pnpm add scribe-cms zod better-sqlite3

Beginnen Sie mit der Erste-Schritte-Anleitung oder lesen Sie, wie die Übersetzung unter der Haube funktioniert.