J’ai cherché comment traduire « commit » dans le contexte d’un contrôle de versions type git ou subversion. J’ai eu quelques propositions qui peuvent permettre de construire des phrases au cas par cas, mais aucun terme vraiment éclairant et générique.
Mais surtout je me suis heurté à pas mal de réactions concernant l’idée même de traduire le terme.
Franchement je ne cherche pas à « défendre la langue française ». Elle va très bien, merci pour elle, et surtout elle ira d’autant mieux qu’elle restera vivante et s’autorisera à importer des termes étrangers. Il est d’ailleurs amusant de voir de temps en temps de la résistance à importer un terme anglais… qui est en fait un terme français qui a été importé outre-manche ou outre-atlantique il y a bien longtemps. Bref, là n’est pas la question.
Ma petite histoire
C’est Eyrolles qui m’a pas mal ouvert les yeux sur l’utilité d’une traduction. À l’époque de la rédaction de mon livre sur PHP, ils nous ont imposé de chercher au maximum des traductions.
- Premier constat : Quand on cherche, le plus souvent, on trouve un terme français qui correspond très bien.
- Second constat : Le plus souvent même ceux qui n’utilisent que les termes anglais ne remarquent même pas qu’il y a eu effort particulier de traduction.
Tout le monde utilise thread, parser, template, tag… mais finalement un fil de discussion ou d’exécution, un moteur ou un analyseur syntaxique, un gabarit, une balise ou une étiquette, ça fonctionne très bien aussi. En fait ça fonctionne même mieux, avec une lecture bien plus fluide quand bien même les termes sont rarement francisés dans le contexte informatique.
Il m’a ainsi fallu pas mal de volonté pour faire un chapitre sur les gabarits de pages HTML en PHP. Damned, j’ai résisté et voulu écrire « template » jusqu’au bout. Je me demande même si nous n’avions pas fini sur un compromis en laissant « template » dans le titre de chapitre en craignant que « gabarit » ne soit pas immédiatement compris. Sauf qu’au final je suis bien content de l’avoir fait ce changement.
Abracadabra
J’ai vu trop d’informaticiens utiliser les termes anglais comme des formules magiques. J’ai même eu plusieurs discussions à l’époque du choix de « gabarit » où on m’a expliqué qu’un « template » c’était différent parce que [insérez ici une connotation imaginaire]. Moins mon interlocuteur avait de recul sur ce qu’il manipulait et de compréhension du fonctionnement, plus il était attaché au terme anglais. Cette constatation n’a jamais été démentie (attention à ne pas vous vexer : je ne prétends pas que la réciproque est vraie).
Si je tiens au français, c’est justement pour parler français et pour ne pas utiliser de termes formules magiques où chacun y met son propre imaginaire. Ça permet de normaliser le discours, de laisser prendre du recul à ceux qui sont trop habitués à copier sans comprendre, et de parler du fonctionnement plus que d’une série d’outils et de commandes.
Comme la plupart des informaticiens, j’ai beaucoup tendance à utiliser l’anglais dans mon jargon. J’ai toutefois pu noter de réelles différence d’impact et de compréhension dès que je fais l’effort d’utiliser des termes français. Et cette facilité d’échange ne concerne pas que les débutants : Je la constate aussi face à des habitués du terme comme de la technique qu’il recoupe. À vrai dire plus la personne en face a du recul et de la compréhension, plus on peut parler de ce qu’il y a derrière et autour et plus la langue utilisée est un détail.
À l’usage
Seule l’habitude fait un peu résistance, mais pas tant que ça. En fait tout l’enjeu c’est de trouver un terme qui sera immédiatement compris sans réfléchir par un natif francophone, même par celui qui n’utilise que le terme anglais dans sa vie professionnelle. Très souvent on trouve, et si extrêmement peu de mes correspondants parleront eux-même de fil d’exécution, aucun ne tique quand je le fais.
Il reste quelques termes difficiles à traduire. Le plus souvent ce sont des termes qui ont déjà été détournés de leur sens usuel en anglais. Forcément, trouver un terme français revient aussi souvent à le détourner de son sens usuel… et là ça coince. À l’écrit, quand ça arrive, je tente de forcer un peu le terme français s’il me semble viable, quitte à mettre le terme anglais en parenthèses à la première occurrence.
Et quand rien ne va ? et bien j’utilise l’anglais, ça me va aussi très bien. Fuck à l’Académie Française qui créé un nouveau mot complètement délirant par volonté absolue de ne pas utiliser l’anglais. Ce n’est pas ma motivation. Par contre j’en arrive là après une recherche sérieuse, avec l’aide de ceux qui le veulent.
Et pour « commit » alors ? Après un nombre important de contributions sans aucune suffisamment claire et générique – de mon avis personnel – Karl a proposé le simplissime « enregistrer ». Ça ne plaira peut être pas aux puriste, mais j’ai l’impression que ça colle parfaitement à pas mal de sens qu’on donne à « commit », et que je trouverai bien les termes pour les quelques sens manquants avec les notions de version et transaction. Ceci dit ça reste un sujet ouvert pour moi.
10 réponses à “Vive la translation du jargon”
Il me semble que le livre « progit » traduit « to commit » par « consigner »
J’adopte ! C’est *exactement* le bon terme pour moi.
Le verbe anglais « to consign » mentionne « to commit » comme synonyme (sur wiktionary)
Le même wiktionnaire donne le sens suivan t à « consigner » :
(Figuré) Rapporter, citer dans un écrit.
Ce fait est consigné dans nos annales. – Cette circonstance a été consignée au procès-verbal.
Par habitude, je n’utilise le jargon anglais qu’avec les développeurs. Certains termes ne sont pas connus de tous, et c’est là où c’est utile : la communauté anglophone est bien plus conséquente. Quand on connaît les bons termes en anglais (+ variantes), ça facilite les recherches.
La question que je me pose est : vous codez en anglais ? (code, commentaires, documentation)
Documentation : rarement.
Commentaires : souvent, pas toujours (quand je suis fatigué ça passe au français, idem si le code a déjà des commentaires français ou si je fais du quick ‘n dirty)
Code : euh… il y a le choix ? en fait oui, mais je n’utilise aucun langage où le « if » soit un « si », et comme j’adore pouvoir lire mon code, les fonctions et variables sont en (charabia)anglais
Je suis très très étonnée que tu commentes en anglais et code en anglais, alors même que tu viens de prôner le français pour la compréhension.
Tes collègues ne sont pas francophones ?
Si, effectivement.
Deux raisons :
Le langage lui même est en anglais (mots clefs, fonctions), donc pour éviter un mélange horrible je fais des méthodes, classes et variables en anglais aussi
Pour les commentaires c’est moins tranché, et je me prends trop souvent à les faire en français (par fainéantise) mais entre le code qui vient de l’extérieur (commenté anglais) et celui destiné à être partagé (commenté anglais pour large diffusion), ça ferait beaucoup de bascules anglais/français suivant les fichiers. Pas forcément idéal à mon sens. Ceci dit un code entièrement commenté français ne me choquerait pas s’il est destiné à rester uniquement lu par des français.
Pour « commit » j’utilise « contribution », tout simplement.
Le mot est souvent connoté à cause de l’influence de l’Open Source : pour beaucoup « contribuer », c’est participer à un projet. Et quand tu leur demande « Ok, et quel type de participation ? », ils répondent naturellement « des commits ! ». Bref, le sens est bien là, il faut juste le saisir :)
Je n’ai jamais eu de problème avec cette traduction. Les développeurs peuvent l’utiliser, la localiser « contribution locale » / « contribution distante » et dans certains cas, « contribution » peut même recouvrir un autre terme anglais difficile à traduire : « merge ».
« J’ai contribué la branche Dev sur Release » se comprend en effet très bien, et traduit correctement notion d’apport de modifications.
Autre avantage : les clients comprennent aussi. Et traduisant le terme, il devient accessible.
Ces commentaires me ramènent bientôt 10 ans en arrière : j’étais tombé sur les mots test case, mock object, framework et legacy code lors de la traduction de SimpleTest… Les pas sont petits, longs, tortueux mais tellement précieux.
http://www.onpk.net/index.php/2004/11/15/224-ce-que-les-traductions-disent-de-vous
La première fois nez à nez avec Eclipse il y a 8 ans, j’entendais autour de moi les collègues parler de « commiter ». Insupportable mot à mes oreilles. D’autant que ces mêmes collègues n’arrivaient que vaguement à me traduire la chose en français, ce qui n’aidait pas à vraiment me la représenter (je ne suis pas développeur à la base). J’ai été le seul à installer le package langue fr qui traduisait les termes. « Commit » est devenu « Livrer » et « update » « Mettre à jour ». J’ai compris à ce moment là (« Hep, j’ai livré mes modifs sur le référentiel les gars ! Faites une mise à jour ! »).
En revanche, les collègues qui intervenaient (régulièrement) sur mon poste perdaient leurs repères (voire un peu de compréhension je crois).
Ne pas savoir (ou vaguement) la signification française de termes anglais qu’on utilise quotidiennement et les franciser en ajoutant la terminaison du premier groupe (Commit – commiter), j’assimile cela ni plus ni moins à de la pauvreté lexicale.
Je voudrais prendre le contrepied de cet article : pourquoi garder commiter / commit ?
Une bonne raison _pratique_, c’est que les traducteurs français vont proposer plusieurs variantes (cf. ci-dessus : enregistrer, consigner, contribuer), donc cela engendre de la confusion, là où il y a une seule et unique notion, pour les utilisateurs qui compareraient plusieurs documentations.
Je ne suis pourtant pas un défenseur du franglais. C’est à éviter autant que possible. Mais ici, il faut considérer qu’on n’a pas un mot anglais, mais un terme technique, correspondant exactement à une commande. On ne traduit pas les commandes, n’est-ce pas ?
Donc on forge un néologisme, qui correspond exactement à la commande, et ainsi ce n’est pas une « trahison » du français.