Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 12c1594

Browse files
deronnaxchristopheNanawecx
authored
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 <[email protected]> * wrapping * "s'interrompt brutalement" + "couts significatifs" * Apply suggestions from code review Co-authored-by: Christophe Nanteuil <[email protected]> * wrapping * retrait fichier ajouté par erreur * Apply suggestions from code review Co-authored-by: Antoine <[email protected]> * autres remarques d'awecx * wrapping * Update howto/sockets.po Co-authored-by: Antoine <[email protected]> * Update howto/sockets.po Co-authored-by: Christophe Nanteuil <[email protected]> Co-authored-by: Antoine <[email protected]>
1 parent 37e803c commit 12c1594

File tree

2 files changed

+129
-38
lines changed

2 files changed

+129
-38
lines changed

dict

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,7 @@ base32
1212
base64
1313
base85
1414
batch
15+
boguer
1516
c++
1617
c-
1718
c/c++

howto/sockets.po

Lines changed: 128 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ msgstr ""
66
"Project-Id-Version: Python 3\n"
77
"Report-Msgid-Bugs-To: \n"
88
"POT-Creation-Date: 2018-06-10 11:27+0200\n"
9-
"PO-Revision-Date: 2020-05-04 22:08+0200\n"
9+
"PO-Revision-Date: 2020-05-08 15:38+0200\n"
1010
"Language-Team: FRENCH <[email protected]>\n"
1111
"Language: fr\n"
1212
"MIME-Version: 1.0\n"
@@ -144,9 +144,9 @@ msgid ""
144144
msgstr ""
145145
"Lorsque l’appel à ``connect`` est terminé, le connecteur ``s`` peut être "
146146
"utilisé pour envoyer une requête demandant le texte de la page. Le même "
147-
"connecteur lira la réponse, puis sera détruit. C'est exact, détruit. Les "
148-
"connecteurs clients ne sont normalement utilisés que pour un seul échange "
149-
"(ou un petit ensemble d'échanges séquentiels)."
147+
"connecteur lira la réponse, puis sera mis au rebut. C'est exact, mis au "
148+
"rebut. Les connecteurs clients ne sont normalement utilisés que pour un seul "
149+
"échange (ou un petit ensemble d'échanges séquentiels)."
150150

151151
#: ../Doc/howto/sockets.rst:70
152152
msgid ""
@@ -201,7 +201,7 @@ msgid ""
201201
"mainloop of the web server::"
202202
msgstr ""
203203
"Maintenant que nous avons un connecteur « serveur », en écoute sur le port "
204-
"80, nous pouvons entrer dans la boucle principale du serveur web: :"
204+
"80, nous pouvons entrer dans la boucle principale du serveur web ::"
205205

