Localiser votre Application .NET
Avec le découpage en région de Marketplace et les règles associées à la validation des applications, il devient nécessaire pour le développeur d’applications ou de widgets de se poser la question de la traduction, ou plus généralement de la localisation de ses applications.
Les règles de localisation de Marketplace :
https://developer.windowsphone.com/resources/fr-FR/MarketplaceMarketValidationGuidelines.pdf
La localisation, c’est la pratique qui consiste à adapter son application au contexte régional : il s’agit bien-sûr de la langue, mais éventuellement aussi des ressources images, et dans les cas les plus extrêmes, d’une adaptation des fonctionnalités ou du contenu en fonction des lois en vigueur dans le marché visé.
La localisation (localization dans la langue de Shakespeare) n’est pas à confondre avec la géolocalisation (geolocation), l’acte de situer des éléments dans un repère géographique J Pour ceux que ce dernier sujet intéresse : cette série de billets est faite pour vous :
- La Boite à Outils de l’Application Géolocalisée: Partie 1: GPS, et CellId
- La Boite à Outils de l'Application Géolocalisée: Partie 2: Geocoding d'adresse
- La Boite à Outils de l'Application Géolocalisée: Partie 3: Afficher une carte
En l’occurrence ici, parlons de la localisation d’applications dans le sens, donner à son application le support de plusieurs locales :)
La première question qu’on se pose quand on localise une application est bien entendue celle de la langue : Comment faire pour changer toutes ces chaines de caractères et ces images en fonction de la langue de l’utilisateur ? En fait il y a plusieurs choses à connaitre :
Les règles pour localiser les WinForms
Cette partie est très simple, car quasiment les mêmes règles s’appliquent pour le framework .NET « de bureau » et le Compact Framework :)
Vous pouvez trouver un article sur MSDN sur le sujet, ainsi qu’un article du MVP Thomas Lebrun
La méthode est la suivante : il faut commencer par créer son interface dans la langue « par défaut » c’est-à-dire celle qui sera utilisée quand aucune locale spécifique ne sera détectée. Il suffit de le faire comme à l’accoutumée, avec le designer Visual Studio.
Une fois que cette interface est définie, il reste à la traduire ! D’abord il faut indiquer que le formulaire va exister dans plusieurs langues : c’est le but de la propriété « Localizable » du formulaire, qu’il faut mettre à la valeur « true ».
Ensuite, il faut changer la propriété « Language » pour la mettre à la locale que l’on veut : par exemple, Français (France), qui correspond, selon la notation ISO, à fr-FR
Ceci étant fait, il ne reste plus qu’à traduire, directement dans le designer ! Changer sans vergogne le texte des boutons, des menus, etc.
Une fois ceci terminé, vous pouvez repasser la propriété « Language » à ((default)) pour vous apercevoir que les ressources ont bien été sauvegardées dans chaque langue : en fait, chaque chaine de caractère traduite est stockée dans un fichier ressource (de type .resx) associé au formulaire : si vous cliquez sur le « + » devant votre formulaire principale dans la vue « solution », vous verrez qu’une notation « standard » est adoptée :
- Form1.resx pour le formulaire par défaut
- Form1.fr-FR.resx pour le formulaire en Français
Mais quid des autres ressources ? Les textes dans les boites de messages par exemple ? C’est très simple, nous allons utiliser le même principe, mais à l’échelle de l’application.
Les règles pour les autres ressources
Pour stocker des chaines de caractère ou n’importe quelle autre ressource localisée, nous allons utiliser… un fichier ressources (avec l’extension .resx donc).
Pour ajouter un fichier de ce type au projet, il convient de cliquer à l’aide du bouton droit de la souris sur le projet, puis sur « Add New Item » et de choisir, dans la catégorie « General », le type « Resource file » : à le nommer, et cliquer sur Add.
Le fichier .resx apparait maintenant dans les fichiers du projet : reste à le remplir, en faisant bien soin au nommage des différents éléments : en effet, c’est par leur nom que nous utiliserons les ressources dans le code !
Une fois ces ressources créées, il reste à les traduire. Pour cela, nous allons tout simplement copier/coller le fichier de ressources, et le renommer, en utilisant la convention « classique » : imaginons que votre fichier s’appelle Resource1.resx, pour la langue par défaut, alors la copie de ce fichier devra s’appeler Resource1.fr-FR.resx (ou tout autre locale de votre choix !)
Reste à l’utiliser dans le code : pour cela nous allons utiliser la réflexion (c’est un terme technique du framework .NET, rien à voir avec le fait de se servir de son cerveau !) et une classe qu’on appelle le ResourceManager : voici comment c’est fait :
ResourceManager rm = new ResourceManager("DemoLMLocalisation.Resource1", typeof(Form1).Assembly);
MessageBox.Show(rm.GetString("LocalizedMessage"));
Dans ce code, on commence par initialiser le ResourceManager en lui donnant le nom de la ressource qu’on veut utiliser. Ensuite, on utiliser la méthode GetString, pour aller chercher la bonne ressource :) C’est aussi simple que 2 lignes de code !
La question qui tue : Est-ce possible de changer la langue de l’application en cours de route ?
Malheureusement, le .NET Compact Framework n’offre pas cette possibilité, qui dans le Framework .NET « de bureau » existe pourtant sous la forme de la propriété Thread.CurrentThread.CurrentCulture et Thread.CurrentThread.CurrentUICulture. Il faudrait trouver un autre moyen de le faire "programmatiquement", et ceci dépasse largement le cadre de ce simple article :)