Lagern Sie Ihre Produktsprache nicht aus

6 Min. Lesezeit

Übersetzung ist Produktarbeit

Der traditionelle Übersetzungsablauf wurde für Broschüren, Handbücher und Rechtsdokumente gebaut. Dort funktioniert er einigermaßen, weil es tatsächlich um das Dokument geht.

Unternehmenssoftware ist anders. Ihre Texte stecken in Berechtigungen, Freigaben, Rechnungen, Validierungsfehlern und Schaltflächen, die Menschen anklicken, wenn Geld oder Kundendaten im Spiel sind. Eine Formulierung ist Teil einer Handlung.

Trotzdem lebt das alte Muster weiter:

• Entwickler exportieren Textdateien
• ein Dienstleister übersetzt sie ohne Kontext
• jemand importiert sie später
• das Produktteam entdeckt, dass die Wörter weder zur Oberfläche noch zum Markt passen
• niemand weiß, welche Änderung die Verwirrung ausgelöst hat

Das ist kein Versagen professioneller Übersetzung. Es ist mangelnde Produktverantwortung.

Mehrsprachige Unternehmenssoftware wird schwieriger, wenn Sprache zur Frontend-Architektur wird. Das ruhigere Modell behält Sprache dort, wo die Verantwortung für das Produkt bereits liegt: im Repository, in der Prüfung, in Tests und im Entwicklungsprozess.

Wer übersetzt, muss das Produkt sehen

Das Entwicklungsteam verantwortet das Produkt. Der Übersetzer verantwortet eine Datei. Das Unternehmen trägt die Folgen.

Großartige Aufteilung. Jeder bekommt einen eigenen Verantwortungsbereich, und niemand verantwortet den Satz, den der Nutzer tatsächlich liest.

Das Problem ist nicht, dass Übersetzer außerhalb des Unternehmens arbeiten. Der Prozess entfernt sie aus dem Kontext, in dem Bedeutung entsteht. Submit kann auf einer Oberfläche harmlos und auf einer anderen falsch sein. Approve, accept, confirm, release und send wirken austauschbar, bis eines davon eine Rechnung auslöst, einen Vertragsstatus ändert oder einen Kunden glauben lässt, etwas sei rechtlich endgültig.

Dieser Kontext überlebt einen Export selten. In einem Pull Request überlebt er deutlich besser.

Wer die Sprache beherrscht und prüft, sieht die geänderten Schlüssel, die umgebenden Templates, die Produktdiskussion und einen Screenshot oder eine Vorschau der funktionierenden Oberfläche. KI kann den ersten Durchgang vorbereiten. Menschliche Prüfung schützt die Produktbedeutung.

Die Aufgabe verschiebt sich von „Übersetzen Sie diese Dateien“ zu „Entscheiden Sie, ob diese Produktänderung in diesem Markt richtig klingt“. Das ist die bessere Aufgabe.

Die Laufzeit langweilig halten

Der serverseitige Ansatz mit Web Components hält das Übersetzungsmodell absichtlich unspektakulär. Der Server bestimmt die Sprache anhand von Accept-Language oder einer gespeicherten Präferenz und rendert dann die Seite in dieser Sprache.

Web Components liefern wiederverwendbares Verhalten, wo es nützt. Sie werden aber nicht zu einer zweiten Laufzeit für Übersetzungen, wenn das Produkt sie nicht wirklich braucht. Eine Komponente kann übersetzte Beschriftungen als Attribute, Slots oder gerenderte Kindelemente erhalten. Sie muss keine deutschen Pluralregeln kennen, nur um ein Statusfeld anzuzeigen.

Backend:

• Sprache aus Request-Headern oder Nutzerpräferenz bestimmen
• Texte laden
• Templates rendern
• Daten, Zahlen und Geldbeträge konsistent formatieren

Web Component:

• Datumswähler, Tabelle, Dialog oder Statusfeld um Browserverhalten erweitern
• Ereignisse auslösen
• Barrierefreiheit erhalten
• die bereits gerenderten Beschriftungen verwenden

Das Ergebnis ist nicht primitiv. Es ist kontrolliert.

Ein Muster für jedes Backend

Eine Route im Flask-Stil kann die Sprache aushandeln, die Texte laden und HTML rendern, ohne die Sprache in die Ressourcen-URL zu stecken:

Das Template übergibt übersetzte Beschriftungen an die Komponente:

Die Kataloge bleiben langweilig:

Die deutschen und spanischen Varianten liegen neben der Ausgangsdatei. Das Team kann die Unterschiede prüfen, KI kann Übersetzungen für fehlende Schlüssel entwerfen, und ein Prüfer mit den nötigen Sprachkenntnissen kann die Formulierung direkt neben dem verwendenden Template korrigieren.

Spring Boot folgt mit Message Bundles demselben Modell:

