Internationalisierung von Silverlight-Anwendungen

by Gregor Biswanger 27. Juli 2009 17:14

Ein ansehnlicher Aspekt des Internets ist das große Publikum das Weltweit erreicht werden kann. Auch Intranet oder Extranet Lösungen werden oft aus verschiedenen Ländern international Konsumiert. Worauf es auch recht oft zu der Anforderung kommt, dass die jeweilige Website ebenfalls auf deren Ländersprache zur Verfügung gestellt wird.

Während die Lokalisierung bei WPF Anwendungen nicht wirklich sauber durchdacht worden ist, verhält sich das bei Silverlight Anwendungen doch noch um einiges einfacher. Es verhält sich gewissermaßen ähnlich zu ehemaligen WinForms Anwendungen. Es unterscheidet sich nur mit etwas aufwändigeren Konfigurationen und das jeder Text mittels Data-Binding auf eine Ressource gebunden wird.

Dabei müssen grob folgende Schritte fabriziert werden: 

- Visual Studio Projektdatei durch gewünschte Spracherweiterungen konfigurieren.
- Ressource-Dateien anlegen für die jeweils gewünschte Sprache.
- Zentralle Ressource-Datei in der Application als allgemeine Ressource Initialisieren.
- beliebiger Text mit der Ressource Binden.

Um die jeweiligen Schritte im Detail folgen zu können, soll nun ein Beispielprojekt für einen besseren Überblick verhelfen.

Beispielanwendung

Erst muss mit Visual Studio ein neues Silverlight Projekt angelegt werden, hier im Beispiel wird der Name „SilverlightLocalizationExample“ verwendet. Um eine bessere Übersicht zu bekommen wurden Projektverzeichnisse mit Client und Server angelegt. Als erster Schritt muss das Silverlight Projekt ungeladen werden, damit die Projektdatei in Visual Studio editiert werden kann. Dazu ein rechtsklick auf die Silverlight Anwendung und auf „Unload Project“ klicken. Nach dem entladen kann mit wiederholten rechtsklick die Projektdatei mittels „Edit SilverlightLocalizationExample.csproj“ bearbeitet werden.


Abb.1.1. – Bearbeiten der Silverlight Projektdatei.

Jetzt wird die Projektdatei durch das SupportedCultures-Element erweitert. Dabei werden hier als Wert alle gewünschten Sprachen mit einem Komma getrennt angegeben. Hier im Beispiel wird Deutsch und Englisch definiert.


Abb.1.2. – SupportedCultures-Element definieren.

Danach wird das Projekt wieder in Visual Studio geladen. Das geht durch wiederholten rechtsklick auf das Projekt und anschließend auf „Reload Project“. Das Projekt wurde nun auf die beiden Sprachen Deutsch und Englisch erfolgreich eingestellt. Für jede Sprache muss jetzt eine Ressource-Datei angelegt werden, sowohl aber auch eine Zentralle Ressource-Datei oft Satellitenassembly genannt. Die Satellitenassembly koordiniert später vollautomatisch die erkannte Sprache des Browsers mit der vorhandenen Resource-Datei. Sollte es für die gewünschte Sprache keine Ressource-Datei geben, wird der Standard-Wert der Satellitenassembly verwendet.

Im Projekt wird ein neues Verzeichnis mit den Namen „LanguageResources“ angelegt, obwohl hierbei der Name frei gewählt werden kann. Dem neuen Verzeichnis werden Ressource-Dateien mittels neuen Items hinzugefügt. Die Namen der Ressource-Dateien kann auch frei gewählt werden. Wichtig! Es muss jeweils am Ende des Namens die Kultur getrennt durch punkte angegeben werden. Ansonsten erkennt später die Satellitenassembly die erwünschte Datei nicht. Die Satellitenassembly selbst bekommt einfach den Standardnamen ohne Kulturangabe.


Abb.1.3. – Ressource-Datei für die Sprache Deutsch anlegen.

Wenn die Ressource-Dateien angelegt wurden, muss die gewünschte Zugriff Bestimmung definiert werden. Dazu muss nur gesagt sein, dass die Satellitenassembly auch als Assembly verarbeitet werden soll und die anderen Ressource-Dateien keine Code-Generation benötigen. Mit einem doppelklick auf die Satellitenassembly wird oben bei „Access Modifier“ der Wert „Public“ gewählt. Alle anderen Dateien müssen auf „No code generation“ gesetzt sein.


Abb.1.4. – Satellitenassembly definieren.

Wenn alles richtig angelegt und definiert wurde, sollte das Projekt wie in Abb.1.5 aussehen.


Abb.1.5. – Die angelegten Ressource-Dateien.

Das Projekt verfügt jetzt um eine Lokalisierungserweiterung. Damit die Anwendung selbst auch auf die Satellitenassembly zugriff bekommt, muss man dessen Code-Behind-Datei anpassen. Den ein bis Visual Studio 2008 mitgelaufener Bug verhindert den Zugriff von außen. Den Visual Studio ändert automatisch nach jedem anpassen der Satellitenassembly den Zugriffsmodifizierer des Constructors auf Internal. Dieser muss leider jedesmal manuell auf Public gesetzt werden.


