Instructions concernant la relecture :

[Siltaar]

Construisons ensemble un recueil de bonnes pratiques pour la relecture
du bouquin :
- pour commencer, il faut vérifier que le code compile
- que les noms de variables et fonctions sont : en vf des chap 2 à 3,
et en vo ensuite
- les symboles de mise en page (tirets, astérismes…) sont reproduit
(en couleur) pour avoir une vf complète
- les liens hypertextes vers d'autre chapitre doivent être de la forme
" ... nous avons vu au \\cregexp que ... " et non " ... nous avons vu
au chapitre \\cregexp que ... ".
- les commentaires sont traduits dans le code
- les tirets quadratins (longs) sont remplacés par des « -- » dans le
texte traduit
- les " et ' sont remplacés par des « et » partout, sauf dans le code
- les NdT sont remplacées par des périphrases partout où c'est
possible (c'est plus agréable à lire)
- que les mots de glossaire : _mot_ et @_mot_ ne sont pas au pluriel,
l'auteur à bien _mot_s partout…

Ensuite je propose la traduction suivante :
- bit bucket = récupérateur de bits

Comme un récupérateur de verre, ou de papier. La lecture du chapitre 3
me donne l'impression que c'est plus proche de l'idée originale, et
c'est d'ailleurs dans ce chapitre que l'expression apparaît.

--
Simon Descarpentries
   +33 6 76 97 02 53
http://sd12s.fdn.fr

[Siltaar]

Il a également été proposé de supprimer un maximum de virgules, et en
particulier celles devant les « et » en milieu de phrase.

Je ne sais pas ce que vous en pensez, mais je suis assez favorable à
cette idée (ça doit être pour ça que je m'en souvient d'ailleurs…
c'est bien fait là haut quand même…).

[mailinfo...@free.fr]

Salut,

concernant la traduction des noms de variable et de fonction, j'ai relu les paragraphes 2 et 3, et personnellement, je trouve ça assez moche,
De plus, j'ai commencé à relire les chapitres 4 et 5 et il y a certaines références à des fonctions écrites dans les chapitres précédents, ce qui nécessite de penser à traduire les fonctions en question.

De plus, ça manque un peu de cohérence entre les chapitres 2 et 3 et le reste du bouquin. Je pense qu'il vaudrait mieux revenir à des noms de fonctions/variabes en anglais dans tous les chapitres.
Ca demande un peu de boulot, mais je pense personnellement que ce serait mieux.

Pour bit bucket, 'récupérateur de bits' me paraît pas mal. Bac de récupération à/de/pour bits est peut-être plus proche du sens voulu, mais c'est plus lourd.

Vincent / Penguin

----- Mail original -----
De: "Siltaar" <sil...@framasoft.net>
À: eloquent-...@googlegroups.com
Envoyé: Mardi 27 Septembre 2011 20:42:57
Objet: [eloquentjavascript] Instructions concernant la relecture :

[Siltaar]

Le 28 septembre 2011 00:13, <mailinfo...@free.fr> a écrit :
> Salut,
>
> concernant la traduction des noms de variable et de fonction, j'ai relu les paragraphes 2 et 3, et personnellement, je trouve ça assez moche,
> De plus, j'ai commencé à relire les chapitres 4 et 5 et il y a certaines références à des fonctions écrites dans les chapitres précédents, ce qui nécessite de penser à traduire les fonctions en question.
>
> De plus, ça manque un peu de cohérence entre les chapitres 2 et 3 et le reste du bouquin. Je pense qu'il vaudrait mieux revenir à des noms de fonctions/variabes en anglais dans tous les chapitres.
> Ca demande un peu de boulot, mais je pense personnellement que ce serait mieux.
>

L'idée de traduire au début, dans les chapitre 2 et 3, et puis *pas*
dans le reste du texte me semble toujours la meilleure option car cela
permet de bien faire la différence entre les mots réservés du langage
et les choses choisies « arbitrairement » au début.
Ensuite, il me semble intéressant de laisser le reste en anglais car
cela introduit la bonne pratique consistant à coder tous dans la même
langue, et cela permet de s'entraîner à lire du code en anglais, ce
qui est objectivement la pratique la plus répandue.
Pour le problème cohérence, il suffit de mettre une note quelque part
au début du livre dans les conventions d'écriture pour expliquer la
démarche.
Mais personnellement, excepté qu'il reste des petits bouts de trucs
traduits là où il ne faudrait pas, je ne vois pas de raison suffisante
de « tout changer à la dernière minute ».

[Maxime BOURREAU]

Bonjour,

je ne vois pas de raison suffisante
de « tout changer à la dernière minute ».

Je partage cet avis, ça me parait dangereux de vouloir tout refaire maintenant.

Je soutiens également l'idée qu'au moindre doute, compte tenu que tout a déjà été relu au moins une fois, il vaut mieux poser une question sur cette mailing-list (ou sur le chat)

Enfin, si les codes javascript sont en anglais (sauf chapitre 2 et 3, sauf les commentaires), je suggère de veillez à ce que les noms de variables et fonctions restent en anglais, mais que les explications de ces codes se fassent en français, sans anglicisme (cette idée est respectée la plupart du temps).

Par exemple :

function bind(func, object) {
  return function(){
    return func.apply(object, arguments);
  };
}
var testArray = [];
var pushTest = bind(testArray.push, testArray);
pushTest("A");
pushTest("B");
show(testArray);

This way, you can bind an inner function to this, and it will have the same this as the outer function.

Ce qui pourrait se traduire en :

i) De cette façon, vous pouvez _bind_ la variable _this_ de la fonction appelée avec ...
ou
ii) De cette façon, vous pouvez _lier_ la variable _ceci_ de la fonction appelée avec ...
ou
iii) De cette façon, vous pouvez _lier_ la variable _this_ de la fonction appelée avec ...

