Fixed broken links, round 3. refs #19516

34 files changed, 127 insertions, 118 deletions

diff --git a/docs/conf.py b/docs/conf.py
index f58e4ecb2e..e651000f8b 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -110,6 +110,7 @@ intersphinx_mapping = {
     'python': ('http://docs.python.org/2.7', None),
     'sphinx': ('http://sphinx.pocoo.org/', None),
     'six': ('http://packages.python.org/six/', None),
+    'simplejson': ('http://simplejson.readthedocs.org/en/latest/', None),
 }
 
 # Python's docs don't change every week.
diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt
index 78e797b607..5fbe5eda59 100644
--- a/docs/howto/error-reporting.txt
+++ b/docs/howto/error-reporting.txt
@@ -123,7 +123,7 @@ Error reports are really helpful for debugging errors, so it is generally
 useful to record as much relevant information about those errors as possible.
 For example, by default Django records the `full traceback`_ for the
 exception raised, each `traceback frame`_'s local variables, and the
-:class:`HttpRequest`'s :ref:`attributes<httprequest-attributes>`.
+:class:`~django.http.HttpRequest`'s :ref:`attributes<httprequest-attributes>`.
 
 However, sometimes certain types of information may be too sensitive and thus
 may not be appropriate to be kept track of, for example a user's password or
@@ -165,11 +165,11 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
 
 .. function:: sensitive_post_parameters(*parameters)
 
-    If one of your views receives an :class:`HttpRequest` object with
-    :attr:`POST parameters<HttpRequest.POST>` susceptible to contain sensitive
-    information, you may prevent the values of those parameters from being
-    included in the error reports using the ``sensitive_post_parameters``
-    decorator::
+    If one of your views receives an :class:`~django.http.HttpRequest` object
+    with :attr:`POST parameters<django.http.HttpRequest.POST>` susceptible to
+    contain sensitive information, you may prevent the values of those
+    parameters from being included in the error reports using the
+    ``sensitive_post_parameters`` decorator::
 
         from django.views.decorators.debug import sensitive_post_parameters
 
@@ -198,10 +198,10 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
     .. versionchanged:: 1.4
 
     Since version 1.4, all POST parameters are systematically filtered out of
-    error reports for certain :mod:`contrib.views.auth` views (``login``,
-    ``password_reset_confirm``, ``password_change``, and ``add_view`` and
-    ``user_change_password`` in the ``auth`` admin) to prevent the leaking of
-    sensitive information such as user passwords.
+    error reports for certain :mod:`django.contrib.auth.views` views (
+    ``login``, ``password_reset_confirm``, ``password_change``, and
+    ``add_view`` and ``user_change_password`` in the ``auth`` admin) to prevent
+    the leaking of sensitive information such as user passwords.
 
 .. _custom-error-reports:
 
diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt
index 2c8d25ae6f..38ad7d88dc 100644
--- a/docs/intro/tutorial02.txt
+++ b/docs/intro/tutorial02.txt
@@ -398,9 +398,9 @@ That adds a "Filter" sidebar that lets people filter the change list by the
    :alt: Polls change list page, updated
 
 The type of filter displayed depends on the type of field you're filtering on.
-Because ``pub_date`` is a :class:`~django.db.models.fields.DateTimeField`,
-Django knows to give appropriate filter options: "Any date," "Today," "Past 7
-days," "This month," "This year."
+Because ``pub_date`` is a :class:`~django.db.models.DateTimeField`, Django
+knows to give appropriate filter options: "Any date," "Today," "Past 7 days,"
+"This month," "This year."
 
 This is shaping up well. Let's add some search capability::
 
