# SOME DESCRIPTIVE TITLE.
# Copyright (C) 1990-2016, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 2.7\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2016-10-30 10:44+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../Doc/library/email.parser.rst:2
msgid ":mod:`email.parser`: Parsing email messages"
msgstr ":mod:`email.parser` : Analyser des e-mails"

#: ../Doc/library/email.parser.rst:8
msgid ""
"Message object structures can be created in one of two ways: they can be "
"created from whole cloth by instantiating :class:`~email.message.Message` "
"objects and stringing them together via :meth:`~email.message.Message."
"attach` and :meth:`~email.message.Message.set_payload` calls, or they can be "
"created by parsing a flat text representation of the email message."
msgstr ""

#: ../Doc/library/email.parser.rst:14
msgid ""
"The :mod:`email` package provides a standard parser that understands most "
"email document structures, including MIME documents.  You can pass the "
"parser a string or a file object, and the parser will return to you the "
"root :class:`~email.message.Message` instance of the object structure.  For "
"simple, non-MIME messages the payload of this root object will likely be a "
"string containing the text of the message.  For MIME messages, the root "
"object will return ``True`` from its :meth:`~email.message.Message."
"is_multipart` method, and the subparts can be accessed via the :meth:`~email."
"message.Message.get_payload` and :meth:`~email.message.Message.walk` methods."
msgstr ""

#: ../Doc/library/email.parser.rst:24
msgid ""
"There are actually two parser interfaces available for use, the classic :"
"class:`Parser` API and the incremental :class:`FeedParser` API.  The "
"classic :class:`Parser` API is fine if you have the entire text of the "
"message in memory as a string, or if the entire message lives in a file on "
"the file system. :class:`FeedParser` is more appropriate for when you're "
"reading the message from a stream which might block waiting for more input "
"(e.g. reading an email message from a socket).  The :class:`FeedParser` can "
"consume and parse the message incrementally, and only returns the root "
"object when you close the parser [#]_."
msgstr ""

#: ../Doc/library/email.parser.rst:33
msgid ""
"Note that the parser can be extended in limited ways, and of course you can "
"implement your own parser completely from scratch.  There is no magical "
"connection between the :mod:`email` package's bundled parser and the :class:"
"`~email.message.Message` class, so your custom parser can create message "
"object trees any way it finds necessary."
msgstr ""

#: ../Doc/library/email.parser.rst:41
msgid "FeedParser API"
msgstr "API *FeedParser*"

#: ../Doc/library/email.parser.rst:45
msgid ""
"The :class:`FeedParser`, imported from the :mod:`email.feedparser` module, "
"provides an API that is conducive to incremental parsing of email messages, "
"such as would be necessary when reading the text of an email message from a "
"source that can block (e.g. a socket).  The :class:`FeedParser` can of "
"course be used to parse an email message fully contained in a string or a "
"file, but the classic :class:`Parser` API may be more convenient for such "
"use cases.  The semantics and results of the two parser APIs are identical."
msgstr ""

#: ../Doc/library/email.parser.rst:53
msgid ""
"The :class:`FeedParser`'s API is simple; you create an instance, feed it a "
"bunch of text until there's no more to feed it, then close the parser to "
"retrieve the root message object.  The :class:`FeedParser` is extremely "
"accurate when parsing standards-compliant messages, and it does a very good "
"job of parsing non-compliant messages, providing information about how a "
"message was deemed broken.  It will populate a message object's *defects* "
"attribute with a list of any problems it found in a message.  See the :mod:"
"`email.errors` module for the list of defects that it can find."
msgstr ""

#: ../Doc/library/email.parser.rst:62
msgid "Here is the API for the :class:`FeedParser`:"
msgstr ""

#: ../Doc/library/email.parser.rst:67
msgid ""
"Create a :class:`FeedParser` instance.  Optional *_factory* is a no-argument "
"callable that will be called whenever a new message object is needed.  It "
"defaults to the :class:`email.message.Message` class."
msgstr ""