Je propose la traduction iii, car :
 - _this_ est une variable prédéfinie, c'est une citation
 - il faut expliquer en français, à un moment ou à un autre, ce que fait la fonction _bind_, à savoir _lier_.

Dans des cas plus complexes, j'ai utilisé, comme d'autres, des périphrases ou des NdT, pour expliciter le sens des noms de fonctions ou de variables, et assurer une bonne correspondance entre le code en anglais et son explication en français.

Maxime

[Adrien P.]

> L'idée de traduire au début, dans les chapitre 2 et 3, et puis *pas*
> dans le reste du texte me semble toujours la meilleure option car cela
> permet de bien faire la différence entre les mots réservés du langage
> et les choses choisies « arbitrairement » au début.

Je ne suis pas du tout d'accord.
Ce n'est pas comme ça qu'est séparé le texte.
Il n'y a pas d'abord deux chapitres avec des exemples concrets et
ensuite des exemples techniques ; c'est le contraire, une alternance
des deux.
Je pense qu'il faut traduire les exemples concrets et laisser les
exemples techniques.
Par exemple, traduire les exemples concernant les monstres du
terrarium, les chats, etc. et laisser en anglais les exemple sur les
algorithmes, les graphes et le dom.
On peut aussi traduire (lorsque c'est possible) les exemples courts e
les noms de variables qui ne sont utilisés qu'une fois et font en
général référence à un groupe de musique, une chanson ou un film.
En gros, je pense que l'on ne devrait pas traduire uniquement s'il y a
un risque de confusion ou si c'est compliqué à faire sans casser le
code.

> Ensuite, il me semble intéressant de laisser le reste en anglais car
> cela introduit la bonne pratique consistant à coder tous dans la même
> langue, et cela permet de s'entraîner à lire du code en anglais, ce
> qui est objectivement la pratique la plus répandue.

On est en train de traduire le livre en français.
J'ai bien entendu que l'on est obligé de parler anglais pour
programmer, que les gens qui veulent programmer n'ont qu'à parler
anglais, doivent parler anglais, etc.
Mais on traduit le livre pour des gens qui à priori ont plus de
facilités avec le français qu'avec l'anglais. Ils ont envie de lire le
livre en français.

D'autre part, je pense que séparer les variables et fonctions
fortement liées au langage de celles qui ne le sont pas en utilisant
deux langues différentes est un avantage et non un inconvénient.
Si je lis valeur ou compteur et non value et counter, je sais
imédiatement que je peux appeler ces variables autrement, alors que
j'y penserais à deux fois avant de renommer this ou
getElementsByTagName.

> Pour le problème cohérence, il suffit de mettre une note quelque part
> au début du livre dans les conventions d'écriture pour expliquer la
> démarche.

Je ne suis pas sûr que ça soit nécessaire. Je ne pense pas que cela
paraisse anormal au lecteur si, justement, la séparation des langues
va de paire avec la séparation entre les exemple techniques et les
exemples pratiques plus "fun".

J'espère que mon mail n'a pas trop l'air d'une agression caractérisée,
d'une déclaration de guerre ou quelque chose dans le genre, mais je me
suis un peu énervé sur divers choses.
Je n'ai pas envie de me battre, mais il me semble qu'il faut conserver
ce qui a été bien fait au départ, en réprimant parfois l'envie de
faire mieux (les deux NdT qui se sont multipliées en sont un
malheureux un exemple) ou de laisser la version originale parce que
"tout les développeurs parlent l'anglais".

À propos de mes problèmes récents, il ne faut pas (vraiment pas)
traduire le mot qui se trouve sur une ligne après trois étoiles, et
celui après le slash dans les titres des chapitres. Il ne s'affiche
nul part et sert à générer les adresses des pages et les ancres des
exercices. Si on y touche le programme qui convertie le texte en html
sort une erreur très peu parlante qui veut dire en gros "exception
imprévue à la ligne X de Main.hs".
Il y a autre chose, mais je vais faire un mail séparé pour ça.

++
Pandark

[Siltaar]

Le 28 septembre 2011 15:11, Adrien P. <m.pa...@gmail.com> a écrit :
> Je ne pense pas que cela
> paraisse anormal au lecteur si, justement, la séparation des langues
> va de paire avec la séparation entre les exemple techniques et les
> exemples pratiques plus "fun".

Voici un point de vue nouveau et intéressant sur la question. Merci
Adrien (qui devrait écrire plus qu'il ne parle :-p).

Je me rangerai volontiers à cet avis, quitte à intervenir pour mettre
le bouquin en conformité avec cette nouvelle règle si on établissait
une liste exhaustive des exemples à traduire (car j'ai dans l'idée que
les exemples à ne pas traduire seront plus nombreux mais c'est n'est
basé sur rien).
Ça peut être sous la forme : chapitre - n° exemple ou chapitre - thème exemple

Si on défini clairement où aller, je serai le premier à courir dans
cette direction.

D'ailleurs, j'ai pris l'initiative de remplacer les NdT pas
indispensable par des propositions supplémentaires dans les phrases là
où ça s'intégrait facilement (chap2-1).

[Maxime BOURREAU]

Par exemple, traduire les exemples concernant les monstres du
terrarium, les chats, etc. et laisser en anglais les exemple sur les
algorithmes, les graphes et le dom.

Dans cette optique, penses-tu laisser en anglais, par exemple, le code suivant (du chapitre 7) et si oui, pourquoi ?

function gamblerPath(from, to) {
  function randomInteger(below) {
    return Math.floor(Math.random() * below);
  }
  function randomDirection(from) {
    var options = roadsFrom(from);
    return options[randomInteger(options.length)].to;
  }

  var path = [];
  while (true) {
    path.push(from);
    if (from == to)
      break;
    from = randomDirection(from);
  }
  return path;
}

show(gamblerPath("Hanaiapa", "Mt Feani"));

Maxime

[Maxime BOURREAU]

En relisant attentivement le 8-1, je vois que "higher-order function" est traduit en "fonction de haut niveau", j'ai mis de mon coté "fonction d'ordre supérieur" dans le 6-2.

Pour information, sur wikipedia c'est bien : http://fr.wikipedia.org/wiki/Fonction_d%27ordre_sup%C3%A9rieur

Quels sont vos avis sur la question ?

Maxime