diff --git a/docs/intro/tutorial04.txt b/docs/intro/tutorial04.txt
index 1619b599bb..333ef9fbc3 100644
--- a/docs/intro/tutorial04.txt
+++ b/docs/intro/tutorial04.txt
@@ -98,9 +98,10 @@ This code includes a few things we haven't covered yet in this tutorial:
   <django.http.HttpRequest.POST>` in our code, to ensure that data is only
   altered via a POST call.
 
-* ``request.POST['choice']`` will raise :exc:`KeyError` if ``choice`` wasn't
-  provided in POST data. The above code checks for :exc:`KeyError` and
-  redisplays the poll form with an error message if ``choice`` isn't given.
+* ``request.POST['choice']`` will raise :exc:`~exceptions.KeyError` if
+  ``choice`` wasn't provided in POST data. The above code checks for
+  :exc:`~exceptions.KeyError` and redisplays the poll form with an error
+  message if ``choice`` isn't given.
 
 * After incrementing the choice count, the code returns an
   :class:`~django.http.HttpResponseRedirect` rather than a normal
diff --git a/docs/ref/contrib/comments/models.txt b/docs/ref/contrib/comments/models.txt
index e773790d65..78e7b92145 100644
--- a/docs/ref/contrib/comments/models.txt
+++ b/docs/ref/contrib/comments/models.txt
@@ -11,12 +11,12 @@ The built-in comment models
 
     .. attribute:: content_object
 
-        A :class:`~django.contrib.contettypes.generic.GenericForeignKey`
+        A :class:`~django.contrib.contenttypes.generic.GenericForeignKey`
         attribute pointing to the object the comment is attached to. You can use
         this to get at the related object (i.e. ``my_comment.content_object``).
 
         Since this field is a
-        :class:`~django.contrib.contettypes.generic.GenericForeignKey`, it's
+        :class:`~django.contrib.contenttypes.generic.GenericForeignKey`, it's
         actually syntactic sugar on top of two underlying attributes, described
         below.
 
@@ -77,4 +77,3 @@ The built-in comment models
 
         ``True`` if the comment was removed. Used to keep track of removed
         comments instead of just deleting them.
-
diff --git a/docs/ref/contrib/comments/moderation.txt b/docs/ref/contrib/comments/moderation.txt
index 39b3ea7913..c042971d39 100644
--- a/docs/ref/contrib/comments/moderation.txt
+++ b/docs/ref/contrib/comments/moderation.txt
@@ -81,8 +81,8 @@ Built-in moderation options
     .. attribute:: auto_close_field
 
         If this is set to the name of a
-        :class:`~django.db.models.fields.DateField` or
-        :class:`~django.db.models.fields.DateTimeField` on the model for which
+        :class:`~django.db.models.DateField` or
+        :class:`~django.db.models.DateTimeField` on the model for which
         comments are being moderated, new comments for objects of that model
         will be disallowed (immediately deleted) when a certain number of days
         have passed after the date specified in that field. Must be
@@ -117,7 +117,7 @@ Built-in moderation options
     .. attribute:: enable_field
 
         If this is set to the name of a
-        :class:`~django.db.models.fields.BooleanField` on the model
+        :class:`~django.db.models.BooleanField` on the model
         for which comments are being moderated, new comments on
         objects of that model will be disallowed (immediately deleted)
         whenever the value of that field is ``False`` on the object
diff --git a/docs/ref/contrib/contenttypes.txt b/docs/ref/contrib/contenttypes.txt
index dfbeabc302..8f329aa388 100644
--- a/docs/ref/contrib/contenttypes.txt
+++ b/docs/ref/contrib/contenttypes.txt
@@ -234,13 +234,15 @@ lookup::
 
 .. versionadded:: 1.5
 
-Prior to Django 1.5 :meth:`~ContentTypeManager.get_for_model()` and
-:meth:`~ContentTypeManager.get_for_models()` always returned the
-:class:`~django.contrib.contenttypes.models.ContentType` associated with the
-concrete model of the specified one(s). That means there was no way to retreive
-the :class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
+Prior to Django 1.5,
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
+always returned the :class:`~django.contrib.contenttypes.models.ContentType`
+associated with the concrete model of the specified one(s). That means there
+was no way to retreive the
+:class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
 using those methods. As of Django 1.5 you can now pass a boolean flag –
-respectively ``for_concrete_model`` and ``for_concrete_models`` – to specify
+``for_concrete_model`` and ``for_concrete_models`` respectively – to specify
 wether or not you want to retreive the
 :class:`~django.contrib.contenttypes.models.ContentType` for the concrete or
 direct model.
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
index dffef314b7..ab1f4b0eea 100644
--- a/docs/ref/forms/api.txt
+++ b/docs/ref/forms/api.txt
@@ -150,11 +150,11 @@ it's not necessary to include every field in your form. For example::
 These values are only displayed for unbound forms, and they're not used as
 fallback values if a particular value isn't provided.
 
-Note that if a :class:`~django.forms.fields.Field` defines
-:attr:`~Form.initial` *and* you include ``initial`` when instantiating the
-``Form``, then the latter ``initial`` will have precedence. In this example,
-``initial`` is provided both at the field level and at the form instance level,
-and the latter gets precedence::
+Note that if a :class:`~django.forms.Field` defines :attr:`~Form.initial` *and*
+you include ``initial`` when instantiating the ``Form``, then the latter
+``initial`` will have precedence. In this example, ``initial`` is provided both
+at the field level and at the form instance level, and the latter gets
+precedence::
 
     >>> class CommentForm(forms.Form):
     ...     name = forms.CharField(initial='class')
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index 75d05c6829..c7d9c5fbbe 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -885,7 +885,7 @@ Slightly complex built-in ``Field`` classes
     .. attribute:: MultiValueField.widget
 
         Must be a subclass of :class:`django.forms.MultiWidget`.
-        Default value is :class:`~django.forms.widgets.TextInput`, which
+        Default value is :class:`~django.forms.TextInput`, which
         probably is not very useful in this case.
 
     .. method:: compress(data_list)
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
index a0ef0731ad..0660329eea 100644
--- a/docs/ref/forms/widgets.txt
+++ b/docs/ref/forms/widgets.txt
@@ -49,8 +49,8 @@ Setting arguments for widgets
 
 Many widgets have optional extra arguments; they can be set when defining the
 widget on the field. In the following example, the
-:attr:`~SelectDateWidget.years` attribute is set for a
-:class:`~django.forms.extras.widgets.SelectDateWidget`::
+:attr:`~django.forms.extras.widgets.SelectDateWidget.years` attribute is set
+for a :class:`~django.forms.extras.widgets.SelectDateWidget`::
 
     from django.forms.fields import DateField, ChoiceField, MultipleChoiceField
     from django.forms.widgets import RadioSelect, CheckboxSelectMultiple
@@ -222,7 +222,7 @@ foundation for custom widgets.
 .. class:: MultiWidget(widgets, attrs=None)
 
     A widget that is composed of multiple widgets.
-    :class:`~django.forms.widgets.MultiWidget` works hand in hand with the
+    :class:`~django.forms.MultiWidget` works hand in hand with the
     :class:`~django.forms.MultiValueField`.
 
     :class:`MultiWidget` has one required argument:
@@ -246,8 +246,8 @@ foundation for custom widgets.
         the combined value of the form field into the values for each widget.
 
         An example of this is how :class:`SplitDateTimeWidget` turns a
-        :class:`datetime` value into a list with date and time split into two
-        separate values::
+        :class:`~datetime.datetime` value into a list with date and time split
+        into two separate values::
 
             class SplitDateTimeWidget(MultiWidget):
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index a33c985e2c..45a70c66e3 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -547,8 +547,7 @@ Also has one optional argument:
     Optional. A storage object, which handles the storage and retrieval of your
     files. See :doc:`/topics/files` for details on how to provide this object.
 
-The default form widget for this field is a
-:class:`~django.forms.widgets.FileInput`.
+The default form widget for this field is a :class:`~django.forms.FileInput`.
 
 Using a :class:`FileField` or an :class:`ImageField` (see below) in a model
 takes a few steps:
@@ -590,7 +589,7 @@ topic guide.
     saved.
 
 The uploaded file's relative URL can be obtained using the
-:attr:`~django.db.models.fields.FileField.url` attribute. Internally,
+:attr:`~django.db.models.FileField.url` attribute. Internally,
 this calls the :meth:`~django.core.files.storage.Storage.url` method of the
 underlying :class:`~django.core.files.storage.Storage` class.
 
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index 6315985ba9..4479e4b766 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -659,7 +659,7 @@ For every :class:`~django.db.models.DateField` and
 <django.db.models.Field.null>`, the object will have ``get_next_by_FOO()`` and
 ``get_previous_by_FOO()`` methods, where ``FOO`` is the name of the field. This
 returns the next and previous object with respect to the date field, raising