#: ../Doc/library/email.parser.rst:74
msgid ""
"Feed the :class:`FeedParser` some more data.  *data* should be a string "
"containing one or more lines.  The lines can be partial and the :class:"
"`FeedParser` will stitch such partial lines together properly.  The lines in "
"the string can have any of the common three line endings, carriage return, "
"newline, or carriage return and newline (they can even be mixed)."
msgstr ""

#: ../Doc/library/email.parser.rst:84
msgid ""
"Closing a :class:`FeedParser` completes the parsing of all previously fed "
"data, and returns the root message object.  It is undefined what happens if "
"you feed more data to a closed :class:`FeedParser`."
msgstr ""

#: ../Doc/library/email.parser.rst:90
msgid "Parser class API"
msgstr ""

#: ../Doc/library/email.parser.rst:92
msgid ""
"The :class:`Parser` class, imported from the :mod:`email.parser` module, "
"provides an API that can be used to parse a message when the complete "
"contents of the message are available in a string or file.  The :mod:`email."
"parser` module also provides a second class, called :class:`HeaderParser` "
"which can be used if you're only interested in the headers of the message. :"
"class:`HeaderParser` can be much faster in these situations, since it does "
"not attempt to parse the message body, instead setting the payload to the "
"raw body as a string. :class:`HeaderParser` has the same API as the :class:"
"`Parser` class."
msgstr ""

#: ../Doc/library/email.parser.rst:105
msgid ""
"The constructor for the :class:`Parser` class takes an optional argument "
"*_class*.  This must be a callable factory (such as a function or a class), "
"and it is used whenever a sub-message object needs to be created.  It "
"defaults to :class:`~email.message.Message` (see :mod:`email.message`).  The "
"factory will be called without arguments."
msgstr ""

#: ../Doc/library/email.parser.rst:111
msgid "The optional *strict* flag is ignored."
msgstr ""

#: ../Doc/library/email.parser.rst:113
msgid ""
"Because the :class:`Parser` class is a backward compatible API wrapper "
"around the new-in-Python 2.4 :class:`FeedParser`, *all* parsing is "
"effectively non-strict.  You should simply stop passing a *strict* flag to "
"the :class:`Parser` constructor."
msgstr ""

#: ../Doc/library/email.parser.rst:119 ../Doc/library/email.parser.rst:173
#: ../Doc/library/email.parser.rst:183
msgid "The *strict* flag was added."
msgstr ""

#: ../Doc/library/email.parser.rst:122
msgid "The *strict* flag was deprecated."
msgstr ""

#: ../Doc/library/email.parser.rst:125
msgid "The other public :class:`Parser` methods are:"
msgstr ""

#: ../Doc/library/email.parser.rst:130
msgid ""
"Read all the data from the file-like object *fp*, parse the resulting text, "
"and return the root message object.  *fp* must support both the :meth:`~io."
"TextIOBase.readline` and the :meth:`~io.TextIOBase.read` methods on file-"
"like objects."
msgstr ""

#: ../Doc/library/email.parser.rst:135
msgid ""
"The text contained in *fp* must be formatted as a block of :rfc:`2822` style "
"headers and header continuation lines, optionally preceded by an envelope "
"header.  The header block is terminated either by the end of the data or by "
"a blank line.  Following the header block is the body of the message (which "
"may contain MIME-encoded subparts)."
msgstr ""

#: ../Doc/library/email.parser.rst:141
msgid ""
"Optional *headersonly* is a flag specifying whether to stop parsing after "
"reading the headers or not.  The default is ``False``, meaning it parses the "
"entire contents of the file."
msgstr ""

#: ../Doc/library/email.parser.rst:145 ../Doc/library/email.parser.rst:158
msgid "The *headersonly* flag was added."
msgstr ""

