Discussion :

[Aurelien.Regat-Barrel]

Sujet dédié à la traduction et la relecture du chapitre 0.0

[r0d]

Mon premier post ici. Je joins le fichier xml. J'espère que je n'ai pas fais d'erreur au niveau de la mise en page (je n'ai pas l'habitude de manipuler du xml).

[Aurelien.Regat-Barrel]

A l"origine il y avait:

le langage résoud

tu as remplacé par

le langage résous

et j'ai changé

le langage résout

J'ai aussi supprimé la balise fermante </section> que tu avais rajouté. En effet, ce n'est pas du véritable xml, et pour des raisons que je n'ai pas encore expliqué (), il ne faut pas toucher à la structure des balises et les laisser tel quelles.
De même j'ai remis <section id="0"> au lieu de <section id="0.0">.

Merci pour ta participation, ce chapitre est clos

[HanLee]

Hey, mais ne clôt pas tout de suite le chapitre ! Il reste encore quelques erreurs :

S'il est réussit, ce support d'expression...

-> S'il est réussi, ...

n'ayant pas de sens prise à part

-> n'ayant pas de sens priseS à part...

me faire commencer "penser en C++."

Je rajouterais un 'à' entre commencer et "penser en C++.", parce que selon moi c'est un jeu de mot, il finit sa phrase en utilisant son titre pour formuler sa phrase.

----

D'une manière générale, je trouve que ça fait pas très naturel à lire, la manière dont c'est traduit, mais en même temps quand on voit le style de l'auteur en anglais, c'est assez difficile à transcrire en français. Il faudrait éviter les calques, on pourrait rendre plus concis certaines tournures.

Ex : la façon que j'ai de voir -> ma façon de voir

Mais ça après c'est libre à vous.

[Aurelien.Regat-Barrel]

J'ai pris en compte tes remarques. Je suis d'accord avec toi, le style est parfois moyen. Cela dit, c'est le style de l'auteur, et on se doit de le respecter. Modifier la tournure des phrases nécessite du temps, et je préfère pour le moment que ce temps soit consacré à la relecture des autres traductions. Une fois que tout sera traduit "mot à mot", on pourra envisager de rendre le texte plus élégant.
Mais je pense que pour commencer il vaut mieux avoir 100% du bouquin traduit de manière "abrupte" que 50% traduit avec élégance

[maxim_um]

Je n'ai lu que le premier paragraphe (dans un premier temps...). Bien que la traduction soit très fidèle, par sa lourdeur, elle risque de rebuter le lecteur.
S'agissant de la préface, et donc des premières lignes que le lecteur est susceptible de lire, je me suis permis de vous proposer en alternative cette suggestion :

Version originale
Comme n'importe quelle langue humaine, le C++ permet d'exprimer des concepts. S'il est réussi, ce support d'expression sera plus simple et plus flexible que les solutions alternatives au fur et à mesure que les problèmes s'amplifient et deviennent plus complexes.

Version alternative
Comme n'importe quel langage humain, le C++ permet d'exprimer des concepts. S'il est réussi, ce support d'expression sera plus simple et plus flexible que les solutions alternatives, qui au fur et à mesure que les problèmes s'amplifient, deviennent plus complexes.

Voilà Aurelien, sache cependant que j'ai bien pris note de ton précédent poste du 17/11/2006 13h34, et que désormais je prendrais en considération tes priorités.

[Aurelien.Regat-Barrel]

J'ai mis a jour

[grob1212]

Je ne suis pas tout à fait d'accord avec l'approche de la traduction littérale à 100% dans un premier temps, puis de l'affiner par la suite. Certes le style de l'auteur est respecté, mais est-ce réellement le but ?

