Traduire une application .NET en anglais : fichiers .resx

Un .resx vers l'anglais : ce qui se joue dans le projet

Dans un projet .NET, chaque texte d'interface est une entrée <data name="BtnSave"> qui contient une <value> et souvent un <comment>. La version anglaise est un fichier distinct posé à côté du fichier neutre : Strings.resx (français) et Strings.en.resx, ou Strings.en-GB.resx et Strings.en-US.resx si vous visez les deux variantes.

À l'exécution, .NET cherche d'abord la culture exacte (en-GB), puis la culture parente (en), puis revient au fichier neutre. Conséquence directe : une clé absente ou non traduite dans la version anglaise s'affiche en français, sans erreur. C'est le premier symptôme à surveiller après réintégration.

L'anglais est en général 10 à 15 % plus court que le français : « Enregistrer les modifications » devient « Save changes ». Les boutons et colonnes gagnent de la marge. Dans les formulaires WinForms, dont le .resx stocke aussi tailles et positions des contrôles, cette marge est surtout utile là où le dimensionnement automatique est désactivé.

Les particularités de l'anglais dans une interface .NET

• Variante. Décidez avant de traduire : colour ou color, organise ou organize, cancelled ou canceled. Mélanger les deux dans une même interface se remarque vite. Si vous servez les deux publics, prévoyez deux fichiers en-GB et en-US.
• Pluriels. L'anglais n'a que deux catégories, one et other, comme le français, mais pas avec la même frontière : le français écrit « 0 fichier », l'anglais « 0 files ». Si votre code choisit la clé avec count <= 1 ? FileCount_One : FileCount_Other, l'anglais affichera « 0 file ». La condition doit devenir count == 1 pour cette culture. Le .resx n'a pas de mécanisme de pluriel : ce sont deux clés et une décision dans le code.
• Ponctuation. Pas d'espace avant les deux-points ni le point d'interrogation : « Nom : » devient « Name: ». Les guillemets « » deviennent des guillemets anglais.
• Majuscules. Les titres et boutons suivent soit la casse de phrase (« Save changes »), plus courante en anglais britannique, soit la casse de titre (« Save Changes »), fréquente aux États-Unis. Choisissez une règle et tenez-la.
• Dates. Le britannique écrit 03/04/2025 pour le 3 avril, l'américain 04/03/2025. Un format comme dd/MM/yyyy écrit en dur dans une valeur n'est pas traduit : préférez les formats standard de CultureInfo, comme {0:d}.

Ce que Manuce rend exactement, et ce qu'il ne fait pas

Vous déposez votre fichier .resx ; vous récupérez le même fichier, dans le même format, prêt à remettre dans le projet :

• les éléments data/value sont traduits ; les <comment> servent de contexte au moteur et ne sont pas modifiés ;
• les ressources non textuelles (images, icônes, tailles et positions de contrôles) restent intactes ;
• indentation, ordre des clés, guillemets, commentaires, fins de ligne, encodage et BOM sont conservés ; seules les valeurs changent ;
• ne sont pas traduits : les clés, les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date, les identifiants et tout ce qui est marqué non traduisible.

Chaque valeur traduite est comparée à la source : {0}, {1:N2} ou une balise <b> doivent s'y retrouver. Si un écart persiste, la valeur source est gardée et le rapport le signale : vous savez quelle chaîne restera en français dans la version anglaise et pourquoi.

Manuce ne modifie pas votre code : il ne corrige pas la logique de pluriel, ne régénère pas le .Designer.cs et ne va pas chercher les chaînes écrites en dur dans le C# ou le XAML. Il ne renomme pas non plus le fichier : le placer sous Strings.en.resx ou Strings.en-GB.resx vous revient. Le prix porte sur les mots des valeurs, clés et balises exclues.

Préparer le .resx avant l'envoi

• Lever les ambiguïtés par les commentaires. « Valider » peut donner Validate, Confirm ou Submit ; « Ouvert » peut être Open (état) ou Opened (action passée). Un commentaire comme « Bouton d'envoi du formulaire, 12 caractères max » oriente la traduction.
• Supprimer les concaténations. Une phrase découpée en "Supprimé par " + user + " le " + date ne se traduit pas proprement : « le » devient on devant une date, autre chose ailleurs. Regroupez-la en une seule valeur : Supprimé par {0} le {1}, qui donnera Deleted by {0} on {1}.
• Séparer singulier et pluriel. Créez FileCount_One et FileCount_Other plutôt qu'une valeur « fichier(s) », qui n'a pas d'équivalent naturel en anglais.
• Marquer ce qui ne bouge pas. Noms de produit, codes ou libellés techniques à garder tels quels : marquez-les non traduisibles.
• Vérifier les paramètres. Un {0} ouvert sans fermeture dans la source sera rejeté au contrôle ; corrigez-le avant envoi.

Vérifier après réintégration

1. Lisez le rapport : chaque chaîne laissée en français y figure avec sa raison.
2. Placez le fichier sous le nom de culture choisi, puis compilez : un dossier en ou en-GB contenant l'assembly satellite doit apparaître dans la sortie.
3. Forcez la culture pour tester, par exemple CultureInfo.CurrentUICulture = new CultureInfo("en-GB"), et parcourez les écrans : tout texte français restant signale une clé manquante ou une valeur conservée.
4. Testez les compteurs à 0, 1 et 2, les messages composés avec {0} et les libellés suivis de deux-points.
5. Contrôlez la variante : un color dans une interface en en-GB se corrige en une ligne.

Pour une interface livrée à des clients, le niveau Professionnel ou Premium convient ; Essentiel suffit pour une version de test interne.

En pratique

1. Choisissez la variante d'anglais (en, en-GB ou en-US) et complétez les commentaires des chaînes ambiguës.
2. Déposez le fichier .resx neutre : le devis s'affiche aussitôt, calculé sur les mots des valeurs.
3. Consultez l'extrait gratuit au niveau choisi, puis lancez la traduction.
4. Renommez le fichier rendu selon la culture, ajoutez-le au projet et compilez.
5. Lisez le rapport et testez l'application avec la culture anglaise forcée.