Discussion :

[Feneck91]

Bonjour à tous et à toutes....

Coup de sang ce matin...
QLinguist est un superbe outils que j'aimerais utiliser. Actuellement nous avons 2 logiciels :

• Un en JAVA
• Un en Qt

Voyant que le débutant qui a créé l'application Qt il a deux ans a utiliser un fichier xml unique pour la traduction de l'application j'ai voulu changer les choses :
Ce fichier xml est composé d'une clef, puis pour cette clef toutes les traductions dans toutes les langues possibles.
Ce fichier est dans le même format que celui utilisé en JAVA.

• Obligation de créer une variable globale qui recompile tout le projet à chaque chaîne ajouté (30 minutes)
• Cette variable membre contient la clef dans le fichier xml de la traduction (donc le texte n'est pas en clair dans le code source, ça ne le rend pas vraiment lisible)
• Aucune gestion de l'obsolescence de la traduction (comme qlinguist)
• Aucune gestion du pluriel (on n'a qu'a mettre (s) et puis c'est tout, j'ai fais plein de projets comme ça : dixit le développeur JAVA hyper expérimenté)
• Aucune gestion de contexte si une même chaîne doit être présente plusieurs fois mais avec des traductions qui peuvent changer en fonction du contexte (bon, on peut faire 2 entrées différente dans le xml)
• La traduction générée automatiquement pour les ui est inutilisable il faut tout retraduire 'à la main'.
• Obligé de se palucher à traduction en même temps qu'on ajoute la chaîne (impossible de mettre tr("ma chaine") et voir plus tard), il faut faire toute la chaîne sinon rien ne s'affiche.
• Pas de vérification des %1 %2 %3 comme qlinguist (vérification qu'il ne manque pas d'argument). De toute façon souvent dans le code on a : "Ma chaine = " + value + " est correcte" au lieu d'utiliser les .arg()
• Edit : Bien entendu, pas de traduction des boites de dialogue standard avec le fichier xml donc elles resteront dans la langue de la plateforme cible.
• Edit : Pas d'affichage de droite à gauche pour l'arabe, de toute façon tout les contrôles sont positionnés en absolue en utilisant un minimum de layout (ou alors mal foutu donc ça ne marche pas) !

Mais : on a le même format pour les deux logiciels et pour le client final, s'il a une chaîne à changer il n'a pas deux systèmes de traduction, voilà c'est à peut près le seul point positif retenu par mon chef et le développeur JAVA confirmé qui de toute façon s'en tape puisque c'est pas lui qui code en Qt.

J'ai l'impression de revenir 6 mois en arrière quand j'ai commencé à mettre ça en place et d'être entouré de gens incompétents.
On prend le pire système des deux logiciels et nous on va se faire super chier à continuer de développer tout ça !

Et hélas, le seul argument c'est l'éditeur et un seul fichier...
Bon, c'est clair que QLinguist est pourri, d'ailleurs c'est le même système utilisé par poEdit (utilisé par wxWidgets) alors qu'un fichier xml c'est tellement bien, comment ça se fait que ces deux grosses librairies n'y ont pas pensé ?
Il faudrait que nos équipes viennent un peu revoir le code de tout ça, Qt c'est quand même de la mer....

Bon, le fichier ts c'est du xml, une solution ce serait de développer l'outils d'édition en masquant tout le format Qt, qu'il lise le fichier ts et propose d'éditer les traductions et le compile quand on sauve.
Mais le développeur JAVA n'est pas chaud, on aurait encore deux formats et pourquoi faire ? En JAVA c'est suffisant !

J'en ai marre devant tant de mauvaise fois et d'incompétence !
Si vous avez des idées ou d'autres arguments je suis preneur !

... désolé un peu énervé là !

[Amnell]

Bonjour,

Une petite erreur :

Obligé de se palucher à traduction en même temps qu'on ajoute la chaîne (impossible de mettre tr("ma chaine") et voir plus tard), il faut faire toute la chaîne sinon rien ne s'affiche.

Dans le cas présent, si, "ma chaine" sera affiché.

Pour les traductions des boîtes de dialogues standard, il se situe déjà un fichier de traduction nommé qt_fr.qm (par exemple) dans le dossier d'installation, par exemple C:\Qt\5.3\mingw482_32\translations) qui gère cela, mais je ne saurais dire comment il est exploité et s'il est nécessaire de faire un QTranslator pour cela. À mon avis, vu que QTranslator permet de charger plusieurs fichiers de traduction, il doit falloir mettre d'abord votre fichier .qm de traduction puis celui de Qt pour que votre fichier soit pris en priorité. Cependant, pour une utilisation en Java, je ne saurais dire comment vous devrez vous en occuper.

En ce qui concerne QLinguist, vous pouvez clairement éditer votre .ts directement à la main vu que c'est du XML, derrière (le format est ici, mais pas forcément très explicite, le mieux pour connaître le format est de faire un lupdate /path/vers/les/sources/ sur votre .ts et de l'ouvrir).

