Eine Plattform in mehreren Sprachen weiterentwickeln, obwohl das Produktteam auf Deutsch arbeitet.

Eine bestehende Plattform einmalig in Englisch, Französisch oder Italienisch zu übersetzen, ist vergleichsweise überschaubar. Die größere Herausforderung beginnt am Tag danach.

Das Produktteam entwickelt weiterhin neue Funktionen. Buttons, Hilfetexte, Fehlermeldungen und E-Mails verändern sich. Mehrere Anbieter stellen laufend neue kaufbare Inhalte ein. Redaktionen korrigieren Texte, Nutzer melden unverständliche Formulierungen und zusätzlich soll ein Teil der Plattform auf Deutsch in einfacher Sprache verfügbar sein.

Mehrsprachigkeit ist dann kein abgeschlossenes Übersetzungsprojekt mehr. Sie wird zu einem dauerhaft betriebenen Produktprozess, der Quelltexte, Kontext, KI-Übersetzung, Freigabe, Feedback und Versionsstände miteinander verbindet.

Die Ausgangssprache bleibt Teil des Entwicklungsprozesses

Das Produktteam soll seine tägliche Arbeit weiterhin effizient in einer gemeinsamen Sprache erledigen können. Neue Funktionen werden auf Deutsch konzipiert, entwickelt und getestet. Daraus darf jedoch kein manueller Flaschenhals entstehen, bei dem vor jedem Release alle neuen Texte in Tabellen kopiert, an Übersetzer verschickt und später wieder in das System eingepflegt werden.

Die Architektur benötigt deshalb eine klare Quellsprache. Für jeden übersetzbaren Inhalt ist bekannt:

• welcher Text die Quelle ist,
• zu welcher Funktion oder Entität er gehört,
• in welchem Kontext er erscheint,
• wann er zuletzt geändert wurde,
• welche Zielsprachen benötigt werden,
• welche Übersetzungen aktuell, geprüft oder veraltet sind.

Die Quellsprache ist dabei nicht automatisch qualitativ überlegen. Sie ist der verlässliche Ausgangspunkt der Versionskette.

Nicht jeder Text kommt aus demselben System

Eine Plattform enthält mehrere Textdomänen:

UI-Texte

• Buttons,
• Labels,
• Navigation,
• Validierungs- und Fehlermeldungen,
• Systemhinweise,
• E-Mail- und Push-Templates.

Redaktionelle Plattforminhalte

• Hilfeseiten,
• Landingpages,
• Onboarding,
• Erklärtexte,
• rechtlich oder markenbezogen sensible Inhalte.

Von Anbietern erzeugte Inhalte

• Titel,
• Beschreibungen,
• Leistungen,
• Bedingungen,
• Termine,
• individuelle Hinweise.

Strukturierte Fachinhalte

• Kategorien,
• Attribute,
• Auswahlwerte,
• Einheiten,
• Statusbezeichnungen.

Einfache Sprache

• sprachlich vereinfachte Fassungen ausgewählter UI- und Inhaltsbereiche.

Diese Domänen benötigen unterschiedliche Workflows. Ein kurzer Button darf automatisiert und unmittelbar übersetzt werden, wenn Kontext und Terminologie klar sind. Ein rechtlich relevanter Hinweis kann eine verpflichtende menschliche Prüfung benötigen. Dynamische Anbieterinhalte müssen skalieren und dürfen die redaktionelle Releaseplanung nicht blockieren.

Übersetzungsschlüssel brauchen Kontext

Ein Schlüssel wie button.save mit dem deutschen Text „Speichern" ist relativ eindeutig. Andere Texte sind ohne Kontext mehrdeutig:

• „Buchen" kann eine Reservierung, einen Kauf oder eine buchhalterische Handlung meinen.
• „Zurück" kann Navigation oder Rückabwicklung bedeuten.
• „Frei" kann kostenlos, verfügbar oder unbesetzt heißen.
• „Anbieter" kann Verkäufer, Veranstalter oder technischer Provider sein.

Jeder übersetzbare UI-Text sollte deshalb Kontextmetadaten besitzen:

• Seite oder Komponente,
• fachlicher Prozess,
• Zielgruppe,
• Variablen und Platzhalter,
• maximal sinnvolle Länge,
• Screenshot oder visuelle Referenz optional,
• Terminologiehinweise,
• gewünschte Tonalität.

Die KI übersetzt dann nicht nur eine Zeichenfolge, sondern einen Text in einem bekannten Produktzustand.

Eine kontinuierliche Localization Pipeline

Ein belastbarer Prozess kann so aussehen:

neuer oder veränderter deutscher Quelltext
        ↓
Änderung erkennen und klassifizieren
        ↓
Kontext, Glossar und bestätigte Übersetzungen laden
        ↓
KI-Übersetzung oder sprachliche Vereinfachung erzeugen
        ↓
automatische Qualitätsprüfungen
        ↓
abhängig von Risiko: direkt veröffentlichen oder prüfen
        ↓
Feedback und Korrekturen speichern
        ↓
bei künftigen Runs berücksichtigen

Dieser Ablauf wird nicht als eine große Blackbox implementiert. Jede Stufe besitzt Zustände und nachvollziehbare Ergebnisse.

Änderungserkennung statt Komplettübersetzung

Bei jedem Release sämtliche Texte neu zu übersetzen wäre teuer und gefährlich. Bestätigte Formulierungen könnten sich ohne Not verändern.

Die Plattform erkennt deshalb:

• neue Schlüssel,
• geänderte Quelltexte,
• entfernte Inhalte,
• geänderten Kontext,
• neue Zielsprachen,
• geänderte Glossarregeln,
• veraltete Übersetzungen.

Für jeden Zieltext wird gespeichert, auf welcher Quellversion er basiert. Ändert sich die Quelle, wechselt der Zieltext beispielsweise von published zu stale oder review_required.

Translation Memory und Glossar

Ein Translation Memory speichert bestätigte Übersetzungen und wiederverwendbare Segmente. Ein Glossar legt fest, wie zentrale Begriffe behandelt werden.

Beispiele:

• Produkt- und Markennamen bleiben unverändert.
• „Anbieter" wird je fachlichem Kontext konsistent übersetzt.
• „Buchung" und „Bestellung" dürfen nicht vermischt werden.
• Funktionsnamen besitzen festgelegte Zielbegriffe.
• formelle oder informelle Ansprache wird je Sprache definiert.

Die KI erhält diese Informationen bei jedem Run. Manuell bestätigte Entscheidungen werden dadurch zu dauerhaftem Produktwissen.

Automatisierung nach Risikoklasse

Nicht jede Übersetzung benötigt denselben Prüfaufwand.

Niedriges Risiko

• kurze, eindeutige UI-Texte,
• wiederkehrende bekannte Formulierungen,
• Inhalte mit hoher Translation-Memory-Übereinstimmung.

Mögliche Behandlung: automatisiert erzeugen und nach formalen Prüfungen veröffentlichen.

Mittleres Risiko

• längere Hilfetexte,
• neue Fachbegriffe,
• Anbieterbeschreibungen mit variabler Qualität,
• Texte mit Platzhaltern und komplexem Kontext.

Mögliche Behandlung: automatisiert veröffentlichen, aber leicht meldbar und stichprobenartig prüfen – oder vor Veröffentlichung reviewen.

Hohes Risiko

• rechtlich relevante Inhalte,
• Preise, Fristen oder Leistungszusagen,
• sicherheitsrelevante Hinweise,
• Texte mit großer Außenwirkung,
• sprachliche Vereinfachung komplexer Fachinhalte.

Mögliche Behandlung: verpflichtende fachliche oder sprachliche Freigabe.

So skaliert der Prozess, ohne Kontrolle pauschal aufzugeben.

Anbieterinhalte als eigener Strom

Auf einer Plattform mit vielen Anbietern entstehen laufend neue Produkt- oder Leistungsbeschreibungen. Diese Inhalte besitzen eine andere Dynamik als die UI.

Der Prozess kann sein:

1. 1Anbieter erstellt oder ändert deutschen Quellinhalt.
2. 2Inhalt wird gespeichert und erhält eine Version.
3. 3Qualitäts- und Sicherheitsprüfung des Quelltexts erfolgt.
4. 4Übersetzungen werden für aktive Zielsprachen erzeugt.
5. 5Zieltexte werden abhängig von Regeln veröffentlicht.
6. 6Plattform zeigt transparent, welche Fassung aktuell ist.
7. 7Änderungen am Quelltext markieren betroffene Übersetzungen als veraltet.

