Freigeben über

Benutzerprofilsprachen und App-Manifest-Sprachen verstehen

  • Artikel

Ein Windows-Benutzer kann Einstellungen> Time & Language>Region & Language verwenden, um eine sortierte Liste der bevorzugten Anzeigesprachen oder nur eine einzelne bevorzugte Anzeigesprache zu konfigurieren. Eine Sprache kann eine regionale Variante haben. Sie können z.B. Spanisch, wie es in Spanien gesprochen wird, Spanisch, wie es in Mexiko gesprochen wird, Spanisch, wie es in den Vereinigten Staaten gesprochen wird, und andere auswählen.

Auch in Einstellungen>Time & Language>Region & Language, aber getrennt von der Sprache, kann der Benutzer seinen Standort (als Region bezeichnet) in der Welt angeben. Beachten Sie, dass die Einstellung der Anzeigesprache (und der regionalen Variante) nicht die Einstellung der Region bestimmt und umgekehrt. Beispielsweise kann ein Benutzer derzeit in Frankreich leben, aber eine bevorzugte Windows-Anzeigesprache von Español (México) auswählen.

Für Windows-Apps wird eine Sprache als BCP-47-Sprachtag dargestellt. Beispielsweise entspricht das BCP-47-Sprachtag „en-US“ englisch (USA) in den Einstellungen. Geeignete Windows Runtime APIs akzeptieren und geben Zeichenketten zur Darstellung von BCP-47 Sprach-Tags zurück.

Siehe auch die IANA Language Subtag Registry.

In den folgenden drei Abschnitten werden die Begriffe „Benutzerprofil-Sprachenliste“, „App-Manifest-Sprachenliste“ und „App-Laufzeit-Sprachenliste“ definiert. Wir verwenden diese Begriffe in diesem Thema und anderen Themen in diesem Featurebereich und daher ist es wichtig zu wissen, was sie bedeuten.

Benutzerprofil-Sprachenliste

Die Benutzerprofil-Sprachenliste ist der Name der Liste, die vom Benutzer in Einstellungen>Time & Language>Region & Language>Languages konfiguriert wird. Im Code können Sie die GlobalizationPreferences.Languages-Eigenschaft verwenden, um auf die Benutzerprofil-Sprachenliste als schreibgeschützte Liste von Zeichenketten zuzugreifen, wobei jede Zeichenkette ein einzelnes BCP-47-Sprachtag wie „en-US“ oder „ja-JP“ ist.

    IReadOnlyList<string> userLanguages = Windows.System.UserProfile.GlobalizationPreferences.Languages;

App-Manifest-Sprachenliste

Die App-Manifest-Sprachenliste ist die Liste der Sprachen, für die Ihre App Unterstützung deklariert (oder deklarieren wird). Diese Liste wächst, je weiter Sie Ihre App durch den Entwicklungszyklus bis hin zur Lokalisierung bringen.

Die Liste wird bei der Kompilierung festgelegt, aber Sie haben zwei Möglichkeiten, genau zu steuern, wie dies geschieht. Eine Möglichkeit ist, Visual Studio die Liste aus den Dateien in Ihrem Projekt ermitteln zu lassen. Legen Sie dazu zunächst die Standardsprache Ihrer App auf der Registerkarte Anwendung in der Manifest-Quelldatei (Package.appxmanifest) Ihres App-Pakets fest. Vergewissern Sie sich dann, dass die gleiche Datei diese Konfiguration enthält (standardmäßig).

  <Resources>
    <Resource Language="x-generate" />
  </Resources>

Jedes Mal, wenn Visual Studio die Manifest-Datei (AppxManifest.xml) Ihres erstellten Anwendungspakets erzeugt, erweitert es das einzelne Resource Element in der Quelldatei zu einer Vereinigung aller Sprachqualifizierer, die es in Ihrem Projekt findet (siehe Anpassen Ihrer Ressourcen für Sprache, Skalierung, hohen Kontrast und andere Qualifizierer). Wenn Sie beispielsweise mit der Lokalisierung begonnen haben und Zeichenfolgen-, Bild- und/oder Dateiressourcen vorhanden sind, deren Ordner- oder Dateinamen „en-US“, „ja-JP“ und „fr-FR“ enthalten, enthält Ihre integrierte AppxManifest.xml Datei Folgendes (der erste Eintrag in der Liste ist die von Ihnen festgelegte Standardsprache).

  <Resources>
    <Resource Language="EN-US" />
    <Resource Language="JA-JP" />
    <Resource Language="FR-FR" />
  </Resources>

Die andere Option besteht darin, dieses einzelne „x-generate“ <Resource> -Element in der Quelldatei des App-Paketmanifests (Package.appxmanifest) durch die erweiterte Liste der <Resource> Elemente zu ersetzen (wobei die Standardsprache zuerst aufgeführt wird). Diese Option ist mit mehr Wartungsaufwand für Sie verbunden, aber sie könnte für Sie eine geeignete Option sein, wenn Sie ein benutzerdefiniertes System verwenden.