-a :exc:`~django.db.DoesNotExist` exception when appropriate.
+a :exc:`~django.core.exceptions.DoesNotExist` exception when appropriate.
 
 Both methods accept optional keyword arguments, which should be in the format
 described in :ref:`Field lookups <field-lookups>`.
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index a19d022c58..ca2e64a8c5 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1112,9 +1112,9 @@ one, doing so will result in an error.
 
 .. note::
 
-    When calling :meth:`~Model.save()` for instances with deferred fields,
-    only the loaded fields will be saved. See :meth:`~Model.save()` for more
-    details.
+    When calling :meth:`~django.db.models.Model.save()` for instances with
+    deferred fields, only the loaded fields will be saved. See
+    :meth:`~django.db.models.Model.save()` for more details.
 
 
 only
@@ -1164,9 +1164,9 @@ using :meth:`select_related` is an error as well.
 
 .. note::
 
-    When calling :meth:`~Model.save()` for instances with deferred fields,
-    only the loaded fields will be saved. See :meth:`~Model.save()` for more
-    details.
+    When calling :meth:`~django.db.models.Model.save()` for instances with
+    deferred fields, only the loaded fields will be saved. See
+    :meth:`~django.db.models.Model.save()` for more details.
 
 using
 ~~~~~
@@ -1248,7 +1248,7 @@ the format described in `Field lookups`_.
 
 ``get()`` raises :exc:`~django.core.exceptions.MultipleObjectsReturned` if more
 than one object was found. The