Wichtig ist, dass der Anbieter weiterhin Eigentümer seines Quellinhalts bleibt. Automatische Übersetzung und redaktionelle Korrektur werden als getrennte Ebenen nachvollziehbar gespeichert.

Einfache Sprache als zusätzlicher Ausgabekanal

Deutsch in einfacher Sprache ist keine gewöhnliche Zielübersetzung. Ausgangs- und Zielsprache sind beide Deutsch, aber Satzbau, Wortwahl und Informationsdichte verändern sich.

Die Pipeline kann dafür einen eigenen Modus besitzen:

• lange Sätze zerlegen,
• klare Verben verwenden,
• unnötige Fachbegriffe ersetzen oder erklären,
• Handlungsaufforderungen eindeutig formulieren,
• Informationen in kleinere Abschnitte gliedern,
• Bedeutung und rechtliche Aussage erhalten.

Da Vereinfachung stärker in die Formulierung eingreift, sind eigene Qualitätsregeln und je nach Inhalt menschliche Prüfungen sinnvoll.

Feedback direkt im Produkt

Nutzer sehen Übersetzungen in dem Kontext, in dem sie tatsächlich funktionieren müssen. Deshalb ist ihr Feedback besonders wertvoll.

Eine Plattform kann an relevanten Texten eine unaufdringliche Meldefunktion anbieten:

• „Text unverständlich" oder „Übersetzung melden" auswählen,
• optional Kommentar ergänzen,
• System speichert Sprache, Textschlüssel, aktuelle Version, Seite und Nutzerkontext,
• Meldung landet direkt beim richtigen Übersetzungseintrag,
• Korrektur wird bestätigt oder in den nächsten Run übernommen.

Damit wird aus diffusem Feedback ein strukturierter Teil des Localization-Prozesses.

Korrekturen vor dem nächsten KI-Run schützen

Ein häufiges Problem automatisierter Übersetzung ist, dass eine manuell verbesserte Formulierung beim nächsten Lauf wieder überschrieben wird.

Jeder Zieltext benötigt daher einen Bearbeitungsstatus:

• maschinell erzeugt,
• automatisch geprüft,
• manuell bearbeitet,
• fachlich bestätigt,
• sprachlich bestätigt,
• geschützt,
• veraltet durch Quelländerung.

Ein geschützter Zieltext wird nicht automatisch ersetzt. Bei einer relevanten Quelländerung kann das System einen Änderungsvorschlag erzeugen oder eine Prüfung anfordern.

Veröffentlichung an Releases koppeln – aber nicht vollständig blockieren

UI-Texte gehören häufig zu einem Software-Release. Wenn eine neue Funktion in einer Sprache nicht vollständig übersetzt ist, gibt es mehrere Optionen:

• Release für diese Sprache blockieren,
• Funktion dort vorübergehend deaktivieren,
• auf die Quellsprache zurückfallen,
• maschinelle Übersetzung mit Kennzeichnung verwenden,
• nur kritische Texte verpflichtend prüfen.

Die Regel hängt von Produkt, Zielgruppe und Risikoklasse ab. Sie sollte nicht bei jedem Release neu improvisiert werden.

Dynamische Anbieterinhalte benötigen dagegen einen eigenen Veröffentlichungszyklus, der nicht an Softwaredeployments gebunden ist.

Localization als Managed Operation

Nach dem Aufbau beginnt der dauerhafte Betrieb:

• neue Texte und Inhalte verarbeiten,
• Fehler und Rückstaus überwachen,
• Modell- und Promptänderungen testen,
• Glossar pflegen,
• Qualitätsstichproben durchführen,
• Feedback bearbeiten,
• Sprachabdeckung messen,
• Kosten und Laufzeiten beobachten,
• veraltete Übersetzungen nachziehen.

Mehrsprachigkeit wird damit zu einer betrieblichen Fähigkeit der Plattform – nicht zu einer einmaligen Exportdatei.