Internationalisation des applications WinForms/WPF : resx, assemblies satellites et changement de culture en pratique

« Nous voulons utiliser la même application dans nos filiales à l’étranger » ou « du personnel non-japonophone a rejoint notre atelier, nous voulons donc aussi un écran en anglais » : formulée ainsi, l’internationalisation d’une application de bureau Windows semble simple, mais dès qu’on s’y attelle, les points d’hésitation s’enchaînent : « comment utiliser resx ? », « WPF propose plusieurs approches, laquelle est la bonne ? », « peut-on changer de langue en cours d’exécution ? ».

Cet article, en prenant pour exemple des applications métier WinForms/WPF, présente dans l’ordre où ces questions se posent en pratique : les fondations de l’internationalisation sous .NET (cultures et repli des ressources), le fonctionnement de resx et des assemblies satellites, les approches réalistes selon le framework, le changement de langue à l’exécution, et enfin les aspects qui dépassent le simple texte (formats, mise en page, RTL).

1. La conclusion d’abord (tableau de décision)

Le choix de l’approche d’internationalisation dépend de la combinaison framework/exigences.

Voici la conclusion en résumé.

• CurrentCulture (format) et CurrentUICulture (langue des ressources) sont deux choses distinctes. Cette distinction constitue le socle de toute la conception de l’internationalisation (chapitre 2).
• Les ressources reposent sur « une ressource en langue neutre + des assemblies satellites par langue », et le repli est automatique. La recherche s’effectue dans l’ordre ja-JP → ja → langue neutre, si bien qu’une traduction manquante ne fait pas planter l’application, qui affiche alors la langue par défaut².
• Pour WinForms, la solution pratique consiste à combiner l’approche du concepteur (Localizable = true) et l’approche resx partagée. Les écrans relèvent de l’approche du concepteur, tandis que les boîtes de message et les libellés communs sont regroupés dans un resx partagé (chapitre 4).
• L’approche LocBaml présentée dans la documentation officielle de WPF n’est pas utilisable sur .NET (Core)¹. L’approche à privilégier aujourd’hui est resx + x:Static (ou liaison de données) (chapitre 5).
• Pour le changement de langue à l’exécution, privilégiez « la prise d’effet au prochain démarrage ». En effet, les ressources de l’écran actuellement affiché ne sont pas remplacées automatiquement (chapitre 6).
• La traduction des chaînes ne représente que la moitié du travail d’internationalisation. L’autre moitié concerne l’adaptation de la mise en page à la longueur des chaînes traduites, le format des dates et des nombres, les polices de caractères et la prise en charge des langues s’écrivant de droite à gauche (RTL) (chapitre 7).

2. Les fondations : la différence entre CurrentCulture et CurrentUICulture

La notion de culture (paramètres régionaux) sous .NET repose sur deux propriétés aux rôles distincts³.

Ces deux propriétés peuvent être définies indépendamment l’une de l’autre. Par exemple, une combinaison comme « écran en anglais, mais dates et devises au format japonais » (une exigence fréquente pour les applications métier utilisées au Japon par du personnel non-japonophone) s’exprime naturellement avec CurrentUICulture = en et CurrentCulture = ja-JP.

Les valeurs par défaut des deux proviennent des paramètres du système d’exploitation ; le point de départ est donc « si rien n’est fait, on suit le système d’exploitation ». Lorsque l’on souhaite changer explicitement la langue pour toute l’application, il faut remplacer les valeurs par défaut plutôt que de les définir thread par thread.

using System.Globalization;

// Remplace la culture par défaut de tous les threads créés par la suite
// (à exécuter avant la création du thread d'interface utilisateur, c'est-à-dire avant Application.Run)
CultureInfo.DefaultThreadCurrentUICulture = new CultureInfo("en"); // langue des ressources
CultureInfo.DefaultThreadCurrentCulture = new CultureInfo("ja-JP"); // format

Assigner Thread.CurrentThread.CurrentUICulture n’affecte que ce thread précis. Pour les applications métier qui traversent plusieurs threads via async/await ou du traitement en arrière-plan, il est plus sûr de modifier directement les valeurs par défaut avec DefaultThreadCurrentUICulture / DefaultThreadCurrentCulture³.