-:exc:`~django.core.excpetions.MultipleObjectsReturned` exception is an
+:exc:`~django.core.exceptions.MultipleObjectsReturned` exception is an
 attribute of the model class.
 
 ``get()`` raises a :exc:`~django.core.exceptions.DoesNotExist` exception if an
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index 3315f9781b..2eefb0ca77 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -212,24 +212,24 @@ m2m_changed
 .. data:: django.db.models.signals.m2m_changed
    :module:
 
-Sent when a :class:`ManyToManyField` is changed on a model instance.
-Strictly speaking, this is not a model signal since it is sent by the
-:class:`ManyToManyField`, but since it complements the
+Sent when a :class:`~django.db.models.ManyToManyField` is changed on a model
+instance. Strictly speaking, this is not a model signal since it is sent by the
+:class:`~django.db.models.ManyToManyField`, but since it complements the
 :data:`pre_save`/:data:`post_save` and :data:`pre_delete`/:data:`post_delete`
 when it comes to tracking changes to models, it is included here.
 
 Arguments sent with this signal:
 
 ``sender``
-    The intermediate model class describing the :class:`ManyToManyField`.
-    This class is automatically created when a many-to-many field is
-    defined; you can access it using the ``through`` attribute on the
-    many-to-many field.
+    The intermediate model class describing the
+    :class:`~django.db.models.ManyToManyField`. This class is automatically
+    created when a many-to-many field is defined; you can access it using the
+    ``through`` attribute on the many-to-many field.
 
 ``instance``
     The instance whose many-to-many relation is updated. This can be an
-    instance of the ``sender``, or of the class the :class:`ManyToManyField`
-    is related to.
+    instance of the ``sender``, or of the class the
+    :class:`~django.db.models.ManyToManyField` is related to.
 
 ``action``
     A string indicating the type of update that is done on the relation.
@@ -303,8 +303,9 @@ Argument        Value
 
 ``action``      ``"pre_add"`` (followed by a separate signal with ``"post_add"``)
 
-``reverse``     ``False`` (``Pizza`` contains the :class:`ManyToManyField`,
-                so this call modifies the forward relation)
+``reverse``     ``False`` (``Pizza`` contains the
+                :class:`~django.db.models.ManyToManyField`, so this call
+                modifies the forward relation)
 
 ``model``       ``Topping`` (the class of the objects added to the
                 ``Pizza``)
@@ -329,8 +330,9 @@ Argument        Value
 
 ``action``      ``"pre_remove"`` (followed by a separate signal with ``"post_remove"``)
 
-``reverse``     ``True`` (``Pizza`` contains the :class:`ManyToManyField`,
-                so this call modifies the reverse relation)
+``reverse``     ``True`` (``Pizza`` contains the
+                :class:`~django.db.models.ManyToManyField`, so this call
+                modifies the reverse relation)
 
 ``model``       ``Pizza`` (the class of the objects removed from the
                 ``Topping``)
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index dd288ababc..4bbc839bea 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -864,7 +864,7 @@ an attribute "description," you could use::
     {% regroup cities by country.description as country_list %}
 
 Or, if ``country`` is a field with ``choices``, it will have a
