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

5 files changed, 50 insertions, 51 deletions

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