[1.5.x] Fixed #19516 - Fixed remaining broken links.

Added -n to sphinx builds to catch issues going forward.

Backport of 9b5f64cc6e from master.

21 files changed, 135 insertions, 104 deletions

diff --git a/docs/ref/contrib/admin/admindocs.txt b/docs/ref/contrib/admin/admindocs.txt
index 4a50856f3d..b3e26eca48 100644
--- a/docs/ref/contrib/admin/admindocs.txt
+++ b/docs/ref/contrib/admin/admindocs.txt
@@ -24,7 +24,7 @@ the following:
 
 * Add :mod:`django.contrib.admindocs` to your :setting:`INSTALLED_APPS`.
 * Add ``(r'^admin/doc/', include('django.contrib.admindocs.urls'))`` to
-  your :data:`urlpatterns`. Make sure it's included *before* the
+  your ``urlpatterns``. Make sure it's included *before* the
   ``r'^admin/'`` entry, so that requests to ``/admin/doc/`` don't get
   handled by the latter entry.
 * Install the docutils Python module (http://docutils.sf.net/).
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index 679b0b62e0..dba438d111 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -170,7 +170,7 @@ subclass::
     ``fields`` option (for more complex layout needs see the
     :attr:`~ModelAdmin.fieldsets` option described in the next section). For
     example, you could define a simpler version of the admin form for the
-    ``django.contrib.flatpages.FlatPage`` model as follows::
+    :class:`django.contrib.flatpages.models.FlatPage` model as follows::
 
         class FlatPageAdmin(admin.ModelAdmin):
             fields = ('url', 'title', 'content')
@@ -214,8 +214,8 @@ subclass::
     a dictionary of information about the fieldset, including a list of fields
     to be displayed in it.
 
-    A full example, taken from the :class:`django.contrib.flatpages.FlatPage`
-    model::
+    A full example, taken from the
+    :class:`django.contrib.flatpages.models.FlatPage` model::
 
         class FlatPageAdmin(admin.ModelAdmin):
             fieldsets = (
@@ -359,7 +359,7 @@ subclass::
 
     Note that the key in the dictionary is the actual field class, *not* a
     string. The value is another dictionary; these arguments will be passed to
-    :meth:`~django.forms.Field.__init__`. See :doc:`/ref/forms/api` for
+    the form field's ``__init__()`` method. See :doc:`/ref/forms/api` for
     details.
 
     .. warning::
@@ -588,7 +588,7 @@ subclass::
 
     .. versionadded:: 1.4
 
-    * a class inheriting from :mod:`django.contrib.admin.SimpleListFilter`,
+    * a class inheriting from ``django.contrib.admin.SimpleListFilter``,
       which you need to provide the ``title`` and ``parameter_name``
       attributes to and override the ``lookups`` and ``queryset`` methods,
       e.g.::
@@ -677,7 +677,7 @@ subclass::
 
     * a tuple, where the first element is a field name and the second
       element is a class inheriting from
-      :mod:`django.contrib.admin.FieldListFilter`, for example::
+      ``django.contrib.admin.FieldListFilter``, for example::
 
           from django.contrib.admin import BooleanFieldListFilter
 
@@ -959,10 +959,9 @@ templates used by the :class:`ModelAdmin` views:
 
 .. attribute:: ModelAdmin.delete_selected_confirmation_template
 
-    Path to a custom template, used by the :meth:`delete_selected`
-    action method for displaying a confirmation page when deleting one
-    or more objects. See the :doc:`actions
-    documentation</ref/contrib/admin/actions>`.
+    Path to a custom template, used by the ``delete_selected`` action method
+    for displaying a confirmation page when deleting one or more objects. See
+    the :doc:`actions documentation</ref/contrib/admin/actions>`.
 
 .. attribute:: ModelAdmin.object_history_template
 
@@ -1134,9 +1133,8 @@ templates used by the :class:`ModelAdmin` views:
 
     Since this is usually not what you want, Django provides a convenience
     wrapper to check permissions and mark the view as non-cacheable. This
-    wrapper is :meth:`AdminSite.admin_view` (i.e.
-    ``self.admin_site.admin_view`` inside a ``ModelAdmin`` instance); use it
-    like so::
+    wrapper is ``AdminSite.admin_view()`` (i.e. ``self.admin_site.admin_view``
+    inside a ``ModelAdmin`` instance); use it like so::
 
         class MyModelAdmin(admin.ModelAdmin):
             def get_urls(self):
@@ -1156,7 +1154,7 @@ templates used by the :class:`ModelAdmin` views:
 
     If the page is cacheable, but you still want the permission check to be
     performed, you can pass a ``cacheable=True`` argument to
-    :meth:`AdminSite.admin_view`::
+    ``AdminSite.admin_view()``::
 
         (r'^my_view/$', self.admin_site.admin_view(self.my_view, cacheable=True))
 
diff --git a/docs/ref/contrib/comments/custom.txt b/docs/ref/contrib/comments/custom.txt
index 0ef37a9a0b..b4ab65bc2d 100644
--- a/docs/ref/contrib/comments/custom.txt
+++ b/docs/ref/contrib/comments/custom.txt
@@ -66,15 +66,17 @@ In the ``models.py`` we'll define a ``CommentWithTitle`` model::
     class CommentWithTitle(Comment):
         title = models.CharField(max_length=300)
 
-Most custom comment models will subclass the :class:`Comment` model. However,
+Most custom comment models will subclass the
+:class:`~django.contrib.comments.models.Comment` model. However,
 if you want to substantially remove or change the fields available in the
-:class:`Comment` model, but don't want to rewrite the templates, you could
-try subclassing from :class:`BaseCommentAbstractModel`.
+:class:`~django.contrib.comments.models.Comment` model, but don't want to
+rewrite the templates, you could try subclassing from
+``BaseCommentAbstractModel``.
 
 Next, we'll define a custom comment form in ``forms.py``. This is a little more
 tricky: we have to both create a form and override
-:meth:`CommentForm.get_comment_model` and
-:meth:`CommentForm.get_comment_create_data` to return deal with our custom title
+``CommentForm.get_comment_model()`` and
+``CommentForm.get_comment_create_data()`` to return deal with our custom title
 field::
 
     from django import forms
@@ -139,7 +141,7 @@ however.
 
     Return the :class:`~django.db.models.Model` class to use for comments. This
     model should inherit from
-    :class:`django.contrib.comments.models.BaseCommentAbstractModel`, which
+    ``django.contrib.comments.models.BaseCommentAbstractModel``, which
     defines necessary core fields.
 
     The default implementation returns
@@ -170,33 +172,33 @@ however.
     attribute when rendering your comment form.
 
     The default implementation returns a reverse-resolved URL pointing
-    to the :func:`post_comment` view.
+    to the ``post_comment()`` view.
 
     .. note::
 
         If you provide a custom comment model and/or form, but you
-        want to use the default :func:`post_comment` view, you will
+        want to use the default ``post_comment()`` view, you will
         need to be aware that it requires the model and form to have
         certain additional attributes and methods: see the
-        :func:`post_comment` view documentation for details.
+        ``django.contrib.comments.views.post_comment()`` view for details.
 
 .. function:: get_flag_url()
 
     Return the URL for the "flag this comment" view.
 
     The default implementation returns a reverse-resolved URL pointing
-    to the :func:`django.contrib.comments.views.moderation.flag` view.
+    to the ``django.contrib.comments.views.moderation.flag()`` view.
 
 .. function:: get_delete_url()
 
     Return the URL for the "delete this comment" view.
 
     The default implementation returns a reverse-resolved URL pointing
-    to the :func:`django.contrib.comments.views.moderation.delete` view.
+    to the ``django.contrib.comments.views.moderation.delete()`` view.
 
 .. function:: get_approve_url()
 
     Return the URL for the "approve this comment from moderation" view.
 
     The default implementation returns a reverse-resolved URL pointing
-    to the :func:`django.contrib.comments.views.moderation.approve` view.
+    to the ``django.contrib.comments.views.moderation.approve()`` view.
diff --git a/docs/ref/contrib/comments/example.txt b/docs/ref/contrib/comments/example.txt
index 2bff778c2f..4e18e37de0 100644
--- a/docs/ref/contrib/comments/example.txt
+++ b/docs/ref/contrib/comments/example.txt
@@ -136,7 +136,7 @@ Feeds
 =====
 
 Suppose you want to export a :doc:`feed </ref/contrib/syndication>` of the
-latest comments, you can use the built-in :class:`LatestCommentFeed`. Just
+latest comments, you can use the built-in ``LatestCommentFeed``. Just
 enable it in your project's ``urls.py``:
 
 .. code-block:: python
@@ -166,7 +166,7 @@ features (all of which or only certain can be enabled):
 * Close comments after a particular (user-defined) number of days.
 * Email new comments to the site-staff.
 
-To enable comment moderation, we subclass the :class:`CommentModerator` and
+To enable comment moderation, we subclass the ``CommentModerator`` and
 register it with the moderation features we want. Let's suppose we want to
 close comments after 7 days of posting and also send out an email to the
 site staff. In ``blog/models.py``, we register a comment moderator in the
diff --git a/docs/ref/contrib/comments/moderation.txt b/docs/ref/contrib/comments/moderation.txt
index c042971d39..a7138dda53 100644
--- a/docs/ref/contrib/comments/moderation.txt
+++ b/docs/ref/contrib/comments/moderation.txt
@@ -185,15 +185,14 @@ via two methods:
     be moderated using the options defined in the
     ``CommentModerator`` subclass. If any of the models are
     already registered for moderation, the exception
-    :exc:`AlreadyModerated` will be raised.
+    ``AlreadyModerated`` will be raised.
 
 .. function:: moderator.unregister(model_or_iterable)
 
     Takes one argument: a model class or list of model classes,
     and removes the model or models from the set of models which
     are being moderated. If any of the models are not currently
-    being moderated, the exception
-    :exc:`NotModerated` will be raised.
+    being moderated, the exception ``NotModerated`` will be raised.
 
 
 Customizing the moderation system
@@ -207,8 +206,8 @@ models with an instance of the subclass.
 
 .. class:: Moderator
 
-    In addition to the :meth:`Moderator.register` and
-    :meth:`Moderator.unregister` methods detailed above, the following methods
+    In addition to the :func:`moderator.register` and
+    :func:`moderator.unregister` methods detailed above, the following methods
     on :class:`Moderator` can be overridden to achieve customized behavior:
 
     .. method:: connect
diff --git a/docs/ref/contrib/comments/signals.txt b/docs/ref/contrib/comments/signals.txt
index 8274539ed7..ea901b6a95 100644
--- a/docs/ref/contrib/comments/signals.txt
+++ b/docs/ref/contrib/comments/signals.txt
@@ -81,8 +81,8 @@ Arguments sent with this signal:
     :meth:`~django.db.models.Model.save` again.
 
 ``flag``
-    The :class:`~django.contrib.comments.models.CommentFlag` that's been
-    attached to the comment.
+    The ``django.contrib.comments.models.CommentFlag`` that's been attached to
+    the comment.
 
 ``created``
     ``True`` if this is a new flag; ``False`` if it's a duplicate flag.
diff --git a/docs/ref/contrib/contenttypes.txt b/docs/ref/contrib/contenttypes.txt
index 8f329aa388..e9cd5e7bc0 100644
--- a/docs/ref/contrib/contenttypes.txt
+++ b/docs/ref/contrib/contenttypes.txt
@@ -453,7 +453,7 @@ Generic relations in forms and admin
 ------------------------------------
 
 The :mod:`django.contrib.contenttypes.generic` module provides
-:class:`~django.contrib.contenttypes.generic.BaseGenericInlineFormSet`,
+``BaseGenericInlineFormSet``,
 :class:`~django.contrib.contenttypes.generic.GenericTabularInline`
 and :class:`~django.contrib.contenttypes.generic.GenericStackedInline`
 (the last two are subclasses of
@@ -480,3 +480,9 @@ information.
 
         The name of the integer field that represents the ID of the related
         object. Defaults to ``object_id``.
+
+.. class:: GenericTabularInline
+.. class:: GenericStackedInline
+
+    Subclasses of :class:`GenericInlineModelAdmin` with stacked and tabular
+    layouts, respectively.
diff --git a/docs/ref/contrib/databrowse.txt b/docs/ref/contrib/databrowse.txt
index 3d411bb7b4..aff8257017 100644
--- a/docs/ref/contrib/databrowse.txt
+++ b/docs/ref/contrib/databrowse.txt
@@ -43,7 +43,7 @@ How to use Databrowse
    .. versionchanged:: 1.4
 
    Since Django 1.4, it is possible to register several models in the same
-   call to :func:`~databrowse.site.register`.
+   call to ``databrowse.site.register()``.
 
    It doesn't matter where you put this, as long as it gets executed at some
    point. A good place for it is in your :doc:`URLconf file
@@ -71,7 +71,7 @@ code. Simply add the following import to your URLconf::
     from django.contrib.auth.decorators import login_required
 
 Then modify the :doc:`URLconf </topics/http/urls>` so that the
-:func:`databrowse.site.root` view is decorated with
+``databrowse.site.root()`` view is decorated with
 :func:`django.contrib.auth.decorators.login_required`::
 
     (r'^databrowse/(.*)', login_required(databrowse.site.root)),
diff --git a/docs/ref/contrib/flatpages.txt b/docs/ref/contrib/flatpages.txt
index 7ff9165642..2b54ea9776 100644
--- a/docs/ref/contrib/flatpages.txt
+++ b/docs/ref/contrib/flatpages.txt
@@ -194,7 +194,7 @@ Via the Python API
     If you add or modify flatpages via your own code, you will likely want to
     check for duplicate flatpage URLs within the same site. The flatpage form
     used in the admin performs this validation check, and can be imported from
-    :class:`django.contrib.flatpages.forms.FlatPageForm` and used in your own
+    ``django.contrib.flatpages.forms.FlatPageForm`` and used in your own
     views.
 
 Flatpage templates
@@ -264,7 +264,7 @@ Displaying ``registration_required`` flatpages
 By default, the :ttag:`get_flatpages` templatetag will only show
 flatpages that are marked ``registration_required = False``. If you
 want to display registration-protected flatpages, you need to specify
-an authenticated user using a``for`` clause.
+an authenticated user using a ``for`` clause.
 
 For example:
 
diff --git a/docs/ref/contrib/formtools/form-preview.txt b/docs/ref/contrib/formtools/form-preview.txt
index 784213ecba..011e72c2e0 100644
--- a/docs/ref/contrib/formtools/form-preview.txt
+++ b/docs/ref/contrib/formtools/form-preview.txt
@@ -25,9 +25,8 @@ application takes care of the following workflow:
    a. If it's valid, displays a preview page.
    b. If it's not valid, redisplays the form with error messages.
 3. When the "confirmation" form is submitted from the preview page, calls
-   a hook that you define -- a
-   :meth:`~django.contrib.formtools.preview.FormPreview.done()` method that gets
-   passed the valid data.
+   a hook that you define -- a ``done()`` method that gets passed the valid
+   data.
 
 The framework enforces the required preview by passing a shared-secret hash to
 the preview page via hidden form fields. If somebody tweaks the form parameters
@@ -51,8 +50,7 @@ How to use ``FormPreview``
      directory to your :setting:`TEMPLATE_DIRS` setting.
 
 2. Create a :class:`~django.contrib.formtools.preview.FormPreview` subclass that
-   overrides the :meth:`~django.contrib.formtools.preview.FormPreview.done()`
-   method::
+   overrides the ``done()`` method::
 
        from django.contrib.formtools.preview import FormPreview
        from myapp.models import SomeModel
@@ -92,13 +90,15 @@ How to use ``FormPreview``
 A :class:`~django.contrib.formtools.preview.FormPreview` class is a simple Python class
 that represents the preview workflow.
 :class:`~django.contrib.formtools.preview.FormPreview` classes must subclass
-``django.contrib.formtools.preview.FormPreview`` and override the
-:meth:`~django.contrib.formtools.preview.FormPreview.done()` method. They can live
-anywhere in your codebase.
+``django.contrib.formtools.preview.FormPreview`` and override the ``done()``
+method. They can live anywhere in your codebase.
 
 ``FormPreview`` templates
 =========================
 
+.. attribute:: FormPreview.form_template
+.. attribute:: FormPreview.preview_template
+
 By default, the form is rendered via the template :file:`formtools/form.html`,
 and the preview page is rendered via the template :file:`formtools/preview.html`.
 These values can be overridden for a particular form preview by setting
diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt
index 3edc019d05..9ea65d7e5f 100644
--- a/docs/ref/contrib/formtools/form-wizard.txt
+++ b/docs/ref/contrib/formtools/form-wizard.txt
@@ -54,7 +54,8 @@ you just have to do these things:
 4. Add ``django.contrib.formtools`` to your
    :setting:`INSTALLED_APPS` list in your settings file.
 
-5. Point your URLconf at your :class:`WizardView` :meth:`~WizardView.as_view` method.
+5. Point your URLconf at your :class:`WizardView` :meth:`~WizardView.as_view`
+   method.
 
 Defining ``Form`` classes
 -------------------------
@@ -89,6 +90,9 @@ the message itself. Here's what the :file:`forms.py` might look like::
 Creating a ``WizardView`` subclass
 ----------------------------------
 
+.. class:: SessionWizardView
+.. class:: CookieWizardView
+
 The next step is to create a
 :class:`django.contrib.formtools.wizard.views.WizardView` subclass. You can
 also use the :class:`SessionWizardView` or :class:`CookieWizardView` classes
@@ -225,9 +229,11 @@ Here's a full example template:
 Hooking the wizard into a URLconf
 ---------------------------------
 
+.. method:: WizardView.as_view
+
 Finally, we need to specify which forms to use in the wizard, and then
 deploy the new :class:`WizardView` object at a URL in the ``urls.py``. The
-wizard's :meth:`as_view` method takes a list of your
+wizard's ``as_view()`` method takes a list of your
 :class:`~django.forms.Form` classes as an argument during instantiation::
 
     from django.conf.urls import patterns
@@ -346,9 +352,9 @@ Advanced ``WizardView`` methods
     used as the form for step ``step``.
 
     Returns an :class:`~django.db.models.Model` object which will be passed as
-    the :attr:`~django.forms.ModelForm.instance` argument when instantiating the
-    ModelForm for step ``step``.  If no instance object was provided while
-    initializing the form wizard, ``None`` will be returned.
+    the ``instance`` argument when instantiating the ``ModelForm`` for step
+    ``step``.  If no instance object was provided while initializing the form
+    wizard, ``None`` will be returned.
 
     The default implementation::
 
@@ -514,10 +520,10 @@ Providing initial data for the forms
 .. attribute:: WizardView.initial_dict
 
     Initial data for a wizard's :class:`~django.forms.Form` objects can be
-    provided using the optional :attr:`~Wizard.initial_dict` keyword argument.
-    This argument should be a dictionary mapping the steps to dictionaries
-    containing the initial data for each step. The dictionary of initial data
-    will be passed along to the constructor of the step's
+    provided using the optional :attr:`~WizardView.initial_dict` keyword
+    argument. This argument should be a dictionary mapping the steps to
+    dictionaries containing the initial data for each step. The dictionary of
+    initial data will be passed along to the constructor of the step's
     :class:`~django.forms.Form`::
 
         >>> from myapp.forms import ContactForm1, ContactForm2
@@ -542,11 +548,13 @@ Providing initial data for the forms
 Handling files
 ==============
 
+.. attribute:: WizardView.file_storage
+
 To handle :class:`~django.forms.FileField` within any step form of the wizard,
-you have to add a :attr:`file_storage` to your :class:`WizardView` subclass.
+you have to add a ``file_storage`` to your :class:`WizardView` subclass.
 
 This storage will temporarily store the uploaded files for the wizard. The
-:attr:`file_storage` attribute should be a
+``file_storage`` attribute should be a
 :class:`~django.core.files.storage.Storage` subclass.
 
 Django provides a built-in storage class (see :ref:`the built-in filesystem
@@ -646,6 +654,8 @@ Usage of ``NamedUrlWizardView``
 ===============================
 
 .. class:: NamedUrlWizardView
+.. class:: NamedUrlSessionWizardView
+.. class:: NamedUrlCookieWizardView
 
 There is a :class:`WizardView` subclass which adds named-urls support to the
 wizard. By doing this, you can have single urls for every step. You can also
diff --git a/docs/ref/contrib/formtools/index.txt b/docs/ref/contrib/formtools/index.txt
index f36470654a..e768c0e655 100644
--- a/docs/ref/contrib/formtools/index.txt
+++ b/docs/ref/contrib/formtools/index.txt
@@ -1,6 +1,8 @@
 django.contrib.formtools
 ========================
 
+.. module:: django.contrib.formtools
+
 A set of high-level abstractions for Django forms (:mod:`django.forms`).
 
 .. toctree::
diff --git a/docs/ref/contrib/gis/db-api.txt b/docs/ref/contrib/gis/db-api.txt
index 519f79f0d4..be413c9df8 100644
--- a/docs/ref/contrib/gis/db-api.txt
+++ b/docs/ref/contrib/gis/db-api.txt
@@ -4,20 +4,23 @@
 GeoDjango Database API
 ======================
 
-.. module:: django.contrib.gis.db.models
-   :synopsis: GeoDjango's database API.
-
 .. _spatial-backends:
 
 Spatial Backends
 ================
 
+.. module:: django.contrib.gis.db.backends
+   :synopsis: GeoDjango's spatial database backends.
+
 GeoDjango currently provides the following spatial database backends:
 
-* :mod:`django.contrib.gis.db.backends.postgis`
-* :mod:`django.contrib.gis.db.backends.mysql`
-* :mod:`django.contrib.gis.db.backends.oracle`
-* :mod:`django.contrib.gis.db.backends.spatialite`
+* ``django.contrib.gis.db.backends.postgis``
+* ``django.contrib.gis.db.backends.mysql``
+* ``django.contrib.gis.db.backends.oracle``
+* ``django.contrib.gis.db.backends.spatialite``
+
+.. module:: django.contrib.gis.db.models
+   :synopsis: GeoDjango's database API.
 
 .. _mysql-spatial-limitations:
 
diff --git a/docs/ref/contrib/gis/feeds.txt b/docs/ref/contrib/gis/feeds.txt
index 7c3a2d011c..7b1b6ebccf 100644
--- a/docs/ref/contrib/gis/feeds.txt
+++ b/docs/ref/contrib/gis/feeds.txt
@@ -27,7 +27,7 @@ API Reference
 .. class:: Feed
 
    In addition to methods provided by
-   the :class:`django.contrib.syndication.feeds.Feed`
+   the :class:`django.contrib.syndication.views.Feed`
    base class, GeoDjango's ``Feed`` class provides
    the following overrides.  Note that these overrides may be done in multiple ways::
 
@@ -71,11 +71,11 @@ API Reference
    can be a ``GEOSGeometry`` instance, or a tuple that represents a
    point coordinate or bounding box.  For example::
 
-       class ZipcodeFeed(Feed):
+        class ZipcodeFeed(Feed):
 
-           def item_geometry(self, obj):
-	       # Returns the polygon.
-               return obj.poly
+            def item_geometry(self, obj):
+                # Returns the polygon.
+                return obj.poly
 
 ``SyndicationFeed`` Subclasses
 ------------------------------
diff --git a/docs/ref/contrib/gis/geoquerysets.txt b/docs/ref/contrib/gis/geoquerysets.txt
index 69280dc028..66afc3d377 100644
--- a/docs/ref/contrib/gis/geoquerysets.txt
+++ b/docs/ref/contrib/gis/geoquerysets.txt
@@ -683,7 +683,7 @@ Keyword Argument       Description
                        a method name clashes with an existing
                        ``GeoQuerySet`` method -- if you wanted to use the
                        ``area()`` method on model with a ``PolygonField``
-		       named ``area``, for example.
+                       named ``area``, for example.
 =====================  =====================================================
 
 Measurement
@@ -1043,7 +1043,7 @@ Keyword Argument       Description
 =====================  =====================================================
 ``relative``           If set to ``True``, the path data will be implemented
                        in terms of relative moves.  Defaults to ``False``,
-		       meaning that absolute moves are used instead.
+                       meaning that absolute moves are used instead.
 
 ``precision``          This keyword may be used to specify the number of
                        significant digits for the coordinates in the SVG
diff --git a/docs/ref/contrib/gis/geos.txt b/docs/ref/contrib/gis/geos.txt
index 7d7c32781c..4d44638488 100644
--- a/docs/ref/contrib/gis/geos.txt
+++ b/docs/ref/contrib/gis/geos.txt
@@ -142,10 +142,9 @@ Geometry Objects
 
 .. class:: GEOSGeometry(geo_input[, srid=None])
 
-  :param geo_input: Geometry input value
-  :type geo_input: string or buffer
+  :param geo_input: Geometry input value (string or buffer)
   :param srid: spatial reference identifier
-  :type srid: integer
+  :type srid: int
 
 This is the base class for all GEOS geometry objects.  It initializes on the
 given ``geo_input`` argument, and then assumes the proper geometry subclass
@@ -800,7 +799,7 @@ Example::
    :param string: string that contains spatial data
    :type string: string
    :param srid: spatial reference identifier
-   :type srid: integer
+   :type srid: int
    :rtype: a :class:`GEOSGeometry` corresponding to the spatial data in the string
 
 Example::
@@ -966,3 +965,10 @@ location (e.g., ``/home/bob/lib/libgeos_c.so``).
 
     The setting must be the *full* path to the **C** shared library; in
     other words you want to use ``libgeos_c.so``, not ``libgeos.so``.
+
+Exceptions
+==========
+
+.. exception:: GEOSException
+
+The base GEOS exception, indicates a GEOS-related error.
diff --git a/docs/ref/contrib/gis/install/index.txt b/docs/ref/contrib/gis/install/index.txt
index 100dc2edd0..35c01c9b7e 100644
--- a/docs/ref/contrib/gis/install/index.txt
+++ b/docs/ref/contrib/gis/install/index.txt
@@ -530,6 +530,6 @@ Finally, :ref:`install Django <installing-official-release>` on your system.
 
 .. rubric:: Footnotes
 .. [#] GeoDjango uses the :func:`~ctypes.util.find_library` routine from
-       :mod:`ctypes.util` to locate shared libraries.
+       ``ctypes.util`` to locate shared libraries.
 .. [#] The ``psycopg2`` Windows installers are packaged and maintained by
        `Jason Erickson <http://www.stickpeople.com/projects/python/win-psycopg/>`_.
diff --git a/docs/ref/contrib/gis/tutorial.txt b/docs/ref/contrib/gis/tutorial.txt
index 5000622ad4..9efa020e61 100644
--- a/docs/ref/contrib/gis/tutorial.txt
+++ b/docs/ref/contrib/gis/tutorial.txt
@@ -226,7 +226,7 @@ model to represent this data::
 
     class WorldBorder(models.Model):
         # Regular Django fields corresponding to the attributes in the
-	# world borders shapefile.
+        # world borders shapefile.
         name = models.CharField(max_length=50)
         area = models.IntegerField()
         pop2005 = models.IntegerField('Population 2005')
@@ -236,13 +236,13 @@ model to represent this data::
         un = models.IntegerField('United Nations Code')
         region = models.IntegerField('Region Code')
         subregion = models.IntegerField('Sub-Region Code')
-    	lon = models.FloatField()
-    	lat = models.FloatField()
+        lon = models.FloatField()
+        lat = models.FloatField()
 
-	# GeoDjango-specific: a geometry field (MultiPolygonField), and
+        # GeoDjango-specific: a geometry field (MultiPolygonField), and
         # overriding the default manager with a GeoManager instance.
-	mpoly = models.MultiPolygonField()
-	objects = models.GeoManager()
+        mpoly = models.MultiPolygonField()
+        objects = models.GeoManager()
 
         # Returns the string representation of the model.
         def __unicode__(self):
@@ -250,7 +250,7 @@ model to represent this data::
 
 Please note two important things:
 
-1. The ``models`` module is imported from :mod:`django.contrib.gis.db`.
+1. The ``models`` module is imported from ``django.contrib.gis.db``.
 2. You must override the model's default manager with
    :class:`~django.contrib.gis.db.models.GeoManager` to perform spatial queries.
 
diff --git a/docs/ref/contrib/sitemaps.txt b/docs/ref/contrib/sitemaps.txt
index ef6c64dc61..6c11698485 100644
--- a/docs/ref/contrib/sitemaps.txt
+++ b/docs/ref/contrib/sitemaps.txt
@@ -49,6 +49,8 @@ loader can find the default templates.)
 Initialization
 ==============
 
+.. function:: views.sitemap(request, sitemaps, section=None, template_name='sitemap.xml', mimetype='application/xml')
+
 To activate sitemap generation on your Django site, add this line to your
 :doc:`URLconf </topics/http/urls>`::
 
@@ -242,9 +244,9 @@ The sitemap framework provides a couple convenience classes for common cases:
 
     The :class:`django.contrib.sitemaps.GenericSitemap` class allows you to
     create a sitemap by passing it a dictionary which has to contain at least
-    a :data:`queryset` entry. This queryset will be used to generate the items
-    of the sitemap. It may also have a :data:`date_field` entry that
-    specifies a date field for objects retrieved from the :data:`queryset`.
+    a ``queryset`` entry. This queryset will be used to generate the items
+    of the sitemap. It may also have a ``date_field`` entry that
+    specifies a date field for objects retrieved from the ``queryset``.
     This will be used for the :attr:`~Sitemap.lastmod` attribute in the
     generated sitemap. You may also pass :attr:`~Sitemap.priority` and
     :attr:`~Sitemap.changefreq` keyword arguments to the
@@ -283,14 +285,16 @@ Here's an example of a :doc:`URLconf </topics/http/urls>` using both::
 Creating a sitemap index
 ========================
 
+.. function:: views.index(request, sitemaps, template_name='sitemap_index.xml', mimetype='application/xml', sitemap_url_name='django.contrib.sitemaps.views.sitemap')
+
 The sitemap framework also has the ability to create a sitemap index that
 references individual sitemap files, one per each section defined in your
-:data:`sitemaps` dictionary. The only differences in usage are:
+``sitemaps`` dictionary. The only differences in usage are:
 
 * You use two views in your URLconf: :func:`django.contrib.sitemaps.views.index`
   and :func:`django.contrib.sitemaps.views.sitemap`.
 * The :func:`django.contrib.sitemaps.views.sitemap` view should take a
-  :data:`section` keyword argument.
+  ``section`` keyword argument.
 
 Here's what the relevant URLconf lines would look like for the example above::
 
@@ -301,7 +305,7 @@ Here's what the relevant URLconf lines would look like for the example above::
 
 This will automatically generate a :file:`sitemap.xml` file that references
 both :file:`sitemap-flatpages.xml` and :file:`sitemap-blog.xml`. The
-:class:`~django.contrib.sitemaps.Sitemap` classes and the :data:`sitemaps`
+:class:`~django.contrib.sitemaps.Sitemap` classes and the ``sitemaps``
 dict don't change at all.
 
 You should create an index file if one of your sitemaps has more than 50,000
@@ -356,19 +360,20 @@ parameter to the ``sitemap`` and ``index`` views via the URLconf::
 Context variables
 ------------------
 
-When customizing the templates for the :func:`~django.contrib.sitemaps.views.index`
-and :func:`~django.contrib.sitemaps.views.sitemaps` views, you can rely on the
+When customizing the templates for the
+:func:`~django.contrib.sitemaps.views.index` and
+:func:`~django.contrib.sitemaps.views.sitemap` views, you can rely on the
 following context variables.
 
 Index
 -----
 
-The variable :data:`sitemaps` is a list of absolute URLs to each of the sitemaps.
+The variable ``sitemaps`` is a list of absolute URLs to each of the sitemaps.
 
 Sitemap
 -------
 
-The variable :data:`urlset` is a list of URLs that should appear in the
+The variable ``urlset`` is a list of URLs that should appear in the
 sitemap. Each URL exposes attributes as defined in the
 :class:`~django.contrib.sitemaps.Sitemap` class:
 
@@ -419,14 +424,14 @@ that: :func:`django.contrib.sitemaps.ping_google()`.
 
 .. function:: ping_google
 
-    :func:`ping_google` takes an optional argument, :data:`sitemap_url`,
+    :func:`ping_google` takes an optional argument, ``sitemap_url``,
     which should be the absolute path to your site's sitemap (e.g.,
     :file:`'/sitemap.xml'`). If this argument isn't provided,
     :func:`ping_google` will attempt to figure out your
     sitemap by performing a reverse looking in your URLconf.
 
     :func:`ping_google` raises the exception
-    :exc:`django.contrib.sitemaps.SitemapNotFound` if it cannot determine your
+    ``django.contrib.sitemaps.SitemapNotFound`` if it cannot determine your
     sitemap URL.
 
 .. admonition:: Register with Google first!
diff --git a/docs/ref/contrib/staticfiles.txt b/docs/ref/contrib/staticfiles.txt
index 3a74797145..f32e1a0f6c 100644
--- a/docs/ref/contrib/staticfiles.txt
+++ b/docs/ref/contrib/staticfiles.txt
@@ -33,7 +33,7 @@ STATICFILES_DIRS
 Default: ``[]``
 
 This setting defines the additional locations the staticfiles app will traverse
-if the :class:`FileSystemFinder` finder is enabled, e.g. if you use the
+if the ``FileSystemFinder`` finder is enabled, e.g. if you use the
 :djadmin:`collectstatic` or :djadmin:`findstatic` management command or use the
 static file serving view.
 
@@ -103,19 +103,19 @@ The list of finder backends that know how to find static files in
 various locations.
 
 The default will find files stored in the :setting:`STATICFILES_DIRS` setting
-(using :class:`django.contrib.staticfiles.finders.FileSystemFinder`) and in a
+(using ``django.contrib.staticfiles.finders.FileSystemFinder``) and in a
 ``static`` subdirectory of each app (using
-:class:`django.contrib.staticfiles.finders.AppDirectoriesFinder`)
+``django.contrib.staticfiles.finders.AppDirectoriesFinder``)
 
 One finder is disabled by default:
-:class:`django.contrib.staticfiles.finders.DefaultStorageFinder`. If added to
+``django.contrib.staticfiles.finders.DefaultStorageFinder``. If added to
 your :setting:`STATICFILES_FINDERS` setting, it will look for static files in
 the default file storage as defined by the :setting:`DEFAULT_FILE_STORAGE`
 setting.
 
 .. note::
 
-    When using the :class:`AppDirectoriesFinder` finder, make sure your apps
+    When using the ``AppDirectoriesFinder`` finder, make sure your apps
     can be found by staticfiles. Simply add the app to the
     :setting:`INSTALLED_APPS` setting of your site.
 
diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt
index 2418dba8ef..d0376e3c1b 100644
--- a/docs/ref/contrib/syndication.txt
+++ b/docs/ref/contrib/syndication.txt
@@ -334,7 +334,7 @@ And the accompanying URLconf::
 Feed class reference
 --------------------
 
-.. class:: django.contrib.syndication.views.Feed
+.. class:: views.Feed
 
 This example illustrates all possible attributes and methods for a
 :class:`~django.contrib.syndication.views.Feed` class::