Par ailleurs, le format utilisé pour les journaux, les fichiers de sortie et les échanges inter-systèmes ne doit pas suivre la culture de l’utilisateur : il doit être fixé sur CultureInfo.InvariantCulture. Pour la conception globale des formats de date, consultez « Conception des dates et fuseaux horaires dans les applications métier ».

3. Le fonctionnement des ressources : resx, assemblies satellites et repli

L’internationalisation sous .NET suit un modèle « hub-and-spoke ». Les ressources de la langue par défaut (neutre) sont intégrées à l’assembly principal, tandis que les ressources de chaque langue sont séparées dans une assembly satellite, une DLL distincte⁴.

Après compilation, les fichiers resx par langue produisent une structure de sortie de ce type.

MyApp.exe                     ← corps principal (contient les ressources neutres)
MyApp.dll
ja/MyApp.resources.dll        ← assembly satellite pour le japonais
en/MyApp.resources.dll        ← assembly satellite pour l'anglais

À l’exécution, à partir de CurrentUICulture, le gestionnaire de ressources recherche dans l’ordre culture spécifique (ja-JP) → culture neutre (ja) → ressource par défaut (assembly principal)². Grâce à ce repli automatique, l’absence d’une seule traduction ne fait pas planter l’application, qui affiche alors la chaîne de la langue par défaut. Inversement, si un écran censé être en anglais affiche partiellement du japonais, c’est le signe d’une traduction manquante, un point à surveiller lors des tests (chapitre 8).

En pratique, deux points sont à retenir.

• Déclarer la culture de la langue par défaut via l’attribut NeutralResourcesLanguage évite une recherche inutile de satellite pour la culture par défaut, et clarifie le point terminal du repli⁴.
• Une assembly satellite ne fonctionne que si elle est distribuée avec le corps principal : il faut donc inclure les dossiers de langue dans la conception de l’installateur ou du déploiement par copie (chapitre 8).

4. La pratique sous WinForms : approche du concepteur et approche resx partagée

WinForms propose deux approches, que l’on combine en pratique.

4.1 Pour les écrans, l’approche du concepteur (Localizable = true)

En réglant la propriété Localizable du formulaire sur true, puis en basculant la propriété Language vers la langue cible (par exemple l’anglais) avant de modifier la propriété Text des libellés et boutons, Visual Studio génère automatiquement un resx par langue, du type Form1.en.resx⁵.

L’atout de cette approche est que non seulement les chaînes, mais aussi la taille et la position des contrôles sont enregistrées par langue. On peut ainsi ajuster, dans le concepteur, langue par langue, le problème du bouton japonais « 登録 » qui devient « Register » en anglais et déborde du bouton. En contrepartie, le nombre de resx augmente proportionnellement au produit du nombre de langues par le nombre de formulaires, et chaque modification de mise en page d’un formulaire nécessite une vérification dans toutes les langues, ce qui engendre un coût de maintenance. Si le nombre de langues est amené à croître, privilégiez plutôt les mesures côté mise en page (chapitre 7) pour construire des écrans qui ne se cassent pas sans ajustement.

4.2 Pour les messages et libellés communs, l’approche resx partagée

Les libellés de boîtes de message, de boîtes de dialogue de confirmation, ou affichés dans la barre d’état — bref, toutes les chaînes utilisées depuis le code — sont regroupés dans un Resources.resx commun au projet, avec l’ajout de resx par langue tels que Resources.en.resx. Une classe fortement typée est générée automatiquement à partir du resx, ce qui permet de la référencer depuis le code sans risque de faute de frappe sur la clé.

// Référencé via la classe fortement typée générée.
// La chaîne renvoyée change automatiquement selon CurrentUICulture
MessageBox.Show(
    Properties.Resources.ConfirmDeleteMessage,
    Properties.Resources.ConfirmTitle,
    MessageBoxButtons.YesNo);

