Discussion :

[schneed]

Bonjour,

Je viens de compiler les lib en version 3.0 sous windows avec MinGW, et depuis, j'ai des problèmes avec mes chaines de caractères.

Lorsque je lance mon soft, les caractères accentués s'affichent dans un mauvais mode (ex. é -> é)

Les compilations que j'ai essayé sont :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
mingw32-make -j2 -f makefile.gcc BUILD=debug UNICODE=1 SHARED=1 MONOLITHIC=0
mingw32-make -j2 -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=0

J'ai essayé le même code sous Debian, avec la version 3.0 également (version des dépôts libwxgtk3.0-dev), et là, mes chaines accentués sont purement et simplement vidées lors de l'utilisation de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

_("ma chaine avec un é")

Avez vous des pistes de recherches pour parer à ce soucis?

J'ai regardé dans le fichier setup.h sous windows, l'unicode est bien activé, par contre, j'ai constaté la ligne suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
// wxUSE_WCHAR_T is required by wxWidgets now, don't change.
#define wxUSE_WCHAR_T 1

Je ne sais pas comment c'était dans les versions antérieures

Merci pour votre aide

@ +

[schneed]

Pour agrémenter mon explication, voici les printout de mon app sous windows et sous linux

[wxXav]

Salut.

Le problème vient d'un conflit entre l'encodage de tes fichiers sources et la façon de spécifier les chaines de caractères.
Je dirais même que tes fichiers sources sont encodés en UTF-8.

Or, l'utilisation de la macro _("...") implique une conversion ASCII => Unicode.
Cette macro est normalement à réserver aux chaines de caractères à traduire (de l'anglais vers d'autres langues).

Si tu souhaites coder ton application directement en français, tu as deux possibilités :

• laisser ton code tel-quel, mais convertir les fichiers sources en ISO-8859-1
• changer ta façon de spécifier les chaines de caractères en remplaçant _("...") par _T("...") ou encore L"..."

@+
Xav'

[schneed]

SAlut wxXav

Ouais, j'avais bien pensé que ce problème venait de l'encodage, mais ce que je ne comprend pas, c'est la différence entre wx2.8 et wx3.0 :

Depuis plusieurs année, mes fichiers sources sont en UTF8, et voici mes derniers résultats :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
wx2.8:
_("é")   --> ok
_T("é")  --> ok
"é"      --> pb lors de la compilation
 
wx3.0
_("é")   --> blanc
_T("é")  --> ok
"é"      --> blanc
L"é"     --> ok
wxT("é") --> ok

Le problème est que tous mes codes sont avec la macro _("..."). Si j'utilise _T("...") ou L"...", je pers l'i18n non?

N'existe-t'il pas une solution pour revenir avec une configuration similaire à la v.2.8 ? Ou alors, quel est la bonne pratique pour les chaines de caractères, avec l'i18n naturellement.

Sinon, je suivrai ton conseil, j'essayerai de développer mes application directement dans la langue de Shakespeare, mais ça va pas être simple .

Si jamais tu as d'autres informations intéressante à ce sujet, ce sera très sympas.

En tous cas, merci en attendant

[wxXav]

SAlut wxXav

Ouais, j'avais bien pensé que ce problème venait de l'encodage, mais ce que je ne comprend pas, c'est la différence entre wx2.8 et wx3.0 :

En fait, depuis wx3.0, tu peux utiliser indifféremment ANSI ou UNICODE pour tes chaines de caractères alors qu'avant, il fallait tenir compte des paramètres de compilation des libs.
Donc en gros, avec wx2.8, quand tu utilisais _("...") ou _T("..."), c'était avec une chaîne de caractères correspondant aux libs.

Mais avec wx3.0, c'est apparemment l'ANSI qui est privilégié (sauf si tu utilises la macro _T("...") ).

Le problème est que tous mes codes sont avec la macro _("..."). Si j'utilise _T("...") ou L"...", je pers l'i18n non?

