Discussion :

[r0d]

Salut à tous les traducteurs et relecteurs.
Il apparait que certains d'entre nous ont décidé de traduire les noms des variables dans les codes sources, et d'autres non. Or, il me parait évident que, comme le souligne mujigka, il faudrait uniformiser cela. Autrement dit, il faudrait que nous nous mettions d'accord.

Personnellement, j'aurais tendance à les laisser en anglais. Mais si on m'écoutais, le fait même de traduire ce livre ne servirait à rien

Plus sérieusement, qu'en pensez-vous?

[Higestromm]

Personellement je pense qu'un code en anglais ne le rend pas forcément plus difficile à comprendre (sauf cas exceptionelle).

[Thierry Chappuis]

Pour le moment, dans la plupart des relectures que j'ai effectuées, les variables n'avaient pas été traduites. Pour ma part, je me suis contenté de traduire avec soin les commentaires, mais n'ai aucunement touché ni aux noms des variables, ni aux noms de fonctions. Je ne pense pas que des noms de variables en anglais nuisent à la compréhension du code, mais une traduction rigoureuse voudrait qu'on les traduise également.

L'objectif principal de ce projet de traduction est de rendre accessif au public débutant non anglophone le texte très pédagogique et formateur que nous a fournit Bruce Eckel avec Thinking in C++. Il m'est difficile d'évaluer les enjeux d'une telle décision, n'ayant aucun problème de compréhension avec l'anglais, et n'étant plus complètement débutant en C++. Toutefois, le rôle que jouent des noms de variables bien choisis dans la compréhension d'un programme n'est pas négligeable, et la question mérite d'être discutée.

Certains morceaux de code reviennent dans plusieurs sous-chapitres souvent traduits par des personnes différentes. Une traduction absolument cohérente des noms de variables et des noms de fonctions serait probablement accompagnée d'un effort de coordination accru entre les différents traducteurs. Cela en vaut-il vraiment la peine?

Thierry

[Thierry Chappuis]

Les traducteurs de "Penser en Java" n'ont pas traduits les noms de variables et de fonctions, je pense qu'il faut faire la même chose.

Thierry

[koala01]

Salut,

Il me semble clair qu'il faut "standardiser" les manières de travailler, surtout au niveau de la traduction (ou, au contraire de la non traduction)des codes sources fournis...

Le problème qui apparait est que les termes anglais me semblent bien souvent plus précis que leurs homologues français, sans oublier les problèmes qui peuvent apparaître en cas de tentative d'utilisation de caractères accentués et autres broutilles dans le genre...

De plus, beaucoup de codeurs ont, malgré tout, l'habitude de nommer les variables et les fonctions en anglais, et ce, meme s'ils sont plutot francophones...

Enfin, il ne faut pas oublier que les codes sources sont malgré tout disponibles sur le site de Eckel, et qu'on y trouve également des corrigés... qui seront fatalement en Anglais

Je ne présente ici que mon avis personnel, qui, comme chaque fois peut donc etre sujet à polémique, mais, selon moi:

• Il serait préférable de traduire avec soin les commentaires, mais de ne pas traduire les noms de variables et de fonction
• Il est envisageable, si un nom de variable ou de fonction semble réellement trop incompréhensible, de rajouter un commentaire en tant que NDT (Note Du Traducteur) qui serait de nature à orienter correctement l'usage de celle-ci, pour autant que la NDT reste suffisemment compacte par rapport au code qu'elle précise

Un exemple tout simple, tiré du chapitre 1.2:

Le code original est

Code :

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

1
2
Light lt;
lt.on();

et la traduction donne

Code :

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

1
2
Ampoule amp;
amp.allumer();

Cela pourrait etre fait sans traduire les noms de types, de variables et de méthodes sous une forme ressemblant à

Code :

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

1
2
3
4
 
//[NDT]lt type est une ampoule et dispose donc d'une fonction allumer
Light lt;
lt.on();

Evidemment, l'exemple de code que j'ai choisi n'est pas des plus significatifs (désolé, c'est le premier code sur lequel je sois tombé), mais c'est pour présenter l'esprit de ma proposition