Resource Management ist ein Werkzeug zur Übersetzung von Texten in unterschiedliche Sprachen. Vielfach werden nicht nur GUI-Texte übersetzt, sondern auch Fehler- und Statusmeldungen aus dem Programmcode. Dieser Artikel beschreibt, wie grundsätzlich das Resource-Management für das GUI funktioniert und wie eine Lokalisierung für Code-Komponenten implementiert werden kann.
GUI Lokalisierung
WinRT bietet in Bereich GUI-Lokalisierung bereits heute zahlreiche Features an. So können die Texte im Ordner [WinRT GUI Projekt]\strings\[Sprach-Code] als resm-Files abgelegt werden. Die resm-Files sind im selben Format wie die aus .NET bekannten resx-Files aufgebaut.
Eine Referenz über die Sprach-Codes und deren Bedeutung findet sich unter https://docs.microsoft.com/en-us/previous-versions/windows/apps/hh965324(v=win.10).
Im WPF XAML-Code werden die Texte anschliessend mit x:Uid-Attribut eines beliebigen Controls referenziert. Der Compiler verknüpft anschliessend die Attribute des Controls mit den Texten aus dem referenzierten Sprach-File:
Die Sprachumschaltung zwischen den verschiedenen im \strings\ Ordner abgelegten Sprachen kann über die Systemsteuerung -> Sprache getestet werden.
Die WPF Lokalisierung ist in der MSDN unter https://docs.microsoft.com/en-us/previous-versions/windows/apps/hh965329(v=win.10) detailliert beschrieben.
Der eigene Weg für Code-Lokalisierung
Weniger zahlreich sind die gebotenen Features im Bereich Code-Lokalisierung. Hier muss für eine wartbare Lösung selbst Hand angelegt werden, da, die aus dem .NET bekannten resx-Files, mit dem Compile Time Code Generator den Weg ins WinRT noch nicht gefunden haben. Daher ist hier ein möglichst .NET ähnlicher Weg anzustreben, da anzunehmen ist, dass entsprechende Features zu einem späteren Zeitpunkt noch nachgeliefert werden.
Dabei stellt sich die Frage, warum Code-Fragmente wie beispielsweise Fehlermeldungen überhaupt lokalisiert werden, da die englische Version der Meldung zumeist weit aussagekräftiger ist. Die Antwort darauf ist ähnlich wie bei der Benutzerschnittstelle: Auch Fehlermeldungen bergen das Risiko, bis zum Benutzer vorzudringen. Gerade bei wiederverwendeten Komponenten sollten die Texte also in separaten Files abgelegt werden, da Apps für verschiedene Sprachen und Regionen erstellt werden können.
Der einfachste Weg, die Code-Resourcen zu implementieren ist das Anlegen eines resm-Files und anschliessendes referenzieren über den Resource-Manager. Dies geschieht beispielsweise wie folgt:
Dies hat allerdings zum Nachteil, dass die Resources über Strings lose an die Eigenschaft im resm-File gebunden werden. Bei einem Rename der Resource von resourceToFind auf resourceToRetrieve muss an allen Stellen im Programm-Code per Search & Replace der String “Resources/resourceToFind” ersetzt werden. Falls nur eine Stelle vergessen wird, kann das Programm zur Laufzeit abstürzen.
Aus diesem Grunde ist es empfehlenswert, die Resourcen möglichst typisiert und automatisiert aus dem resm-File auszulesen und in ein Code-File als Property zu übertragen. Dies wird mittels Visual Studio .tt (T4) Templates erreicht. Sie finden eine Auflistung der T4-Template-Möglichkeiten unter https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/modeling/design-time-code-generation-by-using-t4-text-templates. Das folgende C# Code-Schnipsel des Templates stellt dies sicher:
Die Resourcen werden aus dem angegebenen ReswFile geladen und damit anschliessend die C# Properties generiert. Die Variable resources muss im Vorfeld, wie im Resource-Manager Beispiel oben beschrieben, belegt werden:
Der einzige Nachteil dieser Lösung ist, dass der Entwickler den Template-Run manuell ausführen muss:
Mehr Informationen über das Resource-Management in WinRT können Sie unter https://docs.microsoft.com/en-us/previous-versions/windows/apps/jj552947(v=win.10) nachlesen.
Fazit
WinRT bietet eine gute Lokalisierung im UI Bereich. Für die Lokalisierung des Programm-Codes muss sich der Entwickler selbst eine Lösung suchen, da die gebotenen Features noch nicht vollständig dem heutigen .NET Standard entsprechen.
Das Beispiel oben hat aufgezeigt, dass das Nachrüsten der Code-Lokalisierung keine grossen Aufwände mit sich bringt. Das Template-File einmalig mit minimalem Aufwand zu erstellen ist sicherlich eine lohnenswerte Investition – in der Hoffnung, dass beim nächsten WinRT Release eine ausgereifte Code-Lokalisierung mitgeliefert wird.