Warum laufen Übersetzungsdateien immer wieder auseinander?

Übersetzungsdateien laufen auseinander, weil zwei Systeme dieselben Daten verwalten und keines davon gewinnt. Dein Repository ändert sich, wenn ein Entwickler mergt. Deine Übersetzungsdateien ändern sich, wenn jemand daran denkt, sie zu aktualisieren. Das sind unterschiedliche Uhren, und in der Lücke dazwischen leben fehlende Schlüssel, verwaiste Schlüssel und veraltete Strings. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die diese Lücke schließt, indem sie Schlüssel und Locale-Dateien genau dort generiert, wo der Code geschrieben wird — sodass es keine zweite Uhr gibt, die hinterherhinken kann.

Was verursacht eigentlich, dass Locale-Dateien auseinanderlaufen?

Eine Datei wird verfasst, die restlichen werden nur gepflegt — und das sind nicht dieselbe Aufgabe.

Ein Entwickler, der ein Feature baut, bearbeitet en.json, weil das die Datei ist, in die der String hineingeht. Die anderen Locales sind das Problem von jemand anderem, nach dem Zeitplan von jemand anderem. Ein Entwickler, der auf DEV über dieses Muster schrieb, beschrieb die zwei Fehlerformen: Schlüssel werden zur englischen Datei hinzugefügt und in den anderen vergessen, sodass ein Teil der App still auf Englisch zurückfällt, und Schlüssel werden in einer Locale gelöscht, überleben aber in einer anderen, sodass sich tote Einträge ansammeln. Der Entdeckungsmechanismus ist in beiden Fällen eine Kundenbeschwerde, Wochen später.

Keins von beiden ist ein Übersetzungsproblem. Nichts wurde falsch übersetzt. Die Strings wurden nie irgendwohin geroutet.

Das ist der Fehlermodus, der jedes Tooling-Upgrade übersteht, weil das Tooling dem Ort, an dem der String entstanden ist, nachgelagert sitzt. Wenn der String nie in die Pipeline gelangt, hilft auch eine bessere Pipeline nicht. Dieselbe Ursache zeigt sich weiter vorne in der Kette, wenn ein Coding-Agent Strings schreibt, die nie gekeyt wurden.

Warum verursachen Übersetzungsdateien so viele Merge-Konflikte?

Weil es sich um generierte Daten handelt, die von Hand bearbeitet werden — in einem Format, das für Maschinen zum Schreiben gedacht ist.

Eine Übersetzungsdatei ist eine flache Zuordnung von Schlüsseln zu Strings. Zwei Branches, die beide ein Feature hinzufügen, hängen beide etwas an diese Zuordnung an — meist an der gleichen Stelle, meist in derselben alphabetischen Nachbarschaft. Git sieht zwei Änderungen an benachbarten Zeilen in einer Datei ohne semantische Struktur, die es versteht, und bittet einen Menschen, das zu lösen.

Der Mensch, der das löst, ist ein Entwickler, der die Zielsprache nicht liest. Der sichere Zug ist, beide Seiten zu behalten — so entstehen doppelte Schlüssel. Der schnelle Zug ist, nur eine zu behalten — so werden Übersetzungen stillschweigend gelöscht.

Niemand löst Konflikte in einer Lockfile von Hand. Man regeneriert sie. Übersetzungsdateien verdienen dieselbe Behandlung, sobald sie aufhören, Dokumente zu sein, die ein Mensch schreibt.

Wie veraltet wird eine Übersetzung, während sie im Review wartet?

Veraltet genug, um das Produkt nicht mehr korrekt zu beschreiben — und das lässt sich öffentlich messen.

Ein Feldbericht auf DevOps.com hat fünf reale Lokalisierungs-Pull-Requests in Open-Source-Projekten untersucht. Aufschlussreich ist Kilo Code PR #8377: Die automatisierten Checks liefen sauber durch, das Maintainer-Review kam erst später, und das Repository hatte sich darunter bereits weiterentwickelt. Der PR wurde geschlossen mit der Aufforderung, ihn gegen die aktuelle Architektur neu einzureichen. Derselbe Bericht dokumentiert ein OpenClaw-Issue, bei dem Freiwillige Übersetzungen in Spanisch, Japanisch, Portugiesisch, Koreanisch, Chinesisch und Vietnamesisch anboten — und die Maintainer sagten, sie hätten keine Möglichkeit, diese aufzunehmen.

Lies das als Latenzberichte, nicht als Qualitätsberichte. Die Übersetzungen waren korrekt, als sie geschrieben wurden. Das Interface hat sich verändert, während sie in der Warteschlange standen.

Das sind die Kosten, die beim Vergleich von Lokalisierungstools niemand einpreist. Alle messen die Übersetzung. Fast niemand misst, wie lange ein String unterwegs ist oder was das Interface in dieser Zeit gemacht hat.

Was kostet der Hin-und-her-Prozess tatsächlich?

Mehr an Koordination als an Übersetzung — deshalb erklärt die Rechnung nie, woher der Schmerz kommt.