206206
#: ../Doc/howto/sockets.rst:106
207207
msgid ""
@@ -219,7 +219,7 @@ msgid ""
219219
"allocated port which will be recycled when the conversation ends."
220220
msgstr ""
221221
"Il y a en fait trois façons générales de faire fonctionner cette boucle : "
222-
"envoyer un fil d'exécution pour gérer les ``clientsocket``\\s, créer un "
222+
"mobiliser un fil d'exécution pour gérer les ``clientsocket``\\s, créer un "
223223
"nouveau processus pour gérer les ``clientsocket``\\s, ou restructurer cette "
224224
"application pour utiliser des connecteurs non bloquants, et multiplexer "
225225
"entre notre connecteur « serveur » et n'importe quel ``clientsocket`` actif "
@@ -316,7 +316,7 @@ msgid ""
316316
"again until your message has been completely dealt with."
317317
msgstr ""
318318
"Nous arrivons maintenant au principal écueil des connecteurs — ``send`` et "
319-
"``recv`` fonctionnent sur les mémoires tampons du réseau. ils ne traitent "
319+
"``recv`` fonctionnent sur les mémoires tampons du réseau. Ils ne traitent "
320320
"pas nécessairement tous les octets que vous leur passez (ou que vous "
321321
"attendez d'eux), car leur principal objectif est de gérer les tampons "
322322
"réseau. En général, leur exécution se termine lorsque les tampons réseau "
@@ -363,7 +363,7 @@ msgstr ""
363363
"Mais si vous prévoyez de réutiliser votre connecteur pour d'autres "
364364
"transferts, vous devez réaliser qu'\\ *il n'y a pas* d':abbr:`EOT (End of "
365365
"Transfer)` *sur un connecteur*. Je répète : si un appel à ``send`` ou "
366-
"``recv`` se termine après avoir manipulé 0 octets, la connexion a été "
366+
"``recv`` se termine après avoir traité 0 octet, la connexion a été "
367367
"interrompue. Si la connexion n'a *pas* été interrompue, vous pouvez attendre "
368368
"sur un ``recv`` pour toujours, car le connecteur ne vous dira pas qu'il n'y "
369369
"a plus rien à lire (pour le moment). Maintenant, si vous y réfléchissez un "
@@ -442,13 +442,27 @@ msgid ""
442442
"not always manage to get rid of everything in one pass. And despite having "
443443
"read this, you will eventually get bit by it!"
444444
msgstr ""
445+
"Préfixer le message avec sa longueur (disons, sous la forme de 5 caractères "
446+
"numériques) devient plus complexe, parce que (croyez-le ou non), vous pouvez "
447+
"ne pas recevoir les 5 caractères en un seul ``recv``. Pour une utilisation "
448+
"triviale, vous vous en tirerez à bon compte ; mais en cas de forte charge "
449+
"réseau, votre code se cassera très rapidement, à moins que vous n’utilisiez "
450+
"deux boucles ``recv`` — la première pour déterminer la longueur, la deuxième "
451+
"pour obtenir la partie « données » du message. Vilain. C’est aussi à ce "
452+
"moment que vous découvrirez que « l’envoi » via ``send`` ne parvient pas "
453+
"toujours à tout évacuer en un seul passage. Et bien que vous ayez lu cet "
454+
"avertissement, vous finirez par vous faire avoir par cette subtilité !"
445455

446456
#: ../Doc/howto/sockets.rst:246
447457
msgid ""
448458
"In the interests of space, building your character, (and preserving my "
449459
"competitive position), these enhancements are left as an exercise for the "
450460
"reader. Lets move on to cleaning up."
451461
msgstr ""
462+
"Pour garder une longueur raisonnable à cette page, pour forger votre "
463+
"caractère (et afin de garder l’avantage concurrentiel que j’ai sur vous), "
464+
"ces améliorations ne seront pas abordées et sont laissées en exercice au "
465+
"lecteur. Passons maintenant au nettoyage."
452466

453467
#: ../Doc/howto/sockets.rst:252
454468
msgid "Binary Data"
@@ -466,6 +480,18 @@ msgid ""
466480
"order is host order, these do nothing, but where the machine is byte-"
467481
"reversed, these swap the bytes around appropriately."
468482
msgstr ""
483+
"Il est parfaitement possible d’envoyer des données binaires sur un "
484+
"connecteur. Le gros problème est que toutes les machines n’utilisent pas les "
485+
"mêmes formats pour les données binaires. Par exemple, une puce Motorola code "
486+
"l'entier 1, sous 16 bits, comme les deux octets hexadécimaux 00 01. Intel et "
487+
"DEC, cependant, utilisent l’ordre d’octets inverse — ce même 1 est codé 01 "
488+
"00. Les bibliothèques de connecteurs ont des appels pour convertir des "
489+
"entiers de 16 et 32 bits — ``ntohl, htonl, ntohs, htons`` où ``n`` signifie "
490+
"*réseau* (*network*, en anglais) et ``h`` signifie *hôte*, ``s`` signifie "
491+
"*court* (*short*, en anglais) et ``l`` signifie *long*. Lorsque l’ordre du "
492+
"réseau est l’ordre de l’hôte, ceux-ci ne font rien, mais lorsque la machine "
493+
"utilise l’ordre d’octets inverse, ceux-ci échangent les octets de manière "
494+
"appropriée."
469495