Je viens de trouver un compromis qui devrait te convenir (je ne l'ai testé que sous Windows, à toi de me dire si il marche sous Linux).
Tu peux en fait utiliser un mix de _("...") et L"..." : _(L"...").
Je viens de tester avec une application codée en anglais avec prise en charge de l'i18n pour la traduction française, et ça marche.
Et pour toi, ça sera assez simple de lancer un remplacement de tous les _(" par des _(L"

N'existe-t'il pas une solution pour revenir avec une configuration similaire à la v.2.8 ? Ou alors, quel est la bonne pratique pour les chaines de caractères, avec l'i18n naturellement.

Comme je te l'ai dit : il vaut mieux à mon avis coder tes chaînes en anglais, et traduire ensuite en français via wxLocale & Cie

Si jamais tu as d'autres informations intéressante à ce sujet, ce sera très sympas.

Un petite astuce découverte récemment : il est désormais possible, sous Windows, d'intégrer le fichier ".mo" contenant les traductions aux ressources de l'exécutable (voir la doc de wxResourceTranslationsLoader).
Ainsi, tu peux obtenir une application multi-langues sans avoir à fournir toute une arborescence pour le système de traduction.
Malheureusement, ça n'est valable que sous Windows.
Je suis en train de réfléchir pour essayer de créer quelque chose de similaire sous Linux justement.

En tous cas, merci en attendant

De rien.

Tiens moi au courant.

@+
Xav'

[schneed]

Bonjour à tous !

Désolé pour le retard...

Bon, alors, j'ai testé les chaines de caractères avec _(L"msg") sous linux, et l'internationalisation fonctionne parfaitement avec. Donc, j'ai adopté cette solutions pour toutes mes chaines à traduire.

De plus, comme tu le proposais wxXav, je vais coder mes appz directement avec des chaines en anglais, ça simplifiera la vie de tout le monde (et pis ça ne peut que me faire progresser également )

Un petite astuce découverte récemment : il est désormais possible, sous Windows, d'intégrer le fichier ".mo" contenant les traductions aux ressources de l'exécutable (voir la doc de wxResourceTranslationsLoader).

Ouais, j'ai vu ça, c'est vrai que ça pourrait être pas mal si ça pouvait fonctionner sous linux. Peut être en combinant la fonction wxTranslationsLoader::CreateFormData avec l'utilitaire bin2c du wxWiki... A garder sous le coude, au cas où ça fonctionnerait

Je check en résolu

Merci à toi wxXav

[wxXav]

Salut.

Désolé pour le retard...

Pas de soucis...

Bon, alors, j'ai testé les chaines de caractères avec _(L"msg") sous linux, et l'internationalisation fonctionne parfaitement avec.

C'est toujours bon à savoir. Merci pour le retour.

De plus, comme tu le proposais wxXav, je vais coder mes appz directement avec des chaines en anglais, ça simplifiera la vie de tout le monde (et pis ça ne peut que me faire progresser également )

C'est je le répère à mon avis la meilleurs technique à utiliser (du coup, tu peux revenir à des chaînes codées via _("...") si tu préfères).

Un petite astuce découverte récemment : il est désormais possible, sous Windows, d'intégrer le fichier ".mo" contenant les traductions aux ressources de l'exécutable (voir la doc de wxResourceTranslationsLoader).

Ouais, j'ai vu ça, c'est vrai que ça pourrait être pas mal si ça pouvait fonctionner sous linux. Peut être en combinant la fonction wxTranslationsLoader::CreateFormData avec l'utilitaire bin2c du wxWiki... A garder sous le coude, au cas où ça fonctionnerait

Je suis en train de tester un truc de ce genre :

• Un fichier ".mo" encodé avec un utilitaire style bin2c fait maison (mais le résultat est le même)
• une classe "wxMemoryTranslationsLoader" dérivée de "wxTranslationsLoader"

Ça marché déjà sous Windows : il ne reste plus qu'à tester sous Linux pour voir.

Je te tiens au courant.

Merci à toi wxXav

De rien.
@+
Xav'