Die sichtbaren Kosten sind pro Wort, pro Schlüssel oder pro Sitzplatz kalkuliert und erscheinen einmal im Monat auf einer Rechnung. Die unsichtbaren Kosten sind ein Entwickler, der fragt, welche Datei er bearbeiten soll, ein zweiter Entwickler, der einen Konflikt in einer Sprache löst, die er nicht liest, ein dritter, der bemerkt, dass dem deutschen Build elf Schlüssel fehlen, und der ursprüngliche Feature-Autor, der zu einem String befragt wird, den er vor fünf Wochen geschrieben hat.

Nichts davon taucht in einem Preisvergleich auf. Bezahlt wird das alles in Entwicklerzeit, zu Entwicklerraten, jeden Sprint. Ein Tool mit niedrigem Listenpreis, das zwei Ingenieure einen Tag pro Woche kostet, ist nicht günstig.

Der Hin-und-her-Prozess ist es, der diese Kosten erzeugt. Dateien zwischen dem Ort, an dem Strings entstehen, und dem Ort, an dem sie übersetzt werden, hin- und herzuschieben, ist der teure Schritt — und das bleibt teuer, egal von wem man es kauft. Deshalb wandert die Lokalisierung zunehmend weiter vorne in den Entwicklungs-Loop.

Was ändert sich, wenn die Schlüssel dort entstehen, wo der Code geschrieben wird?

Die zweite Uhr verschwindet, und Drift hat keine Quelle mehr.

Der Ablauf ist nicht mehr: Entwickler schreibt einen hartcodierten String, jemand findet ihn später, jemand keyt ihn, jemand schickt die Datei raus, jemand übersetzt sie, jemand holt sie zurück. Er wird zu: Der String wird direkt als Schlüssel mit Wert geschrieben, im selben Commit wie das Feature, und die Übersetzung folgt von dort aus.

Mit globalize.now beginnt das mit einer einmaligen Konvertierung. Du verbindest dein Repository in der App, und die bestehenden hartcodierten Strings werden in einem einzigen Durchlauf in Schlüssel und Übersetzungsdateien extrahiert. Danach sorgen die Agent-Skills dafür, dass Coding-Agents wie Cursor und Claude Code von Anfang an gekeyte Strings schreiben, statt sie hartzucodieren, und Push-Jobs übersetzen die neuen Katalog-Einheiten, sobald sie entstehen.

Das entscheidende Wort ist einmal. Die Konvertierung ist der schwierige Teil, und sie passiert nur ein einziges Mal. Was danach kommt, ist der Teil, der früher manuell war und jetzt im gleichen Takt wie der Code läuft — genau darum geht es, wenn man es in den Entwickler-Workflow integriert, statt daneben zu stellen.

Runtime-Bibliotheken sind davon nicht betroffen. i18next und next-intl lesen die Übersetzungsdateien weiterhin genau wie zuvor. An der Art, wie Übersetzungen ausgeliefert werden, ändert sich nichts. Was sich ändert, ist, wer die Dateien schreibt.

Wie unterscheidest du Drift von einem echten Übersetzungsproblem?

Frag dich, ob je ein Übersetzer den String gesehen hat.

Fehlt der deutschen Datei ein Schlüssel, hat kein Übersetzer versagt. Der String hat nie einen erreicht. Das ist ein Routing-Fehler, und zusätzliche Review-Schritte machen es schlimmer, weil sie Wartezeit zu einem Prozess hinzufügen, dessen Problem ohnehin schon Latenz ist.

Hat die deutsche Datei den Schlüssel und der Wortlaut passt nicht zum Kontext, ist das ein echtes Übersetzungsproblem — und es verdient einen Menschen, der Deutsch spricht und sehen kann, wo der String gerendert wird. Das ist die Zeit wert.

Die meisten Teams haben deutlich mehr vom ersten als vom zweiten Fall und behandeln beide als dasselbe Problem — deshalb fühlt sich Lokalisierung endlos an. Trennt man sie, sinkt der Aufwand, weil die Routing-Hälfte überhaupt keine menschliche Arbeit mehr ist. Diese Unterscheidung wird umso wichtiger, je kleiner das Team ist — deshalb zeigt sie sich am deutlichsten bei Solo-Entwicklern und kleinen Teams, die schnell releasen.

Ein nützlicher Test: Zähle, wie viele deiner letzten zehn Lokalisierungsbugs falsche Wörter waren und wie viele fehlende Wörter. Waren es meist fehlende, hast du kein Übersetzungsproblem. Du hast ein Rohrleitungsproblem — und Rohrleitungen lassen sich automatisieren, Urteilsvermögen nicht. Dieselbe Logik gilt, wenn du herausfindest, was Lokalisierung dich tatsächlich kosten sollte.

Drift in Übersetzungsdateien ist ein Routing-Problem im Kostüm eines Übersetzungsproblems. Verbinde das Repository einmal, und das Routing ist nicht mehr dein Job.