Suite au mail de Kent1 sur le sujet et à notre skyperie d’hier matin, voilà quelques idées d’évolutions de l’outil de traduction de SPIP.
Gérer plusieurs bases de traductions
Aujourd’hui, Tradlang/Salvatore tourne uniquement sur la base de SPIP.net.
De même, la nouvelle balise permet de définir les modules à traduire par Tradlang/Salvatore sachant que Salvatore désigne aussi la base SPIP.net
Les travaux de Kent1 sur Tradlang visent à rajeunir l’interface elle même (plugin, interface dans le privé, crayons…) et aussi à permettre de définir des environnements de traductions différents que SPIP.net. Par contre, il est essentiel de faire en sorte qu’un module de langue ne soit traduit que dans un seul environnement de traduction.
Une solution serait de faire évoluer la balise de traduire ainsi :
le nouvel attribut environnement servirait en autres à générer non pas un fichier traductions.txt mais traductions_spipnet.txt. Il resterait à Tradlang/Salvatore de SPIP.net de désigner ce fichier de traduction et non plus traudctions.txt.
Regrouper Salvatore et Tradlang
Une autre évolution possible est de combiner le nouveau TradLang avec Salvatore pour en faire un plugin complet (interface de traduction + interface d’import/export) et de l’appeler Salvatore in fine. La ba lise traduire prendra alors tout son sens car actuellement elle ne désigne qu’une partie du gestionnaire de traductions.
J’avais commencé à revoir l’interface de traduction aussi en en parlant avec Fil et Paolo. Je joins à ce mail le fichiers des idées/spécifications pour ceux que ça intéresse.
J'ai vu chez des "concurrent" l'option de traduire "dans le logiciel" un peu comme font les crayons pour le contenu de la bdd SPIP.
Je crois qu'une telle solution encouragerait plus de monde à participer à l'effort collectif surtout quand il faut corriger des erreurs typographique et de malentedus.
Je crains par contre qu'il faudrait élaborer un système de statuts et de droits d'accès pour organiser ce travail avec des contributeurs inconnus. Ca serait nettement moins bien que la situation actuelle où on travaille librement.
Je crois qu'une telle solution encouragerait plus de monde à participer à
l'effort collectif surtout quand il faut corriger des erreurs typographique
et de malentedus.
C'est ça le plus important.
Je crains par contre qu'il faudrait élaborer un système de statuts et de
droits d'accès pour organiser ce travail avec des contributeurs inconnus. Ca
serait nettement moins bien que la situation actuelle où on travaille
librement.
En règle générale ces situations (deux traducteurs travaillant en même
temps sur la même langue) sont rares, et sont gérables par des "merge"
à la main dans des fichiers. Ensuite on purge la base, et on recharge
le fichier.
Je suis traducteur du module x dans la langue y. Des utilisateurs ont
proposés des corrections. Je les vois et je les valide (oui/non) dans
l'interface Tradlang.
Oui! Si on arrive à limiter les routines de gestion à ca, je crois qu'on avancerait beaucoup. Il faudrait deux choses pour que chacun en profite vraiment:
1. La correction devrait se faire dans un site SPIP en production et les changement devraient s'activer dans ce site tout suite après l'intervention du traducteur/webmestre.
(Pour y arriver il faudrait qc du genre d'une table MySQL pour les traductions personnalisées qui surchargereient les fichiers de langue.)
> Question : comment assurer la cohérence entre les langues et aussi la langue
> de référence ?
2. Ces correction devraient être mis "en attente" dans trad_lang afin d'être validé (ou non) par un traducteur ici même. C'est ici que se jouerait la question de la cohérence. Avec une telle démarche on obtiendraot le même niveau de cohérence qu'actuellemnet.
J'ai vu chez des "concurrent" l'option de traduire "dans le logiciel" un peu
comme font les crayons pour le contenu de la bdd SPIP.
Il faut balancer des noms qu'on puisse voir concrètement de quoi il retourne :o
Je crois qu'une telle solution encouragerait plus de monde à participer à
l'effort collectif surtout quand il faut corriger des erreurs typographique
et de malentedus.
Je crains par contre qu'il faudrait élaborer un système de statuts et de
droits d'accès pour organiser ce travail avec des contributeurs inconnus. Ca
serait nettement moins bien que la situation actuelle où on travaille
librement.
J'ai souvenir d'une web-app dont je n'arrive pas à retrouver le nom
qui offrait une option de proposer une meilleure traduction.. En fait
on été redirigé vers la page de traduction du projet et on est
positionné où il fallait. En gros, c'est comme un système de
bug-tracking appliqué à la traduction (on doit donc arriver sur la
page de traduction du module adéquat ou du core, voir afficher la
chaine originale --ou le l'étiquette dans le cas de Spip, voir sa
traduction actuelle --utile pour savoir si la correction est déjà
faite si peut-être qu'on n'a pas la bonne version du fichier de
langue--, voir les propositions déjà faites, pouvoir enfin soumettre
la sienne ou laisser un commentaire)
Un autre CMS (une grosse goutte bleue venue de Belgique) charge le
fichier de langue en base de données (l'éternel débat est de savoir
s'il faut faire des requêtes SQL ou ouvrir des fichiers, sachant que à
un moment les donnés vont être dans le cache... perso, j'ai souvent
reproché à ce gestionnaire de contenu que j'aime bien sa trop grande
dépendance à la bdd..) Du coup, le webmestre peut faire ses
traductions localement (sans appartenir à l'équipe officielle ni
toucher aux sources officiels) et ce sont ses traductions à lui qui
sont gardées en cas de mise à jour (un peu comme Spip permet des
fichiers de lang perso qui ont le dernier mot). Une fois les
traductions locales faites et satisfaisantes, il es possible de
générer un fichier de traduction qui sera alors soumis comme patch
(sachant que n'importe qui peut soumettre un patch de correction et
que ce sont les responsables --authentifiés et ayant droit d'écriture
sur les sources-- qui décident de les intégrer --un merge quoi-- après
relectures)
Ce sont deux approches qui permettent la participation des usagers
mais ne se basent pas sur une structure aussi complexe que j'ai cru
apercevoir dans certaines réponses.