470496
#: ../Doc/howto/sockets.rst:264
471497
msgid ""
@@ -475,6 +501,13 @@ msgid ""
475501
"The string \"0\" would be two bytes, while binary is four. Of course, this "
476502
"doesn't fit well with fixed-length messages. Decisions, decisions."
477503
msgstr ""
504+
"De nos jours, avec les machines 32 bits, la représentation *ASCII* des "
505+
"données binaires est souvent plus compacte que la représentation binaire. "
506+
"C’est parce qu’un nombre surprenant de fois, tous ces *longs* ont la valeur "
507+
"0, ou peut-être 1. La chaîne « 0 » serait codée sur deux octets, alors "
508+
"qu'elle le serait sur quatre en binaire. Bien sûr, cela ne fonctionne pas "
509+
"très bien avec les messages de longueur fixe. Ah, les décisions, les "
510+
"décisions…"
478511

479512
#: ../Doc/howto/sockets.rst:272
480513
msgid "Disconnecting"
@@ -491,6 +524,15 @@ msgid ""
491524
"same as ``shutdown(); close()``. So in most situations, an explicit "
492525
"``shutdown`` is not needed."
493526
msgstr ""
527+
"À proprement parler, vous êtes censé utiliser ``shutdown`` sur un connecteur "
528+
"pour l’arrêter avant de le fermer via ``close``. Le ``shutdown`` est un "
529+
"avertissement au connecteur de l’autre côté. Selon l’argument que vous lui "
530+
"passez, cela peut signifier « Je ne vais plus envoyer, mais je vais quand "
531+
"même écouter », ou « Je n’écoute pas, bon débarras ! ». La plupart des "
532+
"bibliothèques de connecteurs, cependant, sont tellement habituées à ce que "
533+
"les programmeurs négligent d’utiliser ce morceau d’étiquette que normalement "
534+
"un ``close`` est équivalent à ``shutdown() ; close()``. Ainsi, dans la "
535+
"plupart des situations, un ``shutdown`` explicite n’est pas nécessaire."
494536

495537
#: ../Doc/howto/sockets.rst:282
496538
msgid ""
@@ -501,6 +543,13 @@ msgid ""
501543
"complete request. The server sends a reply. If the ``send`` completes "
502544
"successfully then, indeed, the client was still receiving."
503545
msgstr ""
546+
"Une façon d’utiliser efficacement le ``shutdown`` est d’utiliser un échange "
547+
"de type HTTP. Le client envoie une requête et effectue ensuite un "
548+
"``shutdown(1)``. Cela indique au serveur que « ce client a fini d’envoyer, "
549+
"mais peut encore recevoir ». Le serveur peut détecter *EOF* par une "
550+
"réception de 0 octet. Il peut supposer qu’il a la requête complète. Le "
551+
"serveur envoie une réponse. Si le ``send`` se termine avec succès, alors, en "
552+
"effet, le client était encore en train de recevoir."
504553

505554
#: ../Doc/howto/sockets.rst:289
506555
msgid ""
@@ -511,10 +560,17 @@ msgid ""
511560
"indefinitely, thinking you're just being slow. *Please* ``close`` your "
512561
"sockets when you're done."
513562
msgstr ""
563+
"Python pousse l’arrêt automatique un peu plus loin, et dit que lorsqu’un "
564+
"connecteur est collecté par le ramasse-miette, il effectue automatiquement "
565+
"une fermeture via ``close`` si elle est nécessaire. Mais c’est une très "
566+
"mauvaise habitude de s’appuyer sur ce système. Si votre connecteur disparaît "
567+
"sans avoir fait un ``close``, le connecteur à l’autre bout peut rester "
568+
"suspendu indéfiniment, pensant que vous êtes juste lent. Fermez vos "
569+
"connecteurs quand vous avez terminé *s’il vous plait*."
514570

