Merci à JuanedaEr pour l'info.
A mon tour de donner un coup de main :
Cherchez Q166902 sur internet et vous saurez qu'il manque une entrée dans la base de registre pour que l'event viewer puisse afficher correctement l'application qui a loggé l'erreur.
(dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog)

Malgré les quelques problèmes déjà cités en français (d'autres source sur le site proposent des solutions les corrigeant), on peut quand même dire bravo pour l'idée.  Il semble en tout cas que le français soit vraiment le plus difficile pour ce problème; les autres langues ne présentant pas autant d'exceptions. Le multilingue est particulièrement utile ici où un simple dictionnaire ne suffit pas !
Je cherchais justement cela.
Merci.

Très interressant. J'avais pensé utiliser StartLogging et LogEvent de l'objet App, mais je n'ai jamais réussi à en tirer quoi que ce soit alors ton code est le bienvenu !
A propos, si quelqu'un sait comment ces méthodes de l'objet App fonctionnent il est le bienvenu. Merci d'avance

Hello sarl_adc
En effet, tu as raison, écrire du code en allant le mettre dans une ressource, ce n'est pas pratique et pas facile à débogger. Pour ma part, je gère cela en définissant une procédure privée dans chaque source avec un nom fixé et contenant un select case pour obtenir des textes utilisés dans le source dans la langue de développement. Un programme, comme celui que tu décris, complète ces textes avec ceux définis dans les captions, tooltiptextes etc... des controles de la feuille (si la source est une feuille) en plaçant dans le tag la référence du texte (n° de module et n° de texte).
Ensuite, tous ces textes sont exportés dans une base données pour traduction. Un dernier programme permet de créer les ressources à partir de la base de données, ressources qui seront lues au chargement de la feuille ou dans la procédure fixée si la langue n'est pas la langue de base.
On gère comme cela un programme de plus de 15000 textes traduits en 9 langues.

Salut,
Je me souviens de ce code. C'est super de l'avoir porté sur VB. Je m'en vais l'essayer ! ça me rapellera de bons souvenirs

Désolé, j'étais en congés...
- Oui, j'ai oublié d'enlever la référence au controle TxText qu'on utilise par ailleurs, supprimez la référence, il n'est pas utile ici. Une fois ceci enlevé, l'accès aux méthode de vba.Strings ne devrait pas poser de Pb...
- Pour les boutons, il suffit de mettre style "1- Graphical" pour que ça marche., Mais en effet, les controles intrinsèques marchent vraiment bizarrement pour un langage soi-disant Unicode...
J'utilise habituellement ces méthodes dans un controle tableau pour lequel on peux définir le StyleSet (Font, Charset etc.) pour chaque cellule. Ceci me permet de saisir des traductions dans des langages utilisant des charsets différents.
Merci de vos commentaires, je vais continuer à chercher aussi ...

Je viens de poster le code: Exemple d'affichage dans toutes les langues. J'ai fait simple.

Jockos:  j'ai essayé de mettre de l'arabe dans le caption d'une forme et malgré le bon charset, ça ne marche pas. Mais en effet, on ne peut pas modifier l'affichage des captions de fenêtre en changeant la police de la feuille !! Pour cela, je pense qu'il faudrait passer par les windowshook pour controler l'affichage de la fenêtre par dessus windows.
Si tu trouve la solution, n'hésite pas à me le dire

Je dois avouer que je n'ai jamais eu à mettre un titre de fenêtre qui ne soit pas dans la page de code que l'utilisateur a défini dans Windows !
Mais je constate qu'il y a bien une propriété font pour les feuilles donc ça devrait être possible.
Pour les menus, je dois dire que ça fait bien longtemps que je n'utilise plus cela mais le controle ActiveBar2 d'Infragistics qui a une propriété fonte.
Excusez moi si je suis un peu lent à poster le code, mais j'y travaille dès que j'ai 5 minutes...

En Effet bidoch78, avec W2000, on peut mettre son systeme dans la page de code ANSI qu'on veut à condition de le redémarer.... et ça marche.
Mais on peut aussi en restant dans son bon vieux français :
En fait, les controles standard permettent d'afficher les textes dans un des jeux de caractères chargés dans le systeme (cf panneau de config, option régionales). On ne peut par contre pas mélanger des jeux de caractères dans un controle (Ex : de l'arabe et du russe dans le meme caption)
Pour les faire afficher, j'ai mis du temps à comprendre, mais voilà :
Il suffit de définir correctement le 'Charset' de la fonte du controle et de convertir la chaine unicode en ANSI pour la page de code correspondante avant de la mettre dedans.
En pratique :
1) récupérer le codepageAnsi de la langue à afficher (API : GetLocaleInfo(LOCALE_DEFAUTANSICODEPAGE,...)) (Ex: 1256 pour l'arabe)
2) en déduire le Charset correspondant (Ex: 178 pour l'arabe)
3) Indiquer au controle qu'on utilise ce jeu : label.Font.Charset=178
4) Convertir le texte Unicode en ANSI code page 1256  mais comme vb est bizarre il faut le mettre dans une chaine unicode locale !! (LCID est l'ID de locale d'un pays parlant Arabe. exemple: Arabie saoudite : 1025
  label.caption=StrConv(StrConv(Texte, vbFromUnicode, LCId),vbunicode)
et si votre systeme permet l'affichage de ces polices, alors c'est OK.
Si vous le souhaitez, je pourrais poster un exemple de code, mais ça ne me semblait pas interresser grand monde ...
  

Le code pour convertir des nombres en lettres a déjà été mis plein de fois sur Code Source et dans des versions bien plus évoluées.
Je ne vois pas bien l'intéret d'en rajouter une de plus qui n'ajoute rien à part des fautes de français !