UI-Texte, redaktionelle Inhalte, Anbieterinhalte und einfache Sprache brauchen unterschiedliche Übersetzungsprozesse.

Eine zentrale Übersetzungsfunktion wirkt zunächst effizient: Text hinein, Zielsprache auswählen, übersetzten Text speichern. Für eine produktive Plattform ist dieses Modell zu grob.

Ein Button mit acht Zeichen, ein redaktioneller Ratgeber, eine von einem Anbieter verfasste Leistungsbeschreibung und eine Fassung in einfacher Sprache unterscheiden sich nicht nur in ihrer Länge. Sie besitzen andere Eigentümer, Risiken, Kontexte, Aktualisierungszyklen und Qualitätsanforderungen.

Eine belastbare Localization-Architektur behandelt Inhalte deshalb nach Content Class. Jede Klasse erhält einen passenden Workflow.

Content Class 1: UI-Texte

UI-Texte sind kurz und hochgradig kontextabhängig.

Beispiele:

• „Speichern"
• „Buchen"
• „Zurück"
• „Antrag ablehnen"
• „Keine Ergebnisse gefunden"
• Validierungs- und Fehlermeldungen

Besondere Anforderungen

• Text muss in eine definierte Fläche passen.
• Variablen und Platzhalter dürfen nicht beschädigt werden.
• Begriffe müssen über die gesamte Anwendung konsistent sein.
• Tonalität muss zur Interaktion passen.
• Funktionsänderungen können die Bedeutung verändern.
• Übersetzung ist eng an Softwareversionen gebunden.

Sinnvoller Workflow

Textschlüssel + deutscher Quelltext + Komponenten-Kontext
→ Glossar und bestehende Übersetzung laden
→ KI-Übersetzung
→ formale Prüfungen
→ optional Screenshot-/Längenprüfung
→ Veröffentlichung mit Software-Release

Bei sehr kurzen, bekannten Texten kann eine automatische Freigabe sinnvoll sein. Neue oder mehrdeutige Begriffe benötigen Review.

Content Class 2: Systemkommunikation

Dazu gehören:

• E-Mails,
• Push-Nachrichten,
• Statusinformationen,
• Transaktionsbestätigungen,
• Hinweise zu Fehlern und Fristen.

Sie sind länger als UI-Texte und können geschäftlich sensibler sein.

Besondere Anforderungen:

• korrekte Platzhalter,
• konsistente Ansprache,
• verständliche Handlungsempfehlung,
• richtige Datums-, Zahlen- und Währungsformate,
• fachlich korrekte Prozesszustände,
• teilweise rechtliche Relevanz.

Hier ist die Risikoklassifikation wichtiger als die reine Textlänge.

Content Class 3: Redaktionelle Plattforminhalte

Beispiele:

• Hilfebereich,
• Onboarding,
• Landingpages,
• Wissensartikel,
• erklärende Produkttexte des Plattformbetreibers.

Besondere Anforderungen

• Tonalität und Markenstimme,
• Überschriftenstruktur,
• interne Verlinkung,
• Suchintention,
• redaktionelle Freigabe,
• Bildunterschriften und Metadaten,
• längere Lebensdauer.

Eine Segmentierung in Absätze oder strukturierte Contentblöcke ist sinnvoller als die Übersetzung eines großen HTML-Dokuments. Bestätigte Segmente können wiederverwendet werden.

Content Class 4: Von Anbietern erzeugte Inhalte

Beispiele:

• Produkttitel,
• Angebotsbeschreibungen,
• individuelle Bedingungen,
• Termin- und Ortsinformationen,
• Hinweise zur Durchführung.

Besondere Anforderungen

• sehr unterschiedliche Quellqualität,
• hohe Menge und Frequenz,
• Eigentum beim Anbieter,
• möglicher Missbrauch oder ungeeigneter Inhalt,
• Änderungen außerhalb des Produkt-Releasezyklus,
• unterschiedliche Relevanz je Sprache und Markt.

Der Workflow muss skalierbar sein. Gleichzeitig darf die Plattform nicht so tun, als habe sie jeden automatisch übersetzten Inhalt redaktionell geprüft.

Möglicher Prozess:

Quellinhalt speichern und versionieren
→ Sicherheits- und Strukturprüfung
→ KI-Übersetzung je aktiver Sprache
→ formale Qualitätsprüfung
→ Veröffentlichung oder Review nach Risikoklasse
→ Feedback und Korrekturen

Content Class 5: Strukturierte Produkt- und Fachwerte

