KI-gestützte Softwarelokalisierung für Releases
Einführung
Viele Kunden wünschen sich JDisc Discovery auf Deutsch oder Französisch. Das ist nachvollziehbar: Network Discovery, Inventarisierung und Dokumentation sind anspruchsvolle Themen, und eine Oberfläche in der vertrauten Sprache erleichtert die tägliche Arbeit. Lange mussten wir diesen Wunsch jedoch zurückstellen. Nicht weil Lokalisierung unwichtig wäre, sondern weil der übliche Prozess nicht zu unserer Art passte, Software wöchentlich weiterzuentwickeln.
Die Ausgangslage
In unserem Java-Client standen viele sichtbare Texte direkt im Code, zum Beispiel editPanel.addLabelValue("Server hostname", hostnameHelpLabel, true);. Für eine herkömmliche Übersetzung hätten wir zunächst tausende dieser Stellen finden und in Sprachdateien überführen müssen. Danach wären die Dateien an einen Übersetzungsdienst gegangen, die Ergebnisse hätten geprüft und wieder in das Produkt integriert werden müssen.
Das hätte unseren Release-Zyklus ausgebremst. Da der Code am Freitag für den Sonntags-Release bereit sein muss, hätten geänderte Texte ungefähr am Mittwoch abgegeben werden müssen. Danach wären weitere Änderungen an den betroffenen Oberflächentexten kaum noch möglich gewesen. Für ein Team mit wöchentlichen Releases ist das eine spürbare Einschränkung.
Der klassische Ansatz mit ResourceBundles
Java-Anwendungen verwenden dafür häufig Property-Dateien und ResourceBundles. Statt des sichtbaren Textes enthält der Code einen Schlüssel. Die Sprachdateien enthalten für jeden Schlüssel eine Version pro Sprache:
ClientMainWindow.askResumeDisc=Do you really want to resume the discovery activity?ClientMainWindow.askResumeDisc=Möchten Sie die Discovery wirklich wieder aufnehmen?String outputString = resourceBundle.getString("ClientMainWindow.askResumeDisc");Das ist ein bewährter Ansatz. In einer bestehenden Anwendung entstehen aber praktische Nachteile: Entwickler sehen beim Lesen des Codes nicht mehr direkt, was in der Oberfläche angezeigt wird. Dynamisch zusammengesetzte Schlüssel sind schwer vollständig zu finden. Neue und geänderte Einträge müssen gezielt extrahiert, übersetzt und zurückgeführt werden. Und ein externer Übergabeschritt wird zu einer festen Abhängigkeit im Release-Prozess.
Ein direkt im Code sichtbarer UI-Text ist lesbar, hat aber keine Sprachvariante.
Die Abwägungen bei klassischen Sprachdateien
Die Lesbarkeit verlagert sich aus dem Code heraus
ResourceBundles trennen Code und Sprache sauber. Gleichzeitig ist eine Quelldatei weniger unmittelbar lesbar. Wenn Entwickler ClientMainWindow.askResumeDisc sehen, erkennen sie den angezeigten Text nicht, ohne eine weitere Datei zu öffnen und nach dem Schlüssel zu suchen. Bei einem Review ist das für jede geänderte sichtbare Formulierung eine zusätzliche Unterbrechung.
Bei tausenden Einträgen brauchen die Schlüssel außerdem eine Namenskonvention, die über viele Jahre verständlich bleibt. Das ist möglich, aber selbst eine dauerhafte Pflegeaufgabe.
Schlüssel lassen sich nicht immer einfach nachverfolgen
Eine vollständige Liste verwendeter Einträge zu pflegen, ist oft schwieriger als zunächst erwartet. Manche Anwendungen setzen Schlüssel dynamisch zusammen:
String clientWindowBaseKey = "ClientMainWindow";
String messageSubkey = "askResumeDisc";
String labelKey = clientWindowBaseKey + "." + messageSubkey;
String outputString = resourceBundle.getString(labelKey);Eine einfache Suche nach dem fertigen Schlüssel findet dann nicht mehr jede Verwendung. Das gilt ebenso für Hilfsmethoden, Konstanten oder unterschiedliche Module, die Schlüssel auf verschiedene Weise erzeugen. Die Herausforderung ist beherrschbar, aber automatische Vollständigkeitsprüfungen werden komplexer.
Geänderte und neue Texte brauchen einen eigenen Prozess
Für jeden Release möchten Sie nicht alle Texte erneut an einen Übersetzungsdienst senden. Sie müssen ermitteln, welche Einträge in der Mastersprache geändert wurden, nur diese extrahieren, übersetzen lassen und anschließend wieder in die Dateien der Zielsprachen integrieren. Für neue Einträge gilt ein ähnlicher Ablauf.
Versionierung hilft dabei, Dateiänderungen zu erkennen. Sie löst jedoch nicht automatisch die Arbeitsschritte davor und danach. Jeder Schritt kann dazu führen, dass ein Eintrag übersehen wird, eine Übersetzung nicht mehr aktuell ist oder ein Merge-Konflikt entsteht.
Der Release-Kalender wird zur Abhängigkeit
Für uns war vor allem der Zeitfaktor entscheidend. Auf ein externes Ergebnis zu warten, ist grundsätzlich kein falscher Prozess. In einem kurzen, aktiven Release-Zyklus passt er jedoch nicht gut, wenn sichtbare Texte noch spät in der Woche geändert werden können. Dann muss ein Team Texte früh einfrieren, eine Funktion verschieben oder akzeptieren, dass Übersetzungen hinter der englischen Version zurückbleiben.
Wir wollten einen Ablauf, mit dem das Team weiterarbeiten kann und Übersetzungen trotzdem ein fester Bestandteil des Produkts bleiben – nicht ein nachgelagerter Sonderfall.
Unser Ansatz mit Codex
Mit ChatGPT und Codex haben wir gelernt, wie wichtig präzise Aufgaben, Kontext und klare Regeln sind. Deshalb wollten wir nicht einfach „alles übersetzen“ lassen. Unsere Anforderungen waren eindeutig: Neue sichtbare Texte sollten erkannt werden, geänderte englische Texte eine neue Übersetzung auslösen, manuelle Anpassungen erhalten bleiben und interne Strings sicher ausgeschlossen werden.
Die Lösung verwendet ein Translations-Objekt. Es hält den englischen Mastertext und die Sprachvarianten zusammen. Jede Übersetzung erhält eine stabile UUID. Sie beschreibt den Text nicht; sie identifiziert genau diese Textstelle dauerhaft.
String translation = Translations.of("Configurations")
.id("efe093de-2eba-43ee-a69b-fb9a9f9dbc79")
.de("Konfigurationen")
.fr("Paramétrage");
String translatedText = translation.getLabel(Locale.getDefault());Fehlt eine Sprachvariante oder ist kein Locale gesetzt, liefert das Objekt den englischen Mastertext. So bleibt die Oberfläche verständlich statt leer.
Änderungen zuverlässig erkennen
Eine kleine Housekeeping-Datei speichert zu jeder ID einen sourceHash für den englischen Ausgangstext und einen targetHash für die zuletzt verarbeitete Übersetzung. Beim nächsten Lauf prüft der Skill: Ist der englische Text gleich geblieben, ist keine neue Übersetzung nötig. Hat er sich geändert, wird die passende Sprachvariante aktualisiert.
Der targetHash schützt zugleich manuelle Eingriffe. Weicht die Zielübersetzung vom gespeicherten Wert ab, behandelt der Prozess das als bewusste Änderung und überschreibt sie nicht automatisch.
Hashes unterscheiden unveränderte Texte, geänderte Mastertexte und manuell angepasste Übersetzungen.
Automatisierung mit klaren Grenzen
Der Skill sucht im Code nach noch fest kodierten, sichtbaren Texten, erstellt bei passenden Treffern die erforderliche Translations-Instanz und erzeugt die Übersetzungen. Entscheidend ist dabei, was er nicht verändert: interne Logmeldungen, Konstanten, Konfigurationswerte, Kennungen und andere Strings mit Programmfunktion bleiben ausgeschlossen. Im Zweifel lassen wir einen Text lieber zur Prüfung auf Englisch, statt Funktionalität zu gefährden.
Zusätzlich erzeugt der Prozess eine Markdown-Datei mit allen Übersetzungen. Sie ermöglicht eine schnelle fachliche Prüfung. Unsere Wissensdateien definieren die JDisc-spezifischen Regeln: Welche Begriffe werden übersetzt, welche etablierten englischen IT-Begriffe bleiben erhalten, und wann braucht ein Text mehr Kontext? So wird keine allgemeine Übersetzungsschicht erzeugt, sondern ein nachvollziehbarer Prozess für JDisc Discovery.
Ergebnis und Ausblick
Die Übersetzung ist heute kein mehrtägiger Übergabeschritt mehr. Neue oder geänderte UI-Texte werden erkannt und in Minuten nach den festgelegten Regeln verarbeitet. Hashes konzentrieren die Arbeit auf wirklich geänderte Einträge und schützen manuelle Verbesserungen. So konnten wir den vollständigen Prozess etablieren und die Software innerhalb von zwei Wochen übersetzen, ohne unseren wöchentlichen Release-Zyklus aufzugeben.
Als Nächstes möchten wir den gleichen Grundgedanken für unser in Strapi gepflegtes Benutzerhandbuch nutzen: englische Kapitel als Master, hash-basierte Erkennung von Änderungen, gezielte Übersetzung und einfache Prüfung.
Wenn Sie JDisc Discovery kennenlernen möchten, können Sie eine kostenlose Testversion herunterladen oder eine persönliche Demo buchen.
Warum der Prozess im Alltag funktioniert
Entscheidend war für uns nicht, ob ein Konzept für eine einmalige Übersetzungsaktion funktioniert. Es musste auch an einem normalen Entwicklungstag praktikabel sein. Ein Entwickler ändert vielleicht bei der Fehlerbehebung einen Dialog, ergänzt ein Feld in einer Konfiguration oder verbessert kurz vor einem Release einen Hinweis. Keine dieser Änderungen sollte daraus plötzlich ein eigenes Lokalisierungsprojekt machen.
Der Skill macht den vorgesehenen nächsten Schritt nachvollziehbar. Er findet die klar definierten Kategorien sichtbarer Texte, ergänzt oder aktualisiert die Übersetzungsstruktur und hält fest, warum eine Bearbeitung erforderlich war. Im Code Review kann sich das Team dann auf die wichtigen Fragen konzentrieren: Ist der Text tatsächlich für Anwender sichtbar? Ist der englische Ausgangstext eindeutig? Entspricht die deutsche oder französische Formulierung der Produktterminologie? Die wiederholbare Vergleichsarbeit übernimmt die Automatisierung; Verantwortung für Bedeutung und Qualität bleibt bei den Menschen.
Auch Ausnahmen lassen sich so sauber behandeln. Manche Begriffe sollen bewusst Englisch bleiben. Andere Strings sind so eng mit der Programmlogik verbunden, dass sie nicht automatisch verändert werden dürfen. Statt jedes Mal neu zu improvisieren, ergänzen wir eine klare Regel. Spätere Läufe wenden sie einheitlich an, und die Begründung bleibt im Repository nachvollziehbar.
Schritt für Schritt statt großer Umstellung
Die Übersetzung eines gewachsenen Produkts muss nicht als riskante Alles-oder-nichts-Migration stattfinden. Mit dem englischen Mastertext als Fallback können wir Lokalisierung schrittweise einführen. Fehlt eine Übersetzung, ist ein Locale nicht verfügbar oder wartet ein Eintrag noch auf Prüfung, bleibt die Oberfläche trotzdem verständlich und nutzbar.
Your Network, No Secrets!
Keine Geheimnisse mehr!. Keine bösen Überraschungen! Volle Transparenz in Ihrem Netzwerk!
Das gibt uns die Möglichkeit, Ergebnisse in ihrem tatsächlichen Produktkontext zu prüfen. Ein Begriff kann in einer Tabelle, einem Dialog oder einer Fehlermeldung unterschiedlich wirken. Die Markdown-Übersicht hilft dabei, Kandidaten schnell zu vergleichen; die Anwendung selbst zeigt, ob Länge, Ton und technische Genauigkeit stimmen. Werden Regeln oder Formulierungen verbessert, profitiert der nächste Lauf unmittelbar davon.
Was wir aus dem Projekt gelernt haben
Unser wichtigstes Lernziel war Präzision. Gute Ergebnisse entstehen nicht dadurch, dass eine KI möglichst viele Texte verändert. Sie entstehen dadurch, dass die Aufgabe klar eingegrenzt ist: sichtbare Texte erkennen, Produktregeln anwenden, Änderungen zuverlässig bestimmen und manuelle Entscheidungen respektieren. Je klarer diese Grenzen sind, desto besser lässt sich das Ergebnis prüfen.
Ebenso wichtig ist die Verbindung aus Automatisierung und Versionierung. Die Housekeeping-Datei wird mit dem Quellcode committed. Damit sind Änderungen nicht nur technisch verarbeitet, sondern später auch nachvollziehbar. Bei Fragen zu einer Übersetzung sehen wir, wann der englische Text geändert wurde, welche Sprachvariante dazugehört und ob eine manuelle Anpassung geschützt wurde.
Für uns ist das ein sehr praktischer Einsatz von KI in der Softwareentwicklung. Die KI ersetzt weder Produktkenntnis noch Review oder Engineering. Sie nimmt dem Team vor allem die wiederkehrenden Schritte ab, die sonst eine sinnvolle Verbesserung immer wieder verzögert hätten.
Zusammenarbeit zwischen Entwicklung und Übersetzung
Übersetzungen werden oft als nachgelagerte Aufgabe betrachtet: Zuerst wird die Funktion fertiggestellt, anschließend werden die Texte gesammelt und weitergegeben. In einem schnell entwickelten Produkt führt diese Trennung leicht zu Reibung. Die Person, die eine neue Einstellung oder einen Dialog entwirft, kennt den Zweck und die gewünschte Wirkung des Textes am besten. Kommt die Übersetzung erst Tage später in einem isolierten Dokument an, fehlt dieser Kontext häufig.
Mit der Translation-Instanz bleibt der Zusammenhang näher am Code. Englischer Master, ID und Sprachvarianten lassen sich gemeinsam nachvollziehen. Die Review-Datei bündelt zusätzlich die tatsächlichen Ergebnisse in einer lesbaren Form. Das ist keine Ablösung für sorgfältige sprachliche Prüfung, aber eine wesentlich bessere Grundlage dafür.
Auch für die Planung ist das hilfreich. Wir müssen nicht erraten, welche Property-Dateien in einem Release möglicherweise noch betroffen sind. Der Prozess ermittelt die relevanten Änderungen aus dem aktuellen Quellcode. Dadurch kann das Team bis zum regulären Code-Freeze weiterarbeiten, ohne dass ein externer Versandstermin die zweite Wochenhälfte blockiert.
Regeln sind ein Teil der Lösung
Ein Skill wird nicht dadurch zuverlässig, dass er möglichst breit formuliert ist. Gerade bei Source Code ist das Gegenteil sinnvoll: klare Positivregeln für sichtbare Texte und klare Ausschlüsse für technische Werte. Wir dokumentieren deshalb Begriffe, Schreibweisen und Ausnahmen in Wissensdateien. Dazu gehört auch die Entscheidung, wann ein englischer Begriff in der deutschen IT-Praxis präziser ist als eine wörtliche Übersetzung.
Diese Regeln machen das Ergebnis konsistent und verbessern sich mit jeder echten Ausnahme, die wir entdecken. Wenn beispielsweise ein String nur als Schlüssel, Protokollwert oder interne Statusinformation dient, wird er künftig nicht mehr versehentlich als UI-Text behandelt. So wächst die Automatisierung kontrolliert mit dem Produkt.
Ausblick auf Inhalte außerhalb des Clients
Die gleiche Idee eignet sich nicht nur für Labels. Unser Benutzerhandbuch enthält längere Kapitel, Bilder und strukturierte Hilfetexte. Dort ist die Prüfung sogar noch wichtiger, weil Kontext und Stil eine größere Rolle spielen. Trotzdem bleiben die Grundfragen identisch: Welche englische Quelle ist maßgeblich? Was hat sich seit der letzten Übersetzung geändert? Welche Zielversion wurde manuell verbessert und darf nicht überschrieben werden?
Mit Strapi als Headless CMS können wir diese Informationen strukturiert lesen und den gleichen Hash-Ansatz verwenden. Damit entsteht kein einmaliges Übersetzungsprojekt, sondern ein wartbarer Prozess für Produkt und Dokumentation.
Häufig gestellte Fragen
Diese Antworten erklären, wie unsere KI-gestützte Lokalisierung funktioniert und welche Schutzmechanismen sie zuverlässig machen.
Sie sind bewährt, hätten in unserem bestehenden Code aber eine große Umstellung und einen nicht passenden externen Übergabeprozess erfordert.
Sie identifiziert eine konkrete Textstelle stabil, auch wenn sich ihre Formulierung ändert.
Der sourceHash weicht ab; der Skill erkennt, dass die abhängigen Übersetzungen geprüft und aktualisiert werden müssen.
Nein. Ein abweichender targetHash signalisiert eine bewusste Anpassung.
Nein. Er arbeitet bewusst streng und übersetzt nur definierte, sichtbare Texte.
Über den Autor
