ASP.NET MVC I18n – Teil 1: Grundlagen
Als ich mit dieser Serie begann, war der folgende Beitrag nicht einmal geplant. Aber je mehr Beiträge ich in Angriff nahm, desto deutlicher wurde für mich, dass ich daran nicht vorbeikomme. Wir sollten wissen, was gemeint ist, wenn von “Region” oder ähnlichem die Rede ist. Daher zunächst die theoretischen Grundlagen…
Ein zentraler Punkt, dessen man sich bewusst sein muss, ist die Tatsache, dass wir über zwei unterschiedliche Kontexte reden: Die Server-Seite, die durch das .NET Framework bestimmt wird, und die Client-Seite, bestimmt durch HTML und andere Standards. Diese Kontexte unterscheiden sich in ihren Begriffen, in ihren Herangehensweisen, und in ihrem technischen Umfang.
Hinweis: Dieser Beitrag ist Teil einer Serie, die Übersicht findet sich hier.
Server-seitig…
.NET verwaltet die notwendigen Informationen für in der Klasse CultureInfo:
“The CultureInfo class specifies a unique name for each culture, based on RFC 4646. The name is a combination of an ISO 639 two-letter lowercase culture code associated with a language and an ISO 3166 two-letter uppercase subculture code associated with a country or region.”
Kurz zusammengefasst: Wir reden über “en-US”, “de-DE”, etc. (Sonderfälle mal außen vor). Eine Unterscheidung wird hinsichtlich neutraler (d.h. nur mit der Sprache “en” oder “de” assoziierten) und spezifischer (mit der Sprache und Land/Region assoziierten) “cultures” gemacht. Trotzdem werden auch neutrale “cultures” über CultureInfo verwaltet. Typischerweise werden sie durch den “primären Vertreter” der Sprache definiert, also Deutschland für “de” (Sorry Österreich 
), und diese ehemalige britische Kolonie für “en” ….
Es sollte betont werden, dass CultureInfo alle Aspekte von Regionen adressiert: Es identifiziert die Sprache, liefert Datums- und Zeit-Formate, selbst der verwendete Kalender ist berücksichtigt.
Bezüglich der lokalisierten Inhalte (Menü-Texte und ähnliches) bietet .NET ein auf Ressourcen und “satellite assemblies” basiertes System. Zugriff darauf erfolgt über die Klasse ResourceManager, entweder direkt, oder über generierte Zugriffsklassen. (Im Folgenden werde ich das als .NET Grundwissen voraussetzen.)
Alles in allem eine konsistente und runde Sache.
Client-seitig…
HTML adressiert traditionell nur die Sprache (also keine Datenformate):
“The lang attribute’s value is a language code that identifies a natural language spoken, written, or otherwise used for the communication of information among people.”
Andererseits ist HTML dabei deutlich offener als .NET, und geht über das hinaus, was dort möglich ist:
“Here are some sample language codes:
- "en": English
- "en-US": the U.S. version of English.
- "en-cockney": the Cockney version of English.
- "i-navajo": the Navajo language spoken by some Native Americans.
- "x-klingon": The primary tag "x" indicates an experimental language tag”
Allerdings geht dieser Fokus auf “Sprache” soweit, dass andere Lokalisierungsanforderungen ignoriert oder gar unterlaufen werden:
“The golden rule when creating language tags is to keep the tag as short as possible. Avoid region, script or other subtags except where they add useful distinguishing information. For instance, use ja for Japanese and not ja-JP, unless there is a particular reason that you need to say that this is Japanese as spoken in Japan, rather than elsewhere.”
Tatsächlich findet man in den meisten Beispielen zu HTML oder CSS in der Regel 2-buchstabige Sprach-Codes.
Dummerweise ist das seit HTML5 (insbesondere der neuen Input Controls wegen) auch für HTML nicht mehr ausreichend. Ein Kalender-Control unterscheidet sich eben nicht nur die die Sprache der Wochentage, sondern auch durch das Datumsformat oder den ersten Tag der Woche. Das W3C wirkt bei dieser Frage allerdings etwas hilflos und schiebt das Problem auf die Browserhersteller:
“Browsers are encouraged to use user interfaces that present dates, times, and numbers according to the conventions of either the locale implied by the input element’s language or the user’s preferred locale.”
Zumindest gehen sie erfrischend offen damit um:
“There’s still a risk that the user would end up arriving a month late, of course, but there’s only so much that can be done about such cultural differences…”
Nebenbei: Wann immer ich “HTML” geschrieben habe, galt das genauso für XML, CSS, und HTTP (hier und hier).
Lokalisierte Inhalte werden im HTML-Dokument nur entsprechend über das lang Attribut markiert. Man kann unterschiedliche Sprachen im gleichen Dokument mischen, aber HTML selbst kümmert sich nicht weiter um irgendwelche Auswirkungen. CSS hingegen bietet Selektoren mit denen Styles an der Sprache festgemacht werden können.
Konsequenzen?
Für eine LOB-Anwendung ist die auf die Sprache limitierte Sichtweise von HTML et al. zu kurzsichtig, daher werde ich im Folgenden mit der Region arbeiten. In HTML oder CSS mag das ungewohnt sein, aber was soll’s?
Der nächste Beitrag wird wieder Code enthalten, versprochen.