Traduire ou ne pas traduire, telle est la question
Il y a quelques temps, je poussais un grand cri étranglé en rapport avec l’équipe de WordPress-net.fr – cf. mon billet multicommenté WP-fr.net: y’a-t-il un pilote dans l’avion ? – et les nombreuses réactions et précisions m’ont permis de pénétrer dans le monde des gens qui bossent sur le WordPress francophone. Je me moque mais j’imagine que le rapport entre les utilisateurs de WordPress et les « décideurs » est un peu le même que celui d’un fan de BD vis à vis d’un auteur professionnel. On sait qu’ils existent, on profite de leur boulot mais on a un peu de mal à imaginer que ce sont des hommes ou femmes comme vous et moi.
Dernièrement, je me suis occupé de la traduction française d’un plugin que je compte utiliser et j’ai été confronté au problème de la validation de mes traductions – j’en ai déjà parlé mais je développe tout ça dans la suite. Il a fallut que je me replonge dans les méandres de Slack et j’ai fait des découvertes incroyables qui méritent bien un billet ici.
La traduction avant la Civilisation
Traduire un thème ou un plugin WordPress a longtemps été le Far-West. Le concepteur du plugin/thème générait un fichier .pot et le traducteur passait par un éditeur de texte ou PoEdit pour créer les fichiers de traduction française qu’il envoyait au concepteur qui se chargeait d’incorporer ça dans le fichier zip de son travail.
C’était le Far-West puisque n’importe qui pouvait faire une traduction dans son coin comme il l’entendait, fautes d’orthographe et contresens « Google Translate » intégrés. Je me suis même retrouvé avec une traduction « récupérée » par un autre traducteur qui avait dû intervenir sur 10% de mon texte avant de le contester.
Le trou noir
Depuis quelques temps, l’ordre et la loi s’imposent peu à peu dans la jungle des traductions puisque WordPress.org propose aux développeurs un système de traduction collaboratif directement au niveau de la page du thème/plugin. Cette avancée permet de simplifier le processus, automatiser les mises à jour des traductions et… formaliser les traductions.
En effet, le traducteur n’a plus la main sur la validation de la traduction. L’équipe française de traduction de WordPress contrôle le processus de validation du travail du traducteur comme indiqué ici https://fr.wordpress.org/2015/12/18/how-french-community-handles-pte-requests/. Si vous lisez l’english dans le texte, vous voyez qu’il faut qu’un PTE (editor) valide la traduction, PTE qui fait obligatoirement partie de l’équipe de traduction française – mais on peut aussi devenir PTE comme me le fait remarquer Flobogo sans être membre de l’équipe en question. Cela permet évidemment d’obtenir une traduction de qualité mais le côté sombre de l’affaire, c’est que la traduction n’est pas disponible aux utilisateurs tant qu’elle n’est pas validée. Et vous êtes légitimement en droit de penser que ça ne risque pas d’arriver avant les calendes grecques… Le plus simple serait de vous faire bombarder PTE pour valider automatiquement votre travail. Et il est temps de sortir la machette et les porteurs. En avant pour l’Aventure !
Petit manuel en images de la traduction d’un plugin
Comment ne pas devenir PTE en cinq leçons
Alors, pour devenir PTE, il faut pouvoir contacter la French Team. Je pensais – naïvement, j’étais jeune et fougueux – que cela se faisait au niveau du forum WP-net.fr. Oh que non, ce serait trop facile. Et si j’ai appris quelque chose lors de ce passage sur Terre, c’est que rien n’est facile quand il s’agit de la communauté francophone WP. Pour contacter l’équipe de traduction, il faudra passer par Slack qui est devenu un peu le centre de communication de ceux qui portent un chapeau. Évidemment, ce n’est pas le même Slack que pour l’association WP-net.fr – j’en vois qui commencent déjà à décrocher – mais un autre Slack (et Slack, dans sa très grande sagesse, crée des comptes indépendants les uns des autres pour chaque Slack): https://wordpressfr.slack.com/.
Mais on y entre que par invitation pleurnichez-vous ? Pas de problème, il faut vous inscrire en passant par cet URL: http://boiteaweb.fr/slack-invitation (oui, ça marche maintenant). Un peu d’explications ici http://www.geekpress.fr/invitez-vous-sur-le-chat-wordpress-francophone-sur-slack/. Vous trouvez ça un peu tiré par les cheveux ? Moi aussi. Mais qui sommes-nous pour juger…
Slack a la bonne idée de planquer les « channels » auxquels vous n’êtes pas abonnés et il faut donc cliquer pour trouver celui qui nous intéresse, à savoir #traductions. cf. image suivante.
À ce moment-là, vous pouvez rejoindre la discussion et demander la validation de votre traduction. Et là, les ennuis commencent.
Au pays des règles de ponctuation
Inutile de rêver, la communauté des traducteurs n’a rien à voir avec la monitrice de surf sympa et relax de vos vacances à la mer. Nous entrons au pays des Règles et de la Norme – j’ai un copain comme ça et j’ai régulièrement envie de le frapper à coups de barre de fer.
Si vous êtes fâché avec l’orthographe et ne supportez pas les espaces insécables, vous allez vous retrouver en pays ennemi. Mais on ne peut peut guère leur reprocher cette attitude : une bonne traduction de termes techniques demande une rigueur certaine. Les normes ont le gros avantage de structurer le résultat et le rend pérenne. Une bonne traduction demande des règles strictes… ce qui signifie du travail en plus de juste traduire les phrases. J’y ai ainsi découvert des ressources inconnues et utiles:
- le guide officiel de traduction: https://fr.wordpress.org/category/guide/
- le glossaire officiel francophone: https://translate.wordpress.org/projects/wp/dev/fr/default/glossary – mazette !
Et c’est à ce niveau que, hagard et frustré, les cheveux en bataille et les yeux injectés de sang, que je pousse un râle énervé.
Une structure pyramidale au sommet dans les nuages
Si vous avez un peu de bouteille, vous avez dû voir le passage des termes « billet » à « article » ou « mot-clef » à « étiquette » dans le vocabulaire francophone WordPressien. Ignorant des tenants et aboutissants de cette affaire, vous avez pris ça comme on se prend un sanglier dans le pare-choc avant : avec un certain fatalisme en maudissant le Destin cruel et imprévisible. Mais contrairement au sanglier, ces termes ne doivent rien au « pas de bol ». Des gens en chair et en os l’ont décidé… et visiblement sans me demander mon avis.
Et c’est là que je couine. Je ne peux pas reprocher à des personnes de fournir un travail bénévole de traduction mais, encore une fois, je ne peux que reprocher un manque de transparence frustrant. Il y a un forum et un site officiels et aucun message d’information, pas de consultation éventuelle, rien, nada.
La consultation du glossaire officiel m’a même réservé une surprise de taille: le terme shortcode a une traduction officielle qui est code court. Une surprise parce que je n’ai jamais croisé ce terme en plus de dix ans de WordPress. Que nous l’utilisons quasiment quotidiennement sur le forum sans que personne ne fasse de remarque. Que je le sors par louche entière sur ce blog sans qu’aucun visiteur ne vienne gentiment me corriger. Et on se retrouve avec un paradoxe assez classique en France : une terminologie officielle non utilisée par les premiers concernés, à savoir les citoyens/utilisateurs, décidée par une Académie qui ne semble pas se préoccuper de la promotion de ses propres décisions. Parce qu’une recherche rapide sur les mots « code court » sur Google montre rapidement que personne ne l’utilise sur le Web. Pire, le seul shortcode officiel du moteur WordPress, le fameux [ gallery ] n’apparaît sur le Codex qu’en version anglaise. Et encore pire que pire : https://codex.wordpress.org/fr:Shortcode. La traduction officielle du Codex ne prend pas en compte la traduction recommandée.
Avançons au lieu de couiner
Même si je finis en mode ronchon, l’objectif de ce billet n’est pas de contester l’équipe responsable de la traduction – comme beaucoup de gens, ils font un travail bénévole pour soutenir un moteur de CMS que nous aimons bien. Ils cherchent des solutions, ils essaient de faire en sorte que les traductions soient les plus carrées possibles et on ne peut que les en féliciter. Mais une vraie promotion de cette traduction me parait indispensable – et c’est l’objet principal de ce billet – et peut motiver des personnes à se lancer dans la traduction de plugins par exemple en toute connaissance de cause. Et il faut une page expliquant comment devenir traducteur de WordPress et qui travaille là-dessus. Le flou artistique sur cette question est particulièrement frustrant – parce que le logiciel libre donne l’impression que « tout le monde » peut participer sauf que « tout le monde » ne sait même pas à qui s’adresser.
Je finirai quand même par une remarque perfide : est-ce que le principe de validation n’est finalement pas contre-productif ? Le système ancien permettait au programmeur d’avoir rapidement une traduction à la qualité inégale (ou l’on parlait de plugin au lieu d’extension, où on ne respectait pas les espaces insécables, où l’on oubliait les guillemets typographiques…) mais qui avait le mérite d’exister et qui était dans la plupart des cas d’une grande aide pour les non-anglophones. Le système de validation permet d’avoir une traduction de bien meilleure qualité… mais pas immédiate, loin de là, comme le confirme mon expérience. Sans compter les volontaires qui risquent de se décourager rapidement s’ils ne sont pas fans de précision dans leur traduction. Je me retrouve avec un plugin traduit – du mieux que j’ai pu – toujours pas validé. À la merci du bon vouloir de personnes qui vont grimacer à la lecture de ce billet et qui ne le valideront peut-être jamais, qui peut savoir ? Cette contrainte est très frustrante puisqu’on se retrouve à faire un travail bénévole au bénéfice de la communauté mais sans garantie de résultat. Même Wikipedia n’impose pas des règles de participation aussi strictes.
Il va falloir que je regarde quelles sont les règles de validation de traduction pour les autres langues et en relisant la déclaration d’intention de l’équipe de traduction, je comprends limpidement l’objectif ciblé: offrir la meilleure traduction possible pour les créateurs de plugin. C’est magnifique pour les programmeurs qui sont assurés d’avoir un résultat qui satisfera l’utilisateur – sauf l’abruti qui demandera « C’est quoi un code court ? » – mais je ne sais pas s’il sera aussi satisfait d’avoir à poireauter pour une validation de quelques lignes pour les plugins – oups, les extensions – les plus simples.
J’ai été contacté par l’équipe de All in One SEO pour servir de PTE (validateur, quoi) et j’ai naïvement accepté alors que je me rends compte maintenant que j’ignorais tout des règles exigées pour la traduction (je n’ai pas eu de nouvelle). Je suis content que ça ne soit pas fait, c’est un plugin très important et une traduction défectueuse aurait été catastrophique mais toutes les extensions ne sont pas aussi populaires et ne demandent pas une précision de termes impeccable. J’ai bien peur que le système freine la traduction des « petites extensions »…
Enfin, il n’y a pas pour l’instant de règle claire sur ce qui passe ou pas la validation. Par exemple, on peut comprendre que des tournures pas claires ou des fautes d’orthographe nécessitent des corrections mais est-ce qu’utiliser le terme plugin est considéré comme disqualifiant – ou oublier les espaces avant un point d’exclamation ? Si c’est le cas, on risque fort de démotiver les personnes volontaires: le traducteur est sûrement partant pour corriger les erreurs grossières mais s’il doit reprendre deux ou trois fois son boulot parce qu’il a loupé des choses de ce type, il risque de laisser tomber et on va se retrouver avec une correction jamais validée alors qu’elle ne pose aucun problème de clarté ou de compréhension pour l’utilisateur.
Et enfin, dernier paradoxe: les plugins d’auteurs français, qui font donc leur propre version française validée par eux-mêmes, risquent d’avoir des textes pas conformes aux canons demandés et seront donc moins « valables » que des plugins traduits !
Proposition
Au final, en tapant ce texte, je me suis dit que l’on pouvait peut-être moduler ces histoires de validation.
Par exemple:
un plugin de plus de six mois d’âge avec moins de cent utilisateurs pourrait voir sa traduction validée immédiatement – sauf erreur grossière de traduction détectée – après envoi de l’URL de consignes sur les traductions.un plugin avec moins de cinquante entrées de traduction et moins de mille utilisateurs pourrait être validé de la même manière. En effet, les traductions validées ne sont pas gravées dans le marbre et, si erreur il y a, les corrections sont possibles par les utilisateurs.un plugin bien installé et complexe – plus de trois mille utilisateurs et plus de cinquante entrées – nécessite une traduction parfaite parce qu’il est plus susceptible d’être utilisé par la communauté.
Bon, bref, une échelle de référence qui aurait à mon avis un avantage: permettre la traduction rapide de « petites extensions » peu populaires mais qui nécessitent une version française pour quelques utilisateurs pour des phrases qui apparaissent côté visiteur par exemple. Ce qui n’empêcherait pas une traduction conforme pour les « grosses extensions » populaires et très utilisées chez les utilisateurs francophones.
Je comprends parfaitement la notion de défense de la langue française – je milite globalement dans ce sens même au niveau de mon travail – mais je trouverai dommageable que ce combat freine les bonnes volontés autour d’un CMS construit à la base en langue anglaise. Ou alors il faut faire un fork de WordPress en langue française qui n’accepte que les extensions aux traductions dûment validées…
Mise à jour du 06/09/2016 : après discussions et réflexions, je reconnais que cette approche de la validation n’est pas possible. J’ignore si on pourra un jour gérer la traduction d’extensions de manière plus souple mais le système actuel ne supporte pas d’approximation ‑ cf. la réponse faite par FX Bénard dont je donne le lien en fin de billet.
Complément quelques heures plus tard
Rhââââ. J’abandonne la validation de ma traduction par la voie officielle – même si je vais essayer de la rendre nickel pour le coup. En effet, le validateur m’a fait remarquer que j’avais oublié les apostrophes typographiques. Elles se tapent avec un code spécial et il est conseillé d’utiliser un pilote de clavier enrichi. Ce qui va me permettre de les lister ici:
- kbdfr dk – http://psydk.org/kbdfr-dk – est celui que j’utilisais depuis assez longtemps mais on m’a fait remarquer qu’il lui manque la fameuse apostrophe typographique – et aussi les points de suspension. Je le trouve très ergonomique parce qu’il passe naturellement par la touche Majuscule pour les majuscules mais, évidemment, ça signifie que les chiffres à atteindre par majuscule ne fonctionnent pas. Ça peut être gênant mais je m’en passe bien avec un clavier numérique.
- kbdfrac – http://users.sfr.be/denis.liegeois/kbdfrac.htm – est très utilisé mais la disposition des caractères spéciaux est peu pratique pour moi. Il ne propose pas les points de suspension.
- Pilote enrichi – https://sourceforge.net/projects/frelrick/ – me semble le plus complet et plus ergonomique que le précédent. Il embarque même des caractères spéciaux étrangers !
Luciole nous propose deux outils pour tester la validité topographique d’un texte :
- http://typographie.piprime.fr/ – un moteur expérimental
- http://www.dicollecte.org/grammalecte/telecharger.php – une extension Firefox/Libre Office/Open Office
Au final, j’ai passé un temps fou à corriger cette traduction et elle était encore incomplète. Le validateur a passé un temps fou à la vérifier et il n’en peut plus. Ce système me parait complètement kafkaïen. Il nécessite des réflexes de typographie stricts, ce qui signifie dans mon cas littéralement réapprendre à taper. Je n’ose pas imaginer les problèmes que vont rencontrer les personnes qui maîtrisent le français moins bien que moi pour proposer une traduction. Ça me paraît juste impossible. L’obligation de passer à un pilote de clavier spécial ou de taper du code pour les caractères spéciaux me font penser que seules les personnes possédant les réflexes ad hoc de typographie. Celles qui n’en ont pas l’habitude peuvent en profiter pour s’améliorer… ou abandonner devant le travail que cela demande. Et on se retrouve même avec quelques incohérences étranges avec par exemple e-mail dont le glossaire ne propose pas la version officielle française – et c’est volontaire, hein, pas un oubli. Kafkaïen…
FX Bénard me répond
François-Xavier Bénard est un des traducteurs français WP les plus actifs et il a pris le temps de faire une réponse sur mon billet polémique ‑ à lire ici https://fxbenard.com/traduire-wordpress-ensemble/. Évidemment, sa réponse est un peu déprimante puisqu’elle douche quelque peu mon enthousiasme de grande gueule brouillonne mais elle est frappée au coin du bon sens pratique de celui qui fait. Je le remercie pour sa patience et sa compréhension.
Bépo
Dans une espèce de lente spirale sans fin, ce problème de typographie française m’a conduit à m’intéresser au bépo. Je compléte mon histoire ici https://www.li-an.fr/blog/mon-travail/mes-zimages/ami-bepo/.