La règle la plus importante ici est de ne jamais coder en dur dans le code les chaînes destinées à l’utilisateur. L’effort d’internationalisation ne se joue pas dans la mise en place du mécanisme, mais dans « la récupération des chaînes codées en dur dispersées ». Même lorsque l’on n’opère qu’en une seule langue, il est déjà utile de passer par resx.

5. La pratique sous WPF : privilégier resx plutôt que LocBaml

L’internationalisation de WPF est un domaine où les informations ont tendance à se contredire. La procédure décrite dans la documentation officielle consiste à définir UICulture dans le fichier projet pour générer des ressources BAML, puis à insérer les traductions avec l’outil LocBaml — mais LocBaml est un outil d’exemple réservé à WPF sur .NET Framework et ne fonctionne pas avec WPF sur .NET (Core)¹. Ce n’est plus une approche à choisir aujourd’hui pour un nouveau projet.

En pratique, la première option consiste à référencer depuis XAML la même approche resx partagée que pour WinForms.

<!-- Après avoir défini le modificateur d'accès du resx sur Public, on le référence via x:Static -->
<Window xmlns:res="clr-namespace:MyApp.Properties"
        Title="{x:Static res:Resources.MainWindowTitle}">
    <Button Content="{x:Static res:Resources.SaveButton}" />
</Window>

L’avantage de cette approche est que le mécanisme de ressources (assemblies satellites, repli) est entièrement partagé avec WinForms, ce qui permet une gestion centralisée des libellés même dans une solution mixte. x:Static étant une référence statique résolue au démarrage, si un changement à l’exécution est requis, il faut évoluer vers une liaison de données avec notification de changement (chapitre 6).

Côté XAML, définir également l’attribut xml:lang sur l’élément racine permet aux fonctionnalités de WPF dépendantes de la langue — césure, repli de police, affichage des nombres — de fonctionner correctement¹.

Pour le choix même entre WinForms et WPF, consultez « Tableau de décision WinForms / WPF / WinUI ».

6. Le changement de langue à l’exécution : privilégier « la prise d’effet au prochain démarrage »

Lorsque l’exigence est de permettre à l’utilisateur de choisir la langue dans un écran de paramètres, deux options s’offrent quant au moment de la prise d’effet.

• Option A : prise d’effet au prochain démarrage (recommandée). La langue choisie est enregistrée dans un fichier de configuration, et DefaultThreadCurrentUICulture est défini avant Application.Run (ou avant le démarrage de Application pour WPF). L’implémentation est simple, et les dysfonctionnements liés à la reconstruction de l’écran (perte de données en cours de saisie, double enregistrement de gestionnaires d’événements, etc.) ne peuvent structurellement pas se produire.
• Option B : prise d’effet immédiate. Modifier CurrentUICulture ne remplace pas automatiquement les chaînes des écrans déjà affichés. Avec l’approche du concepteur sous WinForms, il faut réappliquer les ressources aux formulaires ouverts via ComponentResourceManager.ApplyResources ; sous WPF, il faut fournir les chaînes via une liaison de données avec notification de changement. Dans les deux cas, cela suppose que « tous les écrans prennent en charge la réapplication des ressources ».

Pour les applications métier, le coût d’implémentation et de test de l’option B est souvent disproportionné par rapport à la fréquence des changements de langue (généralement une seule fois, à la mise en place), c’est pourquoi il est recommandé de retenir l’option A par défaut, et de ne recourir à l’option B que si l’exigence l’impose vraiment. Le paramètre de langue, étant propre à chaque utilisateur, doit être enregistré sous %LOCALAPPDATA%. Pour le choix de l’emplacement de stockage des paramètres, consultez le tableau de décision de « Gestion pratique de la configuration des applications métier Windows ».

7. Au-delà des chaînes : mise en page, formats, polices et RTL

Même une fois la traduction achevée, il reste encore la moitié du travail d’internationalisation.