-:meth:`^django.db.models.Model.get_FOO_display` method available as an
+:meth:`~django.db.models.Model.get_FOO_display` method available as an
 attribute, allowing  you to group on the display string rather than the
 ``choices`` key::
 
diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt
index 2f12c3a96c..4ff31591c8 100644
--- a/docs/ref/utils.txt
+++ b/docs/ref/utils.txt
@@ -145,8 +145,8 @@ results. Instead do::
 
 The functions defined in this module share the following properties:
 
-- They raise :exc:`ValueError` if their input is well formatted but isn't a
-  valid date or time.
+- They raise :exc:`~exceptions.ValueError` if their input is well formatted but
+  isn't a valid date or time.
 - They return ``None`` if it isn't well formatted at all.
 - They accept up to picosecond resolution in input, but they truncate it to
   microseconds, since that's what Python supports.
diff --git a/docs/releases/1.0-porting-guide.txt b/docs/releases/1.0-porting-guide.txt
index 78bc7acb98..ae73baa072 100644
--- a/docs/releases/1.0-porting-guide.txt
+++ b/docs/releases/1.0-porting-guide.txt
@@ -439,9 +439,10 @@ Settings
 Better exceptions
 ~~~~~~~~~~~~~~~~~
 
-The old :exc:`EnvironmentError` has split into an :exc:`ImportError` when
-Django fails to find the settings module and a :exc:`RuntimeError` when you try
-to reconfigure settings after having already used them
+The old :exc:`~exceptions.EnvironmentError` has split into an
+:exc:`~exceptions.ImportError` when Django fails to find the settings module
+and a :exc:`~exceptions.RuntimeError` when you try to reconfigure settings
+after having already used them.
 
 :setting:`LOGIN_URL` has moved
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -476,8 +477,8 @@ Smaller model changes
 Different exception from ``get()``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Managers now return a :exc:`MultipleObjectsReturned` exception
-instead of :exc:`AssertionError`:
+Managers now return a :exc:`~django.core.exceptions.MultipleObjectsReturned`
+exception instead of :exc:`~exceptions.AssertionError`:
 
 Old (0.96)::
 
diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt
index 595f59a52a..68fc624924 100644
--- a/docs/releases/1.1.txt
+++ b/docs/releases/1.1.txt
@@ -132,7 +132,7 @@ public methods.
 Fixed the ``join`` filter's escaping behavior
 ---------------------------------------------
 
-The :ttag:`join` filter no longer escapes the literal value that is
+The :tfilter:`join` filter no longer escapes the literal value that is
 passed in for the connector.
 
 This is backwards incompatible for the special situation of the literal string
diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt
index dac48a4363..bb7f2dbb73 100644
--- a/docs/releases/1.3-alpha-1.txt
+++ b/docs/releases/1.3-alpha-1.txt
@@ -156,7 +156,7 @@ requests. These include:
   requests in tests.
 
 * A new test assertion --
-  :meth:`~django.test.client.Client.assertNumQueries` -- making it
+  :meth:`~django.test.TestCase.assertNumQueries` -- making it
   easier to test the database activity associated with a view.
 
 
diff --git a/docs/releases/1.4-alpha-1.txt b/docs/releases/1.4-alpha-1.txt
index b5ec782f09..3c6f7e9b27 100644
--- a/docs/releases/1.4-alpha-1.txt
+++ b/docs/releases/1.4-alpha-1.txt
@@ -357,8 +357,8 @@ Extended IPv6 support
 
 The previously added support for IPv6 addresses when using the runserver
 management command in Django 1.3 has now been further extended by adding
-a :class:`~django.db.models.fields.GenericIPAddressField` model field,
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
+a :class:`~django.db.models.GenericIPAddressField` model field,
+a :class:`~django.forms.GenericIPAddressField` form field and
 the validators :data:`~django.core.validators.validate_ipv46_address` and
 :data:`~django.core.validators.validate_ipv6_address`
 
diff --git a/docs/releases/1.4-beta-1.txt b/docs/releases/1.4-beta-1.txt
index 88f32ea15f..2a1041bcd0 100644
--- a/docs/releases/1.4-beta-1.txt
+++ b/docs/releases/1.4-beta-1.txt
@@ -395,8 +395,8 @@ Extended IPv6 support
 
 The previously added support for IPv6 addresses when using the runserver
 management command in Django 1.3 has now been further extended by adding
