Discussion :

[avrSag]

Bonjour,
Cela fait plusieurs jours que je bataille avec l'internationalise une IHM développée en C sous VS2005 en langue arabe. J'ai les options régionales correctes pour le symbole monétaire et les dates longues, codage UTF8 lettre & chiffre.

Je pense que mon problème vient de l'OS Windows: quand je traduis un texte de type 'texte chiffres' j'ai le texte qui apparait toujours avant les chiffres:
Par exemple, si je veux traduire en arabe 'AED 10.00' cela affichera dans mon IHM (traduit en francais) : '10.00 AED' au lieu de 'AED 10.00'.
Même chose pour la date système: 25 fevrier 2013 s'affiche en arabe '25 2013 Février'.
Par contre si je mets du texte en premier, cela fonctionne: 'lundi 25 fevrier 2013' s'affichera en '2013 fevrier 25 lundi' (traduit).

J'ai essayé en passant par sprintf () pour faire l'inversion à la mano, en copiant caractére par caractère le buffer à afficher mais j'ai toujours le même problème.
Je soupçonne un problème de windows car mon buffer d'affichage (vu en debug) est correcte (il contient la chaîne de droite à gauche en arabe 'AED 10.00') mais lors de l'affichage, il y a toujours inversion;
je ne peux donc pas traduire un texte qui commence par un chiffre!!!

La solution que j'ai trouvé est de gérer deux chaines que je positionne séparémment suivant la langue.

Avez-vous déjà eu ce genre de problème avec des langues non latines ?
Il n'y a pas le problème avec .NET et je n'ai rien trouvé sur le web pour du C/c++ sans .NET mais est-ce un problème windows ? et existe-t-il un patch pour le corriger ou une modif de la base de registre à faire?

Merci d'avance pour votre aide,
aVr

[JML19]

Bonjour

S'il s'agit d'un texte sans espace que ce passe t'il ==> lundi_25_février_2013 ?

[avrSag]

Bonjour,
et merci pour votre participation.
En fait, je ne peux pas mettre de souligné.

J'utilise Google Traduction pour mes libellés en arabe: GoogleTraductionArabe("25 février 2013") donne la date en arabe dans le bon ordre mais le le copié/collé de cette date donne "فبراير 2013 25" !!!
Et c'est cela mon problème le jour (chiffres) ne veux pas se positionner à droite.
J'ai demandé à des collègues connaissant la langue arabe et ils mont dit que "فبراير 2013 d25" est un format correcte (sans le 'd' que j'ai rajouté pour que cela s'affiche au bon endroit....).
Dans l'exemple ci dessus, si on supprime le 'd', le 25 passe à gauche!!

[JML19]

Si j'ai bien compris il ne reconnaît pas le caractère Arabe comme un texte dans le copier/coller ?

[avrSag]

Oui, 'il' ne reconnait pas que le texte est en arabe et il fait une inversion.
J'arrive à reproduire l'erreur de 2 manières différentes:
- en utilisant le copier/coller sous XP d'un texte arabe commençant par un ou des chiffres,
- en 'déboguant' mon programme, j'ai vu que le MultiByteToWideChar (UTF8,...) inverse de la même manière.
Je pense à une configuration de Windows que je n'ai pas faite: mon XP est en français, j'ai rajouté les langues arabes et j'ai vérifié que les formats des options régionales correspondent à mes besoins.
Je continue à chercher...

[JML19]

Je pense à une configuration de Windows que je n'ai pas faite: mon XP est en français, j'ai rajouté les langues arabes et j'ai vérifié que les formats des options régionales correspondent à mes besoins.
Je continue à chercher...

Bonjour

Dans la reconnaissance du texte Arabe sur une version Française d'XP il faut il me semble que tu n'arrives pas à déterminer la table ASCII correspondante au texte en Arabe.

Je pense que le problème doit venir de cette table ASCII que tu n'as pas sur un XP en français, même si tu as mis la police Arabe.

Car lors de l'écriture tu fais appelles à la police, mais lors d'un copier/coller tu fais appelles à la table ASCII des caractères

Un peu comme la différence entre les caractères d'affichages à l'écran et les caractères imprimables, que tu envoies sur une imprimante.

C'est pour cela qu'a été inventé le WYSIWYG (What you see is what you get) ce que l'on appelle communément l'aperçu avant impression.

[avrSag]

J'ai vu sur http://msdn.microsoft.com/fr-fr/libr...v=sql.80).aspx
qu'il existait un marqueur: 8207 ou hexadécimal 0x200F est le marqueur RLM (Right-to-Left Marker) que l'on utilise pour les BDD.
Je vais voir si il y a l'équivalent sous VS2005.

[avrSag]

Bon, je n'ai pas réussi à utiliser le RIGHT-TO-LEFT MARK dans mon code C sous VS2005 pour forcer le sens de lecture d'une chaine.
Je vais donc utiliser 2 champs: un pour la devise et un autre pour le montant; je les inverserais suivant la langue.
Pour le copier/coller, je ne sais pas comment modifier une table ASCII sous WinXP.
Même si la solution n'est pas 'élégante' je mets mon fil de discussion en 'Résolu'.
Merci à tous.
aVr