[1.5.x] Fixed broken links, round 4. refs #19516

Backport of 067505ad19 from master

9 files changed, 38 insertions, 28 deletions

diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index f349c23626..923b877cc5 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -93,8 +93,8 @@ 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
-:class:`TemplateResponse` with a suitable template, and that object as
-context.
+:class:`~django.template.response.TemplateResponse` with a suitable template,
+and that object as context.
 
 To get the object, :class:`~django.views.generic.detail.DetailView`
 relies on :class:`~django.views.generic.detail.SingleObjectMixin`,
@@ -111,15 +111,14 @@ attribute if that's provided). :class:`SingleObjectMixin` also overrides
 which is used across all Django's built in class-based views to supply
 context data for template renders.
 
-To then make a :class:`TemplateResponse`, :class:`DetailView` uses
+To then make a :class:`~django.template.response.TemplateResponse`,
+:class:`DetailView` uses
 :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`,
-which extends
-:class:`~django.views.generic.base.TemplateResponseMixin`, overriding
-:meth:`get_template_names()` as discussed above. It actually provides
-a fairly sophisticated set of options, but the main one that most
-people are going to use is
-``<app_label>/<object_name>_detail.html``. The ``_detail`` part can be
-changed by setting
+which extends :class:`~django.views.generic.base.TemplateResponseMixin`,
+overriding :meth:`get_template_names()` as discussed above. It actually
+provides a fairly sophisticated set of options, but the main one that most
+people are going to use is ``<app_label>/<object_name>_detail.html``. The
+``_detail`` part can be changed by setting
 :attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
 on a subclass to something else. (For instance, the :doc:`generic edit
 views<generic-editing>` use ``_form`` for create and update views, and
@@ -265,7 +264,7 @@ We can hook this into our URLs easily enough::
 
 Note the ``pk`` named group, which
 :meth:`~django.views.generic.detail.SingleObjectMixin.get_object` uses
-to look up the :class:`Author` instance. You could also use a slug, or
+to look up the ``Author`` instance. You could also use a slug, or
 any of the other features of :class:`SingleObjectMixin`.
 
 Using SingleObjectMixin with ListView
@@ -299,7 +298,7 @@ object. In order to do this, we need to have two different querysets:
     will add in the suitable ``page_obj`` and ``paginator`` for us
     providing we remember to call ``super()``.
 
-Now we can write a new :class:`PublisherDetail`::
+Now we can write a new ``PublisherDetail``::
 
     from django.views.generic import ListView
     from django.views.generic.detail import SingleObjectMixin
@@ -403,7 +402,7 @@ At this point it's natural to reach for a :class:`Form` to encapsulate
 the information sent from the user's browser to Django. Say also that
 we're heavily invested in `REST`_, so we want to use the same URL for
 displaying the author as for capturing the message from the
-user. Let's rewrite our :class:`AuthorDetailView` to do that.
+user. Let's rewrite our ``AuthorDetailView`` to do that.
 
 .. _REST: http://en.wikipedia.org/wiki/Representational_state_transfer
 
@@ -423,7 +422,7 @@ code so that on ``POST`` the form gets called appropriately.
 
 .. highlightlang:: python
 
-Our new :class:`AuthorDetail` looks like this::
+Our new ``AuthorDetail`` looks like this::
 
     # CAUTION: you almost certainly do not want to do this.
     # It is provided as part of a discussion of problems you can
@@ -507,10 +506,10 @@ clear division here: ``GET`` requests should get the
 data), and ``POST`` requests should get the :class:`FormView`. Let's
 set up those views first.
 
-The :class:`AuthorDisplay` view is almost the same as :ref:`when we
+The ``AuthorDisplay`` view is almost the same as :ref:`when we
 first introduced AuthorDetail<generic-views-extra-work>`; we have to
 write our own :meth:`get_context_data()` to make the
-:class:`AuthorInterestForm` available to the template. We'll skip the
+``AuthorInterestForm`` available to the template. We'll skip the
 :meth:`get_object()` override from before for clarity.
 
 .. code-block:: python
@@ -533,11 +532,11 @@ write our own :meth:`get_context_data()` to make the
             context.update(kwargs)
             return super(AuthorDisplay, self).get_context_data(**context)
 
-Then the :class:`AuthorInterest` is a simple :class:`FormView`, but we
+Then the ``AuthorInterest`` is a simple :class:`FormView`, but we
 have to bring in :class:`SingleObjectMixin` so we can find the author
 we're talking about, and we have to remember to set
 :attr:`template_name` to ensure that form errors will render the same
-template as :class:`AuthorDisplay` is using on ``GET``.
+template as ``AuthorDisplay`` is using on ``GET``.
 
 .. code-block:: python
 
@@ -568,14 +567,14 @@ template as :class:`AuthorDisplay` is using on ``GET``.
             # record the interest using the message in form.cleaned_data
             return super(AuthorInterest, self).form_valid(form)
 