515571
#: ../Doc/howto/sockets.rst:297
516572
msgid "When Sockets Die"
517-
msgstr ""
573+
msgstr "Quand les connecteurs meurent"
518574

519575
#: ../Doc/howto/sockets.rst:299
520576
msgid ""
@@ -530,10 +586,23 @@ msgid ""
530586
"automatic recycling of resources. In other words, if you do manage to kill "
531587
"the thread, your whole process is likely to be screwed up."
532588
msgstr ""
589+
"Le pire dans l'utilisation de connecteurs bloquants est probablement ce qui "
590+
"se passe lorsque l'autre côté s'interrompt brutalement (sans faire de "
591+
"fermeture via ``close``). Votre connecteur risque d’attendre infiniment. TCP "
592+
"est un protocole fiable, et il attendra très, très longtemps avant "
593+
"d'abandonner une connexion. Si vous utilisez des fils d’exécution, le fil "
594+
"entier est pratiquement mort. Il n'y a pas grand-chose que vous puissiez "
595+
"faire à ce sujet. Du moment que vous ne faites rien de stupide, comme tenir "
596+
"un verrou verrouillé pendant une lecture bloquante, le fil ne consomme pas "
597+
"vraiment beaucoup de ressources. N'essayez *pas* de tuer le fil — si les "
598+
"fils sont plus efficients que les processus, c'est en partie parce qu'ils "
599+
"évitent les coûts significatifs liés au recyclage automatique des "
600+
"ressources. En d'autres termes, si vous parvenez à tuer le fil, tout votre "
601+
"processus risque d'être foutu."
533602

534603
#: ../Doc/howto/sockets.rst:313
535604
msgid "Non-blocking Sockets"
536-
msgstr ""
605+
msgstr "Connecteurs non bloquants"
537606

538607
#: ../Doc/howto/sockets.rst:315
539608
msgid ""
@@ -543,9 +612,9 @@ msgid ""
543612
"will be almost inside-out."
544613
msgstr ""
545614
"Si vous avez compris ce qui précède, vous savez déjà tout ce que vous devez "
546-
"savoir sur la mécanique de l'utilisation des connecteurs. Vous utiliserez "
547-
"toujours les mêmes appels, de la même façon. C'est juste que, si vous le "
548-
"faites bien, votre application sera presque dans la poche."
615+
"savoir sur la mécanique de lutilisation des connecteurs. Vous utiliserez "
616+
"toujours les mêmes appels, de la même façon. Il n’y que ça. Si vous le "
617+
"faites bien, c’est presque dans la poche."
549618

550619
#: ../Doc/howto/sockets.rst:320
551620
msgid ""
@@ -556,12 +625,12 @@ msgid ""
556625
"the exact same idea. You do this after creating the socket, but before using "
557626
"it. (Actually, if you're nuts, you can switch back and forth.)"
558627
msgstr ""
559-
"En Python, vous utilisez ``socket.setblocking(0)`` pour le rendre non-"
560-
"bloquant. En C, c'est plus complexe (pour commencer, vous devez choisir "
561-
"entre la version BSD ``O_NONBLOCK`` et la version Posix presque impossible à "
628+
"En Python, vous utilisez ``socket.setblocking(0)`` pour rendre non-bloquant. "
629+
"En C, cest plus complexe (pour commencer, vous devez choisir entre la "
630+
"version BSD ``O_NONBLOCK`` et la version Posix presque impossible à "
562631
"distinguer ``O_NDELAY``, qui est complètement différente de "
563-
"``TCP_NODELAY``), mais c'est exactement la même idée. Vous le faites après "
564-
"avoir créé le connecteur mais avant de l'utiliser (en fait, si vous êtes "
632+
"``TCP_NODELAY``), mais cest exactement la même idée. Vous le faites après "
633+
"avoir créé le connecteur mais avant de lutiliser (en fait, si vous êtes "
565634
"fou, vous pouvez alterner)."
566635

