Globaliser une application Windows Forms existante?

Question

J'ai une application winforms existante développée en utilisant VS 2005 et .net framework 2.0.

Maintenant nous devons globaliser cette application. Les deux lieux sont l'allemand et le japonais.

Je sais que nous pouvons utiliser la propriété localisent de formulaire pour créer des ressources de forme localisée et peut avoir d'autres fichiers de ressources pour les chaînes utilisées dans des boîtes de message, exceptions, etc. ..

Je veux savoir la meilleure approche pour globaliser une application existante , devrais-je définir la propriété localiser sur chaque formulaire ou existe-t-il un outil qui extraira les noms des étiquettes et les noms de contrôle? Quelles considérations doivent être prises pour les formats de date, devise, etc

Nous avons également utilisé un composite chaînes dans certains endroits dans le code pour concaténer les chaînes de messages, comment ceux-ci peuvent être localisés?

Nous migrerons l'application vers VS 2008 et .net framework 3.5 avant de commencer l'activité de globalisation.

Answer 1

Je n'ai travaillé qu'avec les langages LTR et je n'ai pas touché au japonais. Dans cet esprit, voici quelques-unes de mes meilleures pratiques du haut de ma tête:

• Mettez toutes les chaînes de programmation spécifique à la langue et des fragments de chaîne dans un fichier .resx (je préfère utiliser un fichier .resx par boîte de dialogue), puis appelez les chaînes à l'aide des classes et des propriétés générées automatiquement. Il ne doit pas rester de chaînes spécifiques à la langue dans votre code (ce qui signifie quasiment aucune chaîne dans votre code, période). Un bon exemple est de mettre aussi des chaînes de formatage dans le .resx, puisque la syntaxe d'un langage varie.
• Définissez la propriété Localizable sur True sur tous vos formulaires et apportez directement les modifications spécifiques à la langue (utilisez la propriété Language).
• Créez vos formulaires de manière à ce que tout ce qui affiche des chaînes spécifiques à la langue dispose d'un espace supplémentaire lorsque nécessaire (remarque: l'allemand est plus long que l'anglais). IMO, les formulaires ne devraient pas avoir à être complètement réarrangés pour un changement fondamental dans la langue - cela peut être fait avec une langue comme le japonais, cependant.
• Pour les contrôles tels que les étiquettes dont le texte doit être défini de manière dynamique, définissez le texte sur le formulaire pour que vous sachiez qu'il s'agit uniquement d'un marqueur. J'utilise "##" pour cela, ce qui ressort vraiment. Évitez de définir le texte sur un "échantillon" du texte dynamique, car vous ne vous souviendrez jamais des contrôles qui sont définis dynamiquement en regardant simplement le formulaire.

Answer 2

Si vous utilisez Visual Source Safe comme contrôle de source (vous ne l'êtes pas), quoi que vous fassiez, ne pas ajouter du texte japonais dans votre code source lui-même. Bien que Visual Studio puisse gérer les fichiers source Unicode, VSS ne les gère pas correctement. J'ai travaillé sur une application qui s'est traduite en japonais, et l'inclusion du japonais dans le code source lui-même (pour les appels à une fonction MessageBox) a corrompu les fichiers, et comme VSS est basé sur les différences, les fichiers étaient corrompu tout le chemin du retour aux versions originales enregistrées. Cette corruption a pris la forme de la plupart des fichiers de code transformés en charabia à base de caractères japonais, et s'est produite parce que VSS a décalé d'un octet des parties des fichiers CS basés sur unicode (qui utilisaient deux octets par caractère). La correction de ces fichiers nécessitait beaucoup de travail manuel, avec mon patron regardant par-dessus mon épaule et criant à quel point nous étions condamnés, alors ne faites pas ça.

De plus, voici quelques questions stackoverflow sur ce sujet:

Best way to implement multi-language/globalization in large .NET project

Best practice to make a multi language application in C#/WinForms?

Personnellement, je préfère une méthode plus simple. Créez une liste dans Excel ou une partie de chaque texte anglais dans l'application à traduire (contrôlez les propriétés de texte, les chaînes à utiliser dans les fonctions de MessageBox, etc.) et envoyez les feuilles de calcul à vos traducteurs. Dans votre application, appelez une méthode dans l'événement Load de chacun de vos formulaires qui itère à travers tous les contrôles du formulaire et modifie leurs propriétés Text pour les valeurs traduites. Remplacez tous les appels à MessageBox par des appels à une fonction intermédiaire qui traduit le texte à afficher, puis appelle MessageBox avec le texte traduit. L'utilisation des méthodes de globalisation intégrées demande beaucoup de travail, car vous devez créer manuellement chaque formulaire globalisé, puis remplacer manuellement tout le texte par les traductions, et cette tâche exige à peu près que le programmeur parle couramment. La méthode que je mentionne est faite par programme, et ne nécessite pas que le programmeur parle couramment les langues traduites.

Answer 3

Si vous souhaitez que la communauté localise, utilisez un fichier XML externe. Regardez http://www.codeplex.com/url2jpeg, ce projet open source est localisé de cette façon et utilise Reflection pour la localisation automatique des formulaires.

Pour la chaîne, utilisez simplement une étiquette cachée.

Answer 4

Il est préférable de définir la propriété de localisation sur chaque formulaire, ce qui permet d'extraire non seulement les chaînes, mais également la géométrie des différents composants, dans le fichier .resx de base. Avec les langues proposées pour inscription, il est peu probable que les dimensions originales des composants conviendront bien à la traduction.

Il est généralement déconseillé de composer des chaînes à partir de fragments, car ils ne seront généralement pas mappés dans le même modèle de fragments dans une langue différente. Utilisation de chaînes formatées (String.Format) pour supprimer des valeurs, oui, mais tout ce qui repose sur la grammaire et l'ordre des phrases de la langue d'origine est peu probable.