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).

[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

[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"