Les blocs de citations n'apparaissent pas dans les .po

[jbarnoud]

Les blocs de citations, blocs indentés précédés d'un « :: », ne sont pas présent dans les fichier .po (ou du moins dans tutorial.po) se qui empêche la traduction des exemples de code.

[JulienPalard]

Ça tombe bien, je pense que c'est une mauvaise idée de traduire les exemples de code. On propose la documentation en Français, c'est une chose (cool), mais encourager (en leur montrant) les gens à écrire du code (noms de variables, fonctions, etc...) en français en est une autre (mauvaise).

Je pense qu'il faut donc laisser les exemples de code en anglais, et ça tombe bien, on ne peut pas les traduire. Ce serait même logique que ce soit volontaire (de la part de ceux qui ont implémenté le xgettext de la doc, de pas mettre les exemples dans les pot).

[jbarnoud]

Je suis partagé sur la traduction des noms de variables : si on traduit la doc c'est que l'on part du postulat que le lecteur ne comprends pas l'anglais, par conséquent des noms de variables en anglais ne sont pas explicites et nuisent à la compréhension des exemples.
Là où je ne suis pas partagé du tout, c'est la traduction des commentaires dans les exemples.
Le 3 déc. 2015 23:49, Julien notifications@github.com a écrit :Ça tombe bien, je pense que c'est une mauvaise idée de traduire les exemples de code. On propose la documentation en Français, c'est une chose (cool), mais encourager (en leur montrant) les gens à écrire du code (noms de variables, fonctions, etc...) en français en est une autre (mauvaise).

Je pense qu'il faut donc laisser les exemples de code en anglais, et ça tombe bien, on ne peut pas les traduire. Ce serait même logique que ce soit volontaire (de la part de ceux qui ont implémenté le xgettext de la doc, de pas mettre les exemples dans les pot).

—Reply to this email directly or view it on GitHub.

[JulienPalard]

Je suis partagé sur la traduction des noms de variables

Il me semble qu'il soit de commune coutume de ne pas nommer les identifiants en français, la PEP8 n'est effectivement pas très stricte sur le sujet effectivement.

Je suis personnellement contre écrire les identifiants en anglais avec cet argument: Les identifiants des modules (standards ou non) sont en anglais, écrire en français reviendrait à mélanger de l'anglais et du français, que je trouve fort peu élégant:

chaines = []
for chaine in get_strings():
    chaines.append(some_module.encode(chaine))

Ce qui donne, en comptant les mots clefs du langages "fr, en, fr, en, en, fr, en, en, en, fr", sale mélange qui me choque horriblement, j'ai l'impression de regarder Foon. (Mon goût pour ce fil pourrait me faire changer d'avis en faveur des identifiants en Français... haha).

si on traduit la doc c'est que l'on part du postulat que le lecteur ne comprends pas l'anglais, par conséquent des noms de variables en anglais ne sont pas explicites et nuisent à la compréhension des exemples.

Je ne peut être que d'accord, bien que je pense que la doc s'adresse aussi à ceux qui comprennent l'anglais, mais trop peu pour lire la doc en anglais sans perdre toute leur énergie en efforts de compréhension.

Si les variables en anglais nuisent à la compréhension, les noms de méthodes en anglais, de la stdlib, nuisent aussi, et ceux-là, on ne risque pas de les traduire. Y'a donc une frontière qu'on ne peut pas dépasser: les identifiants dans les modules. Et il y a donc un curseur qu'on doit placer. Tu es pour le placer au même endroit que la frontière, je suis pour le placer un peu avant:

• Identifiants en français, commentaires en français, stdlib en français -> Hors frontière, on y ira pas
  --- Frontière ---
• identifiants en français, commentaires en français <- Tu semble mettre le curseur ici
• identifiants en anglais, commentaires en francais
• identifiants en francais, commentaires en anglais (Useless)
• Identifiants en anglais, commentaires en anglais <- Je le mettrai là

Je le met là, aussi, parce que la PEP8 dit :

Python coders from non-English speaking countries: please write your comments in English

Mais j'entend ton point de vue, je pense qu'on peut garder ce ticket ouvert pour faire un vote, en attendant, puisqu'on ne peut pas les traduire, traduisons ce qu'on peut traduire ?

[jbarnoud]

En fait, je placerais la limite à identifiant en français et commentaires en anglais. Mais je ne suis pas contre traduire les identifiants pour autant.

Certes, le code et les commentaires devraient être écrits en anglais dans du vrai code, mais la doc n'est pas du vrai code: c'est un outil pédagogique pour que le lecteur comprenne. Je préfère du code qui fonctionne mais qui n'est pas en anglais que du code en anglais qui fait n'importe quoi.

[JulienPalard]

Je vais méditer à ça. Si qq'un d'autre tombe sur ce ticket, on est preneur de vos avis, on laisse ouvert.

[njouanin]

Je partage l'avis précédent. Les exemples de code font partie de la doc. et aident à la compréhension du sujet. Même si le code est en anglais, je pense que les commentaires devraient au moins être traduit.

[JulienPalard]

Montrer des commentaires en français va enseigner aux gens à commenter en français, ce qu'on déteste tous (je veux dire, tomber sur du code avec des commentaires en russe, dannois, tchèque...). Je reste donc réticent à traduire les commentaires.

[JulienPalard]

Je ferme ce ticket car je pense qu'il à plus sa place sur https://github.com/sphinx-doc/sphinx, ce n'est pas nous qui allons changer ça dans tous les cas.