Fixed incorrect formatting for inline pluralized code references in docs.

docs/topics/db/examples/many_to_many.txt

@@ -36,7 +36,7 @@ objects, and a ``Publication`` has multiple ``Article`` objects:
 What follows are examples of operations that can be performed using the Python
 API facilities.
 
-Create a few ``Publications``:
+Create a few ``Publication`` instances:
 
 .. code-block:: pycon
 
@@ -74,7 +74,7 @@ Associate the ``Article`` with a ``Publication``:
 
     >>> a1.publications.add(p1)
 
-Create another ``Article``, and set it to appear in the ``Publications``:
+Create another ``Article``, and set it to appear in its publications:
 
 .. code-block:: pycon
 
@@ -196,7 +196,8 @@ involved is a little complex):
     >>> Article.objects.exclude(publications=p2)
     <QuerySet [<Article: Django lets you build web apps easily>]>
 
-If we delete a ``Publication``, its ``Articles`` won't be able to access it:
+If we delete a ``Publication``, its related ``Article`` instances won't be able
+to access it:
 
 .. code-block:: pycon
 
@@ -207,7 +208,8 @@ If we delete a ``Publication``, its ``Articles`` won't be able to access it:
     >>> a1.publications.all()
     <QuerySet []>
 
-If we delete an ``Article``, its ``Publications`` won't be able to access it:
+If we delete an ``Article``, its related ``Publication`` instances won't be
+able to access it:
 
 .. code-block:: pycon
 
@@ -303,8 +305,8 @@ Recreate the ``Article`` and ``Publication`` we have deleted:
     >>> a2.save()
     >>> a2.publications.add(p1, p2, p3)
 
-Bulk delete some ``Publications`` - references to deleted publications should
-go:
+Bulk delete some ``Publication`` instances, and the references to deleted
+publications will no longer be included in the related entries:
 
 .. code-block:: pycon
 

docs/topics/db/optimization.txt

@@ -427,7 +427,7 @@ objects to reduce the number of SQL queries. For example::
     my_band.members.add(me)
     my_band.members.add(my_friend)
 
-...where ``Bands`` and ``Artists`` have a many-to-many relationship.
+...where ``Band`` and ``Artist`` are models with a many-to-many relationship.
 
 When inserting different pairs of objects into
 :class:`~django.db.models.ManyToManyField` or when the custom
@@ -470,7 +470,7 @@ objects to reduce the number of SQL queries. For example::
     my_band.members.remove(me)
     my_band.members.remove(my_friend)
 
-...where ``Bands`` and ``Artists`` have a many-to-many relationship.
+...where ``Band`` and ``Artist`` are models with a many-to-many relationship.
 
 When removing different pairs of objects from :class:`ManyToManyFields
 <django.db.models.ManyToManyField>`, use

docs/topics/db/queries.txt

@@ -178,11 +178,11 @@ model class, like so:
 
 .. note::
 
-    ``Managers`` are accessible only via model classes, rather than from model
+    A ``Manager`` is accessible only via model classes, rather than from model
     instances, to enforce a separation between "table-level" operations and
     "record-level" operations.
 
-The :class:`~django.db.models.Manager` is the main source of ``QuerySets`` for
+The :class:`~django.db.models.Manager` is the main source of querysets for
 a model. For example, ``Blog.objects.all()`` returns a
 :class:`~django.db.models.query.QuerySet` that contains all ``Blog`` objects in
 the database.
@@ -274,7 +274,7 @@ Example:
     >>> q2 = q1.exclude(pub_date__gte=datetime.date.today())
     >>> q3 = q1.filter(pub_date__gte=datetime.date.today())
 
-These three ``QuerySets`` are separate. The first is a base
+These three querysets are separate. The first is a base
 :class:`~django.db.models.query.QuerySet` containing all entries that contain a
 headline starting with "What". The second is a subset of the first, with an
 additional criteria that excludes records whose ``pub_date`` is today or in the