Vide :

Code xml :

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

1
2
3
4
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE TS>
<TS version="2.1" language="fr_FR">
</TS>

Avec quelques traductions non effectuées :

Code xml :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE TS>
<TS version="2.1" language="fr_FR">
<context>
    <name>QObject</name>
    <message>
        <source>Salut</source>
        <translation type="unfinished"></translation>
    </message>
    <message>
        <source>Ceci est une chaîne avec un %1</source>
        <translation type="unfinished"></translation>
    </message>
</context>
</TS>

Les traductions effectuées, le %1 (warning de QLinguist si non indiqué dans la chaîne traduite) et un commentaire :

Code xml :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE TS>
<TS version="2.1" language="en_US">
<context>
    <name>QObject</name>
    <message>
        <source>Salut</source>
        <translation>Hello</translation>
    </message>
    <message>
        <source>Ceci est une chaîne avec un %1</source>
        <translatorcomment>Hey, this is a comment</translatorcomment>
        <translation>This is a string with a %1</translation>
    </message>
</context>
</TS>

Typiquement, ce que vous devez avoir en trop, c'est le name du context, défini à QObject vu que j'ai utilisé QObject::tr("Salut") pour que l'outil lupdate me génère mon fichier. Cependant, avec un mauvais contexte, la chaîne n'est pas traduite par QTranslator du côté de Qt, ce qui peut s'avérer problématique. Si le tr() est effectué dans le cadre d'une classe MyClass héritant de QObject, MyClass sera le contexte. Si vous souhaitez éviter ces problèmes et n'avoir qu'un contexte, imposez la notation QObject::tr() aux développeurs, définissez une macro tr() ou whatever.

Petit éclaircissement concernant les .ui : le fait de placer une string dans un .ui mène le QtDesigner à le mettre en tr(). Par conséquent, il ne traduit rien seul. Comment obtenir un fichier .ts ou le mettre à jour sans perdre la moindre traduction ? Il suffit de lancer lupdate sur le projet ou sur le dossier contenant les sources avec comme destination le .ts. À noter que c'est optionnel, vous pouvez tout à fait ajouter des chaînes non présentes en tr() (par exemple pour un tr d'une string reçue). Une fois les chaînes traduites avec ou sans QtLinguist, vous pouvez effectuer lrelease sur le fichier .ts pour obtenir le .qm final.

Voilà pour ce que je peux en dire.

Bonne journée,
Louis

[koala01]

Salut,

Respire un grand coup, reste zen et ressors tous les arguments que tu nous as servi ici à tes chefs, en y mettant un minimum les formes

En fait, tu as déjà fait le plus gros du travail en dressant une liste à peu près exhaustive des problèmes rencontrés. Autant te servir de cette liste dans ton argumentation

Tu peux éventuellement préciser qu'il ne suffit pas forcément de rajouter un s dans une chaine ou l'autre : 1 fichier a été modifié deviendra 10 fichiers ont été modifiés, et que qlinguist permet de fournir ce genre de nuance.

Et, bien évidemment, tu peux aussi argumenter sur le fait qu'il est quand même beaucoup plus facile pour tout le monde de partir d'une interface qui contient les chaines de caractères dans une langue donnée plutôt qu'un numéro de chaine de caractères qui risque de ne rien dire à personne (ou, du moins, qui rend beaucoup plus difficile le fait d'identifier le texte que l'on est sensé retrouver pour un widget donné )