-a :class:`~django.db.models.fields.GenericIPAddressField` model field,
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
+a :class:`~django.db.models.GenericIPAddressField` model field,
+a :class:`~django.forms.GenericIPAddressField` form field and
 the validators :data:`~django.core.validators.validate_ipv46_address` and
 :data:`~django.core.validators.validate_ipv6_address`
 
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index 9ff42accc5..746ed58945 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -526,8 +526,8 @@ Extended IPv6 support
 ~~~~~~~~~~~~~~~~~~~~~
 
 Django 1.4 can now better handle IPv6 addresses with the new
-:class:`~django.db.models.fields.GenericIPAddressField` model field,
-:class:`~django.forms.fields.GenericIPAddressField` form field and
+:class:`~django.db.models.GenericIPAddressField` model field,
+:class:`~django.forms.GenericIPAddressField` form field and
 the validators :data:`~django.core.validators.validate_ipv46_address` and
 :data:`~django.core.validators.validate_ipv6_address`.
 
@@ -890,7 +890,7 @@ object, Django raises an exception.
 
 The MySQL backend historically has raised :class:`MySQLdb.OperationalError`
 when a query triggered an exception. We've fixed this bug, and we now raise
-:class:`django.db.utils.DatabaseError` instead. If you were testing for
+:exc:`django.db.DatabaseError` instead. If you were testing for
 :class:`MySQLdb.OperationalError`, you'll need to update your ``except``
 clauses.
 
@@ -1092,8 +1092,8 @@ wild, because they would confuse browsers too.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It's now possible to check whether a template was used within a block of
-code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and
-:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
+code with :meth:`~django.test.TestCase.assertTemplateUsed` and
+:meth:`~django.test.TestCase.assertTemplateNotUsed`. And they
 can be used as a context manager::
 
     with self.assertTemplateUsed('index.html'):
diff --git a/docs/releases/1.5-alpha-1.txt b/docs/releases/1.5-alpha-1.txt
index 8fbeafc68b..b167bb1879 100644
--- a/docs/releases/1.5-alpha-1.txt
+++ b/docs/releases/1.5-alpha-1.txt
@@ -391,12 +391,12 @@ System version of :mod:`simplejson` no longer used
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 As explained below, Django 1.5 deprecates
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
 module. In theory, this change is harmless. Unfortunately, because of
 incompatibilities between versions of :mod:`simplejson`, it may trigger errors
 in some circumstances.
 
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
 This module was actually:
 
 - A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -546,8 +546,9 @@ Miscellaneous
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
   ``QuerySet`` as the empty value instead of an empty list.
 
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
-  instead of :exc:`ValueError` for non-integer inputs.
+* :func:`~django.utils.http.int_to_base36` properly raises a
+  :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
+  non-integer inputs.
 
 * The ``slugify`` template filter is now available as a standard python
   function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -584,8 +585,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
 :meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
 the user profile model, should not be used any longer.
 
-Streaming behavior of :class:`HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Streaming behavior of :class:`~django.http.HttpResponse`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Django 1.5 deprecates the ability to stream a response by passing an iterator
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -600,7 +601,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
 :mod:`json` module being available in Python's standard library, so we've
 removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
-instead :mod:`django.utils.simplejson`.
+instead of ``django.utils.simplejson``.
 
 Unfortunately, this change might have unwanted side-effects, because of
 incompatibilities between versions of :mod:`simplejson` -- see the backwards-
diff --git a/docs/releases/1.5-beta-1.txt b/docs/releases/1.5-beta-1.txt
index f3bfc2a8fa..7208d9657c 100644
--- a/docs/releases/1.5-beta-1.txt
+++ b/docs/releases/1.5-beta-1.txt
@@ -416,12 +416,12 @@ System version of :mod:`simplejson` no longer used
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :ref:`As explained below <simplejson-deprecation-beta-1>`, Django 1.5 deprecates
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
 module. In theory, this change is harmless. Unfortunately, because of
 incompatibilities between versions of :mod:`simplejson`, it may trigger errors
 in some circumstances.
 
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
 This module was actually:
 
 - A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -585,8 +585,9 @@ Miscellaneous
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
   ``QuerySet`` as the empty value instead of an empty list.
 
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
-  instead of :exc:`ValueError` for non-integer inputs.
+* :func:`~django.utils.http.int_to_base36` properly raises a
+  :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
+  non-integer inputs.
 
 * The ``slugify`` template filter is now available as a standard python
   function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -636,8 +637,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
 :meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
 the user profile model, should not be used any longer.
 
-Streaming behavior of :class:`HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Streaming behavior of :class:`~django.http.HttpResponse`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Django 1.5 deprecates the ability to stream a response by passing an iterator
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -653,7 +654,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
 :mod:`json` module being available in Python's standard library, so we've
 removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
