So wird’s gemacht: Verwalten von Sprache und Region (HTML)

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation ]

Sie können steuern, wie UI-Ressourcen in Windows ausgewählt und die UI-Elemente der App formatiert werden. Verwenden Sie die verschiedenen Sprach- und Regionseinstellungen von Windows, um diese Features zu steuern.

Unter Anwendungsressourcen und Lokalisierung – Beispiel finden Sie eine Beispiel-App, die die Verwaltung der Sprach- und Regionseinstellungen veranschaulicht.

In Windows muss der Benutzer nicht genau eine Sprache aus einer begrenzten Gruppe möglicher Sprachen auswählen. Er kann stattdessen jede beliebige Sprache der Welt angeben, selbst wenn Windows selbst noch nicht in diese Sprache übersetzt wurde. Der Benutzer kann auch angeben, dass er mehrere Sprachen spricht.

Ein Windows-Benutzer kann einen Standort angeben, der sich überall auf der Welt befinden kann. Er kann ortsunabhängig auch angeben, dass er jede beliebige Sprache spricht. Standort und Sprache schränken sich nicht gegenseitig ein. Wenn also ein Benutzer Französisch spricht, muss das nicht heißen, dass er sich auch in Frankreich aufhält. Umgekehrt bedeutet ein Standort in Frankreich nicht, dass der Benutzer Französisch sprechen möchte.

Der Benutzer kann Apps in einer völlig anderen Sprache ausführen als Windows selbst. Er kann beispielsweise eine App in Spanisch und Windows in Englisch ausführen.

Für Windows Store-Apps wird eine Sprache als ein BCP-47-Sprachtag dargestellt. Die meisten APIs in Windows-Runtime, HTML und XAML können Zeichenfolgendarstellungen dieser BCP-47-Sprachtags zurückgeben oder diese akzeptieren. Weitere Informationen finden Sie in der IANA-Liste der Sprachen.

Eine Liste der speziell vom Windows Store unterstützten Sprachtags finden Sie unter Auswählen der Sprachen.

Anweisungen

Schritt 1: Festlegen der Spracheinstellungen des Benutzers.

Die Liste mit den Spracheinstellungen des Benutzers enthält dessen bevorzugte Sprachen in der entsprechenden Reihenfolge.

Hinweis  Nur Windows Store-Apps. Der Benutzer legt die Liste unter Systemsteuerung > Zeit, Sprache und Region > Sprache fest.

Hinweis  Nur Windows Phone Store-Apps. Der Benutzer legt die Liste unter Einstellungen > Sprache fest.

Die Liste der bevorzugten Sprachen des Benutzers kann mehrere Sprachen sowie regionale oder andere spezielle Varianten enthalten. Der Benutzer kann beispielsweise "fr-CA" bevorzugen, aber auch "en-GB" verstehen.

Schritt 2: Angeben der unterstützten Sprachen im App-Manifest.

Der Entwickler einer App gibt die Liste der unterstützten Sprachen im Resources-Element des App-Manifests (normalerweise "Package.appxmanifest") an, oder Visual Studio generiert die Liste der Sprachen in der Manifestdatei auf Grundlage der im Projekt gefundenen Sprachen. Die unterstützten Sprachen müssen im Manifest genau und mit dem richtigen Granularitätsgrad beschrieben werden. Die im Manifest aufgeführten Sprachen sind die Sprachen, die den Benutzern im Windows Store angezeigt werden.

Schritt 3: Angeben der Standardsprache.

Wenn eine App keine der Sprachen unterstützt, die der Benutzer ausgewählt hat, wird die Standardsprache verwendet. MSBuild und MakePRI.exe verwenden die Standardsprache, um in dieser Sprache gekennzeichneten Ressourcen Metadaten hinzuzufügen, die die Auswahl der richtigen Ressourcen zur Laufzeit ermöglichen.

So legen Sie in Visual Studio mithilfe eines JavaScript-Projekts die Standardsprache in einer Windows Store-App fest:

• Öffnen Sie „package.appxmanifest“ in Visual Studio, navigieren Sie zur Registerkarte Anwendung, und legen Sie Ihre Standardsprache auf die Sprache fest, in der Sie Ihre Anwendung erstellen.

Die Eigenschaft für die Standardsprache muss im Manifest auch als erste Sprache angegeben werden, damit die App-Sprache richtig festgelegt werden kann (wie unten im Schritt "Erstellen der Anwendungssprachenliste" beschrieben). Ressourcen in der Standardsprache müssen trotzdem mit ihrer Sprache gekennzeichnet werden (z. B. "en-US/logo.png"). Die Standardsprache gibt nicht implizit die Sprache nicht gekennzeichneter Ressourcen an. Weitere Informationen finden Sie unter So wird's gemacht: Benennen von Ressourcen mit Qualifizierern.

Schritt 4: Qualifizieren von Ressourcen mit ihrer Sprache.

Berücksichtigen Sie Ihr Zielpublikum sowie Sprache und Standort der Benutzer, die Sie ansprechen möchten. Viele Menschen, die in einer bestimmten Region leben, bevorzugen nicht die Hauptsprache dieser Region. Es gibt z. B. Millionen von Haushalten in den USA. in den hauptsächlich Spanisch gesprochen wird.

Qualifizieren von Ressourcen mit einer Sprache:

• Binden Sie ein Skript ein, falls für die Sprache kein Wert definiert ist, der besagt, dass Skripte unterdrückt werden sollen. Einzelheiten zu Sprachtags finden Sie unter IANA Subtag Registry. Verwenden Sie z. B. "zh-Hant", "zh-Hant-TW" oder "zh-Hans", aber nicht "zh-CN" oder "zh-TW".
• Markieren Sie den gesamten sprachlichen Inhalt für eine Sprache. Die Projekteigenschaft "Standardsprache" ist nicht die Sprache der nicht markierten Ressourcen (d. h. eine neutrale Sprache), sondern sie gibt an, welche markierte Sprache ausgewählt werden soll, wenn keine markierte Sprachressource zum Benutzer passt.

Markieren von Ressourcen mit einer genauen Darstellung des Inhalts

• Windows führt einen komplexen Abgleich durch, auch über regionale Varianten (z. B. "en-US" und "en-GB"), sodass Anwendungen die Freiheit haben, Ressourcen mit einer genauen Darstellung des Inhalts zu markieren und Windows den richtigen Abgleich für jeden Benutzer zu überlassen.
• Windows Store zeigt für Benutzer, die auf die Anwendung blicken, den Inhalt des Manifests an.
• Berücksichtigen Sie, dass für manche Tools und Komponenten wie Übersetzungsprogramme spezielle Sprachtags wie Informationen zu regionalen Dialekten für das Verständnis der Daten hilfreich sein können.
• Markieren Sie Ressourcen unbedingt mit allen Einzelheiten, insbesondere dann, wenn mehrere Varianten verfügbar sind. Markieren Sie z. B. "en-GB" und "en-US", wenn beide für die Region spezifisch sind.
• Bei Sprachen mit nur einem Standarddialekt muss keine Region hinzugefügt werden. Eine Verwendung von allgemeinen Tags ist in einigen Situationen vernünftig, so z. B. das Markieren von Ressourcen mit "ja" anstelle von "ja-JP".

In manchen Situationen müssen nicht alle Ressourcen lokalisiert werden.

