Comprendre les langues de profil utilisateur et les langues du manifeste de l’application

Un utilisateur Windows peut utiliser Paramètres>Date et langue>Région et langue pour configurer une liste triée des langues d’affichage préférées ou simplement une seule langue d’affichage préférée. Une langue peut avoir une variante régionale. Par exemple, vous pouvez sélectionner l’espagnol comme parlé en Espagne, l’espagnol comme parlé au Mexique, l’espagnol comme parlé dans le États-Unis, entre autres.

En outre, dans Paramètres>Heure et langue>Région et langue, mais séparément de la langue, l’utilisateur peut spécifier son emplacement (connu sous le nom de région) dans le monde. Notez que le paramètre de langue d’affichage (et variante régionale) n’est pas un déterminant du paramètre de région, et inversement. Par exemple, un utilisateur peut actuellement vivre en France, mais choisir une langue d’affichage Windows préférée d’Español (México).

Pour les applications Windows, une langue est représentée sous la forme d’une balise de langue BCP-47. Par exemple, la balise de langue BCP-47 « en-US » correspond à l’anglais (États-Unis) dans Paramètres. Les API Windows Runtime appropriées acceptent et retournent des représentations sous forme de chaîne de balises de langage BCP-47.

Consultez également le registre de sous-balise de langue IANA.

Les trois sections suivantes définissent les termes « liste de langues de profil utilisateur », « liste de langues du manifeste de l’application » et « liste de langues du runtime d’application ». Nous allons utiliser ces termes dans cette rubrique et d’autres rubriques de cette zone de fonctionnalités. Il est donc important de savoir ce qu’ils signifient.

Liste des langues de profil utilisateur

La liste de langues du profil utilisateur est le nom de la liste configurée par l’utilisateur dans Paramètres>Heure et langue>Région et langue>Langues. Dans le code, vous pouvez utiliser la propriété GlobalizationPreferences.Languages pour accéder à la liste des langues de profil utilisateur en tant que liste de chaînes en lecture seule, où chaque chaîne est une balise de langue BCP-47 unique telle que « en-US » ou « ja-JP ».

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

Liste de langues du manifeste de l’application

La liste des langues du manifeste de l’application est la liste des langues pour lesquelles votre application déclare (ou déclare) la prise en charge. Cette liste augmente à mesure que vous progressez votre application dans le cycle de vie du développement jusqu’à la localisation.

La liste est déterminée au moment de la compilation, mais vous avez deux options pour contrôler exactement comment cela se produit. Une option consiste à laisser Visual Studio déterminer la liste des fichiers de votre projet. Pour ce faire, définissez d’abord la langue par défaut de votre application sous l’onglet Application dans le fichier source du manifeste du package d’application (Package.appxmanifest). Ensuite, vérifiez que le même fichier contient cette configuration (qu’elle effectue par défaut).

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

Chaque fois que Visual Studio produit votre fichier manifeste du package d’application généré (AppxManifest.xml), il développe cet élément unique Resource dans le fichier source dans une union de tous les qualificateurs de langue qu’il trouve dans votre projet (voir Personnaliser vos ressources pour la langue, l’échelle, le contraste élevé et d’autres qualificateurs). Par exemple, si vous avez commencé à localiser et que vous avez des ressources de chaîne, d’image et/ou de fichier dont les noms de dossiers ou de fichiers incluent « en-US », « ja-JP » et « fr-FR », votre fichier généré AppxManifest.xml contient les éléments suivants (la première entrée de la liste est la langue par défaut que vous définissez).

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

L’autre option consiste à remplacer cet élément « x-generate » <Resource> unique dans le fichier source du manifeste du package d’application (Package.appxmanifest) par la liste développée d’éléments <Resource> (étant prudent pour répertorier la langue par défaut en premier). Cette option implique davantage de travail de maintenance pour vous, mais il peut s’agir d’une option appropriée si vous utilisez un système de build personnalisé.

Pour commencer, votre liste de langues de manifeste de l’application ne contient qu’une seule langue. Peut-être que c’est en-US. Mais finalement, lorsque vous configurez manuellement votre manifeste, ou que vous ajoutez des ressources traduites à votre projet, cette liste augmente.

Lorsque votre application se trouve dans le Microsoft Store, les langues de la liste des langues du manifeste de l’application sont celles qui sont affichées aux clients. Pour obtenir la liste des balises linguistiques BCP-47 spécifiquement prises en charge par le Microsoft Store, consultez langues prises en charge.

Dans le code, vous pouvez utiliser la propriété ApplicationLanguages.ManifestLanguages pour accéder à la liste de langues du manifeste de l’application en tant que liste de chaînes en lecture seule, où chaque chaîne est une balise de langue BCP-47 unique.

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

Liste des langues du runtime d’application

