Was ist ICU MessageFormat, und warum ist es immer noch so schwer zu übersetzen?

ICU MessageFormat ist ein Unicode-Standard zum Schreiben eines einzigen übersetzbaren Strings, der sich an Anzahl, Genus und andere Variablen anpasst – und er ist nach wie vor schwer zu übersetzen, weil die Syntax für Code entwickelt wurde, nicht für die Menschen, die lokalisieren. Die Spezifikation gibt es seit weit über einem Jahrzehnt, und diejenigen, die am häufigsten daran scheitern, sind nicht-technische Übersetzer:innen, die vor verschachtelten geschweiften Klammern sitzen. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die eine Ebene unter diesem Problem ansetzt: Sie extrahiert Strings und generiert die Übersetzungsdateien, in denen diese ICU-Muster leben, und hält sie bei jedem Git-Push synchron.

Was ist ICU MessageFormat?

ICU MessageFormat ist eine Syntax zum Ausdrücken einer Nachricht, deren endgültige Formulierung von Laufzeitdaten abhängt. Statt Fragmente im Code zu verketten, schreibst du ein Muster und lässt den Formatter pro Locale den richtigen Zweig wählen.

Der häufigste Anwendungsfall ist die Pluralisierung:

{count, plural,
  one {You have # message}
  other {You have # messages}
}

# wird durch die Zahl ersetzt, und die Zweige one / other bilden die Pluralkategorien einer Sprache ab. Englisch hat zwei, Polnisch, Russisch und Arabisch haben mehr. ICU verarbeitet über select auch Genus und andere Auswahlfälle:

{gender, select,
  male {He liked your post}
  female {She liked your post}
  other {They liked your post}
}

Deshalb hat sich ICU als De-facto-Standard für Pluralisierung durchgesetzt: Es verlagert grammatische Komplexität in Daten, die pro Sprache variieren können, statt in Verzweigungslogik, die nur für die Sprache funktioniert, für die sie geschrieben wurde. Laufzeit-Bibliotheken wie FormatJS, i18next und next-intl verstehen es alle.

Warum ist ICU MessageFormat so schwer zu übersetzen?

Es ist schwer zu übersetzen, weil die Syntax für Entwickler:innen gebaut wurde, und die Menschen, die Strings tatsächlich übersetzen, sind meistens keine Entwickler:innen.

Wer eine Übersetzungsdatei öffnet, sieht nicht „Du hast 3 Nachrichten.“ Zu sehen sind geschweifte Klammern, die Schlüsselwörter plural und select, Plural-Kategorien, die vielleicht unbekannt sind, und ein #-Platzhalter, der wie ein Tippfehler aussieht. Eine gelöschte Klammer oder eine umbenannte Kategorie, und der String wirft zur Laufzeit einen Fehler, statt zu rendern. Genau die Struktur, die ICU für Entwickler:innen so mächtig macht, macht sie in der Hand von Sprachexpert:innen so zerbrechlich.

Das ist die Lücke, mit der die Lokalisierungsbranche seit Jahren still lebt. Die meisten Tools lösen das, indem sie das rohe Muster anzeigen und hoffen, dass die Übersetzerin nicht das falsche Zeichen anfasst, oder indem sie Pluralformen hinter einem separaten Editor verstecken, der trotzdem verlangt, dass die Übersetzerin Pluralkategorien versteht. Kein Anbieter hat die Distanz zwischen der Komplexität des Standards und dem mentalen Modell einer nicht-technischen Übersetzerin vollständig geschlossen.

Was hat sich mit MessageFormat 2.0 geändert?

MessageFormat 2.0 ist eine Syntax, die von Grund auf neu entworfen wurde, und 2025 wurde sie zu einem stabilen Standard statt zu einem Entwurf.

MF2 erreichte im März 2025 den Status „Final Candidate“ und ist jetzt fester Bestandteil von CLDR, veröffentlicht als Teil des technischen Unicode-LDML-Standards und verfeinert über die LDML-47- und -48-Releases. Die Referenzimplementierung folgt dem Standard gemäß der Anfang 2026 veröffentlichten Version LDML 48.2. Die neue Syntax trennt Eingaben von der Match-Logik und unterstützt benannte Formatierungsfunktionen, was komplexe Nachrichten lesbarer macht:

.input {$count :number}
.match $count
one {{You have {$count} message}}
*   {{You have {$count} messages}}

Das Ziel ist ein Muster, das sich leichter erweitern lässt und etwas weniger unangenehm zu lesen ist als die ursprünglichen verschachtelten Klammern.

Löst MessageFormat 2.0 das Problem für Übersetzer:innen?

Noch nicht, aus zwei Gründen.

Erstens verbessert MF2 die Ergonomie der Syntax, aber es bleibt Syntax. Eine Übersetzerin stößt weiterhin auf .match, Plural-Keys und Klammern. Die kognitive Last ist geringer als bei MF1, aber sie ist nicht verschwunden, und eine nicht-technische Übersetzerin kann eine Nachricht immer noch kaputtmachen, indem sie das falsche Token bearbeitet.

Zweitens: Kaum jemand setzt es produktiv ein. Die Verbreitung bleibt auch weit im Jahr 2026 begrenzt – der TC39-Prozess für die JavaScript-Seite verlangt, dass etwa ein Dutzend Organisationen MF2 produktiv nutzen, bevor der Standard weiter voranschreitet, und diese Schwelle ist noch nicht erreicht. In der Praxis läuft der Großteil der Apps, die du heute ausliefert, noch auf dem ursprünglichen ICU MessageFormat, über Bibliotheken wie FormatJS und i18next. Das Problem für Übersetzer:innen wird also nicht durch eine Spezifikation gelöst, sondern dadurch, wo die Syntax erzeugt und gepflegt wird.

Wo bricht ICU MessageFormat in KI-generierten Apps?

Es bricht früh, weil KI-Coding-Tools von vornherein selten korrektes ICU erzeugen.

Wenn du mit Cursor, Claude Code oder Lovable baust, geht der generierte Code mit Anzahlen tendenziell den naiven Weg:

// What an AI coding tool often generates
const label = count + " " + (count === 1 ? "message" : "messages");

Diese Logik ist für Englisch korrekt und für die meisten anderen Sprachen falsch, weil sie genau zwei Pluralformen voraussetzt. Außerdem wird der Satz fest in den Anwendungscode gebacken, sodass es gar kein ICU-Muster in einer Übersetzungsdatei gibt, das eine Übersetzerin lokalisieren könnte. Der String ist für die Lokalisierungsebene unsichtbar, bis jemand die fehlerhafte Grammatik in Produktion bemerkt. KI-Tools duplizieren außerdem Schlüssel und verstreuen hartcodierten Text über Komponenten, sodass selbst Teams, die ICU nutzen wollen, am Ende mit Strings dastehen, die es nie in eine übersetzbare Datei geschafft haben. Der globalize.now-Entwickler-Überblick ist genau darauf ausgelegt, diese Art von String abzufangen, bevor sie ausgeliefert wird.

Wie sollten Entwickler:innen 2026 mit ICU MessageFormat umgehen?

Behandle ICU als generierte Infrastruktur, nicht als handgeschriebenen Inhalt.

Die praktische Regel: Weder Entwickler:innen noch KI-Tools sollten Plural-Verkettungen im Code schreiben, und Übersetzer:innen sollten keine rohen ICU-Klammern von Hand bearbeiten. Das ICU-Muster gehört in eine Übersetzungsdatei, die automatisch erzeugt und aktuell gehalten wird, und die dann zur Laufzeit von einer Bibliothek wie FormatJS, i18next oder next-intl gerendert wird. So bleibt die Syntax an der Stelle korrekt, an der sie entsteht, und konsistent über alle Sprachen hinweg, während sich die App weiterentwickelt. Wenn du abwägst, wo ICU im Verhältnis zu deiner Runtime-Ebene einzuordnen ist, deckt der Vergleich globalize.now vs. i18next ab, wie sich Infrastruktur und Runtime die Arbeit teilen.

Auf dieser Ebene setzt globalize.now an. Es extrahiert hartcodierte Strings aus deiner Codebase, generiert die Schlüssel und Übersetzungsdateien, in denen die ICU-Muster leben, und synchronisiert sie bei jedem Git Push neu – so bleibt die Struktur korrekt, ganz ohne manuellen Export-Schritt. Es will weder Lektor für Übersetzer noch Ersatz für deine Runtime-Bibliothek sein; es sorgt dafür, dass die ICU-Dateien, auf die diese Tools angewiesen sind, tatsächlich existieren und synchron bleiben. Der Guide für Vibe Coder zeigt das gleiche Setup für Apps aus Lovable, Bolt und Replit, und der größere Workflow steht auf der globalize.now-Startseite.