Beispiele:

• Kategorien,
• Statuswerte,
• Einheiten,
• Attributnamen,
• Auswahloptionen,
• standardisierte Leistungsmerkmale.

Diese Inhalte wirken klein, sind aber für Filter, Suche und Logik zentral.

Sie sollten häufig über kontrollierte Wertelisten und Glossare übersetzt werden. Freie generative Übersetzung ist hier weniger wichtig als Konsistenz.

Beispiel:

source code:       booking_status.confirmed
Deutsch:           Bestätigt
Englisch:          Confirmed
Französisch:       Confirmée
Einfache Sprache:  Die Buchung ist bestätigt.

Die einfache Sprachfassung kann bewusst erklärender sein als die reguläre UI-Fassung.

Content Class 6: Einfache Sprache

Einfache Sprache ist kein normaler Übersetzungsfall. Ziel ist eine verständlichere Fassung derselben Information.

Besondere Anforderungen:

• kurze Sätze,
• direkte Handlungen,
• geringere Informationsdichte,
• konsistente Begriffe,
• Erklärung unvermeidbarer Fachwörter,
• keine Veränderung zentraler Rechte, Pflichten oder Fristen,
• eventuell anderes UI-Layout durch längere Erklärungen.

Der Prozess benötigt daher eine eigene Prompt- und Prüfstrategie. Eine reguläre deutsche Fassung darf nicht einfach mit „Schreibe leichter" verarbeitet und ungeprüft veröffentlicht werden.

Content Class 7: Rechtlich oder sicherheitsrelevante Inhalte

Diese Klasse kann sich mit anderen Klassen überschneiden.

Beispiele:

• Vertragsbedingungen,
• Widerrufs- oder Zahlungsinformationen,
• Sicherheitsanweisungen,
• Einwilligungstexte,
• regulatorische Hinweise.

Hier kann KI beim Entwurf und bei Konsistenzprüfungen unterstützen. Die finale Freigabe benötigt je nach Inhalt die zuständige Fach- oder Rechtsprüfung.

Der Workflow sollte verhindern, dass eine Quelländerung automatisch zu einer veröffentlichten Zielversion führt, ohne die notwendige Freigabe erneut anzufordern.

Ein gemeinsames Datenmodell, verschiedene Pipelines

Unterschiedliche Workflows bedeuten nicht, dass jede Content Class in einem isolierten System verwaltet werden muss.

Ein gemeinsames Translation-Objekt kann enthalten:

• Inhalts-ID,
• Content Class,
• Quellsprache,
• Quellversion,
• Zielsprachen,
• Kontext,
• Eigentümer,
• Risikoklasse,
• Übersetzungsstatus,
• Reviewanforderung,
• Veröffentlichungsstatus,
• Herkunft und Bearbeitungshistorie.

Anhand dieser Metadaten wird der passende Workflow gewählt.

Qualitätsprüfungen je Klasse

UI

• Platzhalter vollständig,
• Längenlimit,
• Glossarbegriffe,
• keine unzulässigen HTML-Änderungen.

Redaktion

• Struktur erhalten,
• Links und Metadaten korrekt,
• Tonalität,
• Suchbegriffe und Überschriften.

Anbieterinhalt

• Quelle nicht verfälscht,
• verbotene oder gefährliche Inhalte erkannt,
• Produkt- und Eigennamen erhalten,
• veraltete Zielversion sichtbar.

Einfache Sprache

• Satzlänge,
• direkte Verben,
• Begriffskonsistenz,
• Vollständigkeit der Aussage,
• keine unbeabsichtigte Bedeutungsverschiebung.

Rechtlich relevant

• verpflichtende Fachfreigabe,
• Version und Freigabezeitpunkt,
• Zielmarkt,
• keine automatische Veröffentlichung ohne Status.

Unterschiedliche Veröffentlichungsgeschwindigkeiten

Nicht jeder Inhalt muss auf alle Zielsprachen warten.

Mögliche Regeln:

• UI-Funktion wird nur in Sprachen aktiviert, deren kritische Texte vollständig sind.
• Anbieterinhalt erscheint zunächst in Quellsprache und erhält Übersetzungen asynchron.
• Redaktioneller Inhalt wird je Markt separat freigegeben.
• Einfache Sprache wird nur für definierte Kernprozesse angeboten.
• Rechtstext wird erst nach Freigabe veröffentlicht.

Diese Regeln sollten im System hinterlegt sein, nicht in manuellen Release-Checklisten verstreut bleiben.