• L’élasticité de la mise en page. Pour un même sens, la longueur du texte varie fortement d’une langue à l’autre (japonais « 保存 » → allemand « Speichern »). Une mise en page à coordonnées et tailles fixes se casse à chaque traduction ; sous WinForms, la méthode officiellement recommandée consiste à combiner TableLayoutPanel et AutoSize pour obtenir une mise en page qui s’adapte à la longueur du texte⁶. Le système de mise en page de WPF étant nativement flexible, il suffit dans la plupart des cas d’éviter de figer des largeurs. Il est également judicieux de concevoir en parallèle la résistance aux environnements haute résolution (« Guide du haut DPI sous WinForms », « Guide du haut DPI sous WPF »), pour éviter de refaire le travail par la suite.
• Le format des dates, des nombres et des devises. Laissez CurrentCulture gérer l’affichage à l’écran, et réduisez les appels codés en dur du type ToString("yyyy/MM/dd") dans le code d’interface. À l’inverse, fixez sur InvariantCulture les fichiers, journaux et données d’échange (chapitre 2).
• Les polices. Vérifiez que les caractères de la langue cible sont bien présents dans la police utilisée. Lors de l’ajout du chinois (simplifié ou traditionnel) ou du coréen, conserver une police pensée pour le japonais peut produire des glyphes peu naturels (le fameux problème des glyphes CJK). Centraliser en un seul endroit la spécification de la police d’interface facilite les modifications lors de l’ajout d’une langue.
• Les langues s’écrivant de droite à gauche (RTL). La prise en charge de l’arabe ou de l’hébreu nécessite, en plus de la traduction des chaînes, un renversement gauche-droite de l’écran. WinForms le gère via les propriétés RightToLeft / RightToLeftLayout, et WPF via la propriété FlowDirection. Ajouter le support RTL après coup implique de revoir tous les écrans ; s’il existe une possibilité que ces langues soient un jour prises en charge, incluez cette exigence dès le départ.
• Le texte intégré dans les images et icônes. Une chaîne incrustée dans une image ne peut pas être changée par le mécanisme de ressources. Il est plus sûr d’éviter les images contenant du texte et de privilégier une combinaison image + étiquette textuelle.

Pour la conception UX en général, consultez également « Tableau de décision pour la conception UX des applications Windows ».

8. Exploitation : transmission des traductions, détection des manques et distribution

Enfin, quelques aspects opérationnels une fois le mécanisme en place.

• Fournir du contexte lors de la transmission des traductions. Transmettre uniquement la clé resx et le texte original nuit à la stabilité de la traduction pour des libellés courts comme « OK » ou « Ouvrir ». Il est plus réaliste d’échanger via un tableau de correspondance (feuille de calcul, par exemple) associant clé, texte original, traduction et « l’écran et l’usage concernés », puis de reporter dans le resx une fois reçu.
• Détecter les traductions manquantes grâce au repli. Le mécanisme de repli des ressources fait qu’une traduction manquante se manifeste par « la langue par défaut qui se mélange à l’écran de cette langue »². Intégrer dans la CI une vérification simple (script ou test) qui compare la liste des clés de chaque resx par langue avec le resx neutre permet de détecter mécaniquement ces manques avant la publication.
• Inclure les assemblies satellites dans la distribution. Sans distribuer les dossiers de langue tels que ja/ ou en/, la langue correspondante retombe systématiquement en repli, donnant l’impression que « la traduction est faite mais ne s’applique pas ». L’oubli d’un dossier de langue lors d’une copie manuelle est un incident classique ; il faut donc inclure toute la structure de répertoires dans l’installateur (MSI/MSIX, etc.). Avec la distribution ClickOnce, les assemblies satellites de toutes les langues sont incluses par défaut dans le déploiement⁷. Pour le choix global du mode de distribution, consultez « Comment choisir un mode de distribution pour une application Windows ».

Résumé

L’internationalisation d’une application de bureau repose sur des mécanismes éprouvés — resx et assemblies satellites — et le mécanisme lui-même n’est pas complexe. Ce qui détermine le succès en pratique, ce sont une conception qui distingue bien CurrentCulture et CurrentUICulture, la discipline de ne jamais coder en dur les chaînes destinées à l’utilisateur, une mise en page capable d’absorber la longueur des chaînes traduites, et un examen sérieux de l’exigence « le changement immédiat est-il vraiment nécessaire ? ». Pour WPF, il ne faut pas se laisser entraîner par les anciennes informations sur LocBaml : construire sur une base resx est aujourd’hui la solution pratique de référence.