La troisième liste d’intérêt est l’intersection entre les deux listes que nous venons de décrire. Au moment de l’exécution, la liste des langues pour lesquelles votre application a déclaré la prise en charge (la liste des langues du manifeste de l’application) est comparée à la liste des langues pour lesquelles l’utilisateur a déclaré une préférence (la liste des langues de profil utilisateur). La liste de langues du runtime d’application est définie sur cette intersection (si l’intersection n’est pas vide) ou sur la langue par défaut de l’application (si l’intersection est vide).

Plus précisément, la liste des langues du runtime d’application est constituée de ces éléments.

1. (Facultatif) Remplacement du langage principal. PrimaryLanguageOverride est un paramètre de remplacement simple pour les applications qui donnent aux utilisateurs leur propre choix de langue indépendant, ou les applications qui ont une raison forte de remplacer les choix de langue par défaut. Pour plus d’informations, consultez les ressources d’application et l’exemple de localisation.
2. Langues de l’utilisateur prises en charge par l’application. Il s’agit de la liste de langues de profil utilisateur filtrée par la liste de langues du manifeste de l’application. Le filtrage des langages de l’utilisateur par ceux pris en charge par l’application maintient la cohérence entre les kits de développement logiciel (SDK), les bibliothèques de classes, les packages d’infrastructure dépendants et l’application.
3. Si 1 et 2 sont vides, la langue par défaut ou la première langue prise en charge par l’application. Si la liste des langues de profil utilisateur ne contient aucune langue prise en charge par l’application, la langue d’exécution de l’application est la première langue prise en charge par l’application.

Dans le code, vous pouvez utiliser la propriété ResourceContext.QualifierValues pour accéder à la liste de langues du runtime d’application sous la forme d’une chaîne contenant une liste délimitée par des points-virgules de balises de langue BCP-47.

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

Vous pouvez également y accéder en tant que liste de chaînes en lecture seule, chacune contenant une seule balise de langue BCP-47. Vous pouvez utiliser la propriété ResourceContext.Languages ou la propriété ApplicationLanguages.Languages pour effectuer cette opération.

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

    runtimeLanguages = Windows.Globalization.ApplicationLanguages.Languages;

La liste de langues du runtime d’application détermine les ressources que Windows charge pour votre application, ainsi que la ou les langues utilisées pour mettre en forme des dates, des heures, des nombres et d’autres composants. Consultez Globaliser vos formats de date/heure/chiffres.

Notez que si la langue du profil utilisateur et la langue du manifeste de l’application sont des variantes régionales les unes des autres, la variante régionale de l’utilisateur est utilisée comme langue d’exécution de l’application. Par exemple, si l’utilisateur préfère en-Go et que l’application prend en charge en-US, le langage d’exécution de l’application est en-Go. Cela garantit que les dates, heures et nombres sont mis en forme plus étroitement aux attentes de l’utilisateur (en-Go), mais que les ressources localisées sont toujours chargées (en raison de la correspondance de langue) dans la langue prise en charge de l’application (en-US).

Qualifier les fichiers de ressources avec leur langue

Nommez vos fichiers de ressources, ou leurs dossiers, avec des qualificateurs de ressources linguistiques. Pour en savoir plus sur les qualificatifs des ressources, voir Personnaliser vos ressources pour la langue, l’échelle, le contraste élevé et d’autres qualificateurs. Un fichier de ressources peut être une image (ou une autre ressource), ou il peut s’agir d’un fichier conteneur de ressources, tel qu’un fichier .resw qui contient des chaînes de texte.

Notez que les ressources même dans la langue par défaut de votre application doivent spécifier le qualificateur de langue. Par exemple, si la langue par défaut de votre application est l’anglais (États-Unis), qualifiez vos ressources \Assets\Images\en-US\logo.pngcomme .

• Windows effectue des correspondances complexes, notamment entre les variantes régionales telles que en-US et en-Go. Incluez donc la sous-balise de région en fonction des besoins. Consultez Comment le système de gestion des ressources met en correspondance les balises de langue.
• Spécifiez une sous-balise de script de langage dans le qualificateur lorsqu’aucune valeur Suppress-Script n’est définie pour la langue. Par exemple, au lieu de zh-CN ou zh-TW, utilisez zh-Hant, zh-Hant-TW ou zh-Hans (pour plus de détails, consultez le registre de sous-balise de langue IANA).
• Pour les langues qui ont un dialecte standard unique, il n’est pas nécessaire d’inclure le qualificateur de région. Par exemple, utilisez au lieu de .
• Certains outils et d’autres composants tels que les traducteurs de machines peuvent trouver des balises de langue spécifiques, telles que des informations de dialecte régional, utiles pour comprendre les données.

Toutes les ressources ne doivent pas être localisées

La localisation peut ne pas être nécessaire pour toutes les ressources.

