Bonjour à tous,
j'aurais besoin d'un conseil. J'essaie d'internationaliser une appli (fr/en) sous .net. En cherchant un bon moment, j'ai trouvé une classe ResourceManager.
J'ai créé 2 fichiers resX : content.resX et content.fr.resX
 
J'ai repompé le code MSDN.
 
Au bout de 2 petites heures de recherche, j'ai finalement compris qu'il fallait ajouter content.resX dans les ressources managées du projet .... (bouton droit propriété).
A présent, cela marche pour l'anglais (content.resX). Pour le français, cela ne marche toujours pas. Quelque soit la culture choisie, il me prendre content.resX.
Je me suis dit qu'il fallait rajouter content.fr.resX dans les ressources managées du projet, mais visiblement, on peut en mettre qu'une (si je sépare avec des ; ou des , plus rien ne marche). Le problèpme est que le fichier content.fr.resX ne semble pas être compilé
 
Si quelqu'un peut m'aider, ce serait super cool, paske visual studio commence vraiment a me gaver ...

Bienvenue dans le merdier de l'internationalisation
 
Alors c'est tout simple. On va prendre comme nom de projet le nom "HFR.Prout". L'espace de nom du projet est le même (HFR.Prout).
Tu prends le dossier où y'a ton projet, et tu y fout une arborescence qui ressemble à ça :

Donc un dossier nommé "Resources", avec ta ressource générale, et un dossier 'fr', avec le fichier fr dedans. Ensuite, pour le ResourceManager, tu l'instancie sous cette forme (VB.NET):

Note que y'a 2 foix le "HFR.Prout", c'est comme ça que le compilo génère le nom de la ressource. Ensuite tu peut accéder à tes ressources, genre :

Aussi, pour définir la langue utilisée par ton application, faut lui balancer la bonne culture :

Et si t'as pas envie d'instancier la culture, tu peux définir la culture par défaut du processus en cours, et la méthode GetString va chercher la ressource correspondante à la culture du proc je crois bien
 
Si t'as d'autres questions, hésite pas

OK
 
Je te remercie pour ton aide.
En fait, ca ne résoud pas tout à fait mon problème. Je programme en C++. Le code marche bien. Le problème, c'est qu'il me dit que la resource n'est pas dans l'assembly ...
 
Je ne sais pas comment lui dire de bien compiler les ressources avec le projet. Par contre, j'ai trouvé comment créer plusieurs fichier resX dans une form pour qu'il les compile. Donc je vais simplement créer une form vide dico.h
et je vais lui associé plusieurs resX dedans et ca marchera.
 
Si tu sais comment faire en C++ pour qu'il reconnaisse des resX qui ne sont pas dans une form, ca m interesse
 
En tout cas, merci pour ton temps!

Chez moi il fait ça tout seul, je crois. Ou alors dans les propriétés du resX, faut spécifier "Ressource incorporée"

je remonte ce topic en y rajoutant une question:
 
est-il possible d'externaliser les ressources, genre en xml, pour pouvoir gérer l'internationalisation sans recompilation ?

Le fichier de ressource c'est déjà de l'XML, mais je suis à peu près sûr qu'il n'existe pas de mécanisme en natif dans .Net pour pouvoir joindre ce fichier sans le compiler et préciser son langage au runtime.
 
Bref... faut se palucher le boulot à la mano.

ben ouais, c'est de l'xml, c'est pour ça que j'y croyais à mort.  
 
Cela dit, les ressources ont l'air quoi qu'il arrive compilées, d'une manière ou d'une autre.

à vous de gérer éventuellement vous même dans un fichier xml externe l'internationalisation...  
C'est pas si compliqué de mettre en place soit même un petit système d'internationalisation...

oui, et heureusement ! car ça permet à .NET de précalculer la taille des controles, des forms, et tout. imagine si tes ressources étaient chargées dynamiquement : .NET n'ayant aucune idée de la taille des chaines de caractères, ça serait à toi de maintenir la taille, la position de chaque controle pour éviter que le texte ne "déborde" du controle ! tu imagines un peu le merdier que ça serait ?
 

ah c'est sur que faire un GetString() dans un fichier XML, INI ou autre, c'est pas dur. adapter la taille des controles soi même en revanche....
l'internationalisation ne se borne pas qu'à la traduction de strings, y'a tout un travail de redimensionnement qui est fait derrière...

Certes, c'est une raison valable