Thymeleaf übergibt die lokalisierten Texte an die Komponente:

Python, Java oder etwas anderes: Das Verantwortungsmodell bleibt gleich. Der Server rendert die Seite in der gewählten Sprache, die Komponente erhält sprachspezifische Texte, und die Sprachdateien liegen in Git. Niemand schickt eine Tabelle per E-Mail ins Nichts.

KI entwirft; Menschen entscheiden

KI macht die Prüfung von Übersetzungen billiger. Sie macht Urteilskraft nicht optional. Maschinenausgabe auszuliefern, weil die Demo flüssig klang, erzeugt höflichen Unsinn mit tadelloser Zeichensetzung.

Nutzen Sie KI für das, was sie gut kann:

• fehlende Übersetzungen aus vorhandenen Ausgangstexten entwerfen
• Begriffe über Dateien hinweg vereinheitlichen
• Schlüssel finden, die in einer Sprache fehlen
• kürzere Alternativen vorschlagen, wenn Beschriftungen nicht passen
• Formulierungen mit dem unmittelbaren Produktkontext vergleichen
• einen Diff vorbereiten, den Menschen prüfen können

Lassen Sie dann Menschen mit den nötigen Sprachkenntnissen dort urteilen, wo es zählt:

• Klingt das natürlich?
• Passt es zum Ton des Produkts?
• Deutet das Wort die falsche rechtliche oder geschäftliche Handlung an?
• Ist die Form zu förmlich, zu locker, zu englisch oder zu wörtlich?
• Würde ein Kunde in diesem Markt dieser Formulierung vertrauen?

KI entwirft.

Menschen entscheiden.

Das Repository erinnert sich.

Der Pull Request ist das Übersetzungswerkzeug

Die meisten Unternehmen haben das nötige System zur Zusammenarbeit bereits. Sie benutzen es nur weiterhin ausschließlich für Code.

Ein Pull Request für Übersetzungen kann die neuen Schlüssel, KI-Entwürfe, die verwendenden Templates, Screenshots oder Vorschau-Links, Kommentare mehrsprachiger Prüfer und Testergebnisse zeigen, die belegen, dass in keiner Sprache Schlüssel fehlen.

Das liegt viel näher an der Produktwirklichkeit als extrahierte Dateien für einen Dienstleister, der die Nutzerreise nie sieht. Außerdem erhält der CTO etwas, das der alte Prozess selten liefert: Nachvollziehbarkeit.

Wer hat diese Beschriftung geändert? Warum haben wir diese Formulierung gewählt? Hat jemand mit den nötigen Sprachkenntnissen sie geprüft? Können wir sie sauber zurücknehmen?

Übersetzungsarbeit im Repository beantwortet diese Fragen. Bei Dateiübergaben sucht ein Projektmanager in E-Mails.

Der Ablauf ist klein

Der praktische Ablauf ist klein genug, um ohne weitere Plattform zu beginnen:

1. Entwickler ergänzen oder ändern Sprachschlüssel als Teil der Produktänderung.
2. Codex entwirft fehlende Übersetzungen im selben Branch.
3. Automatisierte Prüfungen schlagen fehl, wenn einer Sprache ein erforderlicher Schlüssel fehlt.
4. Ein mehrsprachiger Prüfer kontrolliert die Formulierung im Pull Request.
5. Das Team prüft die Oberfläche, nicht nur die Datei.
6. Das Produkt wird mit Sprache veröffentlicht, die als Teil der Änderung geprüft wurde.

Das richtet sich nicht gegen Übersetzer. Es richtet sich gegen Isolation.

Externe Übersetzer können weiter mitarbeiten, aber innerhalb des Produktprozesses statt am Ende einer Dateiübergabe. Interne Mitarbeiter mit passenden Sprachkenntnissen helfen bei fachlichen Feinheiten. Menschen mit Kundenkontakt können Formulierungen markieren, die unnötige Supportanfragen erzeugen. Der CTO sieht, dass Übersetzung kein spätes Rätsel mehr ist.

Produktsprache gehört nicht ins Nebenzimmer

Das Produkt ändert sich in einem Raum. Die Sprache in einem anderen. Der Kunde erlebt beides als eine Sache.

Diese Lücke ist das ganze Problem.

Rendern Sie sprachspezifische Seiten auf dem Server. Halten Sie Komponenten wiederverwendbar, ohne ihnen Übersetzungszustand aufzubürden. Lassen Sie KI erste Entwürfe vorbereiten. Lassen Sie mehrsprachige Menschen die Wörter dort prüfen, wo das Produkt ohnehin geändert wird.

Das ist kein Transformationsprogramm. Es ist eine bessere Art zu arbeiten. Für einen CTO zählt das mehr als noch eine Lokalisierungsplattform mit einem Dashboard, das nach dem Start niemand mehr öffnet.