567636
#: ../Doc/howto/sockets.rst:327
@@ -573,10 +642,17 @@ msgid ""
573642
"will grow large, buggy and suck CPU. So let's skip the brain-dead solutions "
574643
"and do it right."
575644
msgstr ""
645+
"La différence majeure de fonctionnement est que `send``, ``recv``, "
646+
"``connect`` et ``accept`` peuvent rendre la main sans avoir rien fait. Vous "
647+
"avez (bien sûr) un certain nombre de choix. Vous pouvez vérifier le code de "
648+
"retour et les codes d'erreur et, en général, devenir fou. Si vous ne me "
649+
"croyez pas, essayez un jour. Votre application va grossir, boguer et "
650+
"vampiriser le processeur. Alors, évitons les solutions vouées à l’échec dès "
651+
"le départ et faisons les choses correctement."
576652

577653
#: ../Doc/howto/sockets.rst:334
578654
msgid "Use ``select``."
579-
msgstr "Utiliser ``select``."
655+
msgstr "Utilisation de ``select``."
580656

581657
#: ../Doc/howto/sockets.rst:336
582658
msgid ""
@@ -586,7 +662,7 @@ msgid ""
586662
msgstr ""
587663
"En C, implémenter ``select`` est assez complexe. En Python, c'est du gâteau, "
588664
"mais c'est assez proche de la version C ; aussi, si vous comprenez "
589-
"``select`` en Python, vous aurez peu de problèmes avec lui en C ::"
665+
"``select`` en Python, vous aurez peu de problèmes en C ::"
590666

591667
#: ../Doc/howto/sockets.rst:347
592668
msgid ""
@@ -598,13 +674,26 @@ msgid ""
598674
"generally a sensible thing to do - give it a nice long timeout (say a "
599675
"minute) unless you have good reason to do otherwise."
600676
msgstr ""
677+
"Vous passez à ``select`` trois listes : la première contient tous les "
678+
"connecteurs dont vous souhaiter lire le contenu ; la deuxième tous les "
679+
"connecteurs sur lesquels vous voudriez écrire, et la dernière (normalement "
680+
"laissée vide) ceux sur lesquels vous voudriez vérifier s’il y a des erreurs. "
681+
"Prenez note qu'un connecteur peut figurer dans plus d'une liste. L'appel à "
682+
"``select`` est bloquant, mais vous pouvez lui donner un délai d'attente. "
683+
"C'est généralement une bonne chose à faire — donnez-lui un bon gros délai "
684+
"d'attente (disons une minute), à moins que vous n'ayez une bonne raison de "
685+
"ne pas le faire."
601686

602687
#: ../Doc/howto/sockets.rst:355
603688
msgid ""
604689
"In return, you will get three lists. They contain the sockets that are "
605690
"actually readable, writable and in error. Each of these lists is a subset "
606691
"(possibly empty) of the corresponding list you passed in."
607692
msgstr ""
693+
"En retour, vous recevrez trois listes. Elles contiennent les connecteurs qui "
694+
"sont réellement lisibles, inscriptibles et en erreur. Chacune de ces listes "
695+
"est un sous-ensemble (éventuellement vide) de la liste correspondante que "
696+
"vous avez transmise."
608697

