Fixed #26124 -- Added missing code formatting to docs headers.

32 files changed, 202 insertions, 203 deletions

diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index 3da3cc6970..a1f99f9140 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -289,8 +289,8 @@ example, the following checks if a user may view tasks::
 
 .. _extending-user:
 
-Extending the existing User model
-=================================
+Extending the existing ``User`` model
+=====================================
 
 There are two ways to extend the default
 :class:`~django.contrib.auth.models.User` model without substituting your own
@@ -360,8 +360,8 @@ the extra database load.
 
 .. _auth-custom-user:
 
-Substituting a custom User model
-================================
+Substituting a custom ``User`` model
+====================================
 
 Some kinds of projects may have authentication requirements for which Django's
 built-in :class:`~django.contrib.auth.models.User` model is not always
@@ -414,8 +414,8 @@ use as your User model.
    :class:`~django.db.models.OneToOneField` to ``settings.AUTH_USER_MODEL``
    as described below.
 
-Referencing the User model
---------------------------
+Referencing the ``User`` model
+------------------------------
 
 .. currentmodule:: django.contrib.auth
 
@@ -462,8 +462,8 @@ different User model.
 
 .. _specifying-custom-user-model:
 
-Specifying a custom User model
-------------------------------
+Specifying a custom ``User`` model
+----------------------------------
 
 .. admonition:: Model design considerations
 
@@ -716,8 +716,8 @@ utility methods:
         * ``o``, ``O``, and ``0`` (lowercase letter o, uppercase letter o,
           and zero)
 
-Extending Django's default User
--------------------------------
+Extending Django's default ``User``
+-----------------------------------
 
 If you're entirely happy with Django's :class:`~django.contrib.auth.models.User`
 model and you just want to add some additional profile information, you could
@@ -875,16 +875,16 @@ methods and attributes:
         (the Django app label). If the user is inactive, this method will
         always return ``False``.
 
-.. admonition:: ModelBackend
+.. admonition:: ``PermissionsMixin`` and ``ModelBackend``
 
     If you don't include the
     :class:`~django.contrib.auth.models.PermissionsMixin`, you must ensure you
     don't invoke the permissions methods on ``ModelBackend``. ``ModelBackend``
-    assumes that certain fields are available on your user model. If your User
-    model doesn't provide  those fields, you will receive database errors when
-    you check permissions.
+    assumes that certain fields are available on your user model. If your
+    ``User`` model doesn't provide  those fields, you will receive database
+    errors when you check permissions.
 
-Custom users and Proxy models
+Custom users and proxy models
 -----------------------------
 
 One limitation of custom User models is that installing a custom User model
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index e59f0318cc..5b6472f7a3 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -17,8 +17,8 @@ are somewhat coupled.
 
 .. _user-objects:
 
-User objects
-============
+``User`` objects
+================
 
 :class:`~django.contrib.auth.models.User` objects are the core of the
 authentication system. They typically represent the people interacting with
@@ -112,7 +112,7 @@ passwords.
 Changing a user's password will log out all their sessions. See
 :ref:`session-invalidation-on-password-change` for details.
 
-Authenticating Users
+Authenticating users
 --------------------
 
 .. function:: authenticate(\**credentials)
@@ -363,13 +363,14 @@ If you have an authenticated user you want to attach to the current session
         :func:`~django.contrib.auth.login()`. Now you can set the backend using
         the new ``backend`` argument.
 
-Selecting the :ref:`authentication backend <authentication-backends>`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Selecting the authentication backend
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When a user logs in, the user's ID and the backend that was used for
 authentication are saved in the user's session. This allows the same
-authentication backend to fetch the user's details on a future request. The
-authentication backend to save in the session is selected as follows:
+:ref:`authentication backend <authentication-backends>` to fetch the user's
+details on a future request. The authentication backend to save in the session
+is selected as follows:
 
 #. Use the value of the optional ``backend`` argument, if provided.
 #. Use the value of the ``user.backend`` attribute, if present. This allows
@@ -1673,7 +1674,7 @@ model. Groups can be created, and permissions can be assigned to users or
 groups. A log of user edits to models made within the admin is also stored and
 displayed.
 
-Creating Users
+Creating users
 --------------
 
 You should see a link to "Users" in the "Auth"
@@ -1695,7 +1696,7 @@ non-superuser the ability to edit users, this is ultimately the same as giving
 them superuser status because they will be able to elevate permissions of
 users including themselves!
 
-Changing Passwords
+Changing passwords
 ------------------
 
 User passwords are not displayed in the admin (nor stored in the database), but
diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt
index 944c81408e..ef14f7f330 100644
--- a/docs/topics/auth/passwords.txt
+++ b/docs/topics/auth/passwords.txt
@@ -74,8 +74,8 @@ setting.
 
 .. _bcrypt_usage:
 
-Using bcrypt with Django
-------------------------
+Using ``bcrypt`` with Django
+----------------------------
 
 Bcrypt_ is a popular password storage algorithm that's specifically designed
 for long-term password storage. It's not the default used by Django since it
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index fc0d81abe1..4cfffeeecf 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -1049,8 +1049,8 @@ pages. We'll look at some of these headers in the sections that follow.
 
 .. _using-vary-headers:
 