En traduisant de manière littérale (ce que j'appelle parfois traduction google), certaines phrases perdent leur sens, voire pire, elle peuvent signifier tout à fait l'inverse. En plus de çà, la lecture d'une telle traduction est pénible pour le lecteur. Enfin, dans la deuxième étape qui consisterai à embélir la traduction, il faut recommancer le travail depuis la version anglaise, étant donné que la première traduction est plus qu'approximative.

Pour conclure, et à titre d'exemple, vous ètes pas sans savoir qu'en développement, il vaut mieux avoir les bonnes pratiques tout de suite. D'expérience, un code non-commenté, mal conçu ou truffé de TODO, le restera jusqu'à sa fin de vie...

Je conviens qu'il est beaucoup plus long de traduire correctement le texte, mais je trouve que le jeu en vaut réellement la chandelle.

Tout ceci biensur n'engage que moi...

Je vous donne donc ma traduction des trois premiers paragraphes de ce livre (même si je trouve le style de l'auteur horrible).

A l’instar de n’importe quel langage naturel, le C++ permets d’exprimer des concepts. Lorsqu’il est correctement utilisé, il apporte plus de simplicité et de flexibilité que les solutions alternatives, à mesure que les problèmes posés deviennent lourds et complexes.

On ne peut simplement considérer le C++ comme un ensemble de fonctionnalités distinctes et indépendantes. C’est uniquement en raisonnant en terme de conception qu’il devient possible de pleinement l’utiliser. Pour y arriver, il est indispensable de bien comprendre le C, et la programmation en général. Cet ouvrage traite des problèmes de programmation, en décrivant pourquoi ils sont des problèmes, et quelles sont les approches choisies par le C++ pour les résoudre. Ainsi, l’ensemble des sujets détaillées dans ce livre est agencé pour étudier un type particulier de problème et la solution apportée par le langage. De cette manière, j’espère vous conduire progressivement depuis le langage C jusqu’au point où le C++ soit comme votre langue maternelle.

Tout au long de ce livre, je vais considérer que vous désirez bâtir un modèle mental du langage tel qu’il vous permettra de le comprendre dans les moindres détails. Dès lors qu’un casse-tête se présentera à vous, vous en obtiendrez la solution en le confrontant à votre modèle mental. J’essayerai de vous transmettre les idées qui m’ont conduit à « penser en C++ ».

Vous êtes bien entendu libre de jeter ma traduction à la poubelle si vous la trouvez horrible

[Zavonen]

Je vous donne donc ma traduction des trois premiers paragraphes de ce livre (même si je trouve le style de l'auteur horrible).

D'accord avec vous sur ce point, sauf le respect que l'on doit à Bruce Eckel, pour la qualité scientifique de son travail, en qualité d'auteur, il ne serait pas capable d'écrire un roman de gare, il est même dommage qu'il n'ai pas demandé à un pro de 'revoir sa copie', par moment les phrases sont limites, même du point de vue de la syntaxe de l'anglo-américain usuel. On pourrait s'amuser à un comptage des 'however' 'basically' et 'typically' mis à toutes les sauces. Les phrases sont souvent si longues, alambiquées, qu'on en perd parfois le fil. Je crois que tout cela a été expérimenté plus ou moins par tous ceux qui se sont essayé à l'exercice de traduction. Cela dit, je voudrais livrer à votre réflexion trois arguments:
- Cette traduction n'est pas celle d'une oeuvre littéraire, mais de ce que je considère plus ou moins comme une 'notice technique'. On peut donc faire l'impasse sur le style.
- J'imagine qu'elle se fait avec l'accord de l'auteur et qu'il faudra en définitive qu'elle reçoive son assentiment pour pouvoir être officialisée.
-J'ai rejoint l'équipe tardivement et j'ai pu constater que certains de ses membres avaient un point de vue strictement opposé au vôtre (ils voudraient presque du google).
Il faudra un compromis. En gros coller au texte tant que le résultat est compréhensible, même s'il n'est pas heureux.
Par ailleurs, vous verrez en avançant dans les chapitres, qu'on s'achemine de plus en plus vers du commentaire de code, et que tout cela perd de l'importance.
Pour finir je comprends votre point de vue.

[Aurelien.Regat-Barrel]

Je ne suis pas tout à fait d'accord avec l'approche de la traduction littérale à 100% dans un premier temps, puis de l'affiner par la suite. Certes le style de l'auteur est respecté, mais est-ce réellement le but ?

En traduisant de manière littérale (ce que j'appelle parfois traduction google), certaines phrases perdent leur sens, voire pire, elle peuvent signifier tout à fait l'inverse. En plus de çà, la lecture d'une telle traduction est pénible pour le lecteur. Enfin, dans la deuxième étape qui consisterai à embélir la traduction, il faut recommancer le travail depuis la version anglaise, étant donné que la première traduction est plus qu'approximative.

Pour conclure, et à titre d'exemple, vous ètes pas sans savoir qu'en développement, il vaut mieux avoir les bonnes pratiques tout de suite. D'expérience, un code non-commenté, mal conçu ou truffé de TODO, le restera jusqu'à sa fin de vie...

Je conviens qu'il est beaucoup plus long de traduire correctement le texte, mais je trouve que le jeu en vaut réellement la chandelle.

Il y a deux extrêmes : la traduction google, et la réécriture du livre. Comme vous l'expliquez, une traduction trop littérale est pénible à lire. A l'inverse, il ne faut pas trop s'éloigner du sens original de l'auteur, car lorsque l'on reformule, il devient tentant de rajouter des choses de son cru, et de s'éloigner du sens original. Si l'on faisait cela à une de vos oeuvres, vous le prendriez surement mal.

De ce que j'ai vu, on est globalement dans un juste milieu, et je ne crois pas qu'il y ait tant de traduction google que cela. Certaines traductions seront à revoir bien sûr, et cela se fera petit à petit avec des personnes venant intervenir comme vous le faites. C'est en ce sens que je pense qu'une mauvaise traduction vaut mieux que pas du tout, et mon sentiment est que vous me donnez raison

C'est un peu un projet open source, et l'expérience dans ce domaine montre qu'un mauvais code est toujours meilleur qu'un code inexistant, car au moins le projet existe et il peut évoluer. Bien sûr un bon code dès le départ est préférable Mais chacun est libre de contribuer, dans la limite de ses compétences, et il est délicat de décider qui a la compétence pour participer et qui ne l'a pas.

Je vous donne donc ma traduction des trois premiers paragraphes de ce livre (même si je trouve le style de l'auteur horrible).

[...]

Vous êtes bien entendu libre de jeter ma traduction à la poubelle si vous la trouvez horrible

Je ne peux malheureusement pas récupérer votre travail, car vous le n'avez pas posté sous forme de xml:
http://bruce-eckel.developpez.com/li...ol1/?vue=Guide
http://bruce-eckel.developpez.com/li...e&chapitre=0.0

Merci de votre participation.

[grob1212]

Merci pour tous ces commentaires (après relecture, je trouve mon style assez aggressif et un peu "trollien", mais je ne pouvais m'empêcher de donner mon avis).
J'ai découvert le projet la semaine dernière et je trouve que c'est une bonne initiative.
Je suis assez d'accord avec vos opinions, il faut en effet un juste milieu pour ne pas trop dénaturer les écrits de l'auteur.
Cependant, il faut tout de même veiller à ce que le contenu soit compréhensible.

Par exemple, dans le paragraphe suivant, le "S'il est réussi" ne véhicule pas l'idée de l'auteur (il faudrait d'ailleurs l'interpeler pour savoir ce qu'il voulait dire).

Comme n'importe quelle langue humaine, le C++ permet d'exprimer des concepts. S'il est réussi, ce support d'expression sera plus simple et plus flexible que les solutions alternatives au fur et à mesure que les problèmes s'amplifient et deviennent plus complexes.

Bon j'arrête d'embêter le monde et je vais voir pour traduire mes 3 paragraphes au format xml.