Zunächst enthält ihre App-Manifest-Sprachenliste nur eine Sprache. Vielleicht ist das en-US. Aber schließlich – während Sie Ihr Manifest manuell konfigurieren oder übersetzte Ressourcen zu Ihrem Projekt hinzufügen – wird diese Liste vergrößert.

Wenn Sich Ihre App im Microsoft Store befindet, sind die Sprachen in der App-Manifest-Sprachenliste die Sprachen, die den Kunden angezeigt werden. Eine Liste der vom Microsoft Store speziell unterstützten BCP-47-Sprachtags finden Sie unter Unterstützte Sprachen.

Im Code können Sie die ApplicationLanguages.ManifestLanguages-Eigenschaft verwenden, um auf die App-Manifest-Sprachenliste als schreibgeschützte Liste von Zeichenketten zuzugreifen, wobei jede Zeichenkette ein einzelnes BCP-47-Sprachtag ist.

    IReadOnlyList<string> userLanguages = Windows.Globalization.ApplicationLanguages.ManifestLanguages;

App-Laufzeitsprachenliste

Die dritte Sprachenliste ist die Schnittmenge zwischen den beiden Listen, die wir gerade beschrieben haben. Zur Laufzeit wird die Liste der Sprachen, für die Ihre App die Unterstützung deklariert hat (die App-Manifest-Sprachenliste), mit der Liste der Sprachen verglichen, für die der Benutzer eine Einstellung deklariert hat (die Benutzerprofil-Sprachenliste). Die Laufzeitsprachenliste der App wird auf diesen Schnittpunkt gesetzt (wenn der Schnittpunkt nicht leer ist) oder nur auf die Standardsprache der App (wenn der Schnittpunkt leer ist).

Genauer gesagt besteht die App-Laufzeitsprachenliste aus diesen Elementen.

  1. (Optional) Außerkraftsetzung der primären Sprache. Die PrimaryLanguageOverride ist eine einfache Außerkraftsetzungseinstellung für Apps, die Benutzern eine eigene unabhängige Sprachauswahl oder Apps mit einem starken Grund zur Außerkraftsetzung der Standardsprachauswahl bieten. Weitere Informationen finden Sie im Anwendungsressourcen- und Lokalisierungsbeispiel.
  2. Die Sprachen des Benutzers, die von der App unterstützt werden. Dies ist die Benutzerprofil-Sprachenliste, die nach der App-Manifest-Sprachenliste gefiltert wird. Durch das Filtern der Sprachen des Benutzers nach den von der App unterstützten Sprachen wird die Konsistenz zwischen Software Development Kits (SDKs), Klassenbibliotheken, abhängigen Framework-Paketen und der App gewahrt.
  3. Wenn 1 und 2 leer sind, wird die von der App unterstützte Standardsprache oder erste Sprache verwendet. Wenn die Benutzerprofil-Sprachenliste keine von der App unterstützten Sprachen enthält, ist die App-Laufzeitsprache die erste von der App unterstützte Sprache.

Im Code können Sie die Eigenschaft ResourceContext.QualifierValues verwenden, um auf die App-Laufzeitsprachenliste in Form einer Zeichenkette zuzugreifen, die eine durch Semikolons getrennte Liste von BCP-47-Sprachtags enthält.

    string runtimeLanguages = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues["Language"];

Sie können sie auch als schreibgeschützte Liste von Zeichenketten aufrufen, die jeweils ein einzelnes BCP-47 Sprach-Tag enthalten. Sie können die Eigenschaft ResourceContext.Languages oder die Eigenschaft ApplicationLanguages.Languages verwenden, um dies zu tun.

    IReadOnlyList<string> runtimeLanguages = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().Languages;

    runtimeLanguages = Windows.Globalization.ApplicationLanguages.Languages;

Die App-Laufzeitsprachenliste bestimmt die Ressourcen, die Windows für Ihre App lädt, sowie die Sprachen, die zum Formatieren von Datumsangaben, Uhrzeiten, Zahlen und anderen Komponenten verwendet werden. Siehe Globalisieren von Datums-, Uhrzeit- und Zahlenformaten.

Notiz Wenn die Benutzerprofilsprache und die App-Manifestsprache regionale Varianten voneinander sind, wird die regionale Variante des Benutzers als App-Laufzeitsprache verwendet. Wenn der Benutzer beispielsweise „en-GB“ bevorzugt und die App „en-US“ unterstützt, lautet die App-Laufzeitsprache „en-GB“. Dadurch wird sichergestellt, dass Datumsangaben, Uhrzeiten und Zahlen näher an die Erwartungen des Benutzers (en-GB) angepasst werden, aber lokalisierte Ressourcen werden dennoch (aufgrund der Sprachanpassung) in der von der App unterstützten Sprache (en-US) geladen.

