From 689989e04c6e3dbaaada351579ffefb55e981f8e Mon Sep 17 00:00:00 2001 From: VivienLambert <37274440+VivienLambert@users.noreply.github.com> Date: Tue, 22 Jan 2019 09:30:21 +0100 Subject: [PATCH] Apply suggestions from code review email -> e-mail --- library/email.po | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/library/email.po b/library/email.po index 90a6d787..d0d554fb 100644 --- a/library/email.po +++ b/library/email.po @@ -16,7 +16,7 @@ msgstr "" #: ../Doc/library/email.rst:2 msgid ":mod:`email` --- An email and MIME handling package" -msgstr ":mod:`email` --- Un paquet de gestion des emails et MIME" +msgstr ":mod:`email` --- Un paquet de gestion des e-mails et MIME" #: ../Doc/library/email.rst:11 msgid "**Source code:** :source:`Lib/email/__init__.py`" @@ -32,8 +32,8 @@ msgid "" "well as such MIME-related RFCs as :rfc:`2045`, :rfc:`2046`, :rfc:`2047`, :" "rfc:`2183`, and :rfc:`2231`." msgstr "" -"Le paquet :mod:`email` est une bibliothèque pour gérer les emails. Il n'est " -"spécifiquement *pas* conçu pour faire des envois d'emails vers SMTP (:rfc:" +"Le paquet :mod:`email` est une bibliothèque pour gérer les e-mails. Il n'est " +"spécifiquement *pas* conçu pour faire des envois d'e-mails vers SMTP (:rfc:" "`2821`), NNTP, ou autres serveurs ; ce sont des fonctions de modules comme :" "mod:`smtplib` et :mod:`nntplib`. Le paquet :mod:`email` tente de respecter " "les RFC autant que possible, supportant :rfc:`5233` et :rfc:`6532`, ainsi " @@ -65,10 +65,10 @@ msgstr "" "messages. Une application interagit avec le paquet, dans un premier temps, à " "travers l'interface de modèle d'objet définie dans le sous-module :mod:" "`~email.message`. L'application peut utiliser cette API pour poser des " -"questions à propos d'un mail existant, pour créer un nouvel email, ou " -"ajouter ou retirer des sous-composants d'email qui utilisent la même " +"questions à propos d'un mail existant, pour créer un nouvel e-mail, ou " +"ajouter ou retirer des sous-composants d'e-mail qui utilisent la même " "interface de modèle d'objet. Suivant la nature des messages et leurs sous-" -"composants MIME, le modèle d'objet d'email est une structure en arborescence " +"composants MIME, le modèle d'objet d'e-mail est une structure en arborescence " "d'objets qui fournit tout à l'API de :class:`~email.message.EmailMessage`." #: ../Doc/library/email.rst:37 @@ -84,7 +84,7 @@ msgid "" msgstr "" "Les deux autres composants majeurs de ce paquet sont l'analyseur (:mod:" "`~email.parser`) et le generateur (:mod:`~email.generator`). L'analyseur " -"prend la version sérialisée d'un email (un flux d'octets) et le convertit " +"prend la version sérialisée d'un e-mail (un flux d'octets) et le convertit " "en une arborescence d'objets :class:`~email.message.EmailMessage`. Le " "générateur prend un objet :class:`~email.message.EmailMessage` et le " "retransforme en un flux d'octets sérialisée. (L'analyseur et le générateur " @@ -112,12 +112,12 @@ msgstr "" "contrôle son comportement. Habituellement une application n'a besoin de " "spécifier la politique que quand un :class:`~email.message.EmailMessage` est " "créé, soit en instanciant directement un :class:`~email.message." -"EmailMessage` pour créer un nouvel email, ou en analysant un flux entrant en " +"EmailMessage` pour créer un nouvel e-mail, ou en analysant un flux entrant en " "utilisant un :mod:`~email.parser`. Mais la politique peut être changée quand " "le message est serialisé en utilisant un :mod:`~email.generator`. Cela " -"permet, par exemple, d'analyser un message email générique du disque, mais " +"permet, par exemple, d'analyser un message e-mail générique du disque, mais " "de le sérialiser en utilisant les réglages SMTP standards SMTP quand envoyés " -"vers un serveur d'email." +"vers un serveur d'e-mail." #: ../Doc/library/email.rst:58 msgid "" @@ -135,9 +135,9 @@ msgid "" "modern internet software (not just email), this will be a familiar concept " "to many programmers." msgstr "" -"Le paquet email fait son maximum pour cacher les détails des différentes RFCs " +"Le paquet *email* fait son maximum pour cacher les détails des différentes RFCs " "gouvernants de l'application. Conceptuellement, l'application devrait être " -"capable de traiter l'email comme une arborescence structurée de texte " +"capable de traiter l'e-mail comme une arborescence structurée de texte " "unicode et de pièces jointes binaires, sans avoir à se préoccuper de leur " "représentation sérialisée. Dans la pratique, cependant, il est souvent " "nécessaire d'être conscient d'au moins quelques règles gouvernant les " @@ -148,7 +148,7 @@ msgstr "" "question des structures de haut niveau et non des détails sur la manière " "dont elles sont représentées. Vu que les types de contenus MIME sont " "couramment utilisés dans les logiciels internet modernes (et non uniquement " -"les emails), ce sera un concept familier à de multiples développeurs." +"les e-mails), ce sera un concept familier à de multiples développeurs." #: ../Doc/library/email.rst:71 msgid "" @@ -208,9 +208,9 @@ msgid "" "compat32` API for backward compatibility reasons." msgstr "" "L'élément précédent représente l'API moderne (tolérant l'unicode) du paquet " -"email. Les sections restantes, commençant par la classe :class:`~email." +"*email*. Les sections restantes, commençant par la classe :class:`~email." "message.Message`, couvrent l'API héritée :data:`~email.policy.compat32` qui " -"traite beaucoup plus directement des détails sur la manière dont les emails " +"traite beaucoup plus directement des détails sur la manière dont les e-mails " "sont représentés. L'API :data:`~email.policy.compat32` ne cache *pas* les " "détails des RFCs de l'application, mais pour les applications qui requièrent " "d'opérer à ce niveau, elle peut être un outil pratique. Cette documentation "