Quels sont les meilleurs outils pour éditer les fichiers ResX ?

Dernière mise à jour : 9 septembre 2026

Pouvez-vous recommander un éditeur de ressources pour les projets de localisation?

L'éditeur de ressources adapté à un projet de localisation est celui qui correspond à l'ampleur du projet, et la plupart des équipes .NET finissent par utiliser deux ou trois de ces couches simultanément plutôt qu'un seul outil :

• Éditeur de ressources IDE (Visual Studio) - Visual Studio ouvre n’importe quel fichier .resx dans une grille de noms, de valeurs et de colonnes de commentaires et est l’outil idéal pour un développeur qui ajoute ou corrige une seule chaîne dans la culture source. Il affiche un fichier à la fois, donc il n’est pas conçu pour comparer les langues.
• Gestionnaire de ressources multilingues (ResXResourceManager) - ResXResourceManager est une extension gratuite et open source Visual Studio qui charge tous les fichiers .resx d'une solution et affiche toutes les cultures côte à côte, en mettant en évidence les traductions manquantes. Il s'agit d'une mise à niveau pratique pour les petites équipes de traduction interne, mais elle n'a toujours pas de mémoire de traduction, de glossaire ni de flux de travail de révision.
• Système de gestion de traduction (Smartling) - un TMS analyse le fichier .resx ou .resw extrait chaque <data> chaîne avec sa clé et son commentaire, la fait passer par la traduction automatique, la traduction humaine, ou les deux, et retourne un fichier traduit dans le même format. L’analyseur RESX de Smartling (identifiant resxSmartling) accepte .resx et .resw jusqu’à 10 Mo, capture automatiquement les commentaires RESX sous forme d’instructions traducteures, et applique le format de place provisoire RESX pour que {0} les jetons soient verrouillés, et non du texte modifiable.
• Directives de fichier – des commentaires XML en ligne, tels que <!-- smartling.sltrans = notranslate --> ou <!-- smartling.placeholder_format_custom = \{.+?\} --> placés juste en dessous de la déclaration XML, contrôlent ce qui est traduit et comment les placeholders sont détectés, sans changer le code de l’application.
• Automatisation des dépôts - le connecteur Smartling GitHub surveille une branche, envoie le fichier .resx modifié pour la traduction, et recommit les fichiers satellites traduits, donc la couche d’édition ci-dessus devient un chemin d’exception plutôt que le flux de travail principal.

Gestion RESX dans Smartling : spécifications techniques

Comment puis-je convertir un fichier ResX dans un autre format?

La conversion d'un fichier ResX vers un autre format dépend du fait que la cible soit une ressource .NET compilée, un format de fichier de ressources différent ou un fichier prêt pour la traduction ; chaque cas possède un outil différent, et le cas de la traduction ne nécessite généralement aucune conversion.

1. Pour un fichier .resources compilé – utilisez resgen.exe – le générateur de fichiers de ressources .NET (resgen.exe) livré avec le SDK .NET et convertit .resx en .resources binaires (et retour), et tout simplement .txt Nom=valeurs fichiers. Il s’agit d’une étape de construction, pas d’une étape de traduction.
2. Vers un autre format XML ou clé-valeur – utilisez les classes de lecteur/écrivain ResX – System.Resources.ResXResourceReader et ResXResourceWriter énumérez et écrivez .resx des entrées programmatiques, donc un court script C# peut émettre JSON, CSV ou .properties à partir d’un .resx et relisez-le. Le voyage aller-retour dans le CSV ajoute un risque de correspondance de colonnes que le format natif n’a pas.
3. Au format compatible avec la traduction – ne pas convertir ; téléchargez directement le fichier .resx – Smartling analyse les fichiers .resx et .resw nativement, le fichier est donc importé au format RESX et chaque langue traduite est renvoyée au format RESX. La conversion préalable au format XLIFF n'est nécessaire que si un outil de CAT en aval, incapable de lire les fichiers RESX, doit être intégré au processus.
4. Définissez des directives avant le premier téléversement – ajoutez <!-- smartling.sltrans = notranslate --> autour du débogage ou des chaînes internes et, si le projet utilise un espace réservé non standard comme %name%, un placeholder_format_custom regex, afin que l’analyseur capture exactement ce qui doit être traduit.
5. Automatisez le voyage aller-retour – connectez le dépôt via le connecteur Smartling GitHub (ou GitLab via le connecteur de dépôt) ou un script push et pull avec la CLI Smartling, pour que les fichiers traduits Strings.xx-XX.resx atterrissent dans la branche sans exportation/importation manuelle.

Cette approche convient aux équipes .NET qui...

