Discussion :

[Alro_gr]

Bonjour,
J'ai donc une appli. unicode, contenant des textes en chinois et en russe.
Ils sont sous la forme _T("Texte chinois ou russe").

Pour pouvoir compiler (et afficher ces textes), la langue de windows doit être en chinois (pour les textes en chinois) ou en russe (pour les texte en russe).

Mon problème est que je j'arrive pas à compiler mon appli lorsque mon windows est en chinois. J'ai des erreurs sur mes textes en russe car les guillemets de la chaine de caractères sont bouffés. ex : _T("ØÒÐÈÕ ÊÎÄ?) le guillemet semble remplacé par un ?, sur certain texte.

Lorsque je commute mon window en russe, je n'ai aucun problème, ni avec les textes chinois ni avec les russes (les ? redeviennent des ").

La solution serait d'avoir une directive de compilation pour le chinois et pour le russe. Le russe exclurait les texte chinois et réciproquement. Mais j'aimerais éviter ceci. Il y' a-t-il une solution autre ?

Merci d'avance à tout ceux qui m'auront lu....

[dragonjoker59]

Une question con, tes fichiers sources sont-ils bien en unicode ? (Normalement oui, mais sait-on jamais).

[koala01]

Salut,

La première question que je voudrais te poser, c'est "es-tu sur que ton fichier est bien sauvegardé en UTF, avec en-tête BOM et tout ce qu'il faut

La deuxième question que je voudrais te poser, c'est : si ton application doit parler chinois et russe en fonction de la langue, pourquoi ne pas t'orienter vers une solution qui consisterait à fournir les fichiers de langues séparément (à base de gettext ou de boost::translate ou autre)

De cette manière, tout ton code pourrait n'utiliser qu'une seule langue (l'anglais ) et chaque langue serait prise en charge par un fichier séparé.

Ainsi, tu éviterais les risques de conversion de caractères "foireuse"

[Alro_gr]

Oui, bien sur.
Le russe s'affiche parfaitement dans un éditeur et un windows en russe
Idem pour le chinois.

L'idée était de ne diffuser qu'une seule version de l'application, le code embarquant tous les messages.

[koala01]

Oui, bien sur.
Le russe s'affiche parfaitement dans un éditeur et un windows en russe
Idem pour le chinois.

Encore heureux

Ceci dit, je crois avoir lu il n'y a pas si longtemps que cela un article qui traitait du problème...

Si mes souvenirs sont bons, il indiquait que la plupart des code pages respectaient les 127 premiers caractères ASCII, mais que, justement, le chinois y introduisait une ou deux différence(s).

Je ne pourrais pas jurer qu'il ne s'agisse, justement, pas des guillemets

Je n'ai, bien évidemment, plus l'url sous la main, car c'était durant une séance de suivi de différents liens

Mais, si je ne me trompe pas, je crois vraiment que la solution "idéale" est de passer par un système de traduction "externe" (comprends : grâce auquel les différentes chaines de caractères sont gérées dans des fichiers distincts).

Je viens, justement, de répondre à ==>cette question<== qui, à défaut de résoudre le problème (qui risque d'ailleurs d'être insoluble ) , pourrait au moins te donner donner des pistes intéressantes

[Alro_gr]

Merci pour ta réponse.
Mais je ne peux pas utiliser des fichiers externes.
Ton idée est bien que l'appli vienne piocher dedans les message, lors de l' exécution ?
Mon appli. va tourner sur une carte SD (donc assez lent) et je veux pas charger tous les messages au démarrage, pour des problèmes d'allocation mémoire.
L'appli est une appli CE 5.......

Une précision sur les messages, certains conservent le " et certains le perdent (celui de fin).

[koala01]

Merci pour ta réponse.
Mais je ne peux pas utiliser des fichiers externes.
Ton idée est bien que l'appli vienne piocher dedans les message, lors de l' exécution ?

A peu près, oui

Mon appli. va tourner sur une carte SD (donc assez lent)

cd n'est normalement pas cela qui ralentira ton application

et je veux pas charger tous les messages au démarrage, pour des problèmes d'allocation mémoire.

Attends, on ne parle pas de toute l'application, là, on parle juste des chaines de caractères qui devront être affichées.

Si cela te pose des problèmes de mémoire, c'est qu'il y en a déjà "par ailleurs" et qu'il serait très utile d'y remédier .

Et, surtout, entre le fait d'avoir le texte en chinois et en russe dans ton code et celui de les avoir dans des fichiers séparés, tu n'utiliseras de toutes manière pas d'avantage de mémoire

[white_tentacle]

Ton idée est bien que l'appli vienne piocher dedans les message, lors de l' exécution ?
Mon appli. va tourner sur une carte SD (donc assez lent) et je veux pas charger tous les messages au démarrage, pour des problèmes d'allocation mémoire.
L'appli est une appli CE 5.......

Si tu les mets dans l’exécutable, ils seront forcément chargés en mémoire.

Si tu les mets dans un fichier à part (avec gettext, par exemple), ils seront chargés à la demande.

==> si tu mets plusieurs langues dans l’exécutable, au final tu augmentes ton occupation mémoire.

gettext est quand même pas mal optimisé. C’est un à priori de ne pas l’utiliser (auquel cas, utilise gettext et simplifie-toi la vie), ou c’est le résultats de tests qui ont montré que ça posait un réel problème ?

[Alro_gr]

Si cela te pose des problèmes de mémoire, c'est qu'il y en a déjà "par ailleurs" et qu'il serait très utile d'y remédier .

Et, surtout, entre le fait d'avoir le texte en chinois et en russe dans ton code et celui de les avoir dans des fichiers séparés, tu n'utiliseras de toutes manière pas d'avantage de mémoire

La différence c'est que les messages seront dans la zone "code". Et j'ai beaucoup de messages.
Les fichiers externes me poseront aussi des problèmes lors des mises à jour par la suite (j'en ai déjà fait l'expérience). Je ne veux pas lier un exécutable a un fichier externe contenant des textes, sachant que j'aurais surement des mises à jour à faire, un peu partout dans le monde, et assez fréquemment.

Je crois que malheureusement, je vais devoir me tourner vers les deux versions : une pour le russe, et l'autre pour le reste du monde.

[koala01]

Je ne comprends vraiment pas tes objections.

Gettext est le système de base sur lequel est basée l’internationalisation de linux, qui fonctionne aussi bien sur pc qu'en embarqué.

Et l'on est malgré tout loin des problèmes rencontrés avec des applications manipulant plusieurs fichiers, dans le sens où, si une chaine n'est pas traduite, ce n'est pas "catastrophique": le système retombe sur la chaine originale (celle qui se trouve dans le code).

A mon sens, tu te feras beaucoup plus de mal à vouloir gérer en parallèle une version chinoise et une version russe qu'à utiliser un système d'internationalisation utilisé par des milliers de développeurs

J'ai personnellement travaillé sur des applications qui étaient internationalisées, aussi bien avec Qt (et son QLinguist qui fait la même chose que gettext) qu'avec gettext, et je peux t'assurer, même si je ne connais pas la mécanique interne sur le bout des doigts (loin de là, d'ailleurs ) que c'est parfaitement au point

[Alro_gr]

Merci pour la réponse, je me pencherais dessus.

Mais de toute façon, il me faudra dans tous les cas faire deux compilations avec un environnement windows différents (en russe et chinois).

[koala01]

Justement, non, pas si tu utilises les possibilités d'internationalisation!!!

Tu écris ton code, tes messages en anglais (c'est le langage le plus souvent utilisé en tout cas pour les messages), tu compiles uniquement l'application avec les messages en anglais, puis tu traduits les messages en russe, en chinois, en papou si tu veux, mais tu n'as même plus à recompiler l'application: il "suffit" de définir la locale (au besoin via une option du programme) pour que la magie opère

[Alro_gr]

Effectivement, c'est séduisant ....
Je ferais le test sur ma prochaine version.
Mais je pense avoir un souci quand même....je sais je suis compliqué...

En fait, les textes en question qui m'embêtent sont les traductions de textes d'un appareil connecté sur mon système. Le soucis c'est qu'en fonction de la langue, l'ordre des textes est différents. Par exemple, le troisième texte de ma table en chinois ne sera pas forcément le troisième de ma table en russe. C'est l'appareil lui-même qui me donne l'index.

On se traine de sacré boulet ....

[koala01]

Mais l'ordre dans lequel les messages sont affichés ne pose aucun problème : ce qui compte, c'est l'endroit du code où tu "crées" ta chaine pour qu'elle contienne les informations à afficher.

Par exemple, tu pourrais créer une chaine proche de

"You have ${1} black dogs and ${2} red cats"

(les champs ${1} et ${2} correspondant au nombre de chiens et de chats envisagé )

Gettext va retrouver cette chaine et te demander "comment voulez vous traduire cette chaine ?" et tu n'auras qu'à lui donner la traduction en utilisant ${1} quand il s'agira d'introduire le nombre de chiens noirs et ${2} quand il s'agira d'introduire le nombre de chats rouge, et basta.

Après, que cette chaine de caractères soit utilisée en premier lieu, en troisième lieu ou au milieu d'une autre chaine, sur un bouton, dans un champs éditable ou pour un label ne changera pas grand chose : elle sera traduite