ASP.NET MVC I18n – Teil 10: Finale

7. März 2014

Das war’s. Die komplette Übersicht über die Lokalisierung von ASP.NET MVC basierten Anwendungen.

Hinweis: Dieser Beitrag ist Teil einer Serie, die Übersicht findet sich hier.

 

 

 

Hier sind die Themen im Kontext dargestellt (im Bild sind Links zum jeweiligen Beitrag hinterlegt):

Lokalisierung-a-Overview-de

Eine ganze Menge Stoff für eine Standardanforderung…

 

… und trotzdem gibt es Dinge, die ich nicht betrachtet habe.

right-to-left.

Das ist in der Tat die eine Lücke bei der Betrachtung von Lokalisierung, die ich mir erlaubt habe. Der Grund dafür ist einfach: Ich habe keine Erfahrung mit diesem Aspekt.

Technisch betrachtet gibt es das dir Attribut in HTML und ein entsprechendes direction property in CSS. Aber darüber hinaus würde ich von einer Auseinandersetzung mit dem Thema auch Dinge erwarten wie die Auswirkungen auf das Bildschirm Layout, Tab-Reihenfolge, etc..

WebAPI.

Da gibt’s nicht viel zu sagen: WebAPI Controller profitieren genauso von den Grundlagen, die wir gelegt haben, wie “normale” Controller. Der Controller weiß also, welche Region der Anwender bevorzugt, sollte sich das auf das Ergebnis inhaltlich auswirken. Die Datenserialisierung selbst ist agnostisch bzgl. der Region, Datenaustausch auf JSON-Ebene ist also gar nicht betroffen.

Client-seitige Lokalisierung.

Von ein paar Hinweisen bzgl. Validierung (die von der MVC via unobtrusive validation speziell unterstützt wird) mal abgesehen, passierte alles was ich gezeigt habe im Grunde auf dem Server.

Wer seine Anwendung mit Knockout, AngularJS, Sencha oder anderen JavaScript-Frameworks baut, die große Teile des UI dynamisch (z.B. über data binding) generieren, der hat noch etwas Arbeit vor sich. Immerhin kann der Server zumindest noch die notwendigen Informationen liefern, z.B. über einen JSON Service für die Übersetzungstexte.

Und auch bei JavaScript selbst steht die Entwicklung nicht still.

Entwicklung von “Apps”.

Treibt man die Client-seitige Entwicklung noch einen Schritt weiter, kommt man bei Container-Anwendungen auf Basis von PhoneGap/Cordova an. In diesem Falle muss man vermutlich sämtliche Übersetzungstexte (Images, sonstige Inhalte) am Client vorhalten – keinen Text anzuzeigen, nur weil gerade keine Verbindung verfügbar ist, ist kaum eine valide Option. Daher muss man in diesem Fall Lokalisierung vollständig am Client vornehmen – funktional und bzgl. der Lokalisierungsdaten – und kann nicht auf den Server Rückgriff nehmen.

Lokalisierte Daten.

Anwendungen im internationalen Kontext werden womöglich nicht nur ihr UI lokalisieren müssen. Auch bzgl. der Nutzdaten können hier Anforderungen entstehen, sowohl was Formate angeht, als auch Inhalte, ebenso kann Geschäftslogik abhängig von regionalen Gegebenheiten sein.

Das könnte zum Beispiel die Bereitstellung von Dokumenten in unterschiedlichen Sprachen sein (das Exposé wurde gerade vom Feld zur Tabelle). Unterschiedliche Regeln bei Familiennamen. Internationale Adressen? Viel Spaß. Gesellschaftsformen, Währungen (samt Umrechnung?), Kalender, sonstige Maßeinheiten. (Grüße an die Historiker, die haben mit diesen Themen so richtig viel Spaß.) Ach ja, es soll Leute geben, die halten IBAN/BIC für einfach…

 

Aber diese Themen überlasse ich Anderen, für jetzt soll’s das gewesen sein.Damit schließe ich diese Serie ab. Der Code der Beispielanwendung findet sich hier (als Visual Studio 2013 Projekt, die Nuget Pakete müssen über “Enable NuGet Package Restore” neu eingespielt werden, IIS Express wird vorausgesetzt)…