• Markieren Sie Ressourcen wie UI-Zeichenfolgen, die in allen Sprachen bereitgestellt werden, mit ihrer eigenen Sprache, und stellen Sie sicher, dass alle diese Ressourcen in der Standardsprache vorhanden sind. Es muss keine neutrale Ressource angegeben werden (eine nicht mit einer Sprache markierte).
• Geben Sie bei Ressourcen, die eine Teilmenge der Menge der Sprachen der Anwendung darstellen (partielle Lokalisierung), die Menge der Sprachen an, in denen die Ressourcen vorliegen, und stellen Sie sicher, dass alle diese Ressourcen in der Standardsprache vorliegen. Windows wählt nach Beachtung aller vom Benutzer gesprochenen Sprachen in der bevorzugten Reihenfolge die für den Benutzer bestmögliche Sprache aus. Z. B. muss nicht die ganze UI einer App ins Katalanische lokalisiert werden, wenn die App über einen vollständigen Satz von Ressourcen auf Spanisch verfügt. Wenn ein Benutzer Katalanisch und dann Spanisch spricht, werden die nicht auf Katalanisch verfügbaren Ressourcen auf Spanisch angezeigt.
• Bei Ressourcen mit spezifischen Ausnahmen für bestimmte Sprachen, bei denen alle anderen Sprachen einer gemeinsamen Ressource zugeordnet werden, muss die für alle Sprachen zu verwendende Ressource mit dem Tag "und" für eine unbestimmte Sprache markiert werden. Windows interpretiert das Sprachtag "und" ähnlich wie "*", d. h., spezifische Entsprechungen haben Vorrang vor der Hauptsprache der Anwendung. Wenn beispielsweise einige Ressourcen (z. B. die Breite eines Elements) für Finnisch verschieden sind, der Rest der Ressourcen aber für alle Sprachen übereinstimmt, sollte die Ressource für Finnisch mit dem Sprachtag "Finnisch" und die übrigen mit "und" markiert werden.
• Verwenden Sie für Ressourcen, die auf dem Skript für eine Sprache anstatt auf der Sprache basieren, z. B. eine Schriftart oder eine Texthöhe, das Tag für eine unbestimmte Sprache mit dem angegebenen Skript "und-<script>". Verwenden Sie z. B. für lateinische Schriftarten "und-Latn\fonts.css" und für kyrillische Schriftarten "und-Cryl\fonts.css".

Schritt 5: Erstellen der Anwendungssprachenliste.

Das System ermittelt zur Laufzeit die bevorzugten Benutzersprachen, für die die App im Manifest Unterstützung deklariert, und erstellt eine Anwendungssprachenliste. Anhand dieser Liste werden die Sprachen bestimmt, in denen die App erscheinen soll. Diese Liste bestimmt die Sprachen, die für die App und Systemressourcen, Datumsangaben, Uhrzeiten, Zahlen und andere Komponenten verwendet werden. Das Ressourcenverwaltungssystem (Windows.ApplicationModel.Resources, Windows.ApplicationModel.Resources.Core und WinJS.Resources-Namespace) lädt beispielsweise UI-Ressourcen gemäß der Anwendungssprache. Windows.Globalization wählt ebenfalls Formate basierend auf der Anwendungssprachenliste aus. Die Anwendungssprachenliste ist über Windows.Globalization.ApplicationLanguages.languages verfügbar.

Die Zuordnung zwischen Sprachen und Ressourcen ist schwierig. Wir empfehlen, Windows die Zuordnung zu überlassen, da die Priorität einer Zuordnung von vielen optionalen Komponenten eines Sprachtags beeinflusst wird, die in der Praxis tatsächlich auftreten können.

Beispiele für optionale Komponenten in einem Sprachtag:

• Skript für Sprachen mit Skriptunterdrückung. "en-Latn-US" passt z. B. zu "en-US".
• Region "en-US" passt z. B. zu %%en".
• Varianten. "de-DE-1996" passt z. B. zu %%de-DE".
• "-x" und andere Erweiterungen. "en-US-x-Pirate" passt z. B. zu "en-US".

Es gibt darüber hinaus viele Komponenten von Sprachtags, die nicht die Form "xx" oder "xx-yy" haben, und nicht alle passen zueinander.

• "zh-Hant" passt nicht zu "zh-Hans".

Windows priorisiert die Zuordnung von Sprachen nach einer exakt definierten Standardmethode. "en-US" passt z. B. in der Reihenfolge der Priorität zu "en-US", "en", "en-GB" usw.

• Windows führt eine Zuordnung über Regionen durch. "en-US" passt zu "en-US", dann zu "en" und dann zu "en-*".
• Windows verfügt über zusätzliche Daten zur Affinitätszuordnung einer Region, z. B. die primäre Region für eine Sprache. "fr-FR" passt z. B. besser zu "fr-BE" als zu "fr-CA".
• Sie profitieren kostenlos von allen zukünftigen Verbesserungen der Sprachzuordnung in Windows, wenn Sie sich auf die Windows-APIs verlassen.

