Pourquoi votre application C# a-t-elle besoin d'internationalisation ?
\nImaginez : vous avez créé un super service de gestion de notes. Tout fonctionne, l'interface est épurée, les utilisateurs sont satisfaits. Mais uniquement les francophones. Dès que vous vous lancez sur le marché américain ou allemand, le projet s'arrête. Non pas parce que le code est mauvais, mais parce que le bouton « Сохранить » ne se transforme pas en « Save », et que le message « Ошибка ввода » effraie l'étranger.
\nC'est le problème de la localisation. Dans le monde .NET, sa solution s'appelle l'internationalisation C# (ou i18n — du mot « internationalization », où 18 est le nombre de lettres entre i et n). Si vous utilisez C# et la plateforme .NET (Core, 5/6/7/8/9), vous disposez déjà d'une boîte à outils très puissante pour rendre votre application multilingue. Dans cet article, nous allons l'explorer en pratique : des ressources simples au changement de langue « à la volée ».
\n\nLes bases : qu'est-ce que la culture et la langue neutre
\nAvant d'écrire du code, clarifions les termes. Dans .NET, deux classes clés de l'espace de noms System.Globalization sont responsables de la localisation :
- \n
- CultureInfo — un objet qui décrit la langue et les normes régionales (par exemple,
ru-RU,en-US,de-DE). \n - CurrentUICulture — la culture actuelle de l'interface utilisateur. C'est sur elle que le système se base pour trouver les traductions. \n
- CurrentCulture — le format des dates, des nombres, de la devise. On peut aussi le changer, mais pour les traductions, le premier est important. \n
Dans les applications C#, nous utilisons généralement des fichiers de ressources (.resx). Ce sont des fichiers XML qui stockent des chaînes, des images et d'autres données liées à une culture spécifique. Par exemple :
\n- \n
Messages.resx— chaînes par défaut (généralement en anglais). \n Messages.ru.resx— traduction russe. \n Messages.de.resx— traduction allemande. \n
Lorsque l'application démarre, .NET sélectionne automatiquement le fichier correspondant à la UICulture actuelle. S'il n'y a pas de correspondance exacte, il utilise le fichier neutre (de base).
Création du premier fichier de ressources dans Visual Studio
\nSupposons que nous ayons une application console ou un projet ASP.NET Core. Ajoutons un dossier Resources et, à l'intérieur, un fichier Strings.resx. Remplissons-le :
Nom | Valeur\n--------------|-------------------\nWelcomeMsg | Welcome to our app!\nGoodbyeMsg | Goodbye!\n\nCréons maintenant Strings.ru.resx :
Nom | Valeur\n--------------|-------------------\nWelcomeMsg | Добро пожаловать в наше приложение!\nGoodbyeMsg | До свидания!\n\nRemarque : les noms des clés doivent correspondre. Après l'enregistrement, Visual Studio génère automatiquement la classe Strings avec un accès aux chaînes via des propriétés statiques.
Changement de langue par programmation
\nPour que l'internationalisation C# fonctionne, vous devez définir la culture souhaitée au début de l'exécution de l'application (par exemple, dans Main ou Startup). Voici à quoi cela ressemble :
using System.Globalization;\nusing System.Threading;\n\n// Définit la langue de l'interface en russe\nCultureInfo culture = new CultureInfo("ru-RU");\nThread.CurrentThread.CurrentUICulture = culture;\nThread.CurrentThread.CurrentCulture = culture; // pour les formats de date/nombre\n\n// Maintenant, on accède aux ressources\nConsole.WriteLine(Strings.WelcomeMsg); // Affiche : Добро пожаловать в наше приложение!\n\nSi vous souhaitez permettre à l'utilisateur de changer de langue « à la volée » (sans redémarrage), appelez simplement ces lignes à nouveau après avoir changé la culture. Dans ASP.NET Core, on utilise un middleware pour cela :
\napp.UseRequestLocalization(new RequestLocalizationOptions\n{\n DefaultRequestCulture = new RequestCulture("en-US")