609698
#: ../Doc/howto/sockets.rst:359
610699
msgid ""
@@ -615,14 +704,14 @@ msgid ""
615704
"nothing. (Actually, any reasonably healthy socket will return as writable - "
616705
"it just means outbound network buffer space is available.)"
617706
msgstr ""
618-
"Si un connecteur se trouve dans la liste des sorties que vous pouvez lire, "
707+
"Si un connecteur se trouve dans la liste renvoyée des connecteurs lisibles, "
619708
"vous pouvez être pratiquement certain qu'un ``recv`` sur ce connecteur "
620-
"retournera *quelque chose*. Même chose pour la liste des sorties sur "
621-
"lesquelles vous pouvez écrire. Vous pourrez envoyer *quelque chose*. Peut-"
622-
"être pas tout ce que vous voudrez, mais *quelque chose* est mieux que rien. "
623-
"(En fait, n'importe quel connecteur raisonnablement sain retournera en "
624-
"écriture — cela signifie simplement que l'espace tampon réseau sortant est "
625-
"disponible)."
709+
"renvoie *quelque chose*. Même chose pour la liste renvoyée des connecteurs "
710+
"inscriptibles. Vous pourrez envoyer *quelque chose*. Peut-être pas tout ce "
711+
"que vous voudrez, mais *quelque chose* est mieux que rien (en fait, "
712+
"n'importe quel connecteur raisonnablement sain sera présent dans la liste "
713+
"des connecteurs inscriptibles — cela signifie simplement que l'espace tampon "
714+
"réseau sortant est disponible)."
626715

627716
#: ../Doc/howto/sockets.rst:366
628717
msgid ""
@@ -632,13 +721,14 @@ msgid ""
632721
"it in the potential_writers list. If it shows up in the writable list, you "
633722
"have a decent chance that it has connected."
634723
msgstr ""
635-
"Si vous avez un connecteur « serveur », mettez-le dans la liste des lecteurs "
636-
"potentiels. Si il apparaît dans la liste des sorties que vous pouvez lire, "
637-
"votre ``accept`` fonctionnera (presque certainement). Si vous avez créé un "
638-
"nouveau connecteur pour ``connect`` à quelqu'un d'autre, mettez-le dans la "
639-
"liste des éditeurs potentiels. Si il apparaît dans la liste des sorties sur "
640-
"lesquelles vous pouvez écrire, vous avez une bonne chance qu'il se soit "
641-
"connecté."
724+
"Si vous avez un connecteur « serveur », mettez-le dans la liste des "
725+
"connecteurs potentiellement lisibles ``potential_readers``. S’il apparaît "
726+
"dans la liste renvoyée des connecteurs que vous pouvez lire, votre "
727+
"``accept`` fonctionnera (presque certainement). Si vous avez créé un nouveau "
728+
"connecteur pour se connecter via ``connect`` à quelqu'un d'autre, mettez-le "
729+
"dans la liste des connecteurs potentiellement inscriptibles. S’il apparaît "
730+
"dans la liste renvoyée des connecteurs sur lesquels vous pouvez écrire, vous "
731+
"avez une bonne chance qu'il se soit connecté."
642732

643733
#: ../Doc/howto/sockets.rst:372
644734
msgid ""
@@ -649,10 +739,10 @@ msgid ""
649739
"something else."
650740
msgstr ""
651741
"En fait, ``select`` peut être pratique même avec des connecteurs bloquants. "
652-
"C'est une façon de déterminer si vous allez bloquer — le connecteur "
653-
"redevient lisible lorsqu'il y a quelque chose dans les tampons. Cependant, "
654-
"cela n'aide pas encore à déterminer si l'autre extrémité a terminé, ou si "
655-
"elle est simplement occupée par autre chose."
742+
"C'est une façon de déterminer si vous allez bloquer — le connecteur est "
743+
"renvoyé comme lisible lorsqu'il y a quelque chose dans les mémoires tampons. "
744+
"Cependant, cela n'aide pas encore à déterminer si l'autre extrémité a "
745+
"terminé, ou si elle est simplement occupée par autre chose."
656746

657747
#: ../Doc/howto/sockets.rst:377
658748
msgid ""

0 commit comments

Comments
 (0)