Zuerst wird die erste Sprache in einer Liste abgeglichen und dann die zweite Sprache in der Liste (auch bei anderen regionalen Varianten). Eine Ressource für "en-GB" wird z. B. vor einer "fr-CA"-Ressource ausgewählt, wenn "en-US" die Anwendungssprache ist. Nur dann, wenn keine Ressourcen für eine Form von "en" vorhanden sind, wird eine Ressource für "fr-CA" gewählt.

Die Anwendungssprachenliste wird auf die regionale Variante des Benutzers festgelegt, auch wenn diese sich von der regionalen Variante der App unterscheidet. Wenn der Benutzer z. B. "en-GB" spricht, die App jedoch "en-US" unterstützt, schließt die Anwendungssprachenliste "en-GB"ein. Dadurch wird sichergestellt, dass Datumsangaben, Uhrzeiten und Zahlen den Erwartungen des Benutzers entsprechend formatiert werden ("en-GB"), die UI-Ressourcen aber wegen des Sprachabgleichs trotzdem in der von der App unterstützten Sprache ("en-US") geladen werden.

Die Anwendungssprachenliste umfasst die folgenden Elemente:

1. (Optional) Überschreibung der primären SprachePrimaryLanguageOverride ist eine einfache Überschreibungseinstellung für Apps, in denen die Benutzer eine eigene unabhängige Sprachauswahl treffen können, oder für Apps, bei denen die Standardsprachauswahl aus einem speziellen Grund überschrieben werden sollte. Weitere Informationen dazu finden Sie unter Anwendungsressourcen und Lokalisierung – Beispiel.
2. Die von der App unterstützten Sprachen des Benutzers Hierbei handelt es sich um eine Liste der nach Präferenz geordneten bevorzugten Sprachen des Benutzers. Sie wird anhand der Liste der unterstützten Sprachen im App-Manifest gefiltert. Das Filtern der Benutzersprachen anhand der von der App unterstützten Sprachen sorgt für dauerhafte Konsistenz zwischen den Software Development Kits (SDKs), Klassenbibliotheken, abhängigen Frameworkpaketen und der App.
3. Wenn 1 und 2 leer sind, die Standardsprache oder erste von der App unterstützte Sprache Wenn der Benutzer keine der von der App unterstützten Sprachen versteht, entspricht die ausgewählte Anwendungssprache der ersten von der App unterstützten Sprache.

Beispiele finden Sie unten im Abschnitt "Anmerkungen".

Schritt 6: Festlegen des HTTP-Headers "Accept-Language".

HTTP-Anforderungen, die von Windows Store-Apps und Desktop-Apps in typischen Webanforderungen und XHR-Anforderungen (XMLHttpRequest) gesendet werden, verwenden den standardmäßigen HTTP-Header "Accept-Language". Der HTTP-Header ist standardmäßig auf die bevorzugte Sprache des Benutzers (gemäß der bevorzugten Reihenfolge des Benutzers) festgelegt, die unter Systemsteuerung > Zeit, Sprache und Region > Sprache angegeben ist. Jede Sprache in der Liste wird um die regionsneutralen Angaben der Sprache und Gewichtungen (q) erweitert. Beispielsweise ergibt eine Benutzersprachenliste, die aus "fr-FR" und "en-US" besteht, einen HTTP Accept-Language-Header mit "fr-FR", "fr", "en-US", "en" "(fr-FR,fr;q=0.8,en-US;q=0.5,en;q=0.3)".

Schritt 7: Verwenden der APIs im Windows.Globalization-Namespace.