Le choix d’une approche pour internationaliser une application existante et l’estimation du périmètre impacté, ainsi que la prise en charge multilingue des écrans, des états imprimés et des données d’échange en vue d’un déploiement dans des filiales à l’étranger, nécessitent souvent un jugement fondé sur l’état réel de la base de code : n’hésitez pas à nous consulter en cas de doute.

Articles connexes

• Tableau de décision WinForms / WPF / WinUI
• Tableau de décision pour la conception UX des applications Windows
• Conception des dates et fuseaux horaires dans les applications métier
• Guide du haut DPI sous WinForms
• Guide du haut DPI sous WPF
• Pas seulement appsettings.json : gestion pratique de la configuration des applications métier Windows
• Comment choisir un mode de distribution pour une application Windows (MSI / MSIX / ClickOnce / xcopy / outil de mise à jour maison)
• Le fonctionnement des profils utilisateur Windows

Domaines de conseil associés

Komura Soft LLC prend en charge le conseil technique sur la conception et l’implémentation de la prise en charge multilingue des applications WinForms/WPF, ainsi que sur le choix d’une approche et l’analyse du périmètre impacté lors de l’internationalisation a posteriori d’une application existante.

• Développement d’applications Windows
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Peut-on internationaliser après coup une application existante conçue uniquement en japonais ?

C'est possible, mais l'essentiel du travail ne consiste pas à « mettre en place le mécanisme de ressources » : il s'agit surtout de « recenser et remplacer les chaînes codées en dur dans le code ». L'inventaire ne doit pas se limiter aux chaînes affichées à l'écran : il faut aussi couvrir les boîtes de message, les journaux, les messages d'exception, les états imprimés et les chaînes d'affichage stockées en base de données. L'ampleur du chantier dépend moins du nombre d'écrans que de la dispersion des chaînes de caractères. Si, dès la phase de développement initial, seules les chaînes destinées à l'utilisateur passent par resx, le coût futur d'internationalisation sera considérablement réduit.

Peut-on se contenter d'une traduction automatique ?

Pour un outil interne ou une réponse provisoire, démarrer avec une traduction automatique est réaliste. Cependant, les applications métier comportent de nombreux termes courts dans les boutons et menus (par exemple « Enregistrer », « Annuler »), et l'absence de contexte augmente le taux d'erreur de la traduction automatique dans ce type de contenu. Il est recommandé de prévoir a minima un cycle de relecture par une personne utilisant réellement cette langue. Avant même la qualité de la traduction, il est plus important de garantir en amont, via TableLayoutPanel et AutoSize, que la mise en page ne se casse pas avec des chaînes traduites plus longues.

Faut-il aussi traduire les journaux et les messages d'erreur ?

La règle de l'art consiste à traduire les messages affichés à l'écran pour l'utilisateur, mais à ne pas traduire le contenu écrit dans les fichiers de journalisation ou le journal des événements (en fixant la langue). Les journaux sont lus par les développeurs et les équipes d'exploitation, pas par l'utilisateur final, et des journaux multilingues nuisent à la recherche lors des investigations. Le format (dates, nombres) des journaux doit également être fixé sur CultureInfo.InvariantCulture. Une conception qui distingue clairement CurrentCulture et CurrentUICulture permet d'appliquer naturellement cette séparation.

Faut-il permettre de changer la langue de l'application indépendamment de la langue d'affichage du système d'exploitation ?

Pour un déploiement dans des filiales à l'étranger, ou pour une application métier utilisée au Japon par du personnel non-japonophone, disposer d'un paramètre de langue propre à l'application a une réelle valeur. Une approche prudente consiste à suivre par défaut la langue d'affichage du système d'exploitation (valeur par défaut de CurrentUICulture) et à ne l'écraser que lorsque l'utilisateur l'a choisie explicitement dans l'écran de paramètres. Prévoir que le changement ne prenne effet qu'« au prochain démarrage » est l'option la plus sûre : elle simplifie à la fois l'implémentation et l'explication opérationnelle.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.