10
votes

Globaliser une application de formulaires Windows existante?

J'ai une application WinForms existante développée à l'aide de VS 2005 et .NET Framework 2.0.

Maintenant, nous devons mondialiser cette application. Les deux locaux sont allemands et japonais.

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

Je veux connaître la meilleure approche pour mondialiser une application existante, dois-je définir la propriété localisée sur chaque formulaire ou y avoir un outil qui extraire les noms d'étiquettes et les noms de contrôle..Ques considérations à prendre pour les formats de date , monnaie, etc.

Aussi, nous avons également utilisé des chaînes composites dans certains endroits en code pour concéder les chaînes de message, comment elles peuvent être localisées?

Nous migrerons l'application sur VS 2008 et .NET Framework 3.5 avant de commencer l'activité de la mondialisation.


0 commentaires

4 Réponses :


1
votes

Si vous utilisez Source Visual Safe comme contrôle source (espérons-le que vous n'êtes pas), tout ce que vous faites, ne pas ajouter du texte japonais dans votre code source lui-même. Bien que Visual Studio puisse gérer des fichiers source Unicode, VSS ne les gère pas bien.

J'ai travaillé sur une application qui s'est traduite en japonais et l'inclusion de japonais dans le code source lui-même (pour les appels à une fonction de type MessageBox) a corrompu les fichiers et, étant donné que VSS est basé sur DIFF, les fichiers ont été corrompus. tout le chemin du retour aux versions originales vérifiées. Cette corruption a pris la forme de la plupart des fichiers de code transformés en gibberish basé sur des caractères japonais et s'est produite car les parties VSS décaltraient des portions de CS basées sur unicode (qui ont utilisé deux octets par caractère) désactivés par un octet.

Fixer ces fichiers nécessitait beaucoup de travaux manuels, avec mon patron, regarder sur mon épaule et crier à quel point nous étions condamnés, alors ne faites pas cela.

En outre, voici quelques autres questions sur scaleverflow sur ce sujet:

meilleur moyen de mettre en œuvre la multilingue / Mondialisation dans le grand projet .NET

meilleures pratiques pour faire une application multi-langage dans C # / Winforms?

Personnellement, je préfère une méthode plus simple. Créez une liste dans Excel ou quelque chose de chaque pièce de texte anglais dans l'application que vous devez traduire (contrôler les propriétés de texte, chaînes à utiliser dans les fonctions MessageBox, etc.) et envoyez les feuilles de calcul à vos traducteurs. Dans votre application, appelez une méthode dans l'événement de chargement de chacun de vos formulaires qui iTère via toutes les commandes sur le formulaire et modifie leurs propriétés de texte aux valeurs traduites. Remplacez tous les appels à MessageBox avec des appels sur une fonction intermédiaire qui traduit le texte à afficher, puis appelle la messagerie-boîte avec le texte traduit.

Utiliser les méthodes de mondialisation intégrées est beaucoup de travail, car vous devez créer manuellement chaque forme mondialisée, puis remplacer manuellement tout le texte avec les traductions, et cette tâche nécessite à peu près au programmateur de parler couramment. La méthode que je mentionne est faite de manière programmative et ne nécessite pas le programmeur parle couramment dans les langues traduites.


9 commentaires

Vous auriez dû hurler à votre patron pour ne pas avoir de sauvegarde en place. hurlez-lui en français même avec des sous-titres japonais.


Nous avez-nous une sauvegarde en place - elle s'appelait "Source Visual Safe". Je ne m'attendais jamais à rien de tel que ceci pour pouvoir corrompre un référentiel tout le chemin du fichier à cocher Original.


Vous ne comprenez évidemment pas le concept de sauvegarde.


@Timmerz: Pensez-vous vraiment qu'il est judicieux de conclure qu'un ancien combattant de la programmation de 17 ans ne "comprend pas le concept de sauvegarde" basé sur un commentaire lancé? Ou faites-vous que vous pratiquez d'être une piqûre? Parce que je ne pense pas que tu aies besoin de la pratique.


Je voudrais vous avoir tiré immédiatement. arrogant et pas beaucoup de sens. Pourquoi ne pas regarder ce lien? support.microsoft.com/kb/244016


Comme je l'ai dit, vous n'avez pas besoin de la pratique.


Au lieu de faire face à la question que vous l'aidez et que vous attaquez simplement à m'attaquer et retombez sur votre propre CV. Laissez-moi être vraiment clair ici ... Si vous envisagez Visual SourceSafe votre sauvegarde et il est corrompu comme vous, et vous ne pouvez pas l'enregistrer, vous pouvez simplement avoir complètement détruit une entreprise. Ce n'est pas une sauvegarde. J'essaie vraiment de comprendre comment vous pouvez être si ignorant après 17 ans.


Je m'excuse d'avoir utilisé "Fancy Italics" et pour remettre en question votre expertise sur "la sauvegarde". Merci d'avoir souligné combien je dois encore apprendre à propos de cette entreprise.


MDR. Excuses acceptées! Je t'ai vu écrire quelque chose ailleurs sur les sauvegardes SQL Server, donc je suppose que vous savez en fait comment sauvegarder ;-)



0
votes

Si vous souhaitez que la communauté localise pour vous utiliser un fichier XML externe. Regardez http://www.codeplex.com/url2jpeg , ce projet Open Source est localisé de cette manière. et utilise la réflexion pour la localisation automatique des formes.

pour la chaîne utilise simplement une étiquette cachée.


0 commentaires

2
votes

Il est préférable de définir la propriété de localisation sur chaque formulaire - qui extraire non seulement les chaînes, mais également la géométrie des différents composants, dans le fichier de base .resx. Avec les langues nominées, il est tout à fait improbable que la taille originale des composants soit un bon ajustement pour la traduction.

Il n'est généralement pas recommandé de composer des chaînes de fragments, car elles ne feront généralement pas la même manière dans le même modèle de fragments dans une langue différente. Utilisation de chaînes formatées ( string.format ) pour déposer des valeurs, oui, mais tout ce qui s'appuie sur la grammaire et l'ordre de phrase de la langue d'origine est peu probable.


0 commentaires

7
votes

Je n'ai travaillé que avec des langues LTR, et je n'ai pas touché le japonais. Dans cet esprit, voici quelques-unes de mes meilleures pratiques de la tête:

  • Mettez toutes les chaînes programmatiques et les fragments de chaîne spécifiques à la langue dans un fichier .resx (j'aime 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 devrait pas y avoir de chaînes spécifiques à la langue restantes dans votre code (ce qui signifie presque pas de chaînes dans votre code, période). Un bon motif consiste également à mettre en formatage des chaînes dans le .resx, car la syntaxe d'une langue varie.
  • Définissez la propriété localisable sur True sur toutes vos formulaires et effectuez des modifications spécifiques à la langue directement (utilisez la propriété de langue).
  • Concevez vos formulaires de manière à ce que tout ce qui affiche des chaînes spécifiques à la langue aura un espace supplémentaire si nécessaire (note: l'allemand est plus long que l'anglais). IMO, les formulaires ne doivent pas nécessairement être complètement réorganisés pour un changement de base de la langue - cela peut être fait avec une langue comme le japonais, cependant.
  • Pour des commandes telles que des étiquettes qui ont besoin de texte définie de manière dynamique, définissez le texte sur le formulaire afin que vous sachiez que ce n'est qu'un marqueur. J'utilise "##" pour cela, ce qui se distingue vraiment. Évitez de définir le texte dans un "échantillon" du texte dynamique, car vous ne vous souviendrez jamais que les commandes sont définies de manière dynamique en regardant simplement le formulaire.

4 commentaires

Merci. J'aimerais connaître la maintenabilité et l'écologie avec cette approche si quelque chose est modifié ou que le texte doit être modifié dans le fichier de ressources.or Si je veux étendre cela à une langue supplémentaire, comment il sera atteint si la demande est déjà dans production? Cela nécessite-t-il rééquilibré et réapprovisionnement?


Avec cette approche, vous devriez recompiler et redéployer l'exécutable principal pour une addition et un changement, oui. Mais vous devriez avoir à redéployer quelque chose avec une simple implémentation multilingue. Je ne vois pas cela comme un problème, car les chaînes de langue devraient être l'orthographe / la grammaire vérifiée loin avant sa publication et ajoute une nouvelle langue que le client veut être un événement relativement rare.


L'ajout d'un nouveau support linguistique est requis dans notre application. Donc, s'il n'y a pas de changement d'application, à l'exception de la langue, nous pouvons créer un nouveau fichier .resx, générer un assemblage satellite et le mettre à la structure de répertoire appropriée. Cela ne nécessitera pas de re-compilation, n'est-ce pas? Une autre question est la traduction des données utilisateur saisies, où et comment maintenir cela, si nous avons des données à partager entre les utilisateurs de différents locaux?


Vous devrez faire une abstraction supplémentaire pour récupérer des cordes des assemblages satellites, mais cela devrait fonctionner comme vous le souhaitez. MSDN a probablement des indices sur cette approche. Vous aurez également besoin d'un mécanisme permettant à l'utilisateur de sélectionner la langue de choix à partir de celles disponibles (ou si elle serait dans un fichier de configuration). La traduction de données utilisateur est une discussion complète et vous souhaiterez effectuer des recherches indépendantes en fonction de vos besoins professionnels.