#: ../Doc/library/email.parser.rst:151
msgid ""
"Similar to the :meth:`parse` method, except it takes a string object instead "
"of a file-like object.  Calling this method on a string is exactly "
"equivalent to wrapping *text* in a :class:`~StringIO.StringIO` instance "
"first and calling :meth:`parse`."
msgstr ""

#: ../Doc/library/email.parser.rst:156
msgid "Optional *headersonly* is as with the :meth:`parse` method."
msgstr ""

#: ../Doc/library/email.parser.rst:161
msgid ""
"Since creating a message object structure from a string or a file object is "
"such a common task, two functions are provided as a convenience.  They are "
"available in the top-level :mod:`email` package namespace."
msgstr ""

#: ../Doc/library/email.parser.rst:169
msgid ""
"Return a message object structure from a string.  This is exactly equivalent "
"to ``Parser().parsestr(s)``.  Optional *_class* and *strict* are interpreted "
"as with the :class:`~email.parser.Parser` class constructor."
msgstr ""

#: ../Doc/library/email.parser.rst:179
msgid ""
"Return a message object structure tree from an open file object.  This is "
"exactly equivalent to ``Parser().parse(fp)``.  Optional *_class* and "
"*strict* are interpreted as with the :class:`~email.parser.Parser` class "
"constructor."
msgstr ""

#: ../Doc/library/email.parser.rst:186
msgid ""
"Here's an example of how you might use this at an interactive Python prompt::"
msgstr ""

#: ../Doc/library/email.parser.rst:193
msgid "Additional notes"
msgstr "Notes complémentaires"

#: ../Doc/library/email.parser.rst:195
msgid "Here are some notes on the parsing semantics:"
msgstr "Voici des remarques sur la sémantique d'analyse : ::"

#: ../Doc/library/email.parser.rst:197
msgid ""
"Most non-\\ :mimetype:`multipart` type messages are parsed as a single "
"message object with a string payload.  These objects will return ``False`` "
"for :meth:`~email.message.Message.is_multipart`.  Their :meth:`~email."
"message.Message.get_payload` method will return a string object."
msgstr ""

#: ../Doc/library/email.parser.rst:202
msgid ""
"All :mimetype:`multipart` type messages will be parsed as a container "
"message object with a list of sub-message objects for their payload.  The "
"outer container message will return ``True`` for :meth:`~email.message."
"Message.is_multipart` and their :meth:`~email.message.Message.get_payload` "
"method will return the list of :class:`~email.message.Message` subparts."
msgstr ""

#: ../Doc/library/email.parser.rst:209
msgid ""
"Most messages with a content type of :mimetype:`message/\\*` (e.g. :mimetype:"
"`message/delivery-status` and :mimetype:`message/rfc822`) will also be "
"parsed as container object containing a list payload of length 1.  Their :"
"meth:`~email.message.Message.is_multipart` method will return ``True``. The "
"single element in the list payload will be a sub-message object."
msgstr ""

#: ../Doc/library/email.parser.rst:215
msgid ""
"Some non-standards compliant messages may not be internally consistent about "
"their :mimetype:`multipart`\\ -edness.  Such messages may have a :mailheader:"
"`Content-Type` header of type :mimetype:`multipart`, but their :meth:`~email."
"message.Message.is_multipart` method may return ``False``. If such messages "
"were parsed with the :class:`~email.parser.FeedParser`, they will have an "
"instance of the :class:`~email.errors.MultipartInvariantViolationDefect` "
"class in their *defects* attribute list.  See :mod:`email.errors` for "
"details."
msgstr ""

#: ../Doc/library/email.parser.rst:225
msgid "Footnotes"
msgstr "Notes"

#: ../Doc/library/email.parser.rst:226
msgid ""
"As of email package version 3.0, introduced in Python 2.4, the classic :"
"class:`~email.parser.Parser` was re-implemented in terms of the :class:"
"`~email.parser.FeedParser`, so the semantics and results are identical "
"between the two parsers."
msgstr ""