Discussion :

[olibara]

Bonjour
Dans une application multilangue, la traduction des forms se fait asser facilement graces aux resx automatiquements crées pour chaque forms

Mais malheureusement les forms ne sont pas forcément les seules choses a traduire

Par exemple une classes d'impression qui devrait contenir des libellés..

Ou traduire certains messages propres a différents traitements

Tout mettre dans un resx global a l'application n'aide forcément pas a structurer et organiser les éléments

Donc je me demande s'il existe un moyen simple de creer des resx spécifiques a certaines classes pour y integrer les textes spécifiques

Toutes les idées sont les bienvenues

[Guulh]

Hello,

tu peux créer autant de resx que tu veux. Tout simplement Et regrouper ensemble les ressources propres à une classe / une couche de ton appli / whatever.

[olibara]

Merci Guuhl

J'ai pas encore capté le "Tout simplement"

Je t'avoue qu'actuellement je suis parti dans la direction d'un fichier texte structuré genre .ini (un par langue)
Et au demarage de l'appli ou au changement de langue je relis ce fichier pour creer un dictionnaire des message ou informations localiées spécifiques

Avantage : UN SEUL fichier lisible pouvant facilement etre traduit et maintenance aisée, pas besoin de recompilation

[laedit]

Mais il peut être modifié depuis l'extérieur, c'est pas très sécurisé ça...

[Louis-Guillaume Morand]

Mais il peut être modifié depuis l'extérieur, c'est pas très sécurisé ça...

c'est pourtant le bon choix. un fichier de ressources n'est pas critique. C'est le meilleur moyen de pouvoir corriger une coquille sans redéployer et surtout, il suffit potentiellement de créer X nouveaux fichiers de ressources pour avoir X nouvelles langues.


Maintenant il vaut mieux utiliser le format XML des ressources mais c'est vrai que c'est pas très clair pour un utilisateur neophyte qui devrait l'éditer. L'autre solution reste le bon vieux fichier ini et les méthodes pinvoke readprofilestring et writeprofilestring qui te permettent de trouver directement la clé de ton choix

[Guulh]

Je dis "tout simplement" parce que, indépendamment du fait que te ressources soit externes ou internes, tu n'es pas obligé d'avoir un gros seul fichier resx commun à toute ton assembly, tu peux en créer autant que tu veux (et pour chacun, avoir un truc.fr.resx, truc.es.resx, ...). C'est un moyen simple de structurer.

Après, la gestion des ressources dans visual studio est assez simpliste. Localiser une appli est une galère, vu qu'il n'y a pas d'UI pour voir toutes les ressources d'une assembly dans la langue par défaut et dans une langue autre, par exemple...

[olibara]

Merci pour ton avis Louis-Guillaume, je pense qu'on est +/- sur la meme perception.

Salut Guuhl

Après, la gestion des ressources dans visual studio est assez simpliste. Localiser une appli est une galère, vu qu'il n'y a pas d'UI pour voir toutes les ressources d'une assembly dans la langue par défaut et dans une langue autre, par exemple...

C'est une des raisons pour laquelle je penche vers un fichier de type .ini pour les traductions génériques

Mais pour la localization des form je garde les resx respectif de chaque form

[Guulh]

En quoi l'ini est plus facile ? Au pire, on peut se coder un petit outil qui à partir d'un fichier resx donné, propose une petite grille avec trois colonnes : Nom, valeur par défaut, valeur dans la langue XX, et qui te crée le bidule.fr.resx.
Même s'il ne faut pas forcément suivre Microsoft dans tous ses délires, il me semble que dans le cas des ressources il vaut mieux s'en tenir au standard, quitte à pallier manuellement aux insuffisances de l'IDE

[olibara]

En quoi l'ini est plus facile ? Au pire, on peut se coder un petit outil qui à partir d'un fichier resx donné, propose une petite grille avec trois colonnes : Nom, valeur par défaut, valeur dans la langue XX, et qui te crée le bidule.fr.resx.

Soit.... mais ca a plusieurs conséquences !