-Using Vary headers
-==================
+Using ``Vary`` headers
+======================
 
 The ``Vary`` header defines which request headers a cache
 mechanism should take into account when building its cache key. For example, if
@@ -1231,8 +1231,8 @@ Example::
 
 .. _`Cache-Control spec`: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
 
-Order of MIDDLEWARE_CLASSES
-===========================
+Order of ``MIDDLEWARE_CLASSES``
+===============================
 
 If you use caching middleware, it's important to put each half in the right
 place within the :setting:`MIDDLEWARE_CLASSES` setting. That's because the cache
diff --git a/docs/topics/checks.txt b/docs/topics/checks.txt
index b0074891db..9311475e6a 100644
--- a/docs/topics/checks.txt
+++ b/docs/topics/checks.txt
@@ -120,7 +120,7 @@ The code below is equivalent to the code above::
 
 .. _field-checking:
 
-Field, Model, and Manager checks
+Field, model, and manager checks
 --------------------------------
 
 In some cases, you won't need to register your check function -- you can
@@ -185,7 +185,7 @@ the only difference is that the check is a classmethod, not an instance method::
             # ... your own checks ...
             return errors
 
-Writing Tests
+Writing tests
 -------------
 
 Messages are comparable. That allows you to easily write tests::
diff --git a/docs/topics/class-based-views/generic-editing.txt b/docs/topics/class-based-views/generic-editing.txt
index 0a1cd06961..6cc83ef563 100644
--- a/docs/topics/class-based-views/generic-editing.txt
+++ b/docs/topics/class-based-views/generic-editing.txt
@@ -13,7 +13,7 @@ Implementing this yourself often results in a lot of repeated boilerplate code
 this, Django provides a collection of generic class-based views for form
 processing.
 
-Basic Forms
+Basic forms
 ===========
 
 Given a simple contact form:
@@ -60,7 +60,7 @@ Notes:
   :meth:`~django.views.generic.edit.FormMixin.form_valid` simply
   redirects to the :attr:`~django.views.generic.edit.FormMixin.success_url`.
 
-Model Forms
+Model forms
 ===========
 
 Generic views really shine when working with models.  These generic
@@ -180,8 +180,8 @@ Finally, we hook these new views into the URLconf:
     :attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
     on your view class.
 
-Models and request.user
-=======================
+Models and ``request.user``
+===========================
 
 To track the user that created an object using a :class:`CreateView`,
 you can use a custom :class:`~django.forms.ModelForm` to do this. First, add
diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index 07b2eda2bc..e53a8599e4 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -86,8 +86,8 @@ date-based generic views. These are
 covered in the :doc:`mixin reference
 documentation</ref/class-based-views/mixins>`.
 
-DetailView: working with a single Django object
------------------------------------------------
+``DetailView``: working with a single Django object
+---------------------------------------------------
 
 To show the detail of an object, we basically need to do two things:
 we need to look up the object and then we need to make a
@@ -124,8 +124,8 @@ on a subclass to something else. (For instance, the :doc:`generic edit
 views<generic-editing>` use ``_form`` for create and update views, and
 ``_confirm_delete`` for delete views.)
 
-ListView: working with many Django objects
-------------------------------------------
+``ListView``: working with many Django objects
+----------------------------------------------
 
 Lists of objects follow roughly the same pattern: we need a (possibly
 paginated) list of objects, typically a
@@ -208,8 +208,8 @@ the box.
 
 .. _method resolution order: https://www.python.org/download/releases/2.3/mro/
 
-Using SingleObjectMixin with View
----------------------------------
+Using ``SingleObjectMixin`` with View
+-------------------------------------
 
 If we want to write a simple class-based view that responds only to
 ``POST``, we'll subclass :class:`~django.views.generic.base.View` and
@@ -271,8 +271,8 @@ to look up the ``Author`` instance. You could also use a slug, or
 any of the other features of
 :class:`~django.views.generic.detail.SingleObjectMixin`.
 
-Using SingleObjectMixin with ListView
--------------------------------------
+Using ``SingleObjectMixin`` with ``ListView``
+---------------------------------------------
 
 :class:`~django.views.generic.list.ListView` provides built-in
 pagination, but you might want to paginate a list of objects that are
@@ -404,8 +404,8 @@ is a simpler solution. First, let's look at a naive attempt to combine
 ``POST`` a Django :class:`~django.forms.Form` to the same URL as we're
 displaying an object using :class:`DetailView`.
 
-Using FormMixin with DetailView
--------------------------------
+Using ``FormMixin`` with ``DetailView``
+---------------------------------------
 
 Think back to our earlier example of using :class:`View` and
 :class:`~django.views.generic.detail.SingleObjectMixin` together. We were
diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt
index 4838663beb..bee6cc5168 100644
--- a/docs/topics/db/aggregation.txt
+++ b/docs/topics/db/aggregation.txt
@@ -88,8 +88,8 @@ In a hurry? Here's how to do common aggregate queries, assuming the models above
     >>> pubs[0].num_books
     1323
 
