howto/socket.po: 3ème partie et fin (+ corrections) (#1265)

* howto/socket.po: 3ème partie et fin (+ corrections)

* 'boguer' dans dict

* retrait modification makefile accidentelle

* Apply suggestions from code review

Co-authored-by: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>

* wrapping

* "s'interrompt brutalement" + "couts significatifs"

* Apply suggestions from code review

Co-authored-by: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>

* wrapping

* retrait fichier ajouté par erreur

* Apply suggestions from code review

Co-authored-by: Antoine <43954001+awecx@users.noreply.github.com>

* autres remarques d'awecx

* wrapping

* Update howto/sockets.po

Co-authored-by: Antoine <43954001+awecx@users.noreply.github.com>

* Update howto/sockets.po

Co-authored-by: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>
Co-authored-by: Antoine <43954001+awecx@users.noreply.github.com>

dict

@@ -12,6 +12,7 @@ base32
 base64
 base85
 batch
+boguer
 c++
 c-
 c/c++

howto/sockets.po

@@ -6,7 +6,7 @@ msgstr ""
 "Project-Id-Version: Python 3\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2018-06-10 11:27+0200\n"
-"PO-Revision-Date: 2020-05-04 22:08+0200\n"
+"PO-Revision-Date: 2020-05-08 15:38+0200\n"
 "Language-Team: FRENCH <traductions@lists.afpy.org>\n"
 "Language: fr\n"
 "MIME-Version: 1.0\n"
@@ -144,9 +144,9 @@ msgid ""
 msgstr ""
 "Lorsque l’appel à ``connect`` est terminé, le connecteur ``s`` peut être "
 "utilisé pour envoyer une requête demandant le texte de la page. Le même "
-"connecteur lira la réponse, puis sera détruit. C'est exact, détruit. Les "
-"connecteurs clients ne sont normalement utilisés que pour un seul échange "
-"(ou un petit ensemble d'échanges séquentiels)."
+"connecteur lira la réponse, puis sera mis au rebut. C'est exact, mis au "
+"rebut. Les connecteurs clients ne sont normalement utilisés que pour un seul "
+"échange (ou un petit ensemble d'échanges séquentiels)."
 
 #: ../Doc/howto/sockets.rst:70
 msgid ""
@@ -201,7 +201,7 @@ msgid ""
 "mainloop of the web server::"
 msgstr ""
 "Maintenant que nous avons un connecteur « serveur », en écoute sur le port "
-"80, nous pouvons entrer dans la boucle principale du serveur web: :"
+"80, nous pouvons entrer dans la boucle principale du serveur web ::"
 
 #: ../Doc/howto/sockets.rst:106
 msgid ""
@@ -219,7 +219,7 @@ msgid ""
 "allocated port which will be recycled when the conversation ends."
 msgstr ""
 "Il y a en fait trois façons générales de faire fonctionner cette boucle : "
-"envoyer un fil d'exécution pour gérer les ``clientsocket``\\s, créer un "
+"mobiliser un fil d'exécution pour gérer les ``clientsocket``\\s, créer un "
 "nouveau processus pour gérer les ``clientsocket``\\s, ou restructurer cette "
 "application pour utiliser des connecteurs non bloquants, et multiplexer "
 "entre notre connecteur « serveur » et n'importe quel ``clientsocket`` actif "
@@ -316,7 +316,7 @@ msgid ""
 "again until your message has been completely dealt with."
 msgstr ""
 "Nous arrivons maintenant au principal écueil des connecteurs — ``send`` et "
-"``recv`` fonctionnent sur les mémoires tampons du réseau. ils ne traitent "
+"``recv`` fonctionnent sur les mémoires tampons du réseau. Ils ne traitent "
 "pas nécessairement tous les octets que vous leur passez (ou que vous "
 "attendez d'eux), car leur principal objectif est de gérer les tampons "
 "réseau. En général, leur exécution se termine lorsque les tampons réseau "
@@ -363,7 +363,7 @@ msgstr ""
 "Mais si vous prévoyez de réutiliser votre connecteur pour d'autres "
 "transferts, vous devez réaliser qu'\\ *il n'y a pas* d':abbr:`EOT (End of "
 "Transfer)` *sur un connecteur*. Je répète : si un appel à ``send`` ou "
-"``recv`` se termine après avoir manipulé 0 octets, la connexion a été "
+"``recv`` se termine après avoir traité 0 octet, la connexion a été "
 "interrompue. Si la connexion n'a *pas* été interrompue, vous pouvez attendre "
 "sur un ``recv`` pour toujours, car le connecteur ne vous dira pas qu'il n'y "
 "a plus rien à lire (pour le moment). Maintenant, si vous y réfléchissez un "
@@ -442,6 +442,16 @@ msgid ""
 "not always manage to get rid of everything in one pass. And despite having "
 "read this, you will eventually get bit by it!"
 msgstr ""
+"Préfixer le message avec sa longueur (disons, sous la forme de 5 caractères "
+"numériques) devient plus complexe, parce que (croyez-le ou non), vous pouvez "
+"ne pas recevoir les 5 caractères en un seul ``recv``. Pour une utilisation "
+"triviale, vous vous en tirerez à bon compte ; mais en cas de forte charge "
+"réseau, votre code se cassera très rapidement, à moins que vous n’utilisiez "
+"deux boucles ``recv`` — la première pour déterminer la longueur, la deuxième "
+"pour obtenir la partie « données » du message. Vilain. C’est aussi à ce "
+"moment que vous découvrirez que « l’envoi » via ``send`` ne parvient pas "
+"toujours à tout évacuer en un seul passage. Et bien que vous ayez lu cet "
+"avertissement, vous finirez par vous faire avoir par cette subtilité !"
 
 #: ../Doc/howto/sockets.rst:246
 msgid ""
@@ -449,6 +459,10 @@ msgid ""
 "competitive position), these enhancements are left as an exercise for the "
 "reader. Lets move on to cleaning up."
 msgstr ""
+"Pour garder une longueur raisonnable à cette page, pour forger votre "
+"caractère (et afin de garder l’avantage concurrentiel que j’ai sur vous), "
+"ces améliorations ne seront pas abordées et sont laissées en exercice au "
+"lecteur. Passons maintenant au nettoyage."
 
 #: ../Doc/howto/sockets.rst:252
 msgid "Binary Data"
@@ -466,6 +480,18 @@ msgid ""
 "order is host order, these do nothing, but where the machine is byte-"
 "reversed, these swap the bytes around appropriately."
 msgstr ""
+"Il est parfaitement possible d’envoyer des données binaires sur un "
+"connecteur. Le gros problème est que toutes les machines n’utilisent pas les "
+"mêmes formats pour les données binaires. Par exemple, une puce Motorola code "
+"l'entier 1, sous 16 bits, comme les deux octets hexadécimaux 00 01. Intel et "
+"DEC, cependant, utilisent l’ordre d’octets inverse — ce même 1 est codé 01 "
+"00. Les bibliothèques de connecteurs ont des appels pour convertir des "
+"entiers de 16 et 32 bits — ``ntohl, htonl, ntohs, htons`` où ``n`` signifie "
+"*réseau* (*network*, en anglais) et ``h`` signifie *hôte*, ``s`` signifie "
+"*court* (*short*, en anglais) et ``l`` signifie *long*. Lorsque l’ordre du "
+"réseau est l’ordre de l’hôte, ceux-ci ne font rien, mais lorsque la machine "
+"utilise l’ordre d’octets inverse, ceux-ci échangent les octets de manière "
+"appropriée."
 
 #: ../Doc/howto/sockets.rst:264
 msgid ""
@@ -475,6 +501,13 @@ msgid ""
 "The string \"0\" would be two bytes, while binary is four. Of course, this "
 "doesn't fit well with fixed-length messages. Decisions, decisions."
 msgstr ""
+"De nos jours, avec les machines 32 bits, la représentation *ASCII* des "
+"données binaires est souvent plus compacte que la représentation binaire. "
+"C’est parce qu’un nombre surprenant de fois, tous ces *longs* ont la valeur "
+"0, ou peut-être 1. La chaîne « 0 » serait codée sur deux octets, alors "
+"qu'elle le serait sur quatre en binaire. Bien sûr, cela ne fonctionne pas "
+"très bien avec les messages de longueur fixe. Ah, les décisions, les "
+"décisions…"
 
 #: ../Doc/howto/sockets.rst:272
 msgid "Disconnecting"
@@ -491,6 +524,15 @@ msgid ""
 "same as ``shutdown(); close()``.  So in most situations, an explicit "
 "``shutdown`` is not needed."
 msgstr ""
+"À proprement parler, vous êtes censé utiliser ``shutdown`` sur un connecteur "
+"pour l’arrêter avant de le fermer via ``close``. Le ``shutdown`` est un "
+"avertissement au connecteur de l’autre côté. Selon l’argument que vous lui "
+"passez, cela peut signifier « Je ne vais plus envoyer, mais je vais quand "
+"même écouter », ou « Je n’écoute pas, bon débarras ! ». La plupart des "
+"bibliothèques de connecteurs, cependant, sont tellement habituées à ce que "
+"les programmeurs négligent d’utiliser ce morceau d’étiquette que normalement "
+"un ``close`` est équivalent à ``shutdown() ; close()``. Ainsi, dans la "
+"plupart des situations, un ``shutdown`` explicite n’est pas nécessaire."
 
 #: ../Doc/howto/sockets.rst:282
 msgid ""
@@ -501,6 +543,13 @@ msgid ""
 "complete request.  The server sends a reply. If the ``send`` completes "
 "successfully then, indeed, the client was still receiving."
 msgstr ""
+"Une façon d’utiliser efficacement le ``shutdown`` est d’utiliser un échange "
+"de type HTTP. Le client envoie une requête et effectue ensuite un "
+"``shutdown(1)``. Cela indique au serveur que « ce client a fini d’envoyer, "
+"mais peut encore recevoir ». Le serveur peut détecter *EOF* par une "
+"réception de 0 octet. Il peut supposer qu’il a la requête complète. Le "
+"serveur envoie une réponse. Si le ``send`` se termine avec succès, alors, en "
+"effet, le client était encore en train de recevoir."
 
 #: ../Doc/howto/sockets.rst:289
 msgid ""
@@ -511,10 +560,17 @@ msgid ""
 "indefinitely, thinking you're just being slow. *Please* ``close`` your "
 "sockets when you're done."
 msgstr ""
+"Python pousse l’arrêt automatique un peu plus loin, et dit que lorsqu’un "
+"connecteur est collecté par le ramasse-miette, il effectue automatiquement "
+"une fermeture via ``close`` si elle est nécessaire. Mais c’est une très "
+"mauvaise habitude de s’appuyer sur ce système. Si votre connecteur disparaît "
+"sans avoir fait un ``close``, le connecteur à l’autre bout peut rester "
+"suspendu indéfiniment, pensant que vous êtes juste lent. Fermez vos "
+"connecteurs quand vous avez terminé *s’il vous plait*."
 
 #: ../Doc/howto/sockets.rst:297
 msgid "When Sockets Die"
-msgstr ""
+msgstr "Quand les connecteurs meurent"
 
 #: ../Doc/howto/sockets.rst:299
 msgid ""
@@ -530,10 +586,23 @@ msgid ""
 "automatic recycling of resources. In other words, if you do manage to kill "
 "the thread, your whole process is likely to be screwed up."
 msgstr ""
+"Le pire dans l'utilisation de connecteurs bloquants est probablement ce qui "
+"se passe lorsque l'autre côté s'interrompt brutalement (sans faire de "
+"fermeture via ``close``). Votre connecteur risque d’attendre infiniment. TCP "
+"est un protocole fiable, et il attendra très, très longtemps avant "
+"d'abandonner une connexion. Si vous utilisez des fils d’exécution, le fil "
+"entier est pratiquement mort. Il n'y a pas grand-chose que vous puissiez "
+"faire à ce sujet. Du moment que vous ne faites rien de stupide, comme tenir "
+"un verrou verrouillé pendant une lecture bloquante, le fil ne consomme pas "
+"vraiment beaucoup de ressources. N'essayez *pas* de tuer le fil — si les "
+"fils sont plus efficients que les processus, c'est en partie parce qu'ils "
+"évitent les coûts significatifs liés au recyclage automatique des "
+"ressources. En d'autres termes, si vous parvenez à tuer le fil, tout votre "
+"processus risque d'être foutu."
 
 #: ../Doc/howto/sockets.rst:313
 msgid "Non-blocking Sockets"
-msgstr ""
+msgstr "Connecteurs non bloquants"
 
 #: ../Doc/howto/sockets.rst:315
 msgid ""
@@ -543,9 +612,9 @@ msgid ""
 "will be almost inside-out."
 msgstr ""
 "Si vous avez compris ce qui précède, vous savez déjà tout ce que vous devez "
-"savoir sur la mécanique de l'utilisation des connecteurs. Vous utiliserez "
-"toujours les mêmes appels, de la même façon. C'est juste que, si vous le "
-"faites bien, votre application sera presque dans la poche."
+"savoir sur la mécanique de l’utilisation des connecteurs. Vous utiliserez "
+"toujours les mêmes appels, de la même façon. Il n’y que ça. Si vous le "
+"faites bien, c’est presque dans la poche."
 
 #: ../Doc/howto/sockets.rst:320
 msgid ""
@@ -556,12 +625,12 @@ msgid ""
 "the exact same idea. You do this after creating the socket, but before using "
 "it. (Actually, if you're nuts, you can switch back and forth.)"
 msgstr ""
-"En Python, vous utilisez ``socket.setblocking(0)`` pour le rendre non-"
-"bloquant. En C, c'est plus complexe (pour commencer, vous devez choisir "
-"entre la version BSD ``O_NONBLOCK`` et la version Posix presque impossible à "
+"En Python, vous utilisez ``socket.setblocking(0)`` pour rendre non-bloquant. "
+"En C, c’est plus complexe (pour commencer, vous devez choisir entre la "
+"version BSD ``O_NONBLOCK`` et la version Posix presque impossible à "
 "distinguer ``O_NDELAY``, qui est complètement différente de "
-"``TCP_NODELAY``), mais c'est exactement la même idée. Vous le faites après "
-"avoir créé le connecteur mais avant de l'utiliser (en fait, si vous êtes "
+"``TCP_NODELAY``), mais c’est exactement la même idée. Vous le faites après "
+"avoir créé le connecteur mais avant de l’utiliser (en fait, si vous êtes "
 "fou, vous pouvez alterner)."
 
 #: ../Doc/howto/sockets.rst:327
@@ -573,10 +642,17 @@ msgid ""
 "will grow large, buggy and suck CPU. So let's skip the brain-dead solutions "
 "and do it right."
 msgstr ""
+"La différence majeure de fonctionnement est que `send``, ``recv``, "
+"``connect`` et ``accept`` peuvent rendre la main sans avoir rien fait. Vous "
+"avez (bien sûr) un certain nombre de choix. Vous pouvez vérifier le code de "
+"retour et les codes d'erreur et, en général, devenir fou. Si vous ne me "
+"croyez pas, essayez un jour. Votre application va grossir, boguer et "
+"vampiriser le processeur. Alors, évitons les solutions vouées à l’échec dès "
+"le départ et faisons les choses correctement."
 
 #: ../Doc/howto/sockets.rst:334
 msgid "Use ``select``."
-msgstr "Utiliser ``select``."
+msgstr "Utilisation de ``select``."
 
 #: ../Doc/howto/sockets.rst:336
 msgid ""
@@ -586,7 +662,7 @@ msgid ""
 msgstr ""
 "En C, implémenter ``select`` est assez complexe. En Python, c'est du gâteau, "
 "mais c'est assez proche de la version C ; aussi, si vous comprenez "
-"``select`` en Python, vous aurez peu de problèmes avec lui en C ::"
+"``select`` en Python, vous aurez peu de problèmes en C ::"
 
 #: ../Doc/howto/sockets.rst:347
 msgid ""
@@ -598,6 +674,15 @@ msgid ""
 "generally a sensible thing to do - give it a nice long timeout (say a "
 "minute) unless you have good reason to do otherwise."
 msgstr ""
+"Vous passez à ``select`` trois listes : la première contient tous les "
+"connecteurs dont vous souhaiter lire le contenu ; la deuxième tous les "
+"connecteurs sur lesquels vous voudriez écrire, et la dernière (normalement "
+"laissée vide) ceux sur lesquels vous voudriez vérifier s’il y a des erreurs. "
+"Prenez note qu'un connecteur peut figurer dans plus d'une liste. L'appel à "
+"``select`` est bloquant, mais vous pouvez lui donner un délai d'attente. "
+"C'est généralement une bonne chose à faire — donnez-lui un bon gros délai "
+"d'attente (disons une minute), à moins que vous n'ayez une bonne raison de "
+"ne pas le faire."
 
 #: ../Doc/howto/sockets.rst:355
 msgid ""
@@ -605,6 +690,10 @@ msgid ""
 "actually readable, writable and in error. Each of these lists is a subset "
 "(possibly empty) of the corresponding list you passed in."
 msgstr ""
+"En retour, vous recevrez trois listes. Elles contiennent les connecteurs qui "
+"sont réellement lisibles, inscriptibles et en erreur. Chacune de ces listes "
+"est un sous-ensemble (éventuellement vide) de la liste correspondante que "
+"vous avez transmise."
 
 #: ../Doc/howto/sockets.rst:359
 msgid ""
@@ -615,14 +704,14 @@ msgid ""
 "nothing.  (Actually, any reasonably healthy socket will return as writable - "
 "it just means outbound network buffer space is available.)"
 msgstr ""
-"Si un connecteur se trouve dans la liste des sorties que vous pouvez lire, "
+"Si un connecteur se trouve dans la liste renvoyée des connecteurs lisibles, "
 "vous pouvez être pratiquement certain qu'un ``recv`` sur ce connecteur "
-"retournera *quelque chose*. Même chose pour la liste des sorties sur "
-"lesquelles vous pouvez écrire. Vous pourrez envoyer *quelque chose*. Peut-"
-"être pas tout ce que vous voudrez, mais *quelque chose* est mieux que rien. "
-"(En fait, n'importe quel connecteur raisonnablement sain retournera en "
-"écriture — cela signifie simplement que l'espace tampon réseau sortant est "
-"disponible)."
+"renvoie *quelque chose*. Même chose pour la liste renvoyée des connecteurs "
+"inscriptibles. Vous pourrez envoyer *quelque chose*. Peut-être pas tout ce "
+"que vous voudrez, mais *quelque chose* est mieux que rien (en fait, "
+"n'importe quel connecteur raisonnablement sain sera présent dans la liste "
+"des connecteurs inscriptibles — cela signifie simplement que l'espace tampon "
+"réseau sortant est disponible)."
 
 #: ../Doc/howto/sockets.rst:366
 msgid ""
@@ -632,13 +721,14 @@ msgid ""
 "it in the potential_writers list. If it shows up in the writable list, you "
 "have a decent chance that it has connected."
 msgstr ""
-"Si vous avez un connecteur « serveur », mettez-le dans la liste des lecteurs "
-"potentiels. Si il apparaît dans la liste des sorties que vous pouvez lire, "
-"votre ``accept`` fonctionnera (presque certainement). Si vous avez créé un "
-"nouveau connecteur pour ``connect`` à quelqu'un d'autre, mettez-le dans la "
-"liste des éditeurs potentiels. Si il apparaît dans la liste des sorties sur "
-"lesquelles vous pouvez écrire, vous avez une bonne chance qu'il se soit "
-"connecté."
+"Si vous avez un connecteur « serveur », mettez-le dans la liste des "
+"connecteurs potentiellement lisibles ``potential_readers``. S’il apparaît "
+"dans la liste renvoyée des connecteurs que vous pouvez lire, votre "
+"``accept`` fonctionnera (presque certainement). Si vous avez créé un nouveau "
+"connecteur pour se connecter via ``connect`` à quelqu'un d'autre, mettez-le "
+"dans la liste des connecteurs potentiellement inscriptibles. S’il apparaît "
+"dans la liste renvoyée des connecteurs sur lesquels vous pouvez écrire, vous "
+"avez une bonne chance qu'il se soit connecté."
 
 #: ../Doc/howto/sockets.rst:372
 msgid ""
@@ -649,10 +739,10 @@ msgid ""
 "something else."
 msgstr ""
 "En fait, ``select`` peut être pratique même avec des connecteurs bloquants. "
-"C'est une façon de déterminer si vous allez bloquer — le connecteur "
-"redevient lisible lorsqu'il y a quelque chose dans les tampons. Cependant, "
-"cela n'aide pas encore à déterminer si l'autre extrémité a terminé, ou si "
-"elle est simplement occupée par autre chose."
+"C'est une façon de déterminer si vous allez bloquer — le connecteur est "
+"renvoyé comme lisible lorsqu'il y a quelque chose dans les mémoires tampons. "
+"Cependant, cela n'aide pas encore à déterminer si l'autre extrémité a "
+"terminé, ou si elle est simplement occupée par autre chose."
 
 #: ../Doc/howto/sockets.rst:377
 msgid ""