1- La multiplication des outils et procedure pour le développement
2- La nécessité de recompiler pour integrer les resx

Mais a coté de ces evidences il y a quand meme deux lacunes dans ma connaissance !

1- Je ne sais pas comment produire et gerer d'autres resx que le Ressources.resx

2- Admettant que pour les classes A, B, C j'aie des resx A.resx, A.fr.resx, A.en.resx, A.de.resx, etc, je n'ai pas encore investigué profondément comment acceder les string localizées des resx A,B,C


avec le .ini (ou en tout cas une centralisation dans le genre, basée sur un dictionnaire) ca me semble plus simple

J'envisage meme une classe Statique dediée a cet effet munie des methodes de lecture adequates, delegate de rechargement selon la localisation et dictionnaire associé)

[Guulh]

Reprenons

Si tu veux que tes ressources soient internes, tu peux créer autant de fichier resx que tu veux : dans l'explorateur de solutions, "ajouter..." => "nouvel élémént..." => "fichier de ressources", et si tu l'appelles Toto, tu auras une classe Toto encapsulant de façon fortement typée tout ce que t'as mis dedans.

Ensuite, pour ce qui est de la localisation : VS offre une solution simpliste, qui consiste :
- pour les forms à déclarer la form localisable, à changer la langue dans une combo qui va bien, et à remodifier un par un les textes (voire les positions, les couleurs, ...) des contrôles à traduire.
- pour les fichiers de ressources "hors form" à rajouter à la main un toto.xx.resx, où xx est la langue, et à recopier le contenu de la grille Nom / Valeur de toto.resx vers toto.xx.resx, en traduisant les valeurs au passage.

Donc de toutes façons, pour traduire, soit on se le fait à la mimine (i.e. modifier le resx avec le designer fait pour ça dans VS malgré ses lacunes, ou bien l'éditer à la main en dehors de VS), soit on se fait un petit outil pour ça.

En plus : j'ai jamais essayé, mais je suppose qu'il doit être possible de ne pas incorporer les fichiers resx dans l'exe. Donc t'es doublement gagnant : non seulement tu peux MAJ ton UI sans recompiler, et en plus tu profites d'un classe fortement typée pour accéder à ces valeurs.

Donc je vois pas en quoi une solution à base de fichier INI est préférable, sauf si on a déjà un outil qui permette de le traduire aisément.

[olibara]

Merci Guuhl

Si tu veux que tes ressources soient internes, tu peux créer autant de fichier resx que tu veux : dans l'explorateur de solutions, "ajouter..." => "nouvel élémént..." => "fichier de ressources", et si tu l'appelles Toto, tu auras une classe Toto encapsulant de façon fortement typée tout ce que t'as mis dedans.

Oui j'avais les yeux ailleurs je croyais que c'estait pas pour express !

Je vais donc investiguer plus loin ..

N.B. Le contenu des resx est compilé dans des dll (une par langue)

Mais je comprends que tu n'a as vraiment l'expèrience de devoir produire des application en plusieurs langues
Je suis confronté (en belgique) a ce problème depuis des années !

Pour la traduction des forms en .net les resx sont un grand plus avec le grand inconvénient de ne pas disposer d'un outil d'édition simple

Pour la traduction de tous les messages et autres texte non lié a un control d'une form je pense que l'ini a des nombreux avantages sur le resx

Il est par exemple impossible d'envoyer un resx a un bureau de traduction et leur demander de traduire

l'ideal serait effectivement un bon outil d' import / export des textes des resx !

[Guulh]

Nos applis ont des utilisateurs sur trois continents, donc je connais un peu la problématique quand même Mais ce n'est pas très industrialisé, mes connaissances sont encore lacunaires.

Tu sais comment bossent tes équipes de traduction ?

[olibara]

Salut

Personnellement, je transmet des texte en word ou en txt a des bureaux de traduction ou des traducteurs indépendant
Ensuite je réintégre dans l'appli

Quand c'est un seul fichier ini du genre

[Impression]
mes1=c'est pas bon
mes2=nom incorrect

Je peux demander facilement aux traducteurs de faire attention de ne traduire que ce qui est a droite d'un signe =

Et de traduire tout le fichier FR pour me faire un DE un NL et un EN par exemple


Par contre je peux courrir et payer beaucoup plus cher pour trouver des traducteurs capable de me traduire des libellés repartis dans 10 fichiers resx

Et si ces libellés sont déja pret a traduire dans des resx c'est que j'ai déja du faire un sérieux effort les y mettre

Donc je maintiens l'idée que la mecanique du .ini peut etre facilement integrée dans une librairie interne a l'app et demande peu de manipulation exterieure, tandis que pour les resx c'est la galère !!

Par contre pour les form les resx sont malheureusement le meilleur moyen de garantir une mise en page correcte mais demandent beaucoup d'effort ET de vigileance

[Guulh]

Le resx n'est effectivement pas fait pour être modifié à la main, y'a le risque de foutre la syntaxe XML en l'air trop facilement (alors qu'un ini est plus difficile à casser).