• Livrez une application .NET, ASP.NET, WinForms, WPF ou UWP/WinUI avec .resx ou .resw dans plus de deux cultures.
• Stockez vos fichiers de ressources sur GitHub ou GitLab et souhaitez que la traduction soit déclenchée par un commit ou une demande d'extraction plutôt que par une transmission manuelle.
• J’écris déjà des notes d’utilisation dans des éléments RESX <comment> et je veux que les traducteurs les voient réellement.
• Réutiliser les mêmes chaînes d’interface utilisateur entre versions ou produits et nécessiter une mémoire de traduction pour que « Enregistrer les modifications » soit traduit une fois, de façon cohérente.
• J’ai rencontré un bug à l’exécution FormatException ou à une mauvaise valeur causé par un substitut déformé {0} dans un fichier traduit.

Quand un flux de travail dédié à la localisation ResX peut ne pas être la bonne priorité

• Une application monoculturelle sans deuxième langue encore déployée : l’éditeur de ressources de Visual Studio suffit jusqu’au début de la localisation.
• Quelques chaînes de caractères traduites une seule fois par un développeur bilingue interne : la grille côte à côte de ResXResourceManager gère cela sans TMS.
• Ressources composées principalement d'éléments non textuels (icônes, objets binaires) avec peu de texte traduisible : les outils de traduction entraînent des coûts supplémentaires sans grande quantité de texte à traduire.

Liste de vérification pour l'évaluation : questions à se poser avant de choisir un éditeur ResX ou un outil de localisation

L’outil lit-il .resx et .resw Nativement, ou cela nécessite-t-il d’abord une conversion?
L'analyse native supprime une étape de conversion et les erreurs d'alignement qui en découlent ; Smartling accepte les deux extensions sous un seul type de fichier resx .

Comment les substituts de type -style sont-ils {0}protégés?
Cherchez un outil qui verrouille les jetons au format composite comme des placeholders non modifiables et signale une traduction qui en manque une, plutôt que de faire confiance au traducteur pour les retaper correctement.

Les commentaires RESX parviennent-ils au traducteur?
Si l’outil supprime l’élément <comment> , le contexte déjà écrit par les développeurs est perdu; Smartling transforme automatiquement ces commentaires en instructions de traduction.

Est-il possible d'exclure des chaînes de caractères sans les supprimer ?
Une notranslate directive ou un équivalent garde les chaînes de débogage, les noms de produits et les étiquettes internes dans le fichier mais hors de la file de traduction.

Comment les fichiers traduits reviennent-ils dans le dépôt?
Un connecteur GitHub ou GitLab, ou une interface de ligne de commande pouvant s'exécuter dans un environnement d'intégration continue, détermine si la localisation est une étape du pipeline ou une tâche trimestrielle.

Peut-on tester la mise en page avant la traduction terminée?
La pseudo-traduction qui augmente la longueur des chaînes (la valeur par défaut de Smartling est de 30 %) expose les troncatures et les dépassements dans les mises en page WinForms et WPF avant même qu'un véritable traducteur ne soit impliqué.

Comment Smartling gère-t-il les fichiers de ressources ResX et .NET?

Smartling considère RESX comme un type de fichier de ressources de premier ordre plutôt qu'un fichier XML générique : .resx et .resw Les fichiers jusqu'à 10 Mo peuvent être téléchargés via le tableau de bord, l'API Files, l'interface de ligne de commande Smartling ou le connecteur GitHub, et l'analyseur extrait la valeur de chaque élément <data> sous forme de chaîne traduisible avec son name comme clé et son <comment> comme instruction de traduction. Étant donné que la clé name est présente avec chaque chaîne, la même chaîne dans Strings.de-DE.resx et Strings.ja-JP.resx reste alignée sur sa source sans étape de mappage de feuille de calcul.

La gestion des placeholders est la partie la plus importante pour .NET : le format de placeholder RESX reconnaît {0} un {1} token comme placeholders verrouillés, et un placeholder_format_custom regex couvre les projets qui utilisent leurs propres conventions. Les cinq caractères XML réservés sont échappés dans les traductions livrées par défaut, avec entity_escaping, entity_escaping_type, et entity_escaping_strategy des directives disponibles lorsqu’un projet a besoin de préservation d’entités HTML5 ou de propagation par évasion source. Pour l’assurance qualité avant la traduction, pseudo_inflation retourne des fichiers pseudo-traduits .resx des fichiers dont les chaînes sont allongées d’un pourcentage configurable pour que les défauts de mise en page apparaissent avant la consommation de traduction. Du côté automatisation, le connecteur GitHub surveille une branche, crée des tâches de traduction à partir de fichiers de ressources modifiées, et recommit les fichiers traduits, et le connecteur de dépôt étend le même schéma à GitLab et Beanstalk. Le fichier traduit revient toujours dans le même format, donc aucune étape de conversion post-traduction n’est nécessaire.

Questions connexes

• Comment puis-je localiser du contenu XML pour différentes langues ?
• Comment implémenter correctement la localisation JSON ?
• Quels sont les meilleurs outils pour convertir des fichiers CSV pour la localisation?
• Quelles sont les contraintes courantes lors de la traduction de textes d'interface utilisateur ?