@@ -288,7 +288,7 @@ refinement process.
 ``QuerySet``\s are lazy
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-``QuerySets`` are lazy -- the act of creating a
+``QuerySet`` objects are lazy -- the act of creating a
 :class:`~django.db.models.query.QuerySet` doesn't involve any database
 activity. You can stack filters together all day long, and Django won't
 actually run the query until the :class:`~django.db.models.query.QuerySet` is
@@ -1725,8 +1725,8 @@ foreign-key model will have access to a :class:`~django.db.models.Manager` that
 returns all instances of the first model. By default, this
 :class:`~django.db.models.Manager` is named ``FOO_set``, where ``FOO`` is the
 source model name, lowercased. This :class:`~django.db.models.Manager` returns
-``QuerySets``, which can be filtered and manipulated as described in the
-"Retrieving objects" section above.
+``QuerySet`` instances, which can be filtered and manipulated as described in
+the "Retrieving objects" section above.
 
 Example:
 
@@ -1750,7 +1750,7 @@ related_name='entries')``, the above example code would look like this:
     >>> b = Blog.objects.get(id=1)
     >>> b.entries.all()  # Returns all Entry objects related to Blog.
 
-    # b.entries is a Manager that returns QuerySets.
+    # b.entries is a Manager that returns ``QuerySet`` instances.
     >>> b.entries.filter(headline__contains="Lennon")
     >>> b.entries.count()
 

docs/topics/forms/modelforms.txt

@@ -700,10 +700,10 @@ will be localized.
 Form inheritance
 ----------------
 
-As with basic forms, you can extend and reuse ``ModelForms`` by inheriting
-them. This is useful if you need to declare extra fields or extra methods on a
-parent class for use in a number of forms derived from models. For example,
-using the previous ``ArticleForm`` class:
+As with basic forms, you can extend and reuse ``ModelForm`` classes by
+inheriting them. This is useful if you need to declare extra fields or extra
+methods on a parent class for use in a number of forms derived from models.
+For example, using the previous ``ArticleForm`` class:
 
 .. code-block:: pycon
 
@@ -983,7 +983,7 @@ value (``instances``, in the above example).
 When fields are missing from the form (for example because they have been
 excluded), these fields will not be set by the ``save()`` method. You can find
 more information about this restriction, which also holds for regular
-``ModelForms``, in `Selecting the fields to use`_.
+model forms, in `Selecting the fields to use`_.
 
 Pass ``commit=False`` to return the unsaved model instances:
 
@@ -1104,7 +1104,7 @@ above, in :ref:`saving-objects-in-the-formset`.)
 Overriding ``clean()`` on a ``ModelFormSet``
 --------------------------------------------
 
-Just like with ``ModelForms``, by default the ``clean()`` method of a
+Just like with a ``ModelForm``, by default the ``clean()`` method of a
 ``ModelFormSet`` will validate that none of the items in the formset violate
 the unique constraints on your model (either ``unique``, ``unique_together`` or
 ``unique_for_date|month|year``).  If you want to override the ``clean()`` method

docs/topics/performance.txt

@@ -212,11 +212,12 @@ Laziness in Django
 ------------------
 
 Django is itself quite lazy. A good example of this can be found in the
-evaluation of ``QuerySets``. :ref:`QuerySets are lazy <querysets-are-lazy>`.
+evaluation of a ``QuerySet``. :ref:`QuerySets are lazy <querysets-are-lazy>`.
 Thus a ``QuerySet`` can be created, passed around and combined with other
-``QuerySets``, without actually incurring any trips to the database to fetch
-the items it describes. What gets passed around is the ``QuerySet`` object, not
-the collection of items that - eventually - will be required from the database.
+``QuerySet`` instances, without actually incurring any trips to the database
+to fetch the items it describes. What gets passed around is the ``QuerySet``
+object, not the collection of items that - eventually - will be required from
+the database.
 
 On the other hand, :ref:`certain operations will force the evaluation of a
 QuerySet <when-querysets-are-evaluated>`. Avoiding the premature evaluation of