-Finally we bring this together in a new :class:`AuthorDetail` view. We
+Finally we bring this together in a new ``AuthorDetail`` view. We
 already know that calling :meth:`as_view()` on a class-based view
 gives us something that behaves exactly like a function based view, so
 we can do that at the point we choose between the two subviews.
 
 You can of course pass through keyword arguments to :meth:`as_view()`
 in the same way you would in your URLconf, such as if you wanted the
-:class:`AuthorInterest` behaviour to also appear at another URL but
+``AuthorInterest`` behaviour to also appear at another URL but
 using a different template.
 
 .. code-block:: python
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index a869b6afad..046c23bdcd 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -601,6 +601,8 @@ relation may end up filtering on different linked objects.
 Filters can reference fields on the model
 -----------------------------------------
 
+.. class:: F
+
 In the examples given so far, we have constructed filters that compare
 the value of a model field with a constant. But what if you want to compare
 the value of a model field with another field on the same model?
@@ -755,6 +757,8 @@ To avoid this problem, simply save the
 Complex lookups with Q objects
 ==============================
 
+.. class:: Q
+
 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
 example, queries with ``OR`` statements), you can use ``Q`` objects.
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 7c1771b758..76849c8e23 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -37,7 +37,7 @@ display two blank forms::
 
 Iterating over the ``formset`` will render the forms in the order they were
 created. You can change this order by providing an alternate implementation for
-the :meth:`__iter__()` method.
+the ``__iter__()`` method.
 
 Formsets can also be indexed into, which returns the corresponding form. If you
 override ``__iter__``, you will need to also override ``__getitem__`` to have
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index 4693de6c7e..9b5794a8f2 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -300,9 +300,9 @@ loop::
         <p><input type="submit" value="Send message" /></p>
     </form>
 
-Within this loop, ``{{ field }}`` is an instance of :class:`BoundField`.
-``BoundField`` also has the following attributes, which can be useful in your
-templates:
+Within this loop, ``{{ field }}`` is an instance of
+:class:`~django.forms.BoundField`. ``BoundField`` also has the following
+attributes, which can be useful in your templates:
 
 ``{{ field.label }}``
     The label of the field, e.g. ``Email address``.
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index 233346db0d..67d539447c 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -549,6 +549,8 @@ model's ``clean()`` hook.
 Model formsets
 ==============
 
+.. class:: models.BaseModelFormSet
+
 Like :doc:`regular formsets </topics/forms/formsets>`, Django provides a couple
 of enhanced formset classes that make it easy to work with Django models. Let's
 reuse the ``Author`` model from above::
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index baf8aa5cb5..dac146bf3e 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -264,7 +264,7 @@ You can edit it multiple times.
       - ``modification``: last modification of the session, as a
         :class:`~datetime.datetime` object. Defaults to the current time.
       - ``expiry``: expiry information for the session, as a
-        :class:`~datetime.datetime` object, an :class:`int` (in seconds), or
+        :class:`~datetime.datetime` object, an :func:`int` (in seconds), or
         ``None``. Defaults to the value stored in the session by
         :meth:`set_expiry`, if there is one, or ``None``.
 
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 0b13ea18be..0b37c25f18 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -1248,6 +1248,8 @@ The ``set_language`` redirect view
 
 .. highlightlang:: python
 
+.. currentmodule:: django.views.i18n
+
 .. function:: set_language(request)
 
 As a convenience, Django comes with a view, :func:`django.views.i18n.set_language`,
diff --git a/docs/topics/pagination.txt b/docs/topics/pagination.txt
index 6c3ab77b11..b504b2a373 100644
--- a/docs/topics/pagination.txt
+++ b/docs/topics/pagination.txt
@@ -205,8 +205,8 @@ Attributes
 
 .. exception:: InvalidPage
 
-	A base class for exceptions raised when a paginator is passed an invalid
-	page number.
+    A base class for exceptions raised when a paginator is passed an invalid
+    page number.
 
 The :meth:`Paginator.page` method raises an exception if the requested page is
 invalid (i.e., not an integer) or contains no objects. Generally, it's enough
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index b748a1c7db..128d730a1d 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -850,6 +850,9 @@ Normal Python unit test classes extend a base class of
 
    Hierarchy of Django unit testing classes
 
+Regardless of the version of Python you're using, if you've installed
+``unittest2``, :mod:`django.utils.unittest` will point to that library.
+
 SimpleTestCase
 ~~~~~~~~~~~~~~
 
@@ -1371,7 +1374,7 @@ in the ``with`` block and reset its value to the previous state afterwards.
 .. function:: override_settings
 
 In case you want to override a setting for just one test method or even the
-whole :class:`TestCase` class, Django provides the
+whole :class:`~django.test.TestCase` class, Django provides the
 :func:`~django.test.utils.override_settings` decorator (see :pep:`318`). It's
 used like this::