Fixed broken links, round 3. refs #19516

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.

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
+    If one of your views receives an :class:`~django.http.HttpRequest` object
-    :attr:`POST parameters<HttpRequest.POST>` susceptible to contain sensitive
+    with :attr:`POST parameters<django.http.HttpRequest.POST>` susceptible to
-    information, you may prevent the values of those parameters from being
+    contain sensitive information, you may prevent the values of those
-    included in the error reports using the ``sensitive_post_parameters``
+    parameters from being included in the error reports using the
-    decorator::
+    ``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``,
+    error reports for certain :mod:`django.contrib.auth.views` views (
-    ``password_reset_confirm``, ``password_change``, and ``add_view`` and
+    ``login``, ``password_reset_confirm``, ``password_change``, and
-    ``user_change_password`` in the ``auth`` admin) to prevent the leaking of
+    ``add_view`` and ``user_change_password`` in the ``auth`` admin) to prevent
-    sensitive information such as user passwords.
+    the leaking of sensitive information such as user passwords.
 
 .. _custom-error-reports:
 

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`,
+Because ``pub_date`` is a :class:`~django.db.models.DateTimeField`, Django
-Django knows to give appropriate filter options: "Any date," "Today," "Past 7
+knows to give appropriate filter options: "Any date," "Today," "Past 7 days,"
-days," "This month," "This year."
+"This month," "This year."
 
 This is shaping up well. Let's add some search capability::
 

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
+* ``request.POST['choice']`` will raise :exc:`~exceptions.KeyError` if
-  provided in POST data. The above code checks for :exc:`KeyError` and
+  ``choice`` wasn't provided in POST data. The above code checks for
-  redisplays the poll form with an error message if ``choice`` isn't given.
+  :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

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.
-

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.DateField` or
-        :class:`~django.db.models.fields.DateTimeField` on the model for which
+        :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

docs/ref/contrib/contenttypes.txt

@@ -234,13 +234,15 @@ lookup::
 
 .. versionadded:: 1.5
 
-Prior to Django 1.5 :meth:`~ContentTypeManager.get_for_model()` and
+Prior to Django 1.5,
-:meth:`~ContentTypeManager.get_for_models()` always returned the
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
-:class:`~django.contrib.contenttypes.models.ContentType` associated with the
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
-concrete model of the specified one(s). That means there was no way to retreive
+always returned the :class:`~django.contrib.contenttypes.models.ContentType`
-the :class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
+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.

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
+Note that if a :class:`~django.forms.Field` defines :attr:`~Form.initial` *and*
-:attr:`~Form.initial` *and* you include ``initial`` when instantiating the
+you include ``initial`` when instantiating the ``Form``, then the latter
-``Form``, then the latter ``initial`` will have precedence. In this example,
+``initial`` will have precedence. In this example, ``initial`` is provided both
-``initial`` is provided both at the field level and at the form instance level,
+at the field level and at the form instance level, and the latter gets
-and the latter gets precedence::
+precedence::
 
     >>> class CommentForm(forms.Form):
     ...     name = forms.CharField(initial='class')

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)

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
+:attr:`~django.forms.extras.widgets.SelectDateWidget.years` attribute is set
-:class:`~django.forms.extras.widgets.SelectDateWidget`::
+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
+        :class:`~datetime.datetime` value into a list with date and time split
-        separate values::
+        into two separate values::
 
             class SplitDateTimeWidget(MultiWidget):
 

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
+The default form widget for this field is a :class:`~django.forms.FileInput`.
-:class:`~django.forms.widgets.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.
 

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>`.

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,
+    When calling :meth:`~django.db.models.Model.save()` for instances with
-    only the loaded fields will be saved. See :meth:`~Model.save()` for more
+    deferred fields, only the loaded fields will be saved. See
-    details.
+    :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,
+    When calling :meth:`~django.db.models.Model.save()` for instances with
-    only the loaded fields will be saved. See :meth:`~Model.save()` for more
+    deferred fields, only the loaded fields will be saved. See
-    details.
+    :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

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.
+Sent when a :class:`~django.db.models.ManyToManyField` is changed on a model
-Strictly speaking, this is not a model signal since it is sent by the
+instance. Strictly speaking, this is not a model signal since it is sent by the
-:class:`ManyToManyField`, but since it complements 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`.
+    The intermediate model class describing the
-    This class is automatically created when a many-to-many field is
+    :class:`~django.db.models.ManyToManyField`. This class is automatically
-    defined; you can access it using the ``through`` attribute on the
+    created when a many-to-many field is defined; you can access it using the
-    many-to-many field.
+    ``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`
+    instance of the ``sender``, or of the class the
-    is related to.
+    :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`,
+``reverse``     ``False`` (``Pizza`` contains the
-                so this call modifies the forward relation)
+                :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`,
+``reverse``     ``True`` (``Pizza`` contains the
-                so this call modifies the reverse relation)
+                :class:`~django.db.models.ManyToManyField`, so this call
+                modifies the reverse relation)
 
 ``model``       ``Pizza`` (the class of the objects removed from the
                 ``Topping``)

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::
 

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
+- They raise :exc:`~exceptions.ValueError` if their input is well formatted but
-  valid date or time.
+  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.

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
+The old :exc:`~exceptions.EnvironmentError` has split into an
-Django fails to find the settings module and a :exc:`RuntimeError` when you try
+:exc:`~exceptions.ImportError` when Django fails to find the settings module
-to reconfigure settings after having already used them
+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
+Managers now return a :exc:`~django.core.exceptions.MultipleObjectsReturned`
-instead of :exc:`AssertionError`:
+exception instead of :exc:`~exceptions.AssertionError`:
 
 Old (0.96)::
 

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

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.
 
 

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.db.models.GenericIPAddressField` model field,
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
+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`
 

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.db.models.GenericIPAddressField` model field,
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
+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`
 

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.db.models.GenericIPAddressField` model field,
-:class:`~django.forms.fields.GenericIPAddressField` form field and
+: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
+code with :meth:`~django.test.TestCase.assertTemplateUsed` and
-:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
+:meth:`~django.test.TestCase.assertTemplateNotUsed`. And they
 can be used as a context manager::
 
     with self.assertTemplateUsed('index.html'):

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`
+* :func:`~django.utils.http.int_to_base36` properly raises a
-  instead of :exc:`ValueError` for non-integer inputs.
+  :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-

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`
+* :func:`~django.utils.http.int_to_base36` properly raises a
-  instead of :exc:`ValueError` for non-integer inputs.
+  :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

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`
+* :func:`~django.utils.http.int_to_base36` properly raises a
-  instead of :exc:`ValueError` for non-integer inputs.
+  :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

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

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
+:exc:`~django.core.exceptions.MultipleObjectsReturned`, which again is an
-itself.
+attribute of the model class itself.
 
 
 Other QuerySet methods

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
+zone support, you'll see :exc:`~exceptions.RuntimeWarning`\ s when you load
-rid of the warnings, you must convert your fixtures to the "aware" format.
+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

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::
 

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
 ~~~~~~~~~~~~~

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

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,

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`

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