Qualifizieren von Ressourcendateien mit ihrer Sprache

Benennen Sie Ihre Ressourcendateien oder deren Ordner mit Sprachressourcenqualifizierern. Um mehr über Ressourcenqualifizierer zu erfahren, siehe Anpassen von Ressourcen mit Qualifizierern für Sprache, Skalierung, hohen Kontrast und anderen Qualifizierern. Eine Ressourcendatei kann ein Bild (oder eine andere Ressource) oder eine Ressourcencontainerdatei sein, wie zum Beispiel eine .resw-Datei, die Textzeichenfolgen enthält.

Notiz Selbst Ressourcen in der Standardsprache Ihrer App müssen den Sprachqualifizierer angeben. Wenn die Standardsprache Ihrer Appzum Beispiel Englisch (USA) ist, qualifizieren Sie Ihre Ressourcen als \Assets\Images\en-US\logo.png.

  • Windows führt komplexe Abgleiche durch, auch zwischen regionalen Varianten wie en-US und en-GB. Schließen Sie daher das Subtag Region entsprechend ein. Siehe Wie das Ressourcenverwaltungssystem Sprachtags zuordnet.
  • Geben Sie im Qualifizierer ein Subtag für ein Sprachskript an, wenn für die Sprache kein Suppress-Script-Wert definiert ist. Verwenden Sie z.B. anstelle von zh-CN oder zh-TW, zh-Hant, zh-Hant-TW oder zh-Hans (weitere Details finden Sie in der IANA-Language Subtag Registrierung).
  • Für Sprachen mit einem einzigen Standarddialekt muss der Regionsqualifizierer nicht eingeschlossen werden. Verwenden Sie z.B. ja statt ja-JP.
  • Einige Tools und andere Komponenten, z.B. Maschinelle Übersetzer, finden möglicherweise bestimmte Sprachtags, z.B. Regionale Dialektinformationen, die beim Verständnis der Daten hilfreich sind.

Nicht alle Ressourcen müssen lokalisiert werden

Die Lokalisierung ist möglicherweise nicht für alle Ressourcen erforderlich.

  • Stellen Sie zumindest sicher, dass alle Ressourcen in der Standardsprache vorhanden sind.
  • Eine Teilmenge einiger Ressourcen reicht möglicherweise für eine eng verwandte Sprache (teilweise Lokalisierung) aus. Sie müssen beispielsweise nicht alle Benutzeroberflächen Ihrer App in Katalanisch lokalisieren, wenn Ihre App über einen vollständigen Satz von Ressourcen in Spanisch verfügt. Für Benutzer, die Katalanisch und dann Spanisch sprechen, werden die Ressourcen, die nicht in Katalanisch verfügbar sind, in Spanisch angezeigt.
  • Einige Ressourcen erfordern möglicherweise Ausnahmen für bestimmte Sprachen, während der Großteil der anderen Ressourcen einer gemeinsamen Ressource zugeordnet ist. Markieren Sie in diesem Fall die Ressource, die für alle Sprachen mit dem unbestimmten Sprachtag „und“ verwendet werden soll. Windows interpretiert das Sprachtag „und“ als Wild-Karte (ähnlich wie „*“), da es nach einer anderen Übereinstimmung mit der obersten App-Sprache übereinstimmt. Wenn beispielsweise einige Ressourcen für Finnisch unterschiedlich sind, aber die restlichen Ressourcen für alle Sprachen identisch sind, sollte die finnische Ressource mit dem Finnischen Sprachtag gekennzeichnet werden, und der Rest sollte mit „und“ gekennzeichnet werden.
  • Für Ressourcen, die auf einem Sprachskript basieren, wie z.B. eine Schriftart oder Texthöhe, verwenden Sie das Tag unbestimmte Sprache mit einem angegebenen Skript: 'und-< Skript>'. Verwenden Sie z.B. für lateinische Schriftarten und-Latn\\fonts.css und für kyrillische Schriftarten und-Cryl\\fonts.css.

Setzen Sie den HTTP Accept-Language Anforderungsheader