-instead :mod:`django.utils.simplejson`.
+instead of ``django.utils.simplejson``.
 
 Unfortunately, this change might have unwanted side-effects, because of
 incompatibilities between versions of :mod:`simplejson` -- see the
diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt
index 8259c12cb4..57ac983568 100644
--- a/docs/releases/1.5.txt
+++ b/docs/releases/1.5.txt
@@ -429,12 +429,12 @@ System version of :mod:`simplejson` no longer used
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :ref:`As explained below <simplejson-deprecation>`, Django 1.5 deprecates
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
 module. In theory, this change is harmless. Unfortunately, because of
 incompatibilities between versions of :mod:`simplejson`, it may trigger errors
 in some circumstances.
 
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
 This module was actually:
 
 - A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -598,8 +598,9 @@ Miscellaneous
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
   ``QuerySet`` as the empty value instead of an empty list.
 
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
-  instead of :exc:`ValueError` for non-integer inputs.
+* :func:`~django.utils.http.int_to_base36` properly raises a
+  :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
+  non-integer inputs.
 
 * The ``slugify`` template filter is now available as a standard python
   function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -668,8 +669,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
 :meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
 the user profile model, should not be used any longer.
 
-Streaming behavior of :class:`HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Streaming behavior of :class:`~django.http.HttpResponse`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Django 1.5 deprecates the ability to stream a response by passing an iterator
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -687,7 +688,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
 :mod:`json` module being available in Python's standard library, so we've
 removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
-instead :mod:`django.utils.simplejson`.
+instead of ``django.utils.simplejson``.
 
 Unfortunately, this change might have unwanted side-effects, because of
 incompatibilities between versions of :mod:`simplejson` -- see the
diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
index 3e2b6bbdbf..e7a0ff114e 100644
--- a/docs/topics/auth.txt
+++ b/docs/topics/auth.txt
@@ -284,7 +284,7 @@ Manager functions
         .. versionchanged:: 1.4
            The ``email`` parameter was made optional. The username
            parameter is now checked for emptiness and raises a
-           :exc:`ValueError` in case of a negative result.
+           :exc:`~exceptions.ValueError` in case of a negative result.
 
         Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
 
@@ -558,7 +558,7 @@ Anonymous users
       :meth:`~django.contrib.auth.models.User.delete()`,
       :meth:`~django.contrib.auth.models.User.set_groups()` and
       :meth:`~django.contrib.auth.models.User.set_permissions()` raise
-      :exc:`NotImplementedError`.
+      :exc:`~exceptions.NotImplementedError`.
 
 In practice, you probably won't need to use
 :class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index 90c06ac66a..a869b6afad 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -327,8 +327,8 @@ a primary key of 1, Django will raise ``Entry.DoesNotExist``.
 
 Similarly, Django will complain if more than one item matches the
 :meth:`~django.db.models.query.QuerySet.get` query. In this case, it will raise
-``MultipleObjectsReturned``, which again is an attribute of the model class
-itself.
+:exc:`~django.core.exceptions.MultipleObjectsReturned`, which again is an
+attribute of the model class itself.
 
 
 Other QuerySet methods
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index f3bb13ab03..cefc1667ad 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -456,8 +456,9 @@ zone support.
 
 Fixtures generated with ``USE_TZ = False``, or before Django 1.4, use the
 "naive" format. If your project contains such fixtures, after you enable time
-zone support, you'll see :exc:`RuntimeWarning`\ s when you load them. To get
-rid of the warnings, you must convert your fixtures to the "aware" format.
+zone support, you'll see :exc:`~exceptions.RuntimeWarning`\ s when you load
+them. To get rid of the warnings, you must convert your fixtures to the "aware"
+format.
 
 You can regenerate fixtures with :djadmin:`loaddata` then :djadmin:`dumpdata`.
 Or, if they're small enough, you can simply edit them to add the UTC offset
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 65c6fe2445..0b13ea18be 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -928,7 +928,7 @@ function. Example::
 
     :func:`~django.conf.urls.i18n.i18n_patterns` is only allowed in your root
     URLconf. Using it within an included URLconf will throw an
-    :exc:`ImproperlyConfigured` exception.
+    :exc:`~django.core.exceptions.ImproperlyConfigured` exception.
 
 .. warning::
 
diff --git a/docs/topics/python3.txt b/docs/topics/python3.txt
index e6dc165399..e1d78a10e6 100644
--- a/docs/topics/python3.txt
+++ b/docs/topics/python3.txt
@@ -343,7 +343,7 @@ meaning of ``str`` changed. To test these types, use the following idioms::
     isinstance(myvalue, bytes)                  # replacement for str
 
 Python ≥ 2.6 provides ``bytes`` as an alias for ``str``, so you don't need
-:attr:`six.binary_type`.
+:data:`six.binary_type`.
 
 ``long``
 ~~~~~~~~
@@ -356,7 +356,7 @@ The ``long`` type no longer exists in Python 3. ``1L`` is a syntax error. Use
 ``xrange``
 ~~~~~~~~~~
 
-Import :func:`six.moves.xrange` wherever you use ``xrange``.
+Import ``six.moves.xrange`` wherever you use ``xrange``.
 
 Moved modules
 ~~~~~~~~~~~~~
diff --git a/docs/topics/security.txt b/docs/topics/security.txt
index 169f9ac773..9c4c4bbd9e 100644
--- a/docs/topics/security.txt
+++ b/docs/topics/security.txt
@@ -38,7 +38,7 @@ in unauthorized JavaScript execution, depending on how the browser renders
 imperfect HTML.
 
 It is also important to be particularly careful when using ``is_safe`` with
-custom template tags, the :ttag:`safe` template tag, :mod:`mark_safe
+custom template tags, the :tfilter:`safe` template tag, :mod:`mark_safe
 <django.utils.safestring>`, and when autoescape is turned off.
 
 In addition, if you are using the template system to output something other
