Windows und Unternehmenssoftware international ausrollen: UI, Hilfe und Dokumentation konsistent lokalisieren
-
Dr. Windows
- 16. September 2026
Ein belastbarer Lokalisierungsprozess verbindet Ressourcen, Terminologie, Kontextprüfung und Versionspflege – statt Oberfläche und Begleittexte getrennt zu behandeln.
Ein internationaler Rollout scheitert selten an einem einzelnen falsch übersetzten Wort. Problematisch wird es, wenn dieselbe Funktion in Menü, Fehlermeldung, Knowledge Base und Handbuch unterschiedlich heißt oder Platzhalter beschädigt werden. Deshalb beginnt Lokalisierung nicht mit dem Übersetzen einzelner Dateien, sondern mit einer Bestandsaufnahme aller sichtbaren und unterstützenden Texte.
Alle Sprachbausteine gemeinsam erfassen
Zum Umfang gehören typischerweise:
- UI-Texte aus Menüs, Dialogen und Schaltflächen
- Fehlermeldungen, Systemhinweise und technische Codes
- Artikel, Suchbegriffe und Kategorien der Knowledge Base
- Installations-, Admin- und Anwenderdokumentation
- Glossar, Schreibregeln und nicht zu übersetzende Produktnamen
Ein gemeinsames Glossar gibt die bevorzugten Benennungen vor. Änderungen erscheinen dadurch jedoch nicht automatisch überall: Sie müssen versioniert, in den betroffenen Dateien nachgeführt und anschließend geprüft werden. Genau diese Zuständigkeiten gehören in den Release-Prozess.
Quelltext und Sprache sauber trennen
Lokalisierbare Strings sollten getrennt vom ausführbaren Code verwaltet werden. Für .NET beschreibt Microsoft das Prinzip und den Einsatz von RESX-Dateien in der offiziellen Dokumentation zur Lokalisierung. Je nach Produkt kommen außerdem Formate wie XLIFF oder strukturierte JSON-Ressourcen infrage. Entscheidend ist, dass Schlüssel, Variablen, Markup und Zeichenbegrenzungen eindeutig dokumentiert sind.
Translation Memory und Terminologie
Ein Translation Memory schlägt bereits übersetzte Segmente erneut vor; ein Glossar legt fest, welche Fachbegriffe verwendet oder ausdrücklich vermieden werden. Beides verbessert Konsistenz und kann Wiederholungsaufwand reduzieren. Die Vorschläge müssen dennoch zum aktuellen Kontext, zur Zielgruppe und zur jeweiligen Softwareversion passen.
In-Context-QA vor dem Go-live
Die sprachliche Prüfung in der laufenden Anwendung deckt Fehler auf, die in einer Tabelle unsichtbar bleiben: abgeschnittene Schaltflächen, falsche Bezüge, defekte Variablen oder unpassende Zeilenumbrüche. Einen ergänzenden Überblick über typische technische Schritte bietet ein Entwicklerleitfaden zur Softwarelokalisierung. Vor der Freigabe sollten zusätzlich Platzhalter, Links, Zahlenformate, Datumsangaben und Suchbegriffe systematisch getestet werden.
Knowledge Base und Handbuch im selben Release führen
Wenn die Oberfläche aktualisiert wird, müssen Hilfetexte, Screenshots und Schrittfolgen denselben Stand abbilden. Schon kleinere UI-Änderungen können Beschreibungen entwerten – etwa wenn sich ein Bedienelement verschiebt oder ausblenden lässt, wie die DrWindows-Anleitung zum Bing-Button in Edge zeigt. Sinnvoll sind daher gemeinsame Release-IDs, verantwortliche Content-Owner und ein dokumentierter Abgleich zwischen Produkt und Hilfe.
Wann professionelle Fachübersetzung sinnvoll ist
Bei sicherheitsrelevanten Hinweisen, komplexer Fachterminologie oder vielen Zielsprachen können professionelle Fachübersetzungen den internen Prozess ergänzen. Wichtig sind ein projektbezogenes Glossar, die kontrollierte Nutzung von Translation Memories und eine qualifizierte Schlussprüfung. Ein Anbieter sollte außerdem offenlegen, welche Qualitätssicherung im Angebot enthalten ist und ob maschinelle Übersetzung oder generative KI eingesetzt wird. Bei Fachübersetzungsdienst können Auftraggeber deren Einsatz ausschließen; das Unternehmen ist bei DIN CERTCO für ISO 17100 registriert.
Updates dauerhaft beherrschbar machen
Mit dem Go-live beginnt die Sprachpflege. Für jedes Update sollte feststehen, welche Strings neu, geändert oder entfallen sind und welche Hilfeartikel betroffen sind. Translation Memories können identische oder ähnliche Segmente markieren, übernehmen aber nicht die Verantwortung für die Freigabe. Aufwand und Termine hängen unter anderem von Änderungsmenge, Dateiformat, Sprachpaar, Kontextzugang und Prüfumfang ab.
- Änderungen aus dem Quellsystem exportieren und eindeutig versionieren.
- Glossar und nicht zu übersetzende Elemente vor der Bearbeitung aktualisieren.
- Übersetzung mit Kontextinformationen, Screenshots und Zeichenlimits bereitstellen.
- Automatisierte Prüfungen und sprachliche In-Context-QA durchführen.
- Freigegebene Ressourcen gemeinsam mit Knowledge Base und Dokumentation veröffentlichen.
So bleibt Konsistenz kein einmaliges Versprechen, sondern ein überprüfbarer Bestandteil jedes Releases.
Häufig gestellte Fragen
Welche typischen Fehler passieren beim internationalen Windows-Rollout ohne erfahrenes Lokalisierungsteam?
Ein häufiger Fehler ist das Übersetzen von Strings ohne Kontext, wodurch Begriffe je nach Sichtbarkeit im Dialogfeld unterschiedlich interpretiert werden. Ebenso wird oft vergessen, Platzhalter-Variablen und Zeichenlimits in kürzeren oder längeren Zielsprachen wie Deutsch oder Finnisch zu testen, was zu abgeschnittenen Buttons führt. Auch die Versionierung zwischen Software-Build und Übersetzungsdatei gerät ohne festen Prozess schnell aus dem Takt.
Wie lange dauert es, bis eine neue Sprachversion für ein bestehendes Softwareprodukt produktionsreif ist?
Für eine bereits etablierte Software mit gepflegtem Glossar und Translation Memory rechnet man je nach Umfang mit zwei bis sechs Wochen bis zur ersten testbaren Sprachversion. Entscheidend ist dabei weniger die reine Übersetzungszeit als die Abstimmungsschleifen mit lokalen Reviewern und das anschließende Linguistic Testing in der Zielumgebung. Wird ein neues Land völlig frisch angebunden, verlängert sich der Zeitraum durch den Aufbau der Terminologie oft deutlich.
Wie erkennt man, ob die eigene Software überhaupt bereit für einen internationalen Rollout ist?
Ein guter Indikator ist, ob die Codebasis bereits nach dem I18n-Prinzip aufgebaut ist, also Texte vollständig von der Programmlogik getrennt sind und keine hartcodierten Strings im Quellcode stecken. Zusätzlich sollte man prüfen, ob Datum-, Zeit- und Zahlenformate regionsabhängig umschaltbar sind und ob die Oberfläche auch mit deutlich längeren Textlängen, wie sie etwa im Deutschen oder Russischen entstehen, stabil bleibt. Fehlt diese technische Basis, sollte sie vor der eigentlichen Übersetzungsphase nachgerüstet werden.
Wo finde ich einen Dienstleister, der den kompletten Lokalisierungs-Workflow für Windows-Software inklusive Terminologiepflege übernimmt?
Wer die im Artikel beschriebenen Schritte nicht mit eigenem Personal abdecken will, kann auf spezialisierte Anbieter zurückgreifen, die den Lokalisierungs-Workflow für UI‑Texte und KB von der String-Extraktion bis zum fertigen mehrsprachigen Release routiniert begleiten. Fachübersetzungsdienst GmbH übernimmt dabei sowohl die technische Formatarbeit mit RESX- oder XLIFF-Dateien als auch die konsistente Pflege des Glossars über Software, Hilfecenter und Dokumentation hinweg. So bleibt die Terminologie über alle Sprachversionen synchron, ohne dass eine eigene Lokalisierungsabteilung aufgebaut werden muss.
Was kostet die Lokalisierung von Unternehmenssoftware im internationalen Rollout ungefähr?
Die Kosten hängen stark vom Textvolumen, der Anzahl der Zielsprachen und dem Wiederholungsgrad der Strings ab. Bei sauber gepflegten Translation-Memory-Systemen sinken die Kosten pro Wort mit jedem weiteren Rollout, da bereits übersetzte Segmente wiederverwendet werden. Realistisch sollte man für die Erstlokalisierung einer mittelgroßen Software mit mehreren tausend Euro pro Sprache kalkulieren, Folgeversionen sind deutlich günstiger.
Thema:
- News