In der Regel verwenden die API-Elemente im Windows.Globalization-Namespace die Anwendungssprachenliste zur Bestimmung der Sprache. Hat keine der Sprachen ein übereinstimmendes Format, wird das Benutzergebietsschema verwendet. Hierbei handelt es sich um das Gebietsschema, das die Systemuhr verwendet. Auf das Benutzergebietsschema kann unter Systemsteuerung > Zeit, Sprache und Region > Region: Datums-, Uhrzeit- oder Zahlenformat ändern zugegriffen werden. Die Windows.Globalization-APIs akzeptieren auch eine Überschreibung, wenn Sie eine Liste mit Sprachen angeben möchten, die anstelle der Anwendungssprachenliste verwendet werden soll.

Windows.Globalization besitzt auch ein Language-Objekt, das als Hilfsobjekt fungiert. Damit können Apps die Details der Sprache überprüfen, wie das Skript der Sprache, den Anzeigenamen und den systemeigenen Namen.

Schritt 8: Gegebenenfalls Verwendung einer geografischen Region.

Verwenden Sie die Einstellung für den geografischen Standort des Benutzers anstelle der Sprache zur Auswahl der Inhalte, die dem Benutzer angezeigt werden sollen. Beispielsweise sollte eine Nachrichten-App standardmäßig Inhalte vom Wohnort des Benutzers anzeigen. Dieser Ort wird bei der Installation von Windows festgelegt und kann in der Systemsteuerung unter Region geändert werden. Sie können die aktuelle Wohnorteinstellung mit Windows.System.UserProfile.GlobalizationPreferences.HomeGeographicRegion abrufen.

Windows.Globalization besitzt auch ein GeographicRegion-Objekt, das als Hilfsobjekt fungiert. Sie können damit die Details einer bestimmten Region überprüfen, wie Anzeigename, systemeigener Name und verwendete Währungen.

Anmerkungen

Die folgende Tabelle enthält Beispiele der Elemente, die dem Benutzer in der App-UI bei den verschiedenen Sprach- und Regionseinstellungen anzeigt werden.

Von der App unterstützte Sprachen (im Manifest definiert)	Spracheinstellungen des Benutzers (in der Systemsteuerung festgelegt)	Überschreibung der primären Sprache (optional)	App-Sprachen	Anzeige in der App
Englisch (GB) (Standard) Deutsch (Deutschland)	Englisch (GB)	keine	Englisch (GB)	UI: Englisch (GB) Datum/Uhrzeit/Zahlen: Englisch (GB)
Deutsch (Deutschland) (Standard) Französisch (Frankreich) Italienisch (Italien)	Französisch (Österreich)	(keine)	Französisch (Österreich)	UI: Französisch (Frankreich) (Fallback aus Französisch (Österreich)) Datum/Uhrzeit/Zahlen Französisch (Österreich)
Englisch (US) (Standard) Französisch (Frankreich) Englisch (GB)	Englisch (Kanada) Französisch (Kanada)	keine	Englisch (Kanada) Französisch (Kanada)	UI: Englisch (US) (Fallback aus Englisch (Kanada)) Datum/Uhrzeit/Zahlen: Englisch (Kanada)
Spanisch (Spanien) (Standard) Spanisch (Mexiko) Spanisch (Lateinamerika) Portugiesisch (Brasilien)	Englisch (USA)	keine	Spanisch (Spanien)	UI: Spanisch (Spanien) (verwendet "Standard" da kein Fallback für Englisch verfügbar ist) Datum/Uhrzeit/Zahlen Spanisch (Spanien)
Katalanisch (Standard) Spanisch (Spanien) Französisch (Frankreich)	Katalanisch Französisch (Frankreich)	keine	Katalanisch Französisch (Frankreich)	UI: Vorwiegend Katalanisch etwas Französisch (Frankreich), da nicht alle Zeichenfolgen in Katalanisch vorhanden sind Datum/Uhrzeit/Zahlen: Katalanisch
Englisch (GB) (Standard) Französisch (Frankreich) Deutsch (Deutschland)	Deutsch (Deutschland) Englisch (GB)	Englisch (GB) (vom Benutzer in der App-UI ausgewählt)	Englisch (GB) Deutsch (Deutschland)	UI: Englisch (GB) (Sprachüberschreibung) Datum/Uhrzeit/Zahlen Englisch (GB)