Discussions au sujet de NI LabVIEW
Application avec langage exotique
Hello
Je bute sur un problème de traduction. Notre application tourne chez un client depuis quelques années (Labview 2017). Le poste a été fait à plusieurs exemplaires, et le prochain exemplaire ira en Tchéquie. On nous a demandé de traduire le HMI. "Pas de problème", notre application est dès le départ prévu pour, d'ailleurs elle gère déjà l'anglais/français. Seulement voilà,la langue à rajouter est le tchèque. Le problème est que le tchèque comporte des lettres qui ne font pas partie du même "code page" (codage ANSI) que les langues d'Europe de l'ouest. Et surtout, que Labview ne gère pas vraiment l'Unicode de base.
Mon problème principal est le suivant : je dois charger un texte traduit, en fonction d'un texte d'entrée. Liste de clés-valeurs en somme. Le texte d'entrée comporte des caractères français (ce qui est avant le ; dans le fichier CSV annexe), et le texte traduit est en tchèque. Donc il y a mélange de deux "code page".
Avec un Windows en français, impossible de charger les caractères spéciaux comme le ů ou le č.
Mais si je change la langue de Windows en tchèque, c'est les caractères comme le é qui ne passent plus.
Donc voilà, je me demandais s'il y a une solution? Et si éventuellement qqn pourrait le tester avec le dernier Labview 2022, sait-on jamais ça peut-être été amélioré?
Remarque : Oui je sais, une solution serait de modifier tous mes textes d'entrée et d'en supprimer les accents, mais j'ai pas envie, trop de job.
salut Walker -:)
Le sujet est intéressant.
Malheureusement je suis septique sur l'issue. En effet je pense que les textes de ton CSV sont ceux des labels des objets LabVIEW à traduire. Si cela est le cas, je suis sceptique. Il y a quelques temps j'avais écrit sur mon blog cela : LabVIEW multilingue plurilingue unicode - NI Community
Lorsque je lis ton message
@Walker34 a écrit :
Seulement voilà, la langue à rajouter est le tchèque. Le problème est que le tchèque comporte des lettres qui ne font pas partie du même "code page" (codage ANSI) que les langues d'Europe de l'ouest.
Mon problème principal est le suivant : je dois charger un texte traduit, en fonction d'un texte d'entrée. Le texte d'entrée comporte des caractères français, et le texte traduit est en tchèque. Donc il y a mélange de deux "code page".
As-tu déjà testé ton exécutable avec les paramètres tchèque? As-tu des caractères ASCCI long français dans ton code LabVIEW?
[...] Le code LabVIEW est compilé, mais le fichier binaire de l'exe contient la liste des fichiers / message / texte / label. Si dans cette liste, un caractère n'est pas transposable dans la liste des caractères non unicode de la langue de l'OS, l'exe est brisé. La solution est comme toujours de suivre la règle d'être en ASCII court, donc utiliser les caractères non unicode universels sur les OS, donc les caractères Anglais ! pas de é ou è ou ç ou à dans les noms de VI ou autres! bonne chance
[...]
A suivre A+ luc
Alors mon exe n'est pas brisé lorsque Windows est en tchèque, c'est une bonne chose. J'ai toujours respecté l'ASCII pour le nommage des VI's, donc maintenant je sais pourquoi c'est une bonne pratique.
Pour le chargement de mes textes, j'ai résolu le problème en chargeant spécifiquement les textes identifiants avec le code page 1252. Ca fonctionne. Le seul bémol, c'est qu'effectivement il faut basculer la langue de Windows pour afficher correctement le logiciel avec les textes traduits dans la langue tchèque.
Voilà le chargement sélectif de la langue, la première colonne est chargée avec le code page 1252 :
Salut bonne nouvelle! De mon côté j'utilise plutôt une base de données mdb pour sauvegarder toutes les langues (en français, je devrais écrire sauvegarder tous les textes de traduction des messages).
En effet si deux langues ne sont pas compatibles, le fichier texte ".txt" en formatage "classique - ANSI" ne pourra pas sauvegarder 2 formats de langage incompatible.
L'avantage de passer par mdb, c'est qu'il est unicode, donc tu peux mélanger chinois, français, russe, grec dans le même fichier. Le passage vers le format polybit de LabVIEW est réalisé depuis la requête SQL lors de la conversation OLE Database vers Variant LabVIEW. Et donc cela fonctionne.
Bonne fin de journée, et à bientôt ! A+ Luc