Abb.1.6. – Den Constructor der Satellitenassembly auf Public setzen.

Um das besser zu Demonstrieren wird in jeder Ressource-Datei ein Label mit „Hallo Welt!“ geschrieben. Angefangen mit der Datei „StringLibrary.de-DE.resx“. Das Label bekommt den Namen „Page_label01“, das für alle anderen Dateien gleichermaßen verwendet werden muss. Als Wert tagen wir „Hallo Welt!“ ein. Dasselbe machen wir auch in der Datei „StringLibrary.en-GB.resx“ nur eben mit dem Text „Hello World!“. In der Sattelitenassembly kommt als Standard der Text „hallo welt“. Der Text wird verwendet, wenn es keine Ressource-Datei für eine andere Sprache gibt.  


Abb.1.7. – Erstes Label mit Text vergeben.

Wenn das Projekt jetzt neu gebuildet wird, zum Beispiel mit der Tastenkombination [Strg] + [Shift] + [ B ], wird automatisch der Constructor auf Internal gesetzt. Dann müssen die Schritte, die weiter oben beschrieben wurden, wiederholt werden.

Das wären jetzt alle Grundlegenden Schritte die gemacht werden mussten. Damit der Text über Data-Binding gebunden werden kann, muss für die komplette Anwendung unter App.xaml die Sattelitenassembly als Statische Ressource bekannt geben (siehe Abb.1.8.).


Abb.1.8. – Sattelitenassembly als Statische Ressource initialisieren.

In der MainPage.xaml wird noch ein TextBlock mit dem Data-Binding angelegt. Dabei wird definiert welcher Label angezeigt werden soll und das die Daten in der statischen Ressource zu finden sind. 


Abb.1.9. – TextBlock mit der Sattelitenassembly binden.

Beim Starten der Anwendung wird zufriedengebend das Ergebnis mit „Hallo Welt!“ präsentiert. Das bedeutet, dass durch meinen Browser mein Deutsches Betriebssystem erkannt wurde.


Abb.1.10. – Der Test im Browser.

Sprache zur Laufzeit wechseln

Das sieht schon sehr gut aus! Was aber wenn die Anwendung gewollt während der Laufzeit in einer anderen Sprache geladen werden soll? Das ist ganz einfach, dafür wurde die MainPage.xaml mit einem StackPanel und einem Button erweitert. Der Button hat zudem ein Klick-Event.


Abb.2.1. – MainPage.xaml mit dem Button „Englisch“ erweitern.

Die Sattelitenassembly verfügt nun über ein öffentliches Property das die erkannte Kultur enthält. Dieses muss einfach manuell manipuliert werden. Anschließend muss der TextBlock den Text aktualisieren. Dazu wird im LayoutRoot, das Grid auf höchster Ebene in der MainPage.xaml, komplett geleert. Eine neue Initialisierung der MainPage wird dann mittels „Add“ hinzugefügt.


Abb.2.2. – Source-Code des Buttons in der Code-Behind.

Ein weiterer Test beeindruckt mit der stabilen Funktionalität. Mit einem Klick auf den Button wird sofort der Text auf Englisch angezeigt.


Abb.2.3. – Der Test im Browser.

Fazit

Es ist zufriedenstellend das hier die Lokalisierung etwas einfacher verläuft wie unter WPF Anwendungen. Doch leider ist das stätige abändern des Contructors der Sattelitenassembly auf Public etwas Fehleranfällig. Sobald es einmal vergessen wurde, kann eine Stundenlage Fehleranalyse folgen, ohne dass dabei an die Ressourcen-Datei gedacht wird.

Nichtsdestotrotz wird gleichmäßig eine Lösung geboten und läuft zudem anständig und stabil.



Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
kick it on dotnet-kicks.de

Kommentare

Powered by BlogEngine.NET 1.4.5.0
Theme by Extensive SEO

Über den Autor

Gregor Biswanger

Microsoft MVP für Client App Dev
XING

Gregor Biswanger (Microsoft MVP für Client App Dev) ist freier Consultant, Trainer, Autor und Speaker.


Seine Schwerpunkte liegen im Bereich der .NET-Architektur, agilen Prozessen und XAML. Er veröffentlichte vor kurzem seine DVD´s mit Video-Trainings zum Thema „Meine erste Windows 8 App“, „Windows Store Apps mit XAML und C#“ und „WPF 4.5 und Silverlight 5“ bei Addison-Wesley von video2brain.


Biswanger ist auch im Auftrag von Intel GmbH als Technologieberater für die Intel Developer Zone aktiv und ist Leader bei der Ingolstädter .NET Developers Group (INdotNET). 

 

Video über mich:
http://www.youtube.com/watch?v=mx_6SiiLxjk


Basta! 2011 Speaker

CLIPer

MCTS
Windows SharePoint Services 3.0 – Application Development (MCTS)