La façon d'indiquer la valeur d'un booléen est inconsistante: on trouve « if foo is false », « if foo is False » ou encore « if foo is :const:False ». Qu'elle est la règle lors de la traduction ? (J'ai gardé la façon de faire de la doc originale, même si elle utilise les trois formes)

Pas grave. La documentation n'a pas besoin du même genre de cohérence que le code. Nous essayons de conserver une cohérence au niveau des termes techniques, afin qu'ils restent compréhensibles. Pour le reste, cela dépend du contexte et du style de l'auteur ou du traducteur.

Il y a beaucoup de formules « use the :class:Foo class » ou « call the :meth:handle method ». J'ai traduit en gardant tout : « appelle la méthode :meth:handle ». Est-ce qu'il serait préférable de raccourcir en disant « appelle :meth:handle » ?

Les deux conviennent. Personnellement, j'aime bien mettre la nature de l'objet (comme « méthode ») au moins une fois, et ne pas la répéter ensuite pour alléger.

J'ai un problème à traduire daemon, daemonic et non-daemonic ; j'ai francisé en italique (daemon, daemonique, non-daemonique) (library/socketserver.rst:122). Est-ce qu'il y a une convention sur daemon?

D'après Wikipédia, on utilise le terme anglais daemon.

Quel est le meilleur canal pour poser des questions ? (en dehors d'une PR :-) )

Sur une PR, c'est très bien. Il y a aussi un onglet « Discussions » à côté de « Issues » et « Pull requests ».

Pour la « traduction » de daemon, ça pourrait être une idée de l'ajouter dans https://github.com/python/python-docs-fr/blob/3.10/CONTRIBUTING.rst#glossaire pour que tout le monde respecte cette convention, non ?

La façon d'indiquer la valeur d'un booléen est inconsistante: on trouve « if foo is false », « if foo is False » ou encore « if foo is :const:False ». Qu'elle est la règle lors de la traduction ? (J'ai gardé la façon de faire de la doc originale, même si elle utilise les trois formes)

Pas grave. La documentation n'a pas besoin du même genre de cohérence que le code. Nous essayons de conserver une cohérence au niveau des termes techniques, afin qu'ils restent compréhensibles. Pour le reste, cela dépend du contexte et du style de l'auteur ou du traducteur.

Je pense que je continuerai d'utiliser la façon de faire de l'auteur original dans ce cas.

Il y a beaucoup de formules « use the :class:Foo class » ou « call the :meth:handle method ». J'ai traduit en gardant tout : « appelle la méthode :meth:handle ». Est-ce qu'il serait préférable de raccourcir en disant « appelle :meth:handle » ?

Les deux conviennent. Personnellement, j'aime bien mettre la nature de l'objet (comme « méthode ») au moins une fois, et ne pas la répéter ensuite pour alléger.

C'est une bonne idée, je vais l'adopter :-)

J'ai un problème à traduire daemon, daemonic et non-daemonic ; j'ai francisé en italique (daemon, daemonique, non-daemonique) (library/socketserver.rst:122). Est-ce qu'il y a une convention sur daemon?

D'après Wikipédia, on utilise le terme anglais daemon.

Je vais laisser comme ça.

Quel est le meilleur canal pour poser des questions ? (en dehors d'une PR :-) )

Sur une PR, c'est très bien. Il y a aussi un onglet « Discussions » à côté de « Issues » et « Pull requests ».

Parfait. Merci beaucoup!

Pour la « traduction » de daemon, ça pourrait être une idée de l'ajouter dans https://github.com/python/python-docs-fr/blob/3.10/CONTRIBUTING.rst#glossaire pour que tout le monde respecte cette convention, non ?

Oui, je peux en profiter pour ajouter ça si pas d'opposition. Est-ce qu'il faudrait l'ajouter dans https://github.com/python/python-docs-fr/blob/3.10/dict aussi?

L'ajout au dict est nécessaire seulement si pospell ne connaît pas le terme. Ce sera sûrement le cas ici.

@Gaasmann Concernant mes commentaires, j'ai l'impression que tu as appliqué tous ceux qui étaient visibles, mais que tu as oublié ceux qui sont à l'intérieur du « x hidden conversations ».

@Gaasmann Concernant mes commentaires, j'ai l'impression que tu as appliqué tous ceux qui étaient visibles, mais que tu as oublié ceux qui sont à l'intérieur du « x hidden conversations ».

Oops, effectivement. J'ai encore des progrès à faire en grammaire :-)

Ok, je pense que j'ai répondu à tous les commentaires cette fois. :-)
J'ai aussi passé un coup de powrap et ajouté daemon au glossaire du CONTRIBUTING.rst

Ok, je pense que j'ai répondu à tous les commentaires cette fois. :-)

Non, il y en a encore, vers
#1872 (comment)

@Gaasmann Une astuce à connaître : dans l'interface GitHub, tu peux appliquer plusieurs suggestions en une fois, en « batch ». Je ne sais plus comment cela fonctionne exactement (j'ai davantage l'habitude de GitLab), mais tu devrais trouver facilement. L'avantage est que la PR ne se retrouve pas encombrée de dizaines de commits, et une seule notification se retrouve dans les boîtes mails des relecteurs et de ceux qui suivent le dépôt.

@Gaasmann Une astuce à connaître : dans l'interface GitHub, tu peux appliquer plusieurs suggestions en une fois, en « batch ». Je ne sais plus comment cela fonctionne exactement (j'ai davantage l'habitude de GitLab), mais tu devrais trouver facilement. L'avantage est que la PR ne se retrouve pas encombrée de dizaines de commits, et une seule notification se retrouve dans les boîtes mails des relecteurs et de ceux qui suivent le dépôt.

@jean-abou-samra Ah! Ok, je viens de voir que je pouvais voir les suggestions dans l'onglet Files changed. Ca va être infiniment plus pratique. Désolé pour le bruit.

Bon, cette fois je pense que j'ai adressé tous les commentaires :-)

C'est bien parti ! Ça manque d'un label automerge ?

C'est tout bon pour moi aussi, merci pour ce travail conséquent.