@@ -76,8 +76,8 @@ POST to your Web site and have another logged in user unwittingly submit that
 form. The malicious user would have to know the nonce, which is user specific
 (using a cookie).
 
-When deployed with :ref:`HTTPS <security-recommendation-ssl>`, 
-``CsrfViewMiddleware`` will check that the HTTP referer header is set to a 
+When deployed with :ref:`HTTPS <security-recommendation-ssl>`,
+``CsrfViewMiddleware`` will check that the HTTP referer header is set to a
 URL on the same origin (including subdomain and port). Because HTTPS
 provides additional security, it is imperative to ensure connections use HTTPS
 where it is available by forwarding insecure connection requests and using
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index 28f600e223..e36c7587d1 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -193,7 +193,7 @@ This strategy works well for most objects, but it can cause difficulty in some
 circumstances.
 
 Consider the case of a list of objects that have a foreign key referencing
-:class:`~django.contrib.conttenttypes.models.ContentType`. If you're going to
+:class:`~django.contrib.contenttypes.models.ContentType`. If you're going to
 serialize an object that refers to a content type, then you need to have a way
 to refer to that content type to begin with. Since ``ContentType`` objects are
 automatically created by Django during the database synchronization process,
diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt
index 1078d0372c..5ea0895c42 100644
--- a/docs/topics/signals.txt
+++ b/docs/topics/signals.txt
@@ -30,7 +30,7 @@ notifications:
 
 * :data:`django.db.models.signals.m2m_changed`
 
-  Sent when a :class:`ManyToManyField` on a model is changed.
+  Sent when a :class:`~django.db.models.ManyToManyField` on a model is changed.
 
 * :data:`django.core.signals.request_started` &
   :data:`django.core.signals.request_finished`
diff --git a/docs/topics/testing/index.txt b/docs/topics/testing/index.txt
index 0345b72703..94e88bdf04 100644
--- a/docs/topics/testing/index.txt
+++ b/docs/topics/testing/index.txt
@@ -38,7 +38,7 @@ frameworks are:
 
 * **Unit tests** -- tests that are expressed as methods on a Python class
   that subclasses :class:`unittest.TestCase` or Django's customized
-  :class:`TestCase`. For example::
+  :class:`~django.test.TestCase`. For example::
 
       import unittest