• Au minimum, vérifiez que toutes les ressources existent dans la langue par défaut.
• Un sous-ensemble de certaines ressources peut suffire pour une langue étroitement liée (localisation partielle). Par exemple, vous ne pouvez pas localiser l’interface utilisateur de votre application en catalan si votre application dispose d’un ensemble complet de ressources en espagnol. Pour les utilisateurs qui parlent catalan et espagnol, les ressources qui ne sont pas disponibles en catalan apparaissent en espagnol.
• Certaines ressources peuvent nécessiter des exceptions pour des langues spécifiques, tandis que la majorité des autres ressources sont mappées à une ressource commune. Dans ce cas, marquez la ressource destinée à être utilisée pour toutes les langues avec la balise de langue non déterminée « und ». Windows interprète la balise de langue « und » en tant que caractère générique carte (similaire à « * ») dans le fait qu’elle correspond à la langue de l’application supérieure après toute autre correspondance spécifique. Par exemple, si quelques ressources sont différentes pour le finnois, mais que le reste des ressources est identique pour toutes les langues, la ressource finnoise doit être marquée avec la balise de langue finnoise, et le reste doit être marqué avec « und ».
• Pour les ressources basées sur un script de langage, comme une police ou une hauteur de texte, utilisez la balise de langue indéterminée avec un script spécifié : « und-script<> ». Par exemple, pour les polices latines, utilisez und-Latn\\fonts.css et pour les polices und-Cryl\\fonts.csscyrilliques.

Définir l’en-tête HTTP Accept-Language dans IE

Déterminez si les services web que vous appelez ont la même étendue de localisation que votre application. Les requêtes HTTP effectuées à partir d’applications Windows dans des requêtes web classiques et XMLHttpRequest (XHR), utilisent l’en-tête de requête HTTP Accept-Language standard. Par défaut, l’en-tête HTTP est défini sur la liste de langues du profil utilisateur. Chaque langue de la liste est développée de manière à inclure des neutres de la langue et une pondération (q). Par exemple, la liste de langues d’un utilisateur fr-FR et en-US génère un en-tête de demande HTTP Accept-Language de fr-FR, fr, en-US, en (« fr-FR,fr;q=0.8,en-US;q=0.5,en;q=0.3 »). Mais si votre application météo (par exemple) affiche une interface utilisateur dans Français (France), mais que la langue principale de l’utilisateur dans sa liste de préférences est l’allemand, vous devez demander explicitement Français (France) auprès du service afin de rester cohérent dans votre application.

API dans l’espace de noms Windows.Globalization

En règle générale, les API de l’espace de noms Windows.Globalization utilisent la liste de langues du runtime d’application pour déterminer la langue. Si aucune des langues n’a un format correspondant, les paramètres régionaux de l’utilisateur sont utilisés. Il s’agit des mêmes paramètres régionaux que ceux utilisés pour l’horloge système. Les paramètres régionaux de l’utilisateur sont disponibles à partir de Paramètres> Time &Language>Region &language>Additional date, time, ®ional settings>Region : Change date, time ou number formats. Les API Windows.Globalization ont également des remplacements pour spécifier une liste de langues à utiliser, au lieu de la liste des langues du runtime d’application.

À l’aide de la classe Language, vous pouvez inspecter des détails sur une langue particulière, comme le script de la langue, le nom complet et le nom natif.

Utiliser la région géographique le cas échéant

Dans Paramètres> Région ou>région de langue>, l’utilisateur peut spécifier son emplacement dans le monde. Vous pouvez utiliser ces paramètres, au lieu de la langue, pour choisir le contenu à afficher à l’utilisateur. Par exemple, une application d’actualités peut par défaut afficher du contenu à partir de cette région.

Dans le code, vous pouvez accéder à ce paramètre à l’aide de la propriété GlobalizationPreferences.HomeGeographicRegion.

À l’aide de la classe GeographicRegion, vous pouvez inspecter des détails sur une région particulière, telles que son nom complet, son nom natif et ses devises en cours d’utilisation.

Exemples

Le tableau suivant contient des exemples de ce que l’utilisateur verrait dans l’interface utilisateur de votre application sous différents paramètres de langue et de région.

API importantes

• GlobalizationPreferences.Languages
• ApplicationLanguages.ManifestLanguages
• PrimaryLanguageOverride
• ResourceContext.QualifierValues
• ResourceContext.Languages
• ApplicationLanguages.Languages
• Windows.Globalization
• Langage
• GlobalizationPreferences.HomeGeographicRegion
• GeographicRegion

Rubriques connexes

• Balise de langue BCP-47
• Registre de sous-balise de langue IANA
• Personnaliser vos ressources pour la langue, l’échelle, le contraste élevé et d’autres qualificateurs
• Langues prises en charge
• Globaliser vos formats de date/heure/chiffres
• Comment le système de gestion des ressources met en correspondance les balises de langue

Exemples

• Exemple de ressources d’application et de localisation