[3.1.x] Used :mimetype: role in various docs.

Backport of feb91dbda1 from master

docs/internals/contributing/writing-documentation.txt

@@ -243,6 +243,9 @@ documentation:
   and try to link to the relevant section if possible. For example, use
   ``:pep:`20#easter-egg``` or ``:pep:`Easter Egg <20#easter-egg>```.
 
+* Use :rst:role:`:mimetype:<mimetype>` to refer to a MIME Type unless the value
+  is quoted for a code example.
+
 Django-specific markup
 ======================
 

docs/ref/request-response.txt

@@ -1040,7 +1040,7 @@ can create it with the help of :py:class:`http.HTTPStatus`. For example::
     response. It inherits most behavior from its superclass with a couple
     differences:
 
-    Its default ``Content-Type`` header is set to ``application/json``.
+    Its default ``Content-Type`` header is set to :mimetype:`application/json`.
 
     The first parameter, ``data``, should be a ``dict`` instance. If the
     ``safe`` parameter is set to ``False`` (see below) it can be any

docs/releases/1.11.txt

@@ -275,8 +275,8 @@ Email
   headers in the local time zone rather than in UTC.
 
 * ``EmailMessage.attach()`` and ``attach_file()`` now fall back to MIME type
-  ``application/octet-stream`` when binary content that can't be decoded as
-  UTF-8 is specified for a ``text/*`` attachment.
+  :mimetype:`application/octet-stream` when binary content that can't be
+  decoded as UTF-8 is specified for a :mimetype:`text/*` attachment.
 
 File Storage
 ~~~~~~~~~~~~

docs/releases/1.5.txt

@@ -424,11 +424,11 @@ Non-form data in HTTP requests
 :attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
 posted via HTTP requests with non form-specific content-types in the header.
 In prior versions, data posted with content-types other than
-``multipart/form-data`` or ``application/x-www-form-urlencoded`` would still
-end up represented in the :attr:`request.POST <django.http.HttpRequest.POST>`
-attribute. Developers wishing to access the raw POST data for these cases,
-should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
-instead.
+:mimetype:`multipart/form-data` or
+:mimetype:`application/x-www-form-urlencoded` would still end up represented in
+the :attr:`request.POST <django.http.HttpRequest.POST>` attribute. Developers
+wishing to access the raw POST data for these cases, should use the
+:attr:`request.body <django.http.HttpRequest.body>` attribute instead.
 
 :data:`~django.core.signals.request_finished` signal
 ----------------------------------------------------

docs/releases/1.7.txt

@@ -557,7 +557,9 @@ Email
 ~~~~~
 
 * :func:`~django.core.mail.send_mail` now accepts an ``html_message``
-  parameter for sending a multipart ``text/plain`` and ``text/html`` email.
+  parameter for sending a multipart :mimetype:`text/plain` and
+  :mimetype:`text/html` email.
+
 * The SMTP :class:`~django.core.mail.backends.smtp.EmailBackend` now accepts a
   ``timeout`` parameter.
 

docs/topics/auth/default.txt

@@ -1287,8 +1287,8 @@ implementation details see :ref:`using-the-views`.
       default context data passed to the template.
 
     * ``html_email_template_name``: The full name of a template to use
-      for generating a ``text/html`` multipart email with the password reset
-      link. By default, HTML email is not sent.
+      for generating a :mimetype:`text/html` multipart email with the password
+      reset link. By default, HTML email is not sent.
 
     * ``extra_email_context``: A dictionary of context data that will be
       available in the email template. It can be used to override default

docs/topics/email.txt

@@ -341,15 +341,16 @@ The class has the following methods:
 
        message.attach('design.png', img_data, 'image/png')
 
-    If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
-    :class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
+    If you specify a ``mimetype`` of :mimetype:`message/rfc822`, it will also
+    accept :class:`django.core.mail.EmailMessage` and
+    :py:class:`email.message.Message`.
 
-    For a ``mimetype`` starting with ``text/``, content is expected to be a
-    string. Binary data will be decoded using UTF-8, and if that fails, the
-    MIME type will be changed to ``application/octet-stream`` and the data will
-    be attached unchanged.
+    For a ``mimetype`` starting with :mimetype:`text/`, content is expected to
+    be a string. Binary data will be decoded using UTF-8, and if that fails,
+    the MIME type will be changed to :mimetype:`application/octet-stream` and
+    the data will be attached unchanged.
 
-    In addition, ``message/rfc822`` attachments will no longer be
+    In addition, :mimetype:`message/rfc822` attachments will no longer be
     base64-encoded in violation of :rfc:`2046#section-5.2.1`, which can cause
     issues with displaying the attachments in `Evolution`__ and `Thunderbird`__.
 
@@ -363,7 +364,7 @@ The class has the following methods:
 
     message.attach_file('/images/weather_map.png')
 
-  For MIME types starting with ``text/``, binary data is handled as in
+  For MIME types starting with :mimetype:`text/`, binary data is handled as in
   ``attach()``.
 
 Sending alternative content types