-Generating aggregates over a QuerySet
-=====================================
+Generating aggregates over a ``QuerySet``
+=========================================
 
 Django provides two ways to generate aggregates. The first way is to generate
 summary values over an entire ``QuerySet``. For example, say you wanted to
@@ -134,8 +134,8 @@ the maximum and minimum price of all books, we would issue the query::
     >>> Book.objects.aggregate(Avg('price'), Max('price'), Min('price'))
     {'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}
 
-Generating aggregates for each item in a QuerySet
-=================================================
+Generating aggregates for each item in a ``QuerySet``
+=====================================================
 
 The second way to generate summary values is to generate an independent
 summary for each object in a ``QuerySet``. For example, if you are retrieving
@@ -297,8 +297,8 @@ file::
 (The resulting dictionary will have a key called ``'average__rating'``. If no
 such alias were specified, it would be the rather long ``'book__rating__avg'``.)
 
-Aggregations and other QuerySet clauses
-=======================================
+Aggregations and other ``QuerySet`` clauses
+===========================================
 
 ``filter()`` and ``exclude()``
 ------------------------------
diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index 0d68ad7e0a..a82b78e1a0 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -37,7 +37,7 @@ of all ``Person`` objects.
 
 .. _custom-managers:
 
-Custom Managers
+Custom managers
 ===============
 
 You can use a custom ``Manager`` in a particular model by extending the base
@@ -47,7 +47,7 @@ There are two reasons you might want to customize a ``Manager``: to add extra
 ``Manager`` methods, and/or to modify the initial ``QuerySet`` the ``Manager``
 returns.
 
-Adding extra Manager methods
+Adding extra manager methods
 ----------------------------
 
 Adding extra ``Manager`` methods is the preferred way to add "table-level"
@@ -97,8 +97,8 @@ that list of ``OpinionPoll`` objects with ``num_responses`` attributes.
 Another thing to note about this example is that ``Manager`` methods can
 access ``self.model`` to get the model class to which they're attached.
 
-Modifying initial Manager QuerySets
------------------------------------
+Modifying a manager's initial ``QuerySet``
+------------------------------------------
 
 A ``Manager``’s base ``QuerySet`` returns all objects in the system. For
 example, using this model::
@@ -204,8 +204,8 @@ attribute on the manager class. This is documented fully below_.
 
 .. _calling-custom-queryset-methods-from-manager:
 
-Calling custom ``QuerySet`` methods from the ``Manager``
---------------------------------------------------------
+Calling custom ``QuerySet`` methods from the manager
+----------------------------------------------------
 
 While most methods from the standard ``QuerySet`` are accessible directly from
 the ``Manager``, this is only the case for the extra methods defined on a
@@ -239,8 +239,8 @@ the manager ``Person.people``.
 
 .. _create-manager-with-queryset-methods:
 
-Creating ``Manager`` with ``QuerySet`` methods
-----------------------------------------------
+Creating a manager with ``QuerySet`` methods
+--------------------------------------------
 
 In lieu of the above approach which requires duplicating methods on both the
 ``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
@@ -288,8 +288,8 @@ For example::
             return
         _opted_in_private_method.queryset_only = False
 
-from_queryset
-~~~~~~~~~~~~~
+``from_queryset()``
+~~~~~~~~~~~~~~~~~~~
 
 .. classmethod:: from_queryset(queryset_class)
 
@@ -438,7 +438,7 @@ be copied.
 
 .. _manager-types:
 
-Controlling automatic Manager types
+Controlling automatic manager types
 ===================================
 
 This document has already mentioned a couple of places where Django creates a
@@ -484,7 +484,7 @@ it will use :class:`django.db.models.Manager`.
     so that existing code will :doc:`continue to work </misc/api-stability>` in
     future Django versions.
 
-Writing correct Managers for use in automatic Manager instances
+Writing correct managers for use in automatic manager instances
 ---------------------------------------------------------------
 
 The ``use_for_related_fields`` feature is primarily for managers that need to
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
index 05b8bfcad9..45fc6360e4 100644
--- a/docs/topics/db/models.txt
+++ b/docs/topics/db/models.txt
@@ -686,8 +686,8 @@ provided in :doc:`/howto/custom-model-fields`.
 
 .. _meta-options:
 
-Meta options
-============
+``Meta`` options
+================
 
 Give your model metadata by using an inner ``class Meta``, like so::
 
@@ -1215,8 +1215,8 @@ order by the ``last_name`` attribute when you use the proxy. This is easy::
 Now normal ``Person`` queries will be unordered
 and ``OrderedPerson`` queries will be ordered by ``last_name``.
 
-QuerySets still return the model that was requested
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+``QuerySet``\s still return the model that was requested
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 There is no way to have Django return, say, a ``MyPerson`` object whenever you
 query for ``Person`` objects. A queryset for ``Person`` objects will return
diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt
index f8e031657c..788e447050 100644
--- a/docs/topics/db/optimization.txt
+++ b/docs/topics/db/optimization.txt
@@ -58,14 +58,14 @@ work. This document also does not address other optimization techniques that
 apply to all expensive operations, such as :doc:`general purpose caching
 </topics/cache>`.
 
-Understand QuerySets
-====================
+Understand ``QuerySet``\s
+=========================
 
 Understanding :doc:`QuerySets </ref/models/querysets>` is vital to getting good
 performance with simple code. In particular:
 
-Understand QuerySet evaluation
-------------------------------
+Understand ``QuerySet`` evaluation
+----------------------------------
 
 To avoid performance problems, it is important to understand:
 
@@ -232,13 +232,13 @@ are most useful when you can avoid loading a lot of text data or for fields
 that might take a lot of processing to convert back to Python. As always,
 profile first, then optimize.
 
-Use QuerySet.count()
---------------------
+Use ``QuerySet.count()``
+------------------------
 
 ...if you only want the count, rather than doing ``len(queryset)``.
 
-Use QuerySet.exists()
----------------------
+Use ``QuerySet.exists()``
+-------------------------
 
 ...if you only want to find out if at least one result exists, rather than ``if
 queryset``.
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index b61f16ffbe..ab58bb4f63 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -239,8 +239,8 @@ January 30, 2005, and the current day.
 
 .. _filtered-querysets-are-unique:
 
-Filtered QuerySets are unique
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Filtered ``QuerySet``\s are unique
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Each time you refine a :class:`~django.db.models.query.QuerySet`, you get a
 brand-new :class:`~django.db.models.query.QuerySet` that is in no way bound to
@@ -265,8 +265,8 @@ refinement process.
 
 .. _querysets-are-lazy:
 
-QuerySets are lazy
-~~~~~~~~~~~~~~~~~~
+``QuerySet``\s are lazy
+~~~~~~~~~~~~~~~~~~~~~~~
 
 ``QuerySets`` are lazy -- the act of creating a
 :class:`~django.db.models.query.QuerySet` doesn't involve any database
@@ -287,11 +287,10 @@ until you "ask" for them. When you do, the
 database. For more details on exactly when evaluation takes place, see
 :ref:`when-querysets-are-evaluated`.
 
-
 .. _retrieving-single-object-with-get:
 
-Retrieving a single object with get
------------------------------------
+Retrieving a single object with ``get()``
+-----------------------------------------
 
 :meth:`~django.db.models.query.QuerySet.filter` will always give you a
 :class:`~django.db.models.query.QuerySet`, even if only a single object matches
@@ -324,8 +323,8 @@ Similarly, Django will complain if more than one item matches the
 attribute of the model class itself.
 
 
-Other QuerySet methods
-----------------------
+Other ``QuerySet`` methods
+--------------------------
 
 Most of the time you'll use :meth:`~django.db.models.query.QuerySet.all`,
 :meth:`~django.db.models.query.QuerySet.get`,
@@ -337,8 +336,8 @@ various :class:`~django.db.models.query.QuerySet` methods.
 
 .. _limiting-querysets:
 
-Limiting QuerySets
-------------------
+Limiting ``QuerySet``\s
+-----------------------
 
 Use a subset of Python's array-slicing syntax to limit your
 :class:`~django.db.models.query.QuerySet` to a certain number of results. This
@@ -663,8 +662,8 @@ The ``F()`` objects support bitwise operations by ``.bitand()`` and
 
     >>> F('somefield').bitand(16)
 
-The pk lookup shortcut
-----------------------
+The ``pk`` lookup shortcut
+--------------------------
 
 For convenience, Django provides a ``pk`` lookup shortcut, which stands for
 "primary key".
@@ -692,8 +691,8 @@ equivalent::
     >>> Entry.objects.filter(blog__id=3)        # __exact is implied
     >>> Entry.objects.filter(blog__pk=3)        # __pk implies __id__exact
 
-Escaping percent signs and underscores in LIKE statements
----------------------------------------------------------
+Escaping percent signs and underscores in ``LIKE`` statements
+-------------------------------------------------------------
 
 The field lookups that equate to ``LIKE`` SQL statements (``iexact``,
 ``contains``, ``icontains``, ``startswith``, ``istartswith``, ``endswith``
@@ -720,8 +719,8 @@ for you transparently.
 
 .. _caching-and-querysets:
 
-Caching and QuerySets
----------------------
+Caching and ``QuerySet``\s
+--------------------------
 
 Each :class:`~django.db.models.query.QuerySet` contains a cache to minimize
 database access. Understanding how it works will allow you to write the most
@@ -756,8 +755,8 @@ To avoid this problem, simply save the
     >>> print([p.headline for p in queryset]) # Evaluate the query set.
     >>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation.
 
-When querysets are not cached
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+When ``QuerySet``\s are not cached
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Querysets do not always cache their results.  When evaluating only *part* of
 the queryset, the cache is checked, but if it is not populated then the items
@@ -795,8 +794,8 @@ being evaluated and therefore populate the cache::
 
 .. _complex-lookups-with-q:
 
-Complex lookups with Q objects
-==============================
+Complex lookups with ``Q`` objects
+==================================
 
 Keyword argument queries -- in :meth:`~django.db.models.query.QuerySet.filter`,
 etc. -- are "AND"ed together. If you need to execute more complex queries (for
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
index 96cddff407..2b22d3e538 100644
--- a/docs/topics/email.txt
+++ b/docs/topics/email.txt
@@ -35,8 +35,8 @@ a secure connection is used.
     The character set of email sent with ``django.core.mail`` will be set to
     the value of your :setting:`DEFAULT_CHARSET` setting.
 
-send_mail()
-===========
+``send_mail()``
+===============
 
 .. function:: send_mail(subject, message, from_email, recipient_list, fail_silently=False, auth_user=None, auth_password=None, connection=None, html_message=None)
 
@@ -74,8 +74,8 @@ are required.
 The return value will be the number of successfully delivered messages (which
 can be ``0`` or ``1`` since it can only send one message).
 
-send_mass_mail()
-================
+``send_mass_mail()``
+====================
 
 .. function:: send_mass_mail(datatuple, fail_silently=False, auth_user=None, auth_password=None, connection=None)
 
@@ -103,8 +103,8 @@ mail server would be opened::
 
 The return value will be the number of successfully delivered messages.
 
-send_mass_mail() vs. send_mail()
---------------------------------
+``send_mass_mail()`` vs. ``send_mail()``
+----------------------------------------
 
 The main difference between :meth:`~django.core.mail.send_mass_mail()` and
 :meth:`~django.core.mail.send_mail()` is that
@@ -113,8 +113,8 @@ each time it's executed, while :meth:`~django.core.mail.send_mass_mail()` uses
 a single connection for all of its messages. This makes
 :meth:`~django.core.mail.send_mass_mail()` slightly more efficient.
 
-mail_admins()
-=============
+``mail_admins()``
+=================
 
 .. function:: mail_admins(subject, message, fail_silently=False, connection=None, html_message=None)
 
@@ -134,8 +134,8 @@ If ``html_message`` is provided, the resulting email will be a
 :mimetype:`text/plain` content type and ``html_message`` as the
 :mimetype:`text/html` content type.
 
-mail_managers()
-===============
+``mail_managers()``
+===================
 
 .. function:: mail_managers(subject, message, fail_silently=False, connection=None, html_message=None)
 
@@ -205,8 +205,8 @@ from the request's POST data, sends that to admin@example.com and redirects to
 
 .. _emailmessage-and-smtpconnection:
 
-The EmailMessage class
-======================
+The ``EmailMessage`` class
+==========================
 
 Django's :meth:`~django.core.mail.send_mail()` and
 :meth:`~django.core.mail.send_mass_mail()` functions are actually thin
@@ -235,8 +235,8 @@ For convenience, :class:`~django.core.mail.EmailMessage` provides a simple
 messages, the email backend API :ref:`provides an alternative
 <topics-sending-multiple-emails>`.
 
-EmailMessage Objects
---------------------
+``EmailMessage`` Objects
+------------------------
 
 .. class:: EmailMessage
 
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 1871c223ac..8aa3f67b2a 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -193,8 +193,8 @@ sent without any data)::
 
 .. _understanding-the-managementform:
 
-Understanding the ManagementForm
---------------------------------
+Understanding the ``ManagementForm``
+------------------------------------
 
 You may have noticed the additional data (``form-TOTAL_FORMS``,
 ``form-INITIAL_FORMS`` and ``form-MAX_NUM_FORMS``) that was required
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index 978e9df83b..b5ebbc94ce 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -793,8 +793,8 @@ instances of the model, you can specify an empty QuerySet::
 
    >>> AuthorFormSet(queryset=Author.objects.none())
 
-Changing the ``form``
----------------------
+Changing the form
+-----------------
 
 By default, when you use ``modelformset_factory``, a model form will
 be created using :func:`~django.forms.models.modelform_factory`.
diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index 7ffaa9fc32..e84aafa123 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -85,8 +85,8 @@ Python class that defines one or more of the following methods:
 
 .. _request-middleware:
 
-``process_request``
--------------------
+``process_request()``
+---------------------
 
 .. method:: process_request(request)
 
@@ -106,8 +106,8 @@ return the result.
 
 .. _view-middleware:
 
-``process_view``
-----------------
+``process_view()``
+------------------
 
 .. method:: process_view(request, view_func, view_args, view_kwargs)
 
@@ -145,8 +145,8 @@ view; it'll apply response middleware to that
 
 .. _template-response-middleware:
 
-``process_template_response``
------------------------------
+``process_template_response()``
+-------------------------------
 
 .. method:: process_template_response(request, response)
 
@@ -172,8 +172,8 @@ includes ``process_template_response()``.
 
 .. _response-middleware:
 
-``process_response``
---------------------
+``process_response()``
+----------------------
 
 .. method:: process_response(request, response)
 
@@ -229,8 +229,8 @@ must test for streaming responses and adjust their behavior accordingly::
 
 .. _exception-middleware:
 
-``process_exception``
----------------------
+``process_exception()``
+-----------------------
 
 .. method:: process_exception(request, exception)
 
@@ -248,8 +248,8 @@ Again, middleware are run in reverse order during the response phase, which
 includes ``process_exception``. If an exception middleware returns a response,
 the middleware classes above that middleware will not be called at all.
 
-``__init__``
-------------
+``__init__()``
+--------------
 
 Most middleware classes won't need an initializer since middleware classes are
 essentially placeholders for the ``process_*`` methods. If you do need some
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 5dc1bef043..5e7bd74d2b 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -329,7 +329,7 @@ easily available on the internet. Although the cookie session storage signs the
 cookie-stored data to prevent tampering, a :setting:`SECRET_KEY` leak
 immediately escalates to a remote code execution vulnerability.
 
-Bundled Serializers
+Bundled serializers
 ~~~~~~~~~~~~~~~~~~~
 
 .. class:: serializers.JSONSerializer
@@ -359,7 +359,7 @@ Bundled Serializers
 
 .. _custom-serializers:
 
-Write Your Own Serializer
+Write your own serializer
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Note that unlike :class:`~django.contrib.sessions.serializers.PickleSerializer`,
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 7faef87766..af2da254fb 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -12,8 +12,8 @@ The package ``django.shortcuts`` collects helper functions and classes that
 "span" multiple levels of MVC. In other words, these functions/classes
 introduce controlled coupling for convenience's sake.
 
-``render``
-==========
+``render()``
+============
 
 .. function:: render(request, template_name, context=None, content_type=None, status=None, using=None)
 
@@ -81,8 +81,8 @@ This example is equivalent to::
         return HttpResponse(t.render(c, request),
             content_type="application/xhtml+xml")
 
-``render_to_response``
-======================
+``render_to_response()``
+========================
 
 .. function:: render_to_response(template_name, context=None, content_type=None, status=None, using=None)
 
@@ -90,8 +90,8 @@ This example is equivalent to::
    similarly except that it doesn't make the ``request`` available in the
    response. It's not recommended and is likely to be deprecated in the future.
 
-``redirect``
-============
+``redirect()``
+==============
 
 .. function:: redirect(to, permanent=False, *args, **kwargs)
 
@@ -157,8 +157,8 @@ will be returned::
         object = MyModel.objects.get(...)
         return redirect(object, permanent=True)
 
-``get_object_or_404``
-=====================
+``get_object_or_404()``
+=======================
 
 .. function:: get_object_or_404(klass, *args, **kwargs)
 
@@ -230,8 +230,8 @@ Note: As with ``get()``, a
 :class:`~django.core.exceptions.MultipleObjectsReturned` exception
 will be raised if more than one object is found.
 
-``get_list_or_404``
-===================
+``get_list_or_404()``
+=====================
 
 .. function:: get_list_or_404(klass, *args, **kwargs)
 
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index 068b91bf60..5555a4a1ab 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -234,8 +234,8 @@ Performance
 Each regular expression in a ``urlpatterns`` is compiled the first time it's
 accessed. This makes the system blazingly fast.
 
-Syntax of the urlpatterns variable
-==================================
+Syntax of the ``urlpatterns`` variable
+======================================
 
 ``urlpatterns`` should be a Python list of :func:`~django.conf.urls.url`
 instances.
diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index c21012fa64..020c06e090 100644
--- a/docs/topics/http/views.txt
+++ b/docs/topics/http/views.txt
@@ -94,8 +94,8 @@ to create a return class for any status code you like. For example::
 Because 404 errors are by far the most common HTTP error, there's an easier way
 to handle those errors.
 
-The Http404 exception
----------------------
+The ``Http404`` exception
+-------------------------
 
 .. class:: django.http.Http404()
 
diff --git a/docs/topics/i18n/formatting.txt b/docs/topics/i18n/formatting.txt
index a9f5da66d7..248d6b0d23 100644
--- a/docs/topics/i18n/formatting.txt
+++ b/docs/topics/i18n/formatting.txt
@@ -76,8 +76,8 @@ Template tags
 
 .. templatetag:: localize
 
-localize
-~~~~~~~~
+``localize``
+~~~~~~~~~~~~
 
 Enables or disables localization of template variables in the
 contained block.
@@ -110,8 +110,8 @@ Template filters
 
 .. templatefilter:: localize
 
-localize
-~~~~~~~~
+``localize``
+~~~~~~~~~~~~
 
 Forces localization of a single value.
 
@@ -125,11 +125,10 @@ To disable localization on a single value, use :tfilter:`unlocalize`. To control
 localization over a large section of a template, use the :ttag:`localize` template
 tag.
 
-
 .. templatefilter:: unlocalize
 
-unlocalize
-~~~~~~~~~~
+``unlocalize``
+~~~~~~~~~~~~~~
 
 Forces a single value to be printed without localization.
 
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index 2adfd48267..8ea63f2908 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -257,8 +257,8 @@ Template tags
 
 .. templatetag:: localtime
 
-localtime
-~~~~~~~~~
+``localtime``
+~~~~~~~~~~~~~
 
 Enables or disables conversion of aware datetime objects to the current time
 zone in the contained block.
@@ -286,8 +286,8 @@ To activate or deactivate conversion for a template block, use::
 
 .. templatetag:: timezone
 
-timezone
-~~~~~~~~
+``timezone``
+~~~~~~~~~~~~
 
 Sets or unsets the current time zone in the contained block. When the current
 time zone is unset, the default time zone applies.
@@ -306,8 +306,8 @@ time zone is unset, the default time zone applies.
 
 .. templatetag:: get_current_timezone
 
-get_current_timezone
-~~~~~~~~~~~~~~~~~~~~
+``get_current_timezone``
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 You can get the name of the current time zone using the
 ``get_current_timezone`` tag::
@@ -327,8 +327,8 @@ return aware datetimes.
 
 .. templatefilter:: localtime
 
-localtime
-~~~~~~~~~
+``localtime``
+~~~~~~~~~~~~~
 
 Forces conversion of a single value to the current time zone.
 
@@ -340,8 +340,8 @@ For example::
 
 .. templatefilter:: utc
 
-utc
-~~~
+``utc``
+~~~~~~~
 
 Forces conversion of a single value to UTC.
 
@@ -353,8 +353,8 @@ For example::
 
 .. templatefilter:: timezone
 
-timezone
-~~~~~~~~
+``timezone``
+~~~~~~~~~~~~
 
 Forces conversion of a single value to an arbitrary timezone.
 
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 842003e6d6..df0b891fc2 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -477,8 +477,8 @@ directly with the ``number`` argument::
                 raise forms.ValidationError(self.error_message % number)
 
 
-Joining strings: string_concat()
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Joining strings: ``string_concat()``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Standard Python string joins (``''.join([...])``) will not work on lists
 containing lazy translation objects. Instead, you can use
diff --git a/docs/topics/install.txt b/docs/topics/install.txt
index b5195bea57..fcfd3a89af 100644
--- a/docs/topics/install.txt
+++ b/docs/topics/install.txt
@@ -25,8 +25,8 @@ your operating system's package manager.
     If you are just starting with Django and using Windows, you may find
     :doc:`/howto/windows` useful.
 
-Install Apache and mod_wsgi
-=============================
+Install Apache and ``mod_wsgi``
+===============================
 
 If you just want to experiment with Django, skip ahead to the next
 section; Django includes a lightweight web server you can use for
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index ec560941ae..e4a69c3d16 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -692,8 +692,8 @@ the main module body, rather than the class body.
 
 .. _custom-deconstruct-method:
 
-Adding a deconstruct() method
------------------------------
+Adding a ``deconstruct()`` method
+---------------------------------
 
 You can let Django serialize your own custom class instances by giving the class
 a ``deconstruct()`` method. It takes no arguments, and should return a tuple
diff --git a/docs/topics/performance.txt b/docs/topics/performance.txt
index bfed5969ef..76373f126f 100644
--- a/docs/topics/performance.txt
+++ b/docs/topics/performance.txt
@@ -232,8 +232,8 @@ until it's strictly required.
 Databases
 =========
 
-:doc:`Database optimization </topics/db/optimization>`
-------------------------------------------------------
+Database optimization
+---------------------
 
 Django’s database layer provides various ways to help developers get the best
 performance from their databases. The :doc:`database optimization documentation
diff --git a/docs/topics/python3.txt b/docs/topics/python3.txt
index bac69d785a..003dd0ebc5 100644
--- a/docs/topics/python3.txt
+++ b/docs/topics/python3.txt
@@ -131,8 +131,8 @@ and ``SafeText`` respectively.
 
 For forwards compatibility, the new names work as of Django 1.4.2.
 
-:meth:`~object.__str__` and ` __unicode__()`_ methods
------------------------------------------------------
+``__str__()`` and ``__unicode__()`` methods
+-------------------------------------------
 
 In Python 2, the object model specifies :meth:`~object.__str__` and
 ` __unicode__()`_ methods. If these methods exist, they must return
@@ -370,8 +370,8 @@ Some modules were renamed in Python 3. The ``django.utils.six.moves``
 module (based on the :mod:`six.moves module <six.moves>`) provides a
 compatible location to import them.
 
-PY2
-~~~
+``PY2``
+~~~~~~~
 
 If you need different code in Python 2 and Python 3, check :data:`six.PY2`::
 
@@ -383,8 +383,8 @@ function.
 
 .. module:: django.utils.six
 
-Django customized version of six
---------------------------------
+Django customized version of ``six``
+------------------------------------
 
 The version of six bundled with Django (``django.utils.six``) includes a few
 customizations for internal use only.
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index ce6d7a4ab2..6132c639bf 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -68,7 +68,7 @@ be serialized.
     serialized object doesn't specify all the fields that are required by a
     model, the deserializer will not be able to save deserialized instances.
 
-Inherited Models
+Inherited models
 ----------------
 
 If you have a model that is defined using an :ref:`abstract base class
diff --git a/docs/topics/settings.txt b/docs/topics/settings.txt
index 55e8d221c3..70a4783da3 100644
--- a/docs/topics/settings.txt
+++ b/docs/topics/settings.txt
@@ -48,8 +48,8 @@ Python `import search path`_.
 
 .. _import search path: http://www.diveintopython.net/getting_to_know_python/everything_is_an_object.html
 
-The django-admin utility
----------------------------
+The ``django-admin`` utility
+----------------------------
 
 When using :doc:`django-admin </ref/django-admin>`, you can either set the
 environment variable once, or explicitly pass in the settings module each time
@@ -71,8 +71,8 @@ Use the ``--settings`` command-line argument to specify the settings manually::
 
 .. _django-admin: ../django-admin/
 
-On the server (mod_wsgi)
---------------------------
+On the server (``mod_wsgi``)
+----------------------------
 
 In your live server environment, you'll need to tell your WSGI
 application what settings file to use. Do that with ``os.environ``::
@@ -171,8 +171,8 @@ a convention.
 
 .. _settings-without-django-settings-module:
 
-Using settings without setting DJANGO_SETTINGS_MODULE
-=====================================================
+Using settings without setting ``DJANGO_SETTINGS_MODULE``
+=========================================================
 
 In some cases, you might want to bypass the ``DJANGO_SETTINGS_MODULE``
 environment variable. For example, if you're using the template system by
@@ -235,8 +235,8 @@ defaults, so you must specify a value for every possible setting that might be
 used in that code you are importing. Check in
 ``django.conf.settings.global_settings`` for the full list.
 
-Either configure() or DJANGO_SETTINGS_MODULE is required
---------------------------------------------------------
+Either ``configure()`` or ``DJANGO_SETTINGS_MODULE`` is required
+----------------------------------------------------------------
 
 If you're not setting the ``DJANGO_SETTINGS_MODULE`` environment variable, you
 *must* call ``configure()`` at some point before using any code that reads
diff --git a/docs/topics/signing.txt b/docs/topics/signing.txt
index 2891c685aa..5c2856fbb7 100644
--- a/docs/topics/signing.txt
+++ b/docs/topics/signing.txt
@@ -25,8 +25,8 @@ You may also find signing useful for the following:
   protected resource, for example a downloadable file that a user has
   paid for.
 
-Protecting the SECRET_KEY
-=========================
+Protecting the ``SECRET_KEY``
+=============================
 
 When you create a new Django project using :djadmin:`startproject`, the
 ``settings.py`` file is generated automatically and gets a random
@@ -79,8 +79,8 @@ generate signatures. You can use a different secret by passing it to the
     <https://tools.ietf.org/html/rfc4648#section-5>`_.  This alphabet contains
     alphanumeric characters, hyphens, and underscores.
 
-Using the salt argument
------------------------
+Using the ``salt`` argument
+---------------------------
 
 If you do not wish for every occurrence of a particular string to have the same
 signature hash, you can use the optional ``salt`` argument to the ``Signer``
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index fa2067553f..15fb226d2c 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -534,8 +534,8 @@ Methods
 Testing utilities
 -----------------
 
-django.test.utils
-~~~~~~~~~~~~~~~~~
+``django.test.utils``
+~~~~~~~~~~~~~~~~~~~~~
 
 .. module:: django.test.utils
    :synopsis: Helpers to write custom test runners.
@@ -555,8 +555,8 @@ utility methods in the ``django.test.utils`` module.
     magic hooks into the template system and restoring normal email
     services.
 
-django.db.connection.creation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+``django.db.connection.creation``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. currentmodule:: django.db.connection.creation
 
@@ -615,8 +615,8 @@ can be useful during testing.
 
 .. _topics-testing-code-coverage:
 
-Integration with coverage.py
-============================
+Integration with ``coverage.py``
+================================
 
 Code coverage describes how much source code has been tested. It shows which
 parts of your code are being exercised by tests and which are not. It's an
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index c70b0b187d..e4fa3cee0f 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -617,8 +617,8 @@ Normal Python unit test classes extend a base class of
 
    Hierarchy of Django unit testing classes
 
-SimpleTestCase
---------------
+``SimpleTestCase``
+------------------
 
 .. class:: SimpleTestCase()
 
@@ -701,8 +701,8 @@ then you should use :class:`~django.test.TransactionTestCase` or
     :exc:`unittest.SkipTest` in ``setUpClass()``, be sure to do it before
     calling ``super()`` to avoid this.
 
-TransactionTestCase
--------------------
+``TransactionTestCase``
+-----------------------
 
 .. class:: TransactionTestCase()
 
@@ -742,8 +742,8 @@ to test the effects of commit and rollback:
 
 ``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase`.
 
-TestCase
---------
+``TestCase``
+------------
 
 .. class:: TestCase()
 
@@ -811,8 +811,8 @@ additions, including:
 
 .. _live-test-server:
 
-LiveServerTestCase
-------------------
+``LiveServerTestCase``
+----------------------
 
 .. class:: LiveServerTestCase()