Eine Anwendung besteht alle Bereitstellungsprüfungen in der englischen Version. Bedeutet das, dass auch die deutsche, französische oder spanische Version einsatzbereit ist? Nicht unbedingt. Lokalisierte Anwendungsversionen können sich bei Paketidentität, Ressourcen, Upgrade-Verhalten und Datenverarbeitung unterscheiden. Wer nur eine Sprache testet, übersieht möglicherweise wichtige Bereitstellungsrisiken.
Lokalisierte Anwendungsversionen sind mehr als übersetzte Benutzeroberflächen
Lokalisierung wird häufig auf Änderungen an Menüs, Schaltflächen und Meldungen reduziert. Anbieter können lokalisierte Anwendungsversionen jedoch über separate Installationsprogramme, Sprachtransformationen, optionale Sprachpakete oder mehrsprachige Pakete bereitstellen.
Jedes Bereitstellungsmodell führt zu einem anderen Ergebnis. Ein separates Installationsprogramm kann andere Dateien oder benutzerdefinierte Aktionen enthalten. Eine Transformationsdatei verändert die Installationsdatenbank. Ein Sprachpaket muss mit der Basisanwendung kompatibel bleiben, während ein mehrsprachiges Installationsprogramm die richtigen Ressourcen auswählen muss.
Die Versionsnummer kann gleich bleiben, doch das Paket, das den Endpunkt erreicht, ist nicht immer identisch.
Die Identität des Installationspakets kann sich je nach Sprache ändern
Besonders relevant werden diese Unterschiede bei Windows-Installer-Paketen. Laut Microsofts Richtlinien gilt ein vollständig lokalisiertes MSI-Paket als eigenständiges Produkt. Die englische und die deutsche Version können unterschiedliche ProductCodes, PackageCodes, Sprachkennungen, Dateien und Registrierungsressourcen aufweisen.
Das beeinflusst, wie Unternehmens-Tools lokalisierte Anwendungsversionen verwalten. Intune kann einen MSI-ProductCode zur Erkennung verwenden, ebenso wie Configuration Manager. Wird eine für das englische Paket erstellte Erkennungsregel für ein deutsches Paket mit einem anderen ProductCode wiederverwendet, kann die Installation erfolgreich sein, während die Verwaltungsplattform die Anwendung als fehlend meldet.
Auch Sprachmetadaten können Upgrades beeinflussen. Windows Installer berücksichtigt sie bei der Suche nach verwandten Produkten, während Dateiersetzungsregeln neben Version und Datum auch die Sprache einbeziehen. Ein erfolgreiches Upgrade einer englischen Version auf eine neuere englische Version belegt nicht, dass ein Upgrade der deutschen Version oder ein Wechsel zwischen Sprachen korrekt funktioniert.
Die Paketprüfung muss daher für jedes eigenständige Bereitstellungsartefakt die Erkennung, Reparatur, Aktualisierung, Ersetzung und Deinstallation abdecken.
Regionale Einstellungen können das Anwendungsverhalten verändern
Einige der schwerwiegendsten Lokalisierungsfehler treten erst nach der Installation auf. Anwendungen verwenden Ländereinstellungen, um Datumsangaben, Zahlen, Währungen, Zeitzonen und Kalender zu interpretieren. Beim Sortieren, Suchen oder Vergleichen von Text können zudem sprachspezifische Regeln gelten.
Das Datum „04/05/2026“ kann beispielsweise sowohl den 4. Mai als auch den 5. April bezeichnen. Ein Komma kann in einer Ländereinstellung als Dezimaltrennzeichen und in einer anderen als Feldtrennzeichen in CSV-Dateien dienen. Werden Ländereinstellungen nicht korrekt verarbeitet, kann ein Import oder Export, der bei Tests in englischer Sprache funktioniert hat, unter einer anderen Ländereinstellung fehlschlagen.
Bei der Textverarbeitung bestehen ähnliche Risiken. Microsoft nennt das türkische „I“ mit und ohne Punkt als Beispiel: Vergleiche ohne Beachtung der Groß- und Kleinschreibung, die im Englischen funktionieren, können unter der türkischen Ländereinstellung zu anderen Ergebnissen führen. Dies kann die Suche, Validierung, Dateiverarbeitung und sogar sicherheitsrelevante Entscheidungen beeinflussen.
Diese Probleme betreffen die Funktion, nicht die Übersetzung. Eine reine Übersetzungsprüfung deckt sie nicht auf.
Unterschiedliche Sprachen stellen unterschiedliche Anforderungen an die Benutzeroberfläche
Lokalisierte Anwendungsversionen benötigen in der Benutzeroberfläche unterschiedlich viel Platz und können deren Struktur verändern. Übersetzte Texte können länger sein als das Original. Diakritische Zeichen können abgeschnitten werden. Aus übersetzten Textbausteinen zusammengesetzte Meldungen können eine falsche Wortreihenfolge aufweisen, während Pluralregeln mehr Formen erfordern können, als das Original unterstützt.
Bei Benutzeroberflächen für von rechts nach links geschriebene Sprachen müssen Navigation, Reihenfolge der Steuerelemente, Symbole und Übergänge möglicherweise gespiegelt werden. Inhalte mit gemischter Schreibrichtung werden komplexer, wenn ein Satz eine URL, einen Dateipfad, eine Versionsnummer oder einen Produktcode enthält.
Versionen für komplexe Schriftsysteme benötigen eine geeignete Glyphenabdeckung, Unterstützung für Eingabemethoden-Editoren (IME) sowie die korrekte Verarbeitung von Zeichen in voller und halber Breite. Tests in der Ausgangssprache decken diese Verhaltensweisen nur selten ab.
Ein übersetzter Bildschirm kann korrekt aussehen, obwohl seine barrierefreien Namen weiterhin in der Ausgangssprache vorliegen. Falsche Sprachmetadaten können die Aussprache durch Screenreader beeinträchtigen, während ein gespiegeltes Layout die Fokusreihenfolge bei der Tastaturbedienung stören kann.
Die Testumgebung ist ebenso wichtig wie das Installationspaket
Wird nur die Sprache innerhalb der Anwendung geändert, entsteht dadurch noch kein vollständig lokalisierter Endpunkt. Anwendungssprache, Windows-Anzeigesprache, regionales Format, Tastatur, Zeitzone und Systemgebietsschema lassen sich unabhängig voneinander konfigurieren.
Das ist besonders bei älteren Anwendungen relevant. Windows verwendet das Systemgebietsschema, um Codepages und Schriftarten für Nicht-Unicode-Programme auszuwählen. Eine Anwendung kann daher fehlerhafte Zeichen anzeigen oder einen Pfad falsch verarbeiten, obwohl ihre Benutzeroberfläche während der Tests normal aussah.
Auch moderne Pakete sind von der Umgebung abhängig. Windows kann MSIX-Sprachressourcen entsprechend der Gerätekonfiguration herunterladen. Ist keine passende Ressource verfügbar, verwendet die Anwendung möglicherweise ihre Standardsprache. Ein englischer Endpunkt lädt unter Umständen niemals die Ressourcen, die auf anderen Geräten zum Einsatz kommen.
Was sollte bei lokalisierten Anwendungsversionen separat getestet werden?
Beim Testen lokalisierter Anwendungsversionen muss nicht immer jeder Test von Anfang an wiederholt werden. Der Umfang sollte sich vielmehr danach richten, wie stark sich die lokalisierten Artefakte unterscheiden.
Jedes separate Installationsprogramm, jede Transformationsdatei und jedes Sprachpaket sollte auf Folgendes geprüft werden:
- unbeaufsichtigte Installation und korrekte Rückgabecodes;
- Paketerkennung in Intune oder Configuration Manager;
- installierte Dateien, Dienste, Verknüpfungen und Registrierungseinträge;
- erster Start im vorgesehenen Benutzerkontext;
- Upgrade von der aktuell bereitgestellten Version;
- Reparatur, Rollback und Deinstallation;
- Ressourcenauswahl und Fallback-Verhalten.
Jede Sprache sollte gezielt funktional, visuell und sprachlich sowie auf Barrierefreiheit geprüft werden. Kritische Arbeitsabläufe sollten Texteingabe, Suche, Dateiverarbeitung, Importe, Exporte und lokalisierte Fehlermeldungen abdecken.
Auch sprachübergreifende Szenarien sind relevant. Können Benutzer Daten öffnen, die in einer anderen Sprache erstellt wurden? Lässt sich ein neues Sprachpaket korrekt installieren? Kann eine englische Installation auf eine lokalisierte Version aktualisiert werden? Ein Test in nur einer Sprache kann diese Fragen nicht beantworten.
Separate Tests bedeuten nicht, alles doppelt zu prüfen
Mit einer risikobasierten Strategie bleibt der Prozess überschaubar. Wenn lokalisierte Anwendungsversionen dieselben signierten Binärdateien verwenden und sich nur bei den Ressourcen unterscheiden, können Teams die gemeinsame funktionale Testsuite automatisieren und jede Sprache gezielt validieren.
Umfangreichere Tests sind gerechtfertigt, wenn ein Anbieter unterschiedliche Installationsprogramme, ProductCodes, benutzerdefinierte Aktionen oder Voraussetzungen bereitstellt. Dasselbe gilt für Anwendungen, die regionale Daten verarbeiten, von veralteten Codepages abhängen oder kritische Arbeitsabläufe unterstützen.
Ein erfolgreich getestetes Paket kann nicht alle Sprachen, Konfigurationen und Upgrade-Pfade abbilden. Behandeln IT-Teams lokalisierte Anwendungsversionen als eigenständige Bereitstellungsanforderungen, können sie Fehler bei der Erkennung, fehlgeschlagene Updates, unlesbare Benutzeroberflächen und Datenfehler verhindern, bevor Benutzer davon betroffen sind.
Mit Apptimized Care können IT-Teams Patches für die benötigten Anwendungssprachen über einen zentralen Workflow anfordern. Apptimized bereitet jede erforderliche Sprachversion vor, sodass regionale Updates nicht mehr separat beschafft, paketiert und verwaltet werden müssen. So können Unternehmen Anwendungen in mehrsprachigen Umgebungen sicher und auf dem neuesten Stand halten, den manuellen Aufwand reduzieren und über den gesamten Anwendungslebenszyklus hinweg die Kontrolle behalten.
Möchten Sie Anwendungspaketierung, Tests, Patchmanagement und Bereitstellung in Ihrem gesamten Unternehmen vereinfachen? Vereinbaren Sie eine Demo mit unserem Spezialisten.
Author
Maryna Semesenko