Les fichiers resx sont-ils adaptés à l'internationalisation?

Question

On m'a confié la tâche d'internationaliser une grande application client-serveur. La mission consiste à créer l'application "World Ready", puis l'application et les ressources compilées sont transmises à des collègues d'un autre pays, qui les traduisent et les diffusent à leurs clients. Il y aura plusieurs pays et donc plusieurs traductions distinctes.

L'important ici est que je souhaite un processus de validation simple en deux étapes:

Étape 1: je compile et publie une application "Prêt pour le monde" destinée à mes collègues des différents pays

Étape 2: ils localisent les ressources puis les communiquent à leurs clients

.

Je ne souhaite pas ajouter les étapes supplémentaires de Rendre l’application mondiale prête - > Envoyer des fichiers à la traduction - > Attendez des semaines que les traductions reviennent - > Compiler dans une application - > Publier l'application .

Je me suis intéressé à la mondialisation .NET et à l’utilisation du fichier resx. D'après ce que j'ai vu, le fichier resx est compilé dans l'application et ne peut donc pas être modifié une fois compilé. Même les assemblages satellites ne semblent pas éditables. Et même si je me trompe sur ce point, comment les modifications apportées aux assemblages satellites seront-elles reflétées dans les fichiers resx de mon projet?

Alors maintenant pour la question. Étant donné que je veux juste d'abord compiler l'application et laisser les traductions gérées par la suite, les fichiers resx sont-ils la bonne solution ou dois-je les abandonner et écrire une solution sur mesure basée sur une base de données qui peut être facilement modifiée après l'application? été compilé?

J'espère que tout a du sens. Attendez-vous à vos pensées.

Answer 1

Oui, les fichiers resx sont la meilleure solution.

Pour traduire les ressources, consultez un outil de localisation, par exemple Passolo . Il fait soit

• prend le resx d'origine en entrée et génère un fichier resx traduit que vous devez archiver dans votre base de code
• prend en entrée les assemblys compilés et génère des assemblys satellites.

Nous traduisons des assemblages, car cela permet également de localiser la disposition de l'interface graphique. Pour permettre à un outil externe d’ouvrir un éditeur graphique, il a besoin du code, qui se trouve dans l’assemblage.

Si vous vous concentrez uniquement sur la traduction test, la traduction de resx est probablement plus simple à gérer.

Un tel outil externe fournit ces fonctionnalités importantes:

• rassemblez toutes les chaînes, vous n'avez pas à gérer des centaines de fichiers resx
• gérer les textes de traduction de nombreuses langues, principalement avec le concepteur d'interface graphique.
• reconnaît si un texte source a été modifié ou s'il a été ajouté. Vous devez maintenant indiquer quels textes doivent être traduits.
• traduction des textes dupliqués une seule fois.
• généralement agréable à utiliser pour modifier les traductions.
• exportation / importation au format CSV et formats similaires à traiter par d’autres outils, voire par d’autres entreprises.

Answer 2

Oui, l’ensemble de la structure de mondialisation de .NET est basée sur les fichiers RESX et les assemblys satellites qu’ils créent. Une fois que vous avez compilé l'application principale, les fichiers RESX peuvent être compilés indépendamment dans leurs assemblages satellites.

Je sais qu'il existe des outils qui facilitent le processus de traduction, mais je ne suis pas familier avec aucun de ceux-ci.

Answer 3

Vérifiez le fournisseur de ressources de Rick Strahl

.