python-docs-fr/library/email.po

# Copyright (C) 2001-2018, Python Software Foundation
# For licence information, see README file.
#
msgid ""
msgstr ""
"Project-Id-Version: Python 3.6\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-11-29 16:06+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: FRENCH <traductions@lists.afpy.org>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../Doc/library/email.rst:2
msgid ":mod:`email` --- An email and MIME handling package"
msgstr ""

#: ../Doc/library/email.rst:11
msgid "**Source code:** :source:`Lib/email/__init__.py`"
msgstr ""

#: ../Doc/library/email.rst:15
msgid ""
"The :mod:`email` package is a library for managing email messages.  It is "
"specifically *not* designed to do any sending of email messages to SMTP (:"
"rfc:`2821`), NNTP, or other servers; those are functions of modules such as :"
"mod:`smtplib` and :mod:`nntplib`.  The :mod:`email` package attempts to be "
"as RFC-compliant as possible, supporting :rfc:`5233` and :rfc:`6532`, as "
"well as such MIME-related RFCs as :rfc:`2045`, :rfc:`2046`, :rfc:`2047`, :"
"rfc:`2183`, and :rfc:`2231`."
msgstr ""

#: ../Doc/library/email.rst:23
msgid ""
"The overall structure of the email package can be divided into three major "
"components, plus a fourth component that controls the behavior of the other "
"components."
msgstr ""

#: ../Doc/library/email.rst:27
msgid ""
"The central component of the package is an \"object model\" that represents "
"email messages.  An application interacts with the package primarily through "
"the object model interface defined in the :mod:`~email.message` sub-module.  "
"The application can use this API to ask questions about an existing email, "
"to construct a new email, or to add or remove email subcomponents that "
"themselves use the same object model interface.  That is, following the "
"nature of email messages and their MIME subcomponents, the email object "
"model is a tree structure of objects that all provide the :class:`~email."
"message.EmailMessage` API."
msgstr ""

#: ../Doc/library/email.rst:37
msgid ""
"The other two major components of the package are the :mod:`~email.parser` "
"and the :mod:`~email.generator`.  The parser takes the serialized version of "
"an email message (a stream of bytes) and converts it into a tree of :class:"
"`~email.message.EmailMessage` objects.  The generator takes an :class:"
"`~email.message.EmailMessage` and turns it back into a serialized byte "
"stream.  (The parser and generator also handle streams of text characters, "
"but this usage is discouraged as it is too easy to end up with messages that "
"are not valid in one way or another.)"
msgstr ""

#: ../Doc/library/email.rst:46
msgid ""
"The control component is the :mod:`~email.policy` module.  Every :class:"
"`~email.message.EmailMessage`, every :mod:`~email.generator`, and every :mod:"
"`~email.parser` has an associated :mod:`~email.policy` object that controls "
"its behavior.  Usually an application only needs to specify the policy when "
"an :class:`~email.message.EmailMessage` is created, either by directly "
"instantiating an :class:`~email.message.EmailMessage`  to create a new "
"email, or by parsing an input stream using a :mod:`~email.parser`.  But the "
"policy can be changed when the message is serialized using a :mod:`~email."
"generator`. This allows, for example, a generic email message to be parsed "
"from disk, but to serialize it using standard SMTP settings when sending it "
"to an email server."
msgstr ""

#: ../Doc/library/email.rst:58
msgid ""
"The email package does its best to hide the details of the various governing "
"RFCs from the application.  Conceptually the application should be able to "
"treat the email message as a structured tree of unicode text and binary "
"attachments, without having to worry about how these are represented when "
"serialized.  In practice, however, it is often necessary to be aware of at "
"least some of the rules governing MIME messages and their structure, "
"specifically the names and nature of the MIME \"content types\" and how they "
"identify multipart documents.  For the most part this knowledge should only "
"be required for more complex applications, and even then it should only be "
"the high level structure in question, and not the details of how those "
"structures are represented.  Since MIME content types are used widely in "
"modern internet software (not just email), this will be a familiar concept "
"to many programmers."
msgstr ""

#: ../Doc/library/email.rst:71
msgid ""
"The following sections describe the functionality of the :mod:`email` "
"package. We start with the :mod:`~email.message` object model, which is the "
"primary interface an application will use, and follow that with the :mod:"
"`~email.parser` and :mod:`~email.generator` components.  Then we cover the :"
"mod:`~email.policy` controls, which completes the treatment of the main "
"components of the library."
msgstr ""

#: ../Doc/library/email.rst:78
msgid ""
"The next three sections cover the exceptions the package may raise and the "
"defects (non-compliance with the RFCs) that the :mod:`~email.parser` may "
"detect.  Then we cover the :mod:`~email.headerregistry` and the :mod:`~email."
"contentmanager` sub-components, which provide tools for doing more detailed "
"manipulation of headers and payloads, respectively.  Both of these "
"components contain features relevant to consuming and producing non-trivial "
"messages, but also document their extensibility APIs, which will be of "
"interest to advanced applications."
msgstr ""

#: ../Doc/library/email.rst:87
msgid ""
"Following those is a set of examples of using the fundamental parts of the "
"APIs covered in the preceding sections."
msgstr ""

#: ../Doc/library/email.rst:90
msgid ""
"The foregoing represent the modern (unicode friendly) API of the email "
"package. The remaining sections, starting with the :class:`~email.message."
"Message` class, cover the legacy :data:`~email.policy.compat32` API that "
"deals much more directly with the details of how email messages are "
"represented.  The :data:`~email.policy.compat32` API does *not* hide the "
"details of the RFCs from the application, but for applications that need to "
"operate at that level, they can be useful tools.  This documentation is also "
"relevant for applications that are still using the :mod:`~email.policy."
"compat32` API for backward compatibility reasons."
msgstr ""

#: ../Doc/library/email.rst:100
msgid ""
"Docs reorganized and rewritten to promote the new :class:`~email.message."
"EmailMessage`/:class:`~email.policy.EmailPolicy` API."
msgstr ""

#: ../Doc/library/email.rst:105
msgid "Contents of the :mod:`email` package documentation:"
msgstr ""

#: ../Doc/library/email.rst:120
msgid "Legacy API:"
msgstr ""

#: ../Doc/library/email.rst:136
msgid "Module :mod:`smtplib`"
msgstr ""

#: ../Doc/library/email.rst:136
msgid "SMTP (Simple Mail Transport Protocol) client"
msgstr ""

#: ../Doc/library/email.rst:139
msgid "Module :mod:`poplib`"
msgstr ""

#: ../Doc/library/email.rst:139
msgid "POP (Post Office Protocol) client"
msgstr ""

#: ../Doc/library/email.rst:142
msgid "Module :mod:`imaplib`"
msgstr ""

#: ../Doc/library/email.rst:142
msgid "IMAP (Internet Message Access Protocol) client"
msgstr ""

#: ../Doc/library/email.rst:145
msgid "Module :mod:`nntplib`"
msgstr ""

#: ../Doc/library/email.rst:145
msgid "NNTP (Net News Transport Protocol) client"
msgstr ""

#: ../Doc/library/email.rst:149
msgid "Module :mod:`mailbox`"
msgstr ""

#: ../Doc/library/email.rst:148
msgid ""
"Tools for creating, reading, and managing collections of messages on disk "
"using a variety standard formats."
msgstr ""

#: ../Doc/library/email.rst:151
msgid "Module :mod:`smtpd`"
msgstr ""

#: ../Doc/library/email.rst:152
msgid "SMTP server framework (primarily useful for testing)"
msgstr ""