Je te posais la question parce que je ne sais pas s'il existe des standards dans l'externalisation de la localisation de ressources texte, que ce soit au niveau des formats de fichier ou des process. En interne dans sa boîte, tu peux imaginer fournir tes resx + ton appli maison de traduction (ou un outil du marché, il me semble avoir vu des pubs pour des éditeurs de resx multilingues).

[Arsou]

Bonjour,

Comment fait-on pour localiser une forme grâce à un fichier extérieur?
Je voit bien comment faire directement dans visual studio mais ce serai plus simple avec un fichier externe (txt, ini, xml, autre) et es-ce qu'il y a moyen de le faire pour les classes ne comportant pas de forme visible?

Louis-Guillaume parle de pinvoke readprofilestring et writeprofilestring mais je ne m'en suis jamais servi :s

merci d'avance.

[olibara]

Louis-Guillaume parle de pinvoke readprofilestring et writeprofilestring mais je ne m'en suis jamais servi

Ce sont des methodes du Kernel de Windows donc externes au FW

Personnelement je me mefie un peu de leur usage actuellement car je ne connais pas les intentions de MS a leur sujet

Et ce n'est pas tres complique de les reproduire en Csharp tout en offrant la liberté d'une syntaxe un peu "enrichie"

Comment fait-on pour localiser une forme grâce à un fichier extérieur?

Personnellement, je ne parlais pas de localiser une form a'laide d'un fichier exterieur, la mecanique des resx et bien la pour ca et a ce niveau je partage l'avis de guulh d'utiliser un outil d'import export de texte des resx pour faciliter l'edition

Par contre le débat porte sur la localization de tous les textes exterieurs a des form

[Arsou]

En fait le fichier externe pour les formes est une demande de l'employeur.
Quand j'aurai fini mon stage il n'y aura plus aucune connaissance en C# dans la société et la traduction est reportée à... plus tard.

A la limite pour les formes, il ne faudra pas beaucoup d'explication pour qu'il puisse le faire seul avec le visuel de VS, mon problème se situe dans mes deux classes (une Logique et une accès aux données) qui peuvent renvoyer des erreurs et je ne sais pas comment coder le programme pour que ce soit le plus simple à traduire par la suite.

[laedit]

Tu pourrais renvoyer des codes d'erreur et utiliser ce code pour aller chercher la traduction correspondante.

[Arsou]

Ha vi bonne idée!

Mais heuuu ça se code comment? parce que j'ai pas vu ça au cours et mes recherches sur le net me parlent toutes des formes et des RESX :s

merci d'avance

[laedit]

Ah ça, à implémenter c'est autre chose.

Comme la discussion plus haut en témoigne, c'est dans le domaine de la traduction en dehors des Forms. Pour cela, un .resx n'est pas obligatoire et d'après les avis données, il serait mieux d'utiliser un fichier externe telle un ini, xml ou autre.

Par la suite, je vois les choses de cette façon :
Tu pourrais créer une énumération pour les différentes erreur possibles.

Et tu aurais une fonction qui te retournerait le bon texte en fonction de la valeur de l'énumération passée en paramètre ainsi que de la langue choisie.