@@ -43,7 +43,7 @@ JOBS := auto
 .PHONY: all
 all: setup
 	mkdir -p $(WORKTREE)/locales/$(LANGUAGE)/LC_MESSAGES/
-	cp --parents *.po */*.po $(WORKTREE)/locales/$(LANGUAGE)/LC_MESSAGES/
+	gcp --parents *.po */*.po $(WORKTREE)/locales/$(LANGUAGE)/LC_MESSAGES/
 	$(MAKE) -C $(WORKTREE)/Doc/ VENVDIR=$(WORKTREE)/Doc/venv/ PYTHON=$(PYTHON) \
 	  SPHINXOPTS='-qW -j$(JOBS)   \
 	  -D locale_dirs=../locales   \
 
@@ -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 octets, 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,13 +442,27 @@ 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, comme 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 seconde "
+"pour obtenir la partie « données » du message. Sordide. 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 ""
 "In the interests of space, building your character, (and preserving my "
 "competitive position), these enhancements are left as an exercise for the "
 "reader. Lets move on to cleaning up."
 msgstr ""
+"Dans l’intérêt de l’univers, 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 comme un exercice que vous pouvez faire. 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 "
+"représentera un entier de 16 bits avec la valeur 1 comme les deux octets "
+"hexadécimaux 00 01. Intel et DEC, cependant, utilisent l’ordre d’octets "
+"inverse — ce même 1 est 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* 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,12 @@ 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 « 0 » serait de deux octets, alors que le binaire est "
+"de quatre. 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 +523,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 le même que ``shutdown() ; close()``. Ainsi, dans la "
+"plupart des situations, un ``shutdown`` explicite n’est pas nécessaire."
 
 #: ../Doc/howto/sockets.rst:282
 msgid ""
@@ -501,6 +542,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 l’\\ ``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 +559,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 +585,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 lors que l'autre côté s'écroule violemment (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 pas quelque chose 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 frais généraux 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 +611,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 +624,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 +641,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 mécanique majeure 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 +661,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,13 +673,26 @@ 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 touts les "
+"connecteurs que vous voudriez lire ; la seconde tous les connecteurs sur "
+"lesquels vous voudriez écrire, et la dernière (normalement laissée vide) "
+"ceux sur lesquels que 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 ""
 "In return, you will get three lists. They contain the sockets that are "
 "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 +703,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ées 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)."
+"renverra *quelque chose*. Même chose pour la liste renvoyées 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 +720,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 +738,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 ""