Überlegen Sie, ob die von Ihnen aufgerufenen Webdienste den gleichen Umfang der Lokalisierung aufweisen wie Ihre App. HTTP-Anforderungen von Windows-Apps in typischen Webanforderungen und XMLHttpRequest (XHR) verwenden den standardmäßigen HTTP Accept-Language-Anforderungsheader. Standardmäßig wird der HTTP-Header auf die Benutzerprofil-Sprachenliste festgelegt. Jede Sprache in der Liste wird weiter erweitert, um Neutrale der Sprache und eine Gewichtung (q) einzuschließen. Beispielsweise führt die Sprachliste eines Benutzers von fr-FR und en-US zu einem HTTP Accept-Language-Anforderungsheader von fr-FR, fr, en-US, en („fr-FR,fr; q=0,8,en-US; q=0,5,en; q=0,3“). Wenn Ihre Wetter-App (zum Beispiel) eine Benutzeroberfläche in Französisch (Frankreich) anzeigt, die oberste Sprache in der Präferenzliste des Benutzers aber Deutsch ist, dann müssen Sie den Dienst explizit um Französisch (Frankreich) bitten, um innerhalb Ihrer App konsistent zu bleiben.

APIs im Windows.Globalization-Namespace

Die APIs im Windows.Globalization-Namespace verwenden normalerweise die App-Laufzeitsprachenliste, um die Sprache zu bestimmen. Wenn keine der Sprachen ein passendes Format aufweist, wird das Gebietsschema des Benutzers verwendet. Dies ist dasselbe Gebietsschema, das für die Systemuhr verwendet wird. Das Gebietsschema des Benutzers ist über Einstellungen>Zeit & Sprache>Region & Sprache>Zusätzliche Einstellungen zu Datum, Zeit & Region>Region: Datum-, Zeit- oder Nummer-Format ändern erreichbar. Die Windows.Globalization-APIs verfügen auch über Außerkraftsetzungen, um eine Liste der zu verwendenden Sprachen anstelle der App-Laufzeitsprachenliste anzugeben.

Mithilfe der Sprachklasse können Sie Details zu einer bestimmten Sprache überprüfen, wie z.B. das Skript der Sprache, den Anzeigenamen und den nativen Namen.

Geografische Region bei Bedarf verwenden

In Einstellungen>Time & Language>Region & Language>Country or Region kann der Benutzer seinen Standort in der Welt angeben. Sie können diese Einstellungen anstelle der Sprache verwenden, um auszuwählen, welche Inhalte dem Benutzer angezeigt werden sollen. Eine Nachrichten-App kann z. B. standardmäßig Inhalte aus dieser Region anzeigen.

Im Code können Sie mithilfe der Eigenschaft GlobalizationPreferences.HomeGeographicRegion auf diese Einstellung zugreifen.

Mithilfe der GeographicRegion-Klasse können Sie Details zu einer bestimmten Region prüfen, z.B. den Anzeigenamen, den nativen Namen und die verwendeten Währungen.

Beispiele

Die folgende Tabelle enthält Beispiele dafür, was der Benutzer auf der Benutzeroberfläche Ihrer App unter verschiedenen Sprach- und Regionseinstellungen sehen würde.

App-Manifest-Sprachenliste Benutzerprofil-Sprachenliste Außerkraftsetzung der primären Sprache (Option). App-Laufzeitsprachenliste Was der Benutzer in der App sieht
Englisch (GB) (Standard); Deutsch (Deutschland) Englisch (GB) keine Englisch (GB) Benutzeroberfläche: Englisch (GB)
Datum/Uhrzeit/Zahlen: Englisch (GB)
Deutsch (Deutschland) (Standard); Französisch (Frankreich); Italienisch (Italien) Französisch (Österreich) keine Französisch (Österreich) Benutzeroberfläche: Französisch (Frankreich) (Fallback von Französisch (Österreich))
Datum/Uhrzeit/Zahlen: Französisch (Österreich)
Englisch (USA) (Standard); Französisch (Frankreich); Englisch (GB) Englisch (Kanada); Französisch (Kanada) keine Englisch (Kanada); Französisch (Kanada) Benutzeroberfläche: Englisch (USA) (Fallback von Englisch (Kanada))
Datum/Uhrzeit/Zahlen: Englisch (Kanada)
Spanisch (Spanien) (Standard); Spanisch (Mexiko); Spanisch (Lateinamerika); Portugiesisch (Brasilien) Englisch (USA) keine Spanisch (Spanien) Benutzeroberfläche: 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) Benutzeroberfläche: Meist Katalanisch und einige Französisch (Frankreich) weil nicht alle Zeichenfolgen in Katalanisch sind
Datum/Uhrzeit/Zahlen: Katalanisch
Englisch (GB) (Standard); Französisch (Frankreich); Deutsch (Deutschland) Deutsch (Deutschland); Englisch (GB) Englisch (GB) (vom Benutzer in der Benutzeroberfläche der App ausgewählt) Englisch (GB); Deutsch (Deutschland) Benutzeroberfläche: Englisch (GB) (Sprachüberschreibung)
Datum/Uhrzeit/Zahlen: Englisch (GB)

Hinweis

Eine Liste der standardmäßigen Länder-/Regionscodes, die von Microsoft verwendet werden, finden Sie in der offiziellen Länder-/Regionsliste.

Wichtige APIs

Beispiele