[Feneck91]

Le lUpdate est fait automatiquement à la compilation. Sauf que le format de ce fichier est "trop compliqué" pour le client final (qu'on a d'ailleurs pas pour le moment).
Donc le format est le suivant :

Code xml :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Localisation class="Localisation" available="fr,uk,es,ar,zh" default="fr">
  <String class="String" id="MACHAINE">
    <fr class="Lang" value="Ceci est ma chaine en français"/>
    <uk class="Lang" value="This is my string in english"/>
    <ar class="Lang" value="texte en arable"/>
    <zh class="Lang" value="texte en chinois"/>
  </String>
  <String class="String" id="MACHAINE2">
    <fr class="Lang" value="Ceci est ma chaine 2 en français"/>
    <uk class="Lang" value="This is my string 2 in english"/>
    <ar class="Lang" value="texte en arable"/>
    <zh class="Lang" value="texte en chinois"/>
  </String>
</Localisation>

Et démerdez vous : en fait, n'utilisez pas qlinguist et gérer à la main les traductions pour avoir CE système de fichier tellement révolutionnaire que même Qt n'y a pas pensé !

Pour les ui, Qt génère la traduction (avec des tr("")) et en effet, lUpdate récupère ce qu'il y a à traduire et appel la traduction ce qui permet de traduire l'UI une fois le fichier ts compilé.
Et bien ça non ! On a notre propre système révolutionnaire qui refait exactement la même chose que Qt mais .... à la main !

EDIT : @ koala01 : Hélas tu prèches un converti ! J'ai fais pas mal de wxWidgets et lorsque je me suis intéressé au cas Qlinguist je me suis dit : "c'est amusant, ils ont exactement le même principe !! (gettext pour wxWidgets), seul le format du xml change, les outils aussi mais le principe est exactement le même et c'est pas pour rien !
Et les arguments je les ai déjà donnés ! Plusieurs fois !
Les pluriels ? Ils s'en tapent ! Il y a plusieurs écritures ? Pas grave on fera des if dans les rares cas qu'on aura à traiter !
On perd du temps ? Oui et alors ? JAVA eux ils n'en perdent pas (et de toute façon, ils ne gère pas les pluriel non plus avec ce système) et puis ils ne perdent pas 35 minutes à chaque re-compilation.

Une des solutions serait que côté JAVA ils utilisent le même format (ou via une moulinette on pourrait le générer), ainsi on pourrait utiliser l'éditeur QLinguist et ça évite d'en refaire un ... mais bon là on peut rêver !
Non, on va se faire chier pendant des mois à développer avec un système de traduction pourri pour ne pas avoir deux éditeurs différents !

EDIT : Une question : n'y a-t-il pas moyen d'utiliser QLinguist et son système de traduction pour JAVA ? Ça donnerais du taf à l'équipe JAVA donc elle ne voudra pas mais au moins ce serait un 'vrai' système de traduction.

[Feneck91]

Autre queston : Est-il possible de générer une fichier compatible QLinguist (via xslt ou autre) à partir du format du fichier donné ?
Ça permettrait de générer le fichier QLinguist, puis, une fois QLinguist quitté, de réintroduire les chaînes traduite dans le format xml utilisé par JAVA.

[Feneck91]

J'avais oublié : pas de gestion de 'non utilisation' de la traduction. Donc quand on n'utilise plus la traduction, il faut vérifier dans tout le projet si elle doit être supprimé (en tant que variable membre) ou pas.
Impossible aussi de vérifier qu'à chaque variable membre son entrée dans le fichier xml est bien présent !

[Feneck91]

Petites nouvelles.... J'avais implémenté QLinguist dans une branche où il y avait plein de nouveautés : branche scratchée...

J'ai fini par démissionner pour travailler avec des vrais pros. Ce qu'a fait presque toute l'équipe....
Le développeur Java confirmé s'est fait débarquer du jour au lendemain...
Le chef de projet qui avait décidé ça aussi...

Ça me ferait presque rire ce message maintenant...