Context Navigation

Back to Ticket #9502

Ticket #9502: xref-markup-r9475.diff

File xref-markup-r9475.diff, 111.3 KB (added by Ramiro Morales, 16 years ago)
Patch update to r9475, applies to trunk and 1.0.X added :mod: and some :class:, :data:, :attr: and :exc: prefixes

docs/faq/admin.txt

diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt

-              a
 sent out by Django doesn't match the domain in your browser. Try these two
 things:
     * Set the ``SESSION_COOKIE_DOMAIN`` setting in your admin config file
+    * Set the :setting:`SESSION_COOKIE_DOMAIN` setting in your admin config file
       to match your domain. For example, if you're going to
       "http://www.example.com/admin/" in your browser, in
       "myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.example.com'``.
 …
       don't have dots in them. If you're running the admin site on "localhost"
       or another domain that doesn't have a dot in it, try going to
       "localhost.localdomain" or "127.0.0.1". And set
       ``SESSION_COOKIE_DOMAIN`` accordingly.
+      :setting:`SESSION_COOKIE_DOMAIN` accordingly.
 I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
 -----------------------------------------------------------------------------------------------------------------------------------------------------------
 …
 My "list_filter" contains a ManyToManyField, but the filter doesn't display.
 ----------------------------------------------------------------------------
 Django won't bother displaying the filter for a ``ManyToManyField`` if there
+Django won't bother displaying the filter for a :class:`ManyToManyField` if there
 are fewer than two related objects.
 For example, if your ``list_filter`` includes ``sites``, and there's only one

docs/faq/models.txt

diff --git a/docs/faq/models.txt b/docs/faq/models.txt

-              a
 How can I see the raw SQL queries Django is running?
 ----------------------------------------------------
 Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do
+Make sure your Django :setting:`DEBUG` setting is set to ``True``. Then, just do
 this::
     >>> from django.db import connection
 …
     [{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
     'time': '0.002'}]
 ``connection.queries`` is only available if ``DEBUG`` is ``True``. It's a list
+:data:`connection.queries` is only available if :setting:`DEBUG` is ``True``. It's a list
 of dictionaries in order of query execution. Each dictionary has the following::
     ``sql`` -- The raw SQL statement
     ``time`` -- How long the statement took to execute, in seconds.
 ``connection.queries`` includes all SQL statements -- INSERTs, UPDATES,
+:data:`connection.queries` includes all SQL statements -- INSERTs, UPDATES,
 SELECTs, etc. Each time your app hits the database, the query will be recorded.
 Can I use Django with a pre-existing database?
 …
 Django isn't known to leak memory. If you find your Django processes are
 allocating more and more memory, with no sign of releasing it, check to make
 sure your ``DEBUG`` setting is set to ``False``. If ``DEBUG`` is ``True``, then
+sure your :setting:`DEBUG` setting is set to ``False``. If ``DEBUG`` is ``True``, then
 Django saves a copy of every SQL statement it has executed.
 (The queries are saved in ``django.db.connection.queries``. See
+(The queries are saved in :data:`django.db.connection.queries`. See
 `How can I see the raw SQL queries Django is running?`_.)
 To fix the problem, set ``DEBUG`` to ``False``.
+To fix the problem, set :setting:`DEBUG` to ``False``.
 If you need to clear the query list manually at any point in your functions,
 just call ``reset_queries()``, like this::
+just call :func:`reset_queries`, like this::
     from django import db
     db.reset_queries()

docs/howto/custom-file-storage.txt

diff --git a/docs/howto/custom-file-storage.txt b/docs/howto/custom-file-storage.txt

-              a
 ``_save(name, content)``
 ~~~~~~~~~~~~~~~~~~~~~~~~
 Called by ``Storage.save()``. The ``name`` will already have gone through
 ``get_valid_name()`` and ``get_available_name()``, and the ``content`` will be a
 ``File`` object itself. No return value is expected.
+Called by :meth:`Storage.save`. The ``name`` will already have gone through
+:meth:`get_valid_name` and :meth:`get_available_name`, and the ``content`` will be a
+:class:`File` object itself. No return value is expected.
 ``get_valid_name(name)``
 ------------------------
 …
 server, after having any path information removed. Override this to customize
 how non-standard characters are converted to safe filenames.
 The code provided on ``Storage`` retains only alpha-numeric characters, periods
+The code provided on :class:`Storage` retains only alpha-numeric characters, periods
 and underscores from the original filename, removing everything else.
 ``get_available_name(name)``
 …
 Returns a filename that is available in the storage mechanism, possibly taking
 the provided filename into account. The ``name`` argument passed to this method
 will have already cleaned to a filename valid for the storage system, according
 to the ``get_valid_name()`` method described above.
+to the :meth:`get_valid_name` method described above.
 The code provided on ``Storage`` simply appends underscores to the filename
+The code provided on :class:`Storage` simply appends underscores to the filename
 until it finds one that's available in the destination directory.

docs/howto/custom-model-fields.txt

diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt

-              a
 Alternatively, you may have a complex Python object that can somehow be
 serialized to fit into a standard database column type. This is another case
 where a ``Field`` subclass will help you use your object with your models.
+where a :class:`Field` subclass will help you use your object with your models.
 Our example object
 ------------------
 …
 If you aim to build a database-agnostic application, you should account for
 differences in database column types. For example, the date/time column type
 in PostgreSQL is called ``timestamp``, while the same column in MySQL is called
 ``datetime``. The simplest way to handle this in a ``db_type()`` method is to
+``datetime``. The simplest way to handle this in a :meth:`db_type` method is to
 import the Django settings module and check the :setting:`DATABASE_ENGINE` setting.
 For example::
 …
 .. method:: get_db_prep_save(self, value)
 Same as the above, but called when the Field value must be *saved* to the
 database. As the default implementation just calls ``get_db_prep_value``, you
+database. As the default implementation just calls :meth:`get_db_prep_value`, you
 shouldn't need to implement this method unless your custom field need a special
 conversion when being saved that is not the same as the used for normal query
 parameters (which is implemented by ``get_db_prep_value``).
+parameters (which is implemented by :meth:`get_db_prep_value`).
 Preprocessing values before saving
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 …
 Prepares the ``value`` for passing to the database when used in a lookup (a
 ``WHERE`` constraint in SQL). The ``lookup_type`` will be one of the valid
 Django filter lookups: ``exact``, ``iexact``, ``contains``, ``icontains``,
 ``gt``, ``gte``, ``lt``, ``lte``, ``in``, ``startswith``, ``istartswith``,
 ``endswith``, ``iendswith``, ``range``, ``year``, ``month``, ``day``,
 ``isnull``, ``search``, ``regex``, and ``iregex``.
+Django filter lookups: :lookup:`exact`, :lookup:`iexact`, :lookup:`contains`, :lookup:`icontains`,
+:lookup:`gt`, :lookup:`gte`, :lookup:`lt`, :lookup:`lte`, :lookup:`in`, :lookup:`startswith`, :lookup:`istartswith`,
+:lookup:`endswith`, :lookup:`iendswith`, :lookup:`range`, :lookup:`year`, :lookup:`month`, :lookup:`day`,
+:lookup:`isnull`, :lookup:`search`, :lookup:`regex`, and :lookup:`iregex`.
 Your method must be prepared to handle all of these ``lookup_type`` values and
 should raise either a ``ValueError`` if the ``value`` is of the wrong sort (a
+should raise either a :exc:`ValueError` if the ``value`` is of the wrong sort (a
 list when you were expecting an object, for example) or a ``TypeError`` if
 your field does not support that type of lookup. For many fields, you can get
 by with handling the lookup types that need special handling for your field
 and pass the rest of the :meth:`get_db_prep_lookup` method of the parent class.
 If you needed to implement ``get_db_prep_save()``, you will usually need to
 implement ``get_db_prep_lookup()``. If you don't, ``get_db_prep_value`` will be
 called by the default implementation, to manage ``exact``, ``gt``, ``gte``,
 ``lt``, ``lte``, ``in`` and ``range`` lookups.
+If you needed to implement :meth:`get_db_prep_save`, you will usually need to
+implement :meth:`get_db_prep_lookup`. If you don't, :meth:`get_db_prep_value` will be
+called by the default implementation, to manage :lookup:`exact`, :lookup:`gt`, :lookup:`gte`,
+:lookup:`lt`, :lookup:`lte`, :lookup:`in` and :lookup:`range` lookups.
 You may also want to implement this method to limit the lookup types that could
 be used with your custom field type.
 Note that, for ``range`` and ``in`` lookups, ``get_db_prep_lookup`` will receive
+Note that, for :lookup:`range` and :lookup:`in` lookups, :meth:`get_db_prep_lookup` will receive
 a list of objects (presumably of the right type) and will need to convert them
 to a list of things of the right type for passing to the database. Most of the
 time, you can reuse ``get_db_prep_value()``, or at least factor out some common
+time, you can reuse :meth:`get_db_prep_value`, or at least factor out some common
 pieces.
 For example, the following code implements ``get_db_prep_lookup`` to limit the
 accepted lookup types to ``exact`` and ``in``::
+For example, the following code implements :meth:`get_db_prep_lookup` to limit the
+accepted lookup types to :lookup:`exact` and ``in``::
     class HandField(models.Field):
         # ...
 …
 In addition to the above methods, fields that deal with files have a few other
 special requirements which must be taken into account. The majority of the
 mechanics provided by ``FileField``, such as controlling database storage and
+mechanics provided by :class:`FileField`, such as controlling database storage and
 retrieval, can remain unchanged, leaving subclasses to deal with the challenge
 of supporting a particular type of file.
 Django provides a ``File`` class, which is used as a proxy to the file's
+Django provides a :class:`File` class, which is used as a proxy to the file's
 contents and operations. This can be subclassed to customize how the file is
 accessed, and what methods are available. It lives at
 ``django.db.models.fields.files``, and its default behavior is explained in the
+:mod:`django.db.models.fields.files`, and its default behavior is explained in the
 :ref:`file documentation <ref-files-file>`.
 Once a subclass of ``File`` is created, the new ``FileField`` subclass must be
 told to use it. To do so, simply assign the new ``File`` subclass to the special
 ``attr_class`` attribute of the ``FileField`` subclass.
+Once a subclass of :class:`File` is created, the new :class:`FileField` subclass must be
+told to use it. To do so, simply assign the new :class:`File` subclass to the special
+:attr:`attr_class` attribute of the ``FileField`` subclass.
 A few suggestions
 ------------------
 …
 In addition to the above details, there are a few guidelines which can greatly
 improve the efficiency and readability of the field's code.
 . The source for Django's own ``ImageField`` (in
+. The source for Django's own :class:`ImageField` (in
        ``django/db/models/fields/files.py``) is a great example of how to
        subclass ``FileField`` to support a particular type of file, as it
        incorporates all of the techniques described above.

docs/howto/custom-template-tags.txt

diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt

-              a
 the given Python module name, not the name of the app.
 To be a valid tag library, the module must contain a module-level variable
 named ``register`` that is a ``template.Library`` instance, in which all the
+named ``register`` that is a :class:`template.Library` instance, in which all the
 tags and filters are registered. So, near the top of your module, put the
 following::
 …
         return value.lower()
 This way, you'll be able to pass, say, an integer to this filter, and it
 won't cause an ``AttributeError`` (because integers don't have ``lower()``
+won't cause an :exc:`AttributeError` (because integers don't have ``lower()``
 methods).
 Registering custom filters
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 Once you've written your filter definition, you need to register it with
 your ``Library`` instance, to make it available to Django's template language::
+your :class:`Library` instance, to make it available to Django's template language::
     register.filter('cut', cut)
     register.filter('lower', lower)
 The ``Library.filter()`` method takes two arguments:
+The :meth:`Library.filter` method takes two arguments:
 . The name of the filter -- a string.
 . The compilation function -- a Python function (not the name of the
        function as a string).
 If you're using Python 2.4 or above, you can use ``register.filter()`` as a
+If you're using Python 2.4 or above, you can use :func:`register.filter` as a
 decorator instead::
     @register.filter(name='cut')
 …
       They're commonly used for output that contains raw HTML that is intended
       to be interpreted as-is on the client side.
       Internally, these strings are of type ``SafeString`` or ``SafeUnicode``.
       They share a common base class of ``SafeData``, so you can test
+      Internally, these strings are of type :class:`SafeString` or :class:`SafeUnicode`.
+      They share a common base class of :class:`SafeData`, so you can test
       for them using code like::
           if isinstance(value, SafeData):
 …
       These strings are only escaped once, however, even if auto-escaping
       applies.
       Internally, these strings are of type ``EscapeString`` or
       ``EscapeUnicode``. Generally you don't have to worry about these; they
+      Internally, these strings are of type :class:`EscapeString` or
+      :class:`EscapeUnicode`. Generally you don't have to worry about these; they
       exist for the implementation of the ``escape`` filter.
 Template filter code falls into one of two situations:
 …
        introduce any possibility of unsafe HTML."
        The reason ``is_safe`` is necessary is because there are plenty of
        normal string operations that will turn a ``SafeData`` object back into
+       normal string operations that will turn a :class:`SafeData` object back into
        a normal ``str`` or ``unicode`` object and, rather than try to catch
        them all, which would be very difficult, Django repairs the damage after
        the filter has completed.
 …
        ``autoescape`` keyword argument mean that our function will know whether
        automatic escaping is in effect when the filter is called. We use
        ``autoescape`` to decide whether the input data needs to be passed
        through ``django.utils.html.conditional_escape`` or not. (In the latter
+       through :func:`django.utils.html.conditional_escape` or not. (In the latter
        case, we just use the identity function as the "escape" function.) The
        ``conditional_escape()`` function is like ``escape()`` except it only
        escapes input that is **not** a ``SafeData`` instance. If a ``SafeData``
+       :func:`conditional_escape` function is like :func:`escape` except it only
+       escapes input that is **not** a :class:`SafeData` instance. If a ``SafeData``
        instance is passed to ``conditional_escape()``, the data is returned
        unchanged.
 …
 how the compilation works and how the rendering works.
 When Django compiles a template, it splits the raw template text into
 ''nodes''. Each node is an instance of ``django.template.Node`` and has
 a ``render()`` method. A compiled template is, simply, a list of ``Node``
+''nodes''. Each node is an instance of :class:`django.template.Node` and has
+a ``render()`` method. A compiled template is, simply, a list of :class:`Node`
 objects. When you call ``render()`` on a compiled template object, the template
 calls ``render()`` on each ``Node`` in its node list, with the given context.
 The results are all concatenated together to form the output of the template.
 …
 .. _`strftime syntax`: http://docs.python.org/library/time.html#time.strftime
 The parser for this function should grab the parameter and create a ``Node``
+The parser for this function should grab the parameter and create a :class:`Node`
 object::
     from django import template
 …
     * ``token.contents`` is a string of the raw contents of the tag. In our
       example, it's ``'current_time "%Y-%m-%d %I:%M %p"'``.
     * The ``token.split_contents()`` method separates the arguments on spaces
+    * The :meth:`token.split_contents` method separates the arguments on spaces
       while keeping quoted strings together. The more straightforward
       ``token.contents.split()`` wouldn't be as robust, as it would naively
+      :func:`token.contents.split` wouldn't be as robust, as it would naively
       split on *all* spaces, including those within quoted strings. It's a good
       idea to always use ``token.split_contents()``.
+      idea to always use :meth:`token.split_contents`.
     * This function is responsible for raising
       ``django.template.TemplateSyntaxError``, with helpful messages, for
+      :exc:`django.template.TemplateSyntaxError`, with helpful messages, for
       any syntax error.
     * The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
+    * The :exc:`TemplateSyntaxError` exceptions use the ``tag_name`` variable.
       Don't hard-code the tag's name in your error messages, because that
       couples the tag's name to your function. ``token.contents.split()[0]``
       will ''always'' be the name of your tag -- even when the tag has no
 …
 Writing the renderer
 ~~~~~~~~~~~~~~~~~~~~
 The second step in writing custom tags is to define a ``Node`` subclass that
 has a ``render()`` method.
+The second step in writing custom tags is to define a :class:`Node` subclass that
+has a :meth:`render` method.
 Continuing the above example, we need to define ``CurrentTimeNode``::
 …
 Also, if your template tag creates a new context for performing some
 sub-rendering, set the auto-escape attribute to the current context's value.
 The ``__init__`` method for the ``Context`` class takes a parameter called
+The ``__init__`` method for the :class:`Context` class takes a parameter called
 ``autoescape`` that you can use for this purpose. For example::
     def render(self, context):
 …
 Registering the tag
 ~~~~~~~~~~~~~~~~~~~
 Finally, register the tag with your module's ``Library`` instance, as explained
+Finally, register the tag with your module's :class:`Library` instance, as explained
 in "Writing custom template filters" above. Example::
     register.tag('current_time', do_current_time)
 …
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Although you can pass any number of arguments to a template tag using
 ``token.split_contents()``, the arguments are all unpacked as
+:meth:`token.split_contents`, the arguments are all unpacked as
 string literals. A little more work is required in order to pass dynamic
 content (a template variable) to a template tag as an argument.
 While the previous examples have formatted the current time into a string and
 returned the string, suppose you wanted to pass in a ``DateTimeField`` from an
+returned the string, suppose you wanted to pass in a :class:`DateTimeField` from an
 object and have the template tag format that date-time:
 .. code-block:: html+django
     <p>This post was last updated at {% format_time blog_entry.date_updated "%Y-%m-%d %I:%M %p" %}.</p>
 Initially, ``token.split_contents()`` will return three values:
+Initially, :meth:`token.split_contents` will return three values:
 . The tag name ``format_time``.
 . The string "blog_entry.date_updated" (without the surrounding quotes).
 …
 .. versionchanged:: 1.0
     Variable resolution has changed in the 1.0 release of Django. ``template.resolve_variable()``
     has been deprecated in favor of a new ``template.Variable`` class.
+    has been deprecated in favor of a new :class:`template.Variable` class.
 You also have to change the renderer to retrieve the actual contents of the
 ``date_updated`` property of the ``blog_entry`` object.  This can be
 accomplished by using the ``Variable()`` class in ``django.template``.
+accomplished by using the :class:`Variable` class in :mod:`django.template`.
 To use the ``Variable`` class, simply instantiate it with the name of the
+To use the :class:`Variable` class, simply instantiate it with the name of the
 variable to be resolved, and then call ``variable.resolve(context)``. So,
 for example::
 …
             except template.VariableDoesNotExist:
                 return ''
 Variable resolution will throw a ``VariableDoesNotExist`` exception if it cannot
+Variable resolution will throw a :exc:`VariableDoesNotExist` exception if it cannot
 resolve the string passed to it in the current context of the page.
 Shortcut for simple tags
 …
 To ease the creation of the types of tags, Django provides a helper function,
 ``simple_tag``. This function, which is a method of
 ``django.template.Library``, takes a function that accepts any number of
+:class:`django.template.Library`, takes a function that accepts any number of
 arguments, wraps it in a ``render`` function and the other necessary bits
 mentioned above and registers it with the template system.
 …
     </ul>
 Now, create and register the inclusion tag by calling the ``inclusion_tag()``
 method on a ``Library`` object. Following our example, if the above template is
+method on a :class:`Library` object. Following our example, if the above template is
 in a file called ``results.html`` in a directory that's searched by the template
 loader, we'd register the tag like this::
 …
 (Note that the first parameter to the function *must* be called ``context``.)
 In that ``register.inclusion_tag()`` line, we specified ``takes_context=True``
+In that :func:`register.inclusion_tag` line, we specified ``takes_context=True``
 and the name of the template. Here's what the template ``link.html`` might look
 like:
 …
             return ''
 ``parser.parse()`` takes a tuple of names of block tags ''to parse until''. It
 returns an instance of ``django.template.NodeList``, which is a list of
 all ``Node`` objects that the parser encountered ''before'' it encountered
+returns an instance of :class:`django.template.NodeList`, which is a list of
+all :class:`Node` objects that the parser encountered ''before'' it encountered
 any of the tags named in the tuple.
 In ``"nodelist = parser.parse(('endcomment',))"`` in the above example,
 …
 After ``parser.parse()`` is called, the parser hasn't yet "consumed" the
 ``{% endcomment %}`` tag, so the code needs to explicitly call
 ``parser.delete_first_token()``.
+:func:`parser.delete_first_token`.
 ``CommentNode.render()`` simply returns an empty string. Anything between
 ``{% comment %}`` and ``{% endcomment %}`` is ignored.

docs/howto/deployment/fastcgi.txt

diff --git a/docs/howto/deployment/fastcgi.txt b/docs/howto/deployment/fastcgi.txt

-              a
 In the cases where Django cannot work out the prefix correctly and where you
 want the original value to be used in URLs, you can set the
 ``FORCE_SCRIPT_NAME`` setting in your main ``settings`` file. This sets the
+:setting:`FORCE_SCRIPT_NAME` setting in your main ``settings`` file. This sets the
 script name uniformly for every URL served via that settings file. Thus you'll
 need to use different settings files if you want different sets of URLs to
 have different script names in this case, but that is a rare situation.

docs/howto/static-files.txt

diff --git a/docs/howto/static-files.txt b/docs/howto/static-files.txt

-              a
 This code is straightforward. It imports the settings and checks the value of
 the :setting:`DEBUG` setting. If it evaluates to ``True``, then ``site_media``
 will be associated with the ``django.views.static.serve`` view. If not, then the
+will be associated with the :func:`django.views.static.serve` view. If not, then the
 view won't be made available.
 Of course, the catch here is that you'll have to remember to set ``DEBUG=False``

docs/internals/committers.txt

diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt

-              a
     University of Houston who enjoys studying legal topics related to
     intellectual property and spatial law.
     Justin is the primary developer of ``django.contrib.gis``, a.k.a.
+    Justin is the primary developer of :mod:`django.contrib.gis`, a.k.a.
     GeoDjango_.
 .. _GeoDjango: http://geodjango.org/

docs/internals/contributing.txt

diff --git a/docs/internals/contributing.txt b/docs/internals/contributing.txt

-              a
     ./runtests.py --settings=path.to.django.settings
 Yes, the unit tests need a settings module, but only for database connection
 info, with the ``DATABASE_ENGINE`` setting.
+info, with the :setting:`DATABASE_ENGINE` setting.
 If you're using the ``sqlite3`` database backend, no further settings are
 needed. A temporary database will be created in memory when running the tests.
 …
 You will also need to ensure that your database uses UTF-8 as the default
 character set. If your database server doesn't use UTF-8 as a default charset,
 you will need to include a value for ``TEST_DATABASE_CHARSET`` in your settings
+you will need to include a value for :setting:`TEST_DATABASE_CHARSET` in your settings
 file.
 If you want to run the full suite of tests, you'll need to install a number of

docs/intro/tutorial01.txt

diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt

-              a
     * :setting:`DATABASE_NAME` -- The name of your database. If you're using
       SQLite, the database will be a file on your computer; in that case,
       ``DATABASE_NAME`` should be the full absolute path, including filename, of
+      :setting:`DATABASE_NAME` should be the full absolute path, including filename, of
       that file. If the file doesn't exist, it will automatically be created
       when you synchronize the database for the first time (see below).

docs/misc/api-stability.txt

diff --git a/docs/misc/api-stability.txt b/docs/misc/api-stability.txt

-              a
 ``django.utils``
 ----------------
 Most of the modules in ``django.utils`` are designed for internal use. Only the following parts of ``django.utils`` can be considered stable:
+Most of the modules in :mod:`django.utils` are designed for internal use. Only the following parts of :mod:`django.utils` can be considered stable:
     - ``django.utils.cache``
     - ``django.utils.datastructures.SortedDict`` -- only this single class; the
+    - :mod:`django.utils.cache`
+    - :class:`django.utils.datastructures.SortedDict` -- only this single class; the
       rest of the module is for internal use.
     - ``django.utils.encoding``
     - ``django.utils.feedgenerator``
     - ``django.utils.http``
     - ``django.utils.safestring``
     - ``django.utils.translation``
     - ``django.utils.tzinfo``
+    - :mod:`django.utils.encoding`
+    - :mod:`django.utils.feedgenerator`
+    - :mod:`django.utils.http`
+    - :mod:`django.utils.safestring`
+    - :mod:`django.utils.translation`
+    - :mod:`django.utils.tzinfo`
 Exceptions
 ==========
 …
 ``django.contrib.flatpages``, we'll make sure you can still use the Django 1.4
 version alongside Django 1.5. This will continue to allow for easy upgrades.
 Historically, apps in ``django.contrib`` have been more stable than the core, so
+Historically, apps in :mod:`django.contrib` have been more stable than the core, so
 in practice we probably won't have to ever make this exception. However, it's
 worth noting if you're building apps that depend on ``django.contrib``.
+worth noting if you're building apps that depend on :mod:`django.contrib`.
 APIs marked as internal
 -----------------------

docs/misc/design-philosophies.txt

diff --git a/docs/misc/design-philosophies.txt b/docs/misc/design-philosophies.txt

-              a
 This is why developers need to call ``save()`` explicitly, rather than the
 framework saving things behind the scenes silently.
 This is also why the ``select_related()`` ``QuerySet`` method exists. It's an
+This is also why the ``select_related()`` :class:`QuerySet` method exists. It's an
 optional performance booster for the common case of selecting "every related
 object."

docs/ref/contrib/admin.txt

diff --git a/docs/ref/contrib/admin.txt b/docs/ref/contrib/admin.txt

-              a
 There are five steps in activating the Django admin site:
 . Add ``django.contrib.admin`` to your ``INSTALLED_APPS`` setting.
+. Add ``django.contrib.admin`` to your :setting:`INSTALLED_APPS` setting.
 . Determine which of your application's models should be editable in the
        admin interface.
 …
 dictionary of information about the fieldset, including a list of fields to be
 displayed in it.
 A full example, taken from the ``django.contrib.flatpages.FlatPage`` model::
+A full example, taken from the :class:`django.contrib.flatpages.FlatPage` model::
     class FlatPageAdmin(admin.ModelAdmin):
         fieldsets = (
 …
 Use this option as an alternative to ``fieldsets`` if the layout does not
 matter and if you want to only show a subset of the available fields in the
 form. For example, you could define a simpler version of the admin form for
 the ``django.contrib.flatpages.FlatPage`` model as follows::
+the :class:`django.contrib.flatpages.FlatPage` model as follows::
     class FlatPageAdmin(admin.ModelAdmin):
         fields = ('url', 'title', 'content')
 …
 field should be either a ``BooleanField``, ``CharField``, ``DateField``,
 ``DateTimeField``, ``IntegerField`` or ``ForeignKey``.
 This example, taken from the ``django.contrib.auth.models.User`` model, shows
+This example, taken from the :class:`django.contrib.auth.models.User` model, shows
 how both ``list_display`` and ``list_filter`` work::
     class UserAdmin(admin.ModelAdmin):
 …
         radio_fields = {"group": admin.VERTICAL}
 You have the choice of using ``HORIZONTAL`` or ``VERTICAL`` from the
 ``django.contrib.admin`` module.
+:mod:`django.contrib.admin` module.
 Don't include a field in ``radio_fields`` unless it's a ``ForeignKey`` or has
 ``choices`` set.
 …
+            }
             js = ("my_code.js",)
 Keep in mind that this will be prepended with ``MEDIA_URL``. The same rules
+Keep in mind that this will be prepended with :setting:`MEDIA_URL`. The same rules
 apply as :ref:`regular media definitions on forms <topics-forms-media>`.
 Adding custom validation to the admin
 …
 If you want to allow editing and creating ``Image`` instance on the ``Product``
 add/change views you can simply use ``GenericInlineModelAdmin`` provided by
 ``django.contrib.contenttypes.generic``. In your ``admin.py`` for this
+:mod:`django.contrib.contenttypes.generic`. In your ``admin.py`` for this
 example app::
     from django.contrib import admin
 …
     admin.site.register(Product, ProductAdmin)
 ``django.contrib.contenttypes.generic`` provides both a ``GenericTabularInline``
+:mod:`django.contrib.contenttypes.generic` provides both a ``GenericTabularInline``
 and ``GenericStackedInline`` and behave just like any other inline. See the
 :ref:`contenttypes documentation <ref-contrib-contenttypes>` for more specific
 information.
 …
 In order to override one or more of them, first create an ``admin`` directory in
 your project's ``templates`` directory. This can be any of the directories you
 specified in ``TEMPLATE_DIRS``.
+specified in :setting:`TEMPLATE_DIRS`.
 Within this ``admin`` directory, create sub-directories named after your app.
 Within these app subdirectories create sub-directories named after your models.
 …
 =====================
 A Django administrative site is represented by an instance of
 ``django.contrib.admin.sites.AdminSite``; by default, an instance of
+:class:`django.contrib.admin.sites.AdminSite`; by default, an instance of
 this class is created as ``django.contrib.admin.site`` and you can
 register your models and ``ModelAdmin`` instances with it.
 …
+    )
 Above we used ``admin.autodiscover()`` to automatically load the
 ``INSTALLED_APPS`` admin.py modules.
+:setting:`INSTALLED_APPS` admin.py modules.
 In this example, we register the ``AdminSite`` instance
 ``myproject.admin.admin_site`` at the URL ``/myadmin/`` ::

docs/ref/contrib/comments/settings.txt

diff --git a/docs/ref/contrib/comments/settings.txt b/docs/ref/contrib/comments/settings.txt

-              a
 COMMENTS_APP
 ------------
 The app (i.e. entry in ``INSTALLED_APPS``) responsible for all "business logic."
+The app (i.e. entry in :setting:`INSTALLED_APPS`) responsible for all "business logic."
 You can change this to provide custom comment models and forms, though this is
 currently undocumented.

docs/ref/contrib/index.txt

diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt

-              a
     For most of these add-ons -- specifically, the add-ons that include either
     models or template tags -- you'll need to add the package name (e.g.,
     ``'django.contrib.admin'``) to your ``INSTALLED_APPS`` setting and re-run
+    ``'django.contrib.admin'``) to your :setting:`INSTALLED_APPS` setting and re-run
     ``manage.py syncdb``.
 .. _"batteries included" philosophy: http://docs.python.org/tut/node12.html#batteries-included
 …
 ===========
 A collection of various Django snippets that are useful only for a particular
 country or culture. For example, ``django.contrib.localflavor.us.forms``
+country or culture. For example, :mod:`django.contrib.localflavor.us.forms`
 contains a ``USZipCodeField`` that you can use to validate U.S. zip codes.
 See the :ref:`localflavor documentation <ref-contrib-localflavor>`.

docs/ref/contrib/localflavor.txt

diff --git a/docs/ref/contrib/localflavor.txt b/docs/ref/contrib/localflavor.txt

-              a
     * `United Kingdom`_
     * `United States of America`_
 The ``django.contrib.localflavor`` package also includes a ``generic`` subpackage,
+The :mod:`django.contrib.localflavor` package also includes a ``generic`` subpackage,
 containing useful code that is not specific to one particular country or
 culture. Currently, it defines date and datetime input fields based on those
 from :ref:`forms <topics-forms-index>`, but with non-US default formats.

docs/ref/contrib/webdesign.txt

diff --git a/docs/ref/contrib/webdesign.txt b/docs/ref/contrib/webdesign.txt

-              a
    :synopsis: Helpers and utilities targeted primarily at Web *designers*
               rather than Web *developers*.
 The ``django.contrib.webdesign`` package, part of the
+The :mod:`django.contrib.webdesign` package, part of the
 :ref:`"django.contrib" add-ons <ref-contrib-index>`, provides various Django
 helpers that are particularly useful to Web *designers* (as opposed to
 developers).

docs/ref/databases.txt

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt

-              a
        :setting:`DATABASE_PORT`
 . MySQL option files.
 In other words, if you set the name of the database in ``DATABASE_OPTIONS``,
 this will take precedence over ``DATABASE_NAME``, which would override
+In other words, if you set the name of the database in :setting:`DATABASE_OPTIONS`,
+this will take precedence over :setting:`DATABASE_NAME`, which would override
 anything in a `MySQL option file`_.
 Here's a sample configuration which uses a MySQL option file::

docs/ref/django-admin.txt

diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt

-              a
 ---------
 Many subcommands take a list of "app names." An "app name" is the basename of
 the package containing your models. For example, if your ``INSTALLED_APPS``
+the package containing your models. For example, if your :setting:`INSTALLED_APPS`
 contains the string ``'mysite.blog'``, the app name is ``blog``.
 Determining the version
 …
 it when running interactively.
 This command is only available if Django's :ref:`authentication system
 <topics-auth>` (``django.contrib.auth``) is installed.
+<topics-auth>` (:mod:`django.contrib.auth`) is installed.
 dbshell
 -------
 …
 .. django-admin:: dbshell
 Runs the command-line client for the database engine specified in your
 ``DATABASE_ENGINE`` setting, with the connection parameters specified in your
 ``DATABASE_USER``, ``DATABASE_PASSWORD``, etc., settings.
+:setting:`DATABASE_ENGINE` setting, with the connection parameters specified in your
+:setting:`DATABASE_USER`, :setting:`DATABASE_PASSWORD`, etc., settings.
     * For PostgreSQL, this runs the ``psql`` command-line client.
     * For MySQL, this runs the ``mysql`` command-line client.
 …
 settings.
 Settings that don't appear in the defaults are followed by ``"###"``. For
 example, the default settings don't define ``ROOT_URLCONF``, so
+example, the default settings don't define :setting:`ROOT_URLCONF`, so
 ``ROOT_URLCONF`` is followed by ``"###"`` in the output of ``diffsettings``.
 Note that Django's default settings live in ``django/conf/global_settings.py``,
 …
 ---------
 Introspects the database tables in the database pointed-to by the
 ``DATABASE_NAME`` setting and outputs a Django model module (a ``models.py``
+:setting:`DATABASE_NAME` setting and outputs a Django model module (a ``models.py``
 file) to standard output.
 Use this if you have a legacy database with which you'd like to use Django.
 …
 Django will search in three locations for fixtures:
 . In the ``fixtures`` directory of every installed application
 . In any directory named in the ``FIXTURE_DIRS`` setting
+. In any directory named in the :setting:`FIXTURE_DIRS` setting
 . In the literal path named by the fixture
 Django will load any and all fixtures it finds in these locations that match
 …
 would search ``<appname>/fixtures/foo/bar/mydata.json`` for each installed
 application,  ``<dirname>/foo/bar/mydata.json`` for each directory in
 ``FIXTURE_DIRS``, and the literal path ``foo/bar/mydata.json``.
+:setting:`FIXTURE_DIRS`, and the literal path ``foo/bar/mydata.json``.
 Note that the order in which fixture files are processed is undefined. However,
 all fixture data is installed as a single transaction, so data in
 …
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 By default, the development server doesn't serve any static files for your site
 (such as CSS files, images, things under ``MEDIA_URL`` and so forth). If
+(such as CSS files, images, things under :setting:`MEDIA_URL` and so forth). If
 you want to configure Django to serve static media, read :ref:`howto-static-files`.
 Turning off auto-reload
 …
 syncdb
 ------
 Creates the database tables for all apps in ``INSTALLED_APPS`` whose tables
+Creates the database tables for all apps in :setting:`INSTALLED_APPS` whose tables
 have not already been created.
 Use this command when you've added new applications to your project and want to
 install them in the database. This includes any apps shipped with Django that
 might be in ``INSTALLED_APPS`` by default. When you start a new project, run
+might be in :setting:`INSTALLED_APPS` by default. When you start a new project, run
 this command to install the default apps.
 .. admonition:: Syncdb will not alter existing tables
 …
    to match, use the ``sql`` command to display the new SQL structure and
    compare that to your existing table schema to work out the changes.
 If you're installing the ``django.contrib.auth`` application, ``syncdb`` will
+If you're installing the :mod:`django.contrib.auth` application, ``syncdb`` will
 give you the option of creating a superuser immediately.
 ``syncdb`` will also search for and install any fixture named ``initial_data``
 …
 validate
 --------
 Validates all installed models (according to the ``INSTALLED_APPS`` setting)
+Validates all installed models (according to the :setting:`INSTALLED_APPS` setting)
 and prints validation errors to standard output.
 Default options

docs/ref/forms/api.txt

diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt

-              a
 Accessing "clean" data
 ----------------------
 Each ``Field`` in a ``Form`` class is responsible not only for validating data,
+Each :class:`Field` in a :class:`Form` class is responsible not only for validating data,
 but also for "cleaning" it -- normalizing it to a consistent format. This is a
 nice feature, because it allows data for a particular field to be input in
 a variety of ways, always resulting in consistent output.
 For example, ``DateField`` normalizes input into a Python ``datetime.date``
+For example, :class:`DateField` normalizes input into a Python ``datetime.date``
 object. Regardless of whether you pass it a string in the format
 ``'1994-07-15'``, a ``datetime.date`` object or a number of other formats,
 ``DateField`` will always normalize it to a ``datetime.date`` object as long as
 it's valid.
 Once you've created a ``Form`` instance with a set of data and validated it,
 you can access the clean data via the ``cleaned_data`` attribute of the ``Form``
+Once you've created a :class:`Form` instance with a set of data and validated it,
+you can access the clean data via the :attr:`cleaned_data` attribute of the ``Form``
 object::
     >>> data = {'subject': 'hello',
 …
     {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
 .. versionchanged:: 1.0
     The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases.
+    The :attr:`cleaned_data` attribute was called ``clean_data`` in earlier releases.
 Note that any text-based field -- such as ``CharField`` or ``EmailField`` --
+Note that any text-based field -- such as :class:`CharField` or :class:`EmailField` --
 always cleans the input into a Unicode string. We'll cover the encoding
 implications later in this document.
 If your data does *not* validate, your ``Form`` instance will not have a
 ``cleaned_data`` attribute::
+If your data does *not* validate, your :class:`Form` instance will not have a
+:attr:`cleaned_data` attribute::
     >>> data = {'subject': '',
     ...         'message': 'Hi there',
 …
     ...
     AttributeError: 'ContactForm' object has no attribute 'cleaned_data'
 ``cleaned_data`` will always *only* contain a key for fields defined in the
 ``Form``, even if you pass extra data when you define the ``Form``. In this
+:attr:`cleaned_data` will always *only* contain a key for fields defined in the
+:class:`Form`, even if you pass extra data when you define the :class:`Form`. In this
 example, we pass a bunch of extra fields to the ``ContactForm`` constructor,
 but ``cleaned_data`` contains only the form's fields::
+but :attr:`cleaned_data` contains only the form's fields::
     >>> data = {'subject': 'hello',
     ...         'message': 'Hi there',
 …
     >>> f.cleaned_data # Doesn't contain extra_field_1, etc.
     {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
 ``cleaned_data`` will include a key and value for *all* fields defined in the
 ``Form``, even if the data didn't include a value for fields that are not
+:attr:`cleaned_data` will include a key and value for *all* fields defined in the
+:class:`Form`, even if the data didn't include a value for fields that are not
 required. In this example, the data dictionary doesn't include a value for the
 ``nick_name`` field, but ``cleaned_data`` includes it, with an empty value::
+``nick_name`` field, but :attr:`cleaned_data` includes it, with an empty value::
     >>> class OptionalPersonForm(Form):
     ...     first_name = CharField()
 …
     >>> f.cleaned_data
     {'nick_name': u'', 'first_name': u'John', 'last_name': u'Lennon'}
 In this above example, the ``cleaned_data`` value for ``nick_name`` is set to an
 empty string, because ``nick_name`` is ``CharField``, and ``CharField``\s treat
+In this above example, the :attr:`cleaned_data` value for ``nick_name`` is set to an
+empty string, because ``nick_name`` is :class:`CharField`, and :class:`CharField`\s treat
 empty values as an empty string. Each field type knows what its "blank" value
 is -- e.g., for ``DateField``, it's ``None`` instead of the empty string. For
+is -- e.g., for :class:`DateField`, it's ``None`` instead of the empty string. For
 full details on each field's behavior in this case, see the "Empty value" note
 for each field in the "Built-in ``Field`` classes" section below.
+for each field in the "Built-in :class:`Field` classes" section below.
 You can write code to perform validation for particular form fields (based on
 their name) or for the form as a whole (considering combinations of various
 …
 Outputting forms as HTML
 ------------------------
 The second task of a ``Form`` object is to render itself as HTML. To do so,
+The second task of a :class:`Form` object is to render itself as HTML. To do so,
 simply ``print`` it::
     >>> f = ContactForm()
 …
       ``</table>`` tags, nor does it include the ``<form>`` and ``</form>``
       tags or an ``<input type="submit">`` tag. It's your job to do that.
     * Each field type has a default HTML representation. ``CharField`` and
       ``EmailField`` are represented by an ``<input type="text">``.
       ``BooleanField`` is represented by an ``<input type="checkbox">``. Note
+    * Each field type has a default HTML representation. :class:`CharField` and
+      :class:`EmailField` are represented by an ``<input type="text">``.
+      :class:`BooleanField` is represented by an ``<input type="checkbox">``. Note
       these are merely sensible defaults; you can specify which HTML to use for
       a given field by using widgets, which we'll explain shortly.
 …
 ``as_p()``
 ~~~~~~~~~~
 ``Form.as_p()`` renders the form as a series of ``<p>`` tags, with each ``<p>``
+:meth:`Form.as_p` renders the form as a series of ``<p>`` tags, with each ``<p>``
 containing one field::
     >>> f = ContactForm()
 …
 ``as_ul()``
 ~~~~~~~~~~~
 ``Form.as_ul()`` renders the form as a series of ``<li>`` tags, with each
+:meth:`Form.as_ul` renders the form as a series of ``<li>`` tags, with each
 ``<li>`` containing one field. It does *not* include the ``<ul>`` or ``</ul>``,
 so that you can specify any HTML attributes on the ``<ul>`` for flexibility::
 …
 ``as_table()``
 ~~~~~~~~~~~~~~
 Finally, ``Form.as_table()`` outputs the form as an HTML ``<table>``. This is
+Finally, :meth:`Form.as_table` outputs the form as an HTML ``<table>``. This is
 exactly the same as ``print``. In fact, when you ``print`` a form object, it
 calls its ``as_table()`` method behind the scenes::
+calls its :meth:`as_table` method behind the scenes::
     >>> f = ContactForm()
     >>> f.as_table()
 …
 This behavior is configurable, though, if you want to change the ``id``
 convention or remove HTML ``id`` attributes and ``<label>`` tags entirely.
 Use the ``auto_id`` argument to the ``Form`` constructor to control the label
+Use the ``auto_id`` argument to the :class:`Form` constructor to control the label
 and ``id`` behavior. This argument must be ``True``, ``False`` or a string.
 If ``auto_id`` is ``False``, then the form output will not include ``<label>``
 …
 Notes on field ordering
 ~~~~~~~~~~~~~~~~~~~~~~~
 In the ``as_p()``, ``as_ul()`` and ``as_table()`` shortcuts, the fields are
+In the :meth:`as_p`, :meth:`as_ul` and :meth:`as_table` shortcuts, the fields are
 displayed in the order in which you define them in your form class. For
 example, in the ``ContactForm`` example, the fields are defined in the order
 ``subject``, ``message``, ``sender``, ``cc_myself``. To reorder the HTML
 …
 How errors are displayed
 ~~~~~~~~~~~~~~~~~~~~~~~~
 If you render a bound ``Form`` object, the act of rendering will automatically
+If you render a bound :class:`Form` object, the act of rendering will automatically
 run the form's validation if it hasn't already happened, and the HTML output
 will include the validation errors as a ``<ul class="errorlist">`` near the
 field. The particular positioning of the error messages depends on the output
 …
 Customizing the error list format
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 By default, forms use ``django.forms.util.ErrorList`` to format validation
+By default, forms use :class:`django.forms.util.ErrorList` to format validation
 errors. If you'd like to use an alternate class for displaying errors, you can
 pass that in at construction time::
 …
 More granular output
 ~~~~~~~~~~~~~~~~~~~~
 The ``as_p()``, ``as_ul()`` and ``as_table()`` methods are simply shortcuts for
+The :meth:`as_p`, :meth:`as_ul` and :meth:`as_table` methods are simply shortcuts for
 lazy developers -- they're not the only way a form object can be displayed.
 To display the HTML for a single field in your form, use dictionary lookup
 …
     >>> print f['message']
     <input type="text" name="message" id="id_message" />
 For a field's list of errors, access the field's ``errors`` attribute. This
+For a field's list of errors, access the field's :attr:`errors` attribute. This
 is a list-like object that is displayed as an HTML ``<ul class="errorlist">``
 when printed::
 …
 .. versionadded:: 1.0
 Dealing with forms that have ``FileField`` and ``ImageField`` fields
+Dealing with forms that have :class:`FileField` and :class:`ImageField` fields
 is a little more complicated than a normal form.
 Firstly, in order to upload files, you'll need to make sure that your
 …
 Secondly, when you use the form, you need to bind the file data. File
 data is handled separately to normal form data, so when your form
 contains a ``FileField`` and ``ImageField``, you will need to specify
+contains a :class:`FileField` and :class:`ImageField`, you will need to specify
 a second argument when you bind your form. So if we extend our
 ContactForm to include an ``ImageField`` called ``mugshot``, we
+ContactForm to include an :class:`ImageField` called ``mugshot``, we
 need to bind the file data containing the mugshot image::
     # Bound form with an image field
 …
     >>> file_data = {'mugshot': SimpleUploadedFile('face.jpg', <file data>)}
     >>> f = ContactFormWithMugshot(data, file_data)
 In practice, you will usually specify ``request.FILES`` as the source
 of file data (just like you use ``request.POST`` as the source of
+In practice, you will usually specify :attr:`request.FILES` as the source
+of file data (just like you use :attr:`request.POST` as the source of
 form data)::
     # Bound form with an image field, data from the request
 …
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 If you're writing reusable views or templates, you may not know ahead of time
 whether your form is a multipart form or not. The ``is_multipart()`` method
+whether your form is a multipart form or not. The :meth:`is_multipart` method
 tells you whether the form requires multipart encoding for submission::
     >>> f = ContactFormWithMugshot()
 …
 Subclassing forms
 -----------------
 If you have multiple ``Form`` classes that share fields, you can use
+If you have multiple :class:`Form` classes that share fields, you can use
 subclassing to remove redundancy.
 When you subclass a custom ``Form`` class, the resulting subclass will
+When you subclass a custom :class:`Form` class, the resulting subclass will
 include all fields of the parent class(es), followed by the fields you define
 in the subclass.
 …
 .. attribute:: Form.prefix
 You can put several Django forms inside one ``<form>`` tag. To give each
 ``Form`` its own namespace, use the ``prefix`` keyword argument::
+:class:`Form` its own namespace, use the ``prefix`` keyword argument::
     >>> mother = PersonForm(prefix="mother")
     >>> father = PersonForm(prefix="father")

docs/ref/forms/fields.txt

diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt

-              a
 .. attribute:: URLField.validator_user_agent
     String used as the user-agent used when checking for a URL's existence.
     Defaults to the value of the ``URL_VALIDATOR_USER_AGENT`` setting.
+    Defaults to the value of the :setting:`URL_VALIDATOR_USER_AGENT` setting.
 Slightly complex built-in ``Field`` classes
 -------------------------------------------

docs/ref/generic-views.txt

diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt

-              a
 "Simple" generic views
 ======================
 The ``django.views.generic.simple`` module contains simple views to handle a
+The :mod:`django.views.generic.simple` module contains simple views to handle a
 couple of common cases: rendering a template when no view logic is needed,
 and issuing a redirect.
 …
       just before rendering the template.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 **Example:**
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       the view's template.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       this is ``False``.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       determining the variable's name.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       determining the variable's name.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       determining the variable's name.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
 …
       It's a bit of a brain-bender, but it's useful in some cases.
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       to use in the template context. By default, this is ``'object'``.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       determining the variable's name.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 **Template name:**
 …
       It's a bit of a brain-bender, but it's useful in some cases.
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       to use in the template context. By default, this is ``'object'``.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
+      to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 **Template name:**
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the
 …
       page. This lets you override the default template name (see below).
     * ``template_loader``: The template loader to use when loading the
       template. By default, it's ``django.template.loader``.
+      template. By default, it's :mod:`django.template.loader`.
     * ``extra_context``: A dictionary of values to add to the template
       context. By default, this is an empty dictionary. If a value in the

docs/ref/request-response.txt

diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt

-              a
     .. versionadded:: 1.0
     A string representing the current encoding used to decode form submission
     data (or ``None``, which means the ``DEFAULT_CHARSET`` setting is used).
+    data (or ``None``, which means the :setting:`DEFAULT_CHARSET` setting is used).
     You can write to this attribute to change the encoding used when accessing
     the form data. Any subsequent attribute accesses (such as reading from
     ``GET`` or ``POST``) will use the new ``encoding`` value.  Useful if you
 …
 .. attribute:: HttpRequest.GET
     A dictionary-like object containing all given HTTP GET parameters. See the
     ``QueryDict`` documentation below.
+    :class:`QueryDict` documentation below.
 .. attribute:: HttpRequest.POST
     A dictionary-like object containing all given HTTP POST parameters. See the
     ``QueryDict`` documentation below.
+    :class:`QueryDict` documentation below.
     It's possible that a request can come in via POST with an empty ``POST``
     dictionary -- if, say, a form is requested via the POST HTTP method but
 …
     A dictionary-like object containing all uploaded files. Each key in
     ``FILES`` is the ``name`` from the ``<input type="file" name="" />``. Each
     value in ``FILES`` is an ``UploadedFile`` object containing the following
+    value in ``FILES`` is an :class:`UploadedFile` object containing the following
     attributes:
         * ``read(num_bytes=None)`` -- Read a number of bytes from the file.
 …
 .. attribute:: HttpRequest.user
     A ``django.contrib.auth.models.User`` object representing the currently
+    A :class:`django.contrib.auth.models.User` object representing the currently
     logged-in user. If the user isn't currently logged in, ``user`` will be set
     to an instance of ``django.contrib.auth.models.AnonymousUser``. You
     can tell them apart with ``is_authenticated()``, like so::
+    to an instance of :class:`django.contrib.auth.models.AnonymousUser`. You
+    can tell them apart with :meth:`is_authenticated`, like so::
         if request.user.is_authenticated():
             # Do something for logged-in users.
 …
     Not defined by Django itself, but will be read if other code (e.g., a custom
     middleware class) sets it. When present, this will be used as the root
     URLconf for the current request, overriding the ``ROOT_URLCONF`` setting.
+    URLconf for the current request, overriding the :setting:`ROOT_URLCONF` setting.
     See :ref:`how-django-processes-a-request` for details.
 Methods
 …
 .. class:: QueryDict
 In an :class:`HttpRequest` object, the ``GET`` and ``POST`` attributes are instances
 of ``django.http.QueryDict``. :class:`QueryDict` is a dictionary-like
+of ``django.http.QueryDict``. ``QueryDict`` is a dictionary-like
 class customized to deal with multiple values for the same key. This is
 necessary because some HTML form elements, notably
 ``<select multiple="multiple">``, pass multiple values for the same key.
 …
 Methods
 -------
 :class:`QueryDict` implements all the standard dictionary methods, because it's
+``QueryDict`` implements all the standard dictionary methods, because it's
 a subclass of dictionary. Exceptions are outlined here:
 .. method:: QueryDict.__getitem__(key)
 …
     Just like the standard dictionary ``setdefault()`` method, except it uses
     ``__setitem__`` internally.
 .. method:: QueryDict.update(other_dict)
+.. method:: QueryDict.update(other_dict)
     Takes either a ``QueryDict`` or standard dictionary. Just like the standard
     dictionary ``update()`` method, except it *appends* to the current
 …
     Like :meth:`items()`, except it includes all values, as a list, for each
     member of the dictionary. For example::
          >>> q = QueryDict('a=1&a=2&a=3')
          >>> q.lists()
          [('a', ['1', '2', '3'])]
 .. method:: QueryDict.urlencode()
     Returns a string of the data in query-string format.
 …
 .. class:: HttpResponse
 In contrast to :class:`HttpRequest` objects, which are created automatically by
 Django, :class:`HttpResponse` objects are your responsibility. Each view you
+Django, ``HttpResponse`` objects are your responsibility. Each view you
 write is responsible for instantiating, populating and returning an
 :class:`HttpResponse`.
+``HttpResponse``.
 The :class:`HttpResponse` class lives in the ``django.http`` module.
+The ``HttpResponse`` class lives in the :mod:`django.http` module.
 Usage
 -----
 …
 ~~~~~~~~~~~~~~~
 Typical usage is to pass the contents of the page, as a string, to the
 :class:`HttpResponse` constructor::
+``HttpResponse`` constructor::
     >>> response = HttpResponse("Here's the text of the Web page.")
     >>> response = HttpResponse("Text only, please.", mimetype="text/plain")
 …
 hard-coded strings. If you use this technique, follow these guidelines:
     * The iterator should return strings.
     * If an :class:`HttpResponse` has been initialized with an iterator as its
       content, you can't use the class:`HttpResponse` instance as a file-like
+    * If an ``HttpResponse`` has been initialized with an iterator as its
+      content, you can't use the ``HttpResponse`` instance as a file-like
       object. Doing so will raise ``Exception``.
 Setting headers
 …
 -------
 .. method:: HttpResponse.__init__(content='', mimetype=None, status=200, content_type=DEFAULT_CONTENT_TYPE)
     Instantiates an ``HttpResponse`` object with the given page content (a
     string) and MIME type. The ``DEFAULT_CONTENT_TYPE`` is ``'text/html'``.
+    string) and MIME type. The :setting:`DEFAULT_CONTENT_TYPE` is ``'text/html'``.
     ``content`` can be an iterator or a string. If it's an iterator, it should
     return strings, and those strings will be joined together to form the
 …
     encoding, which makes it more than just a MIME type specification.
     If ``mimetype`` is specified (not ``None``), that value is used.
     Otherwise, ``content_type`` is used. If neither is given, the
     ``DEFAULT_CONTENT_TYPE`` setting is used.
+    :setting:`DEFAULT_CONTENT_TYPE` setting is used.
 .. method:: HttpResponse.__setitem__(header, value)
 …
 .. method:: HttpResponse.write(content)
     This method makes an :class:`HttpResponse` instance a file-like object.
+    This method makes an ``HttpResponse`` instance a file-like object.
 .. method:: HttpResponse.flush()
     This method makes an :class:`HttpResponse` instance a file-like object.
+    This method makes an ``HttpResponse`` instance a file-like object.
 .. method:: HttpResponse.tell()
     This method makes an :class:`HttpResponse` instance a file-like object.
+    This method makes an ``HttpResponse`` instance a file-like object.
 .. _HTTP Status code: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10
 …
 HttpResponse subclasses
 -----------------------
 Django includes a number of ``HttpResponse`` subclasses that handle different
+Django includes a number of :class:`HttpResponse` subclasses that handle different
 types of HTTP responses. Like ``HttpResponse``, these subclasses live in
 :mod:`django.http`.

docs/ref/settings.txt

diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt

-              a
 The URL prefix for admin media -- CSS, JavaScript and images used by
 the Django administrative interface. Make sure to use a trailing
 slash, and to have this be different from the ``MEDIA_URL`` setting
+slash, and to have this be different from the :setting:`MEDIA_URL` setting
 (since the same URL cannot be mapped onto two different sets of
 files).
 …
 Whether to append trailing slashes to URLs. This is only used if
 ``CommonMiddleware`` is installed (see :ref:`topics-http-middleware`). See also
 ``PREPEND_WWW``.
+:setting:`PREPEND_WWW`.
 .. setting:: AUTHENTICATION_BACKENDS
 …
 Default: ``''`` (Empty string)
 The name of the database to use. For SQLite, it's the full path to the database
 file. When specifying the path, always use forward slashes, even on Windows
+file. When specifying the path, always use forward slashes, even on Windows
 (e.g. ``C:/homes/user/mysite/sqlite3.db``).
 .. setting:: DATABASE_OPTIONS
 …
 default port. Not used with SQLite.
 .. setting:: DATABASE_USER
 DATABASE_USER
 -------------
 …
 and ``MONTH_DAY_FORMAT``.
 .. setting:: DATETIME_FORMAT
 DATETIME_FORMAT
 ---------------
 …
 .. warning::
     **Always prefix the mode with a 0.**
     If you're not familiar with file modes, please note that the leading
     ``0`` is very important: it indicates an octal number, which is the
     way that modes must be specified. If you try to use ``644``, you'll
     get totally incorrect behavior.
+.. _documentation for os.chmod: http://docs.python.org/lib/os-file-dir.html
+.. _documentation for os.chmod: http://docs.python.org/lib/os-file-dir.html
 .. setting:: FIXTURE_DIRS
 …
 If you define a custom ``LANGUAGES`` setting, it's OK to mark the languages as
 translation strings (as in the default value displayed above) -- but use a
 "dummy" ``gettext()`` function, not the one in ``django.utils.translation``.
 You should *never* import ``django.utils.translation`` from within your
+"dummy" ``gettext()`` function, not the one in :mod:`django.utils.translation`.
+You should *never* import :mod:`django.utils.translation` from within your
 settings file, because that module in itself depends on the settings, and that
 would cause a circular import.
 …
 .. versionadded:: 1.0
 Default: ``django.contrib.sessions.backends.db``
+Default: :mod:`django.contrib.sessions.backends.db`
 Controls where Django stores session data. Valid values are:
 …
     Django cannot reliably use alternate time zones in a Windows environment.
     If you're running Django on Windows, this variable must be set to match the
     system timezone.
 .. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE
 .. setting:: URL_VALIDATOR_USER_AGENT

docs/ref/templates/api.txt

diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt

-              a
 To cut down on the repetitive nature of loading and rendering
 templates, Django provides a shortcut function which largely
 automates the process: ``render_to_string()`` in
 ``django.template.loader``, which loads a template, renders it and
+:mod:`django.template.loader`, which loads a template, renders it and
 returns the resulting string::
     from django.template.loader import render_to_string

docs/ref/templates/builtins.txt

diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt

-              a
 ===============================
 Django comes with a couple of other template-tag libraries that you have to
 enable explicitly in your ``INSTALLED_APPS`` setting and enable in your
+enable explicitly in your :setting:`INSTALLED_APPS` setting and enable in your
 template with the ``{% load %}`` tag.
 django.contrib.humanize

docs/ref/unicode.txt

diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt

-              a
 Conversion functions
 ~~~~~~~~~~~~~~~~~~~~
 The ``django.utils.encoding`` module contains a few functions that are handy
+The :mod:`django.utils.encoding` module contains a few functions that are handy
 for converting back and forth between Unicode and bytestrings.
     * ``smart_unicode(s, encoding='utf-8', strings_only=False, errors='strict')``
 …
 E-mail
 ======
 Django's e-mail framework (in ``django.core.mail``) supports Unicode
+Django's e-mail framework (in :mod:`django.core.mail`) supports Unicode
 transparently. You can use Unicode data in the message bodies and any headers.
 However, you're still obligated to respect the requirements of the e-mail
 specifications, so, for example, e-mail addresses should use only ASCII

docs/topics/auth.txt

diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt

-              a
 ============
 Authentication support is bundled as a Django application in
 ``django.contrib.auth``. To install it, do the following:
+:mod:`django.contrib.auth`. To install it, do the following:
 . Put ``'django.contrib.auth'`` in your :setting:`INSTALLED_APPS` setting.
 . Run the command ``manage.py syncdb``.
 …
 .. function:: views.login()
     Here's what ``django.contrib.auth.views.login`` does:
+    Here's what :func:`django.contrib.auth.views.login` does:
         * If called via ``GET``, it displays a login form that POSTs to the same
           URL. More on this in a bit.
 …
 Default permissions
 -------------------
 When ``django.contrib.auth`` is listed in your :setting:`INSTALLED_APPS`
+When :mod:`django.contrib.auth` is listed in your :setting:`INSTALLED_APPS`
 setting, it will ensure that three default permissions -- add, change
 and delete -- are created for each Django model defined in one of your
 installed applications.
 These permissions will be created when you run
 :djadmin:`manage.py syncdb <syncdb>`; the first time you run ``syncdb`` after
 adding ``django.contrib.auth`` to :setting:`INSTALLED_APPS`, the default
+adding :mod:`django.contrib.auth` to :setting:`INSTALLED_APPS`, the default
 permissions will be created for all previously-installed models, as well as
 for any new models being installed at that time. Afterward, it will create
 default permissions for new models each time you run

docs/topics/cache.txt

diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt

-              a
 or directly in memory. This is an important decision that affects your cache's
 performance; yes, some cache types are faster than others.
 Your cache preference goes in the ``CACHE_BACKEND`` setting in your settings
+Your cache preference goes in the :setting:`CACHE_BACKEND` setting in your settings
 file. Here's an explanation of all available values for CACHE_BACKEND.
 Memcached
 …
     The ``cmemcache`` option is new in 1.0. Previously, only
     ``python-memcached`` was supported.
 To use Memcached with Django, set ``CACHE_BACKEND`` to
+To use Memcached with Django, set :setting:`CACHE_BACKEND` to
 ``memcached://ip:port/``, where ``ip`` is the IP address of the Memcached
 daemon and ``port`` is the port on which Memcached is running.
 …
 One excellent feature of Memcached is its ability to share cache over multiple
 servers. To take advantage of this feature, include all server addresses in
 ``CACHE_BACKEND``, separated by semicolons. In this example, the cache is
+:setting:`CACHE_BACKEND`, separated by semicolons. In this example, the cache is
 shared over Memcached instances running on IP address 172.19.26.240 and
 .19.26.242, both on port 11211::
 …
 in your database that is in the proper format that Django's database-cache
 system expects.
 Once you've created that database table, set your ``CACHE_BACKEND`` setting to
+Once you've created that database table, set your :setting:`CACHE_BACKEND` setting to
 ``"db://tablename"``, where ``tablename`` is the name of the database table.
 In this example, the cache table's name is ``my_cache_table``::
 …
 ------------------
 To store cached items on a filesystem, use the ``"file://"`` cache type for
 ``CACHE_BACKEND``. For example, to store cached data in ``/var/tmp/django_cache``,
+:setting:`CACHE_BACKEND`. For example, to store cached data in ``/var/tmp/django_cache``,
 use this setting::
     CACHE_BACKEND = 'file:///var/tmp/django_cache'
 …
 If you want the speed advantages of in-memory caching but don't have the
 capability of running Memcached, consider the local-memory cache backend. This
 cache is multi-process and thread-safe. To use it, set ``CACHE_BACKEND`` to
+cache is multi-process and thread-safe. To use it, set :setting:`CACHE_BACKEND` to
 ``"locmem:///"``. For example::
     CACHE_BACKEND = 'locmem:///'
 …
 various places but a development/test environment on which you don't want to
 cache. As a result, your development environment won't use caching and your
 production environment still will. To activate dummy caching, set
 ``CACHE_BACKEND`` like so::
+:setting:`CACHE_BACKEND` like so::
     CACHE_BACKEND = 'dummy:///'
 …
 While Django includes support for a number of cache backends out-of-the-box,
 sometimes you might want to use a customized cache backend. To use an external
 cache backend with Django, use a Python import path as the scheme portion (the
 part before the initial colon) of the ``CACHE_BACKEND`` URI, like so::
+part before the initial colon) of the :setting:`CACHE_BACKEND` URI, like so::
     CACHE_BACKEND = 'path.to.backend://'
 …
 -----------------------
 All caches may take arguments. They're given in query-string style on the
 ``CACHE_BACKEND`` setting. Valid arguments are:
+:setting:`CACHE_BACKEND` setting. Valid arguments are:
     timeout
         Default timeout, in seconds, to use for the cache. Defaults to 5
 …
 entire site. You'll need to add
 ``'django.middleware.cache.UpdateCacheMiddleware'`` and
 ``'django.middleware.cache.FetchFromCacheMiddleware'`` to your
 ``MIDDLEWARE_CLASSES`` setting, as in this example::
+:setting:`MIDDLEWARE_CLASSES` setting, as in this example::
     MIDDLEWARE_CLASSES = (
         'django.middleware.cache.UpdateCacheMiddleware',
 …
 Then, add the following required settings to your Django settings file:
 * ``CACHE_MIDDLEWARE_SECONDS`` -- The number of seconds each page should be
+* :setting:`CACHE_MIDDLEWARE_SECONDS` -- The number of seconds each page should be
   cached.
 * ``CACHE_MIDDLEWARE_KEY_PREFIX`` -- If the cache is shared across multiple
+* :setting:`CACHE_MIDDLEWARE_KEY_PREFIX` -- If the cache is shared across multiple
   sites using the same Django installation, set this to the name of the site,
   or some other string that is unique to this Django instance, to prevent key
   collisions. Use an empty string if you don't care.
 The cache middleware caches every page that doesn't have GET or POST
 parameters. Optionally, if the ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting is
+parameters. Optionally, if the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting is
 ``True``, only anonymous requests (i.e., not those made by a logged-in user)
 will be cached. This is a simple and effective way of disabling caching for any
 user-specific pages (include Django's admin interface). Note that if you use
 ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY``, you should make sure you've activated
+:setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY`, you should make sure you've activated
 ``AuthenticationMiddleware``.
 Additionally, the cache middleware automatically sets a few headers in each
 …
 * Sets the ``Last-Modified`` header to the current date/time when a fresh
   (uncached) version of the page is requested.
 * Sets the ``Expires`` header to the current date/time plus the defined
   ``CACHE_MIDDLEWARE_SECONDS``.
+  :setting:`CACHE_MIDDLEWARE_SECONDS`.
 * Sets the ``Cache-Control`` header to give a max age for the page -- again,
   from the ``CACHE_MIDDLEWARE_SECONDS`` setting.
+  from the :setting:`CACHE_MIDDLEWARE_SECONDS` setting.
 See :ref:`topics-http-middleware` for more on middleware.
 …
 If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in
 its ``Cache-Control`` header) then the page will be cached until the expiry
 time, rather than ``CACHE_MIDDLEWARE_SECONDS``. Using the decorators in
 ``django.views.decorators.cache`` you can easily set a view's expiry time
+time, rather than :setting:`CACHE_MIDDLEWARE_SECONDS`. Using the decorators in
+:mod:`django.views.decorators.cache` you can easily set a view's expiry time
 (using the ``cache_control`` decorator) or disable caching for a view (using
 the ``never_cache`` decorator). See the `using other headers`__ section for
 more on these decorators.
 …
 ==================
 A more granular way to use the caching framework is by caching the output of
 individual views. ``django.views.decorators.cache`` defines a ``cache_page``
+individual views. :mod:`django.views.decorators.cache` defines a ``cache_page``
 decorator that will automatically cache the view's response for you. It's easy
 to use::
 …
 intensive database query. In cases like this, you can use the low-level cache
 API to store objects in the cache with any level of granularity you like.
 The cache API is simple. The cache module, ``django.core.cache``, exports a
 ``cache`` object that's automatically created from the ``CACHE_BACKEND``
+The cache API is simple. The cache module, :mod:`django.core.cache`, exports a
+``cache`` object that's automatically created from the :setting:`CACHE_BACKEND`
 setting::
     >>> from django.core.cache import cache
 …
     'hello, world!'
 The ``timeout_seconds`` argument is optional and defaults to the ``timeout``
 argument in the ``CACHE_BACKEND`` setting (explained above).
+argument in the :setting:`CACHE_BACKEND` setting (explained above).
 If the object doesn't exist in the cache, ``cache.get()`` returns ``None``::
 …
 For explanation of Cache-Control HTTP directives, see the `Cache-Control spec`_.
 (Note that the caching middleware already sets the cache header's max-age with
 the value of the ``CACHE_MIDDLEWARE_SETTINGS`` setting. If you use a custom
+the value of the :setting:`CACHE_MIDDLEWARE_SETTINGS` setting. If you use a custom
 ``max_age`` in a ``cache_control`` decorator, the decorator will take
 precedence, and the header values will be merged correctly.)
 …
 ===========================
 If you use caching middleware, it's important to put each half in the right
 place within the ``MIDDLEWARE_CLASSES`` setting. That's because the cache
+place within the :setting:`MIDDLEWARE_CLASSES` setting. That's because the cache
 middleware needs to know which headers by which to vary the cache storage.
 Middleware always adds something to the ``Vary`` response header when it can.

docs/topics/db/transactions.txt

diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt

-              a
 transactions.
 To activate this feature, just add the ``TransactionMiddleware`` middleware to
 your ``MIDDLEWARE_CLASSES`` setting::
+your :setting:`MIDDLEWARE_CLASSES` setting::
     MIDDLEWARE_CLASSES = (
         'django.contrib.sessions.middleware.SessionMiddleware',
 …
 =================================================
 Control freaks can totally disable all transaction management by setting
 ``DISABLE_TRANSACTION_MANAGEMENT`` to ``True`` in the Django settings file.
+:setting:`DISABLE_TRANSACTION_MANAGEMENT` to ``True`` in the Django settings file.
 If you do this, Django won't provide any automatic transaction management
 whatsoever. Middleware will no longer implicitly commit transactions, and

docs/topics/email.txt

diff --git a/docs/topics/email.txt b/docs/topics/email.txt

-              a
 Django provides a couple of light wrappers over it, to make sending e-mail
 extra quick.
 The code lives in a single module: ``django.core.mail``.
+The code lives in a single module: :mod:`django.core.mail`.
 .. _smtplib library: http://docs.python.org/library/smtplib.html
 …
 .. note::
     The character set of e-mail sent with ``django.core.mail`` will be set to
+    The character set of e-mail sent with :mod:`django.core.mail` will be set to
     the value of your :setting:`DEFAULT_CHARSET` setting.
 send_mail()
 …
       possible exceptions, all of which are subclasses of ``SMTPException``.
     * ``auth_user``: The optional username to use to authenticate to the SMTP
       server. If this isn't provided, Django will use the value of the
       ``EMAIL_HOST_USER`` setting.
+      :setting:`EMAIL_HOST_USER` setting.
     * ``auth_password``: The optional password to use to authenticate to the
       SMTP server. If this isn't provided, Django will use the value of the
       ``EMAIL_HOST_PASSWORD`` setting.
+      :setting:`EMAIL_HOST_PASSWORD` setting.
 .. _smtplib docs: http://docs.python.org/library/smtplib.html
 …
 Django's ``send_mail()`` and ``send_mass_mail()`` functions are actually thin
 wrappers that make use of the ``EmailMessage`` and ``SMTPConnection`` classes
 in ``django.core.mail``.  If you ever need to customize the way Django sends
+in :mod:`django.core.mail`.  If you ever need to customize the way Django sends
 e-mail, you can subclass these two classes to suit your needs.
 .. note::

docs/topics/files.txt

diff --git a/docs/topics/files.txt b/docs/topics/files.txt

-              a
 -------------------------------------
 Django ships with a built-in ``FileSystemStorage`` class (defined in
 ``django.core.files.storage``) which implements basic local filesystem file
+:mod:`django.core.files.storage`) which implements basic local filesystem file
 storage. Its initializer takes two arguments:
 ======================  ===================================================
 …
 ======================  ===================================================
 ``location``            Optional. Absolute path to the directory that will
                         hold the files. If omitted, it will be set to the
                         value of your ``MEDIA_ROOT`` setting.
+                        value of your :setting:`MEDIA_ROOT` setting.
 ``base_url``            Optional. URL that serves the files stored at this
                         location. If omitted, it will default to the value
                         of your ``MEDIA_URL`` setting.
+                        of your :setting:`MEDIA_URL` setting.
 ======================  ===================================================
 For example, the following code will store uploaded files under
 ``/media/photos`` regardless of what your ``MEDIA_ROOT`` setting is::
+``/media/photos`` regardless of what your :setting:`MEDIA_ROOT` setting is::
     from django.db import models
     from django.core.files.storage import FileSystemStorage

docs/topics/forms/index.txt

diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt

-              a
 .. highlightlang:: html+django
 ``django.forms`` is Django's form-handling library.
+:mod:`django.forms` is Django's form-handling library.
 While it is possible to process form submissions just using Django's
 :class:`~django.http.HttpRequest` class, using the form library takes care of a
 …
 The library is decoupled from the other Django components, such as the database
 layer, views and templates. It relies only on Django settings, a couple of
 ``django.utils`` helper functions and Django's internationalization hooks (but
+:mod:`django.utils` helper functions and Django's internationalization hooks (but
 you're not required to be using internationalization features to use this
 library).

docs/topics/forms/media.txt

diff --git a/docs/topics/forms/media.txt b/docs/topics/forms/media.txt

-              a
     If you like the widgets that the Django Admin application uses,
     feel free to use them in your own application! They're all stored
     in ``django.contrib.admin.widgets``.
+    in :mod:`django.contrib.admin.widgets`.
 .. admonition:: Which JavaScript toolkit?

docs/topics/forms/modelforms.txt

diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt

-              a
                                      below)
     ``NullBooleanField``             ``CharField``
     ``PhoneNumberField``             ``USPhoneNumberField``
                                      (from ``django.contrib.localflavor.us``)
+                                     (from :mod:`django.contrib.localflavor.us`)
     ``PositiveIntegerField``         ``IntegerField``
     ``PositiveSmallIntegerField``    ``IntegerField``
     ``SlugField``                    ``SlugField``

docs/topics/http/file-uploads.txt

diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt

-              a
 When a user uploads a file, Django passes off the file data to an *upload
 handler* -- a small class that handles file data as it gets uploaded. Upload
 handlers are initially defined in the ``FILE_UPLOAD_HANDLERS`` setting, which
+handlers are initially defined in the :setting:`FILE_UPLOAD_HANDLERS` setting, which
 defaults to::
     ("django.core.files.uploadhandler.MemoryFileUploadHandler",
 …
 Sometimes particular views require different upload behavior. In these cases,
 you can override upload handlers on a per-request basis by modifying
 ``request.upload_handlers``. By default, this list will contain the upload
 handlers given by ``FILE_UPLOAD_HANDLERS``, but you can modify the list as you
+handlers given by :setting:`FILE_UPLOAD_HANDLERS`, but you can modify the list as you
 would any other list.
 For instance, suppose you've written a ``ProgressBarUploadHandler`` that

docs/topics/http/sessions.txt

diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt

-              a
 To enable session functionality, do the following:
     * Edit the ``MIDDLEWARE_CLASSES`` setting and make sure
       ``MIDDLEWARE_CLASSES`` contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
+    * Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
+      :setting:`MIDDLEWARE_CLASSES` contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
       The default ``settings.py`` created by ``django-admin.py startproject`` has
       ``SessionMiddleware`` activated.
     * Add ``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting,
+    * Add ``'django.contrib.sessions'`` to your :setting:`INSTALLED_APPS` setting,
       and run ``manage.py syncdb`` to install the single database table
       that stores session data.
 …
    see `configuring the session engine`_.
 If you don't want to use sessions, you might as well remove the
 ``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and ``'django.contrib.sessions'``
 from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
+``SessionMiddleware`` line from :setting:`MIDDLEWARE_CLASSES` and ``'django.contrib.sessions'``
+from your :setting:`INSTALLED_APPS`. It'll save you a small bit of overhead.
 Configuring the session engine
 ==============================
 …
 Using file-based sessions
 -------------------------
 To use file-based sessions, set the ``SESSION_ENGINE`` setting to
+To use file-based sessions, set the :setting:`SESSION_ENGINE` setting to
 ``"django.contrib.sessions.backends.file"``.
 You might also want to set the ``SESSION_FILE_PATH`` setting (which defaults
+You might also want to set the :setting:`SESSION_FILE_PATH` setting (which defaults
 to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to control
 where Django stores session files. Be sure to check that your Web server has
 permissions to read and write to this location.
 …
 Using cache-based sessions
 --------------------------
 To store session data using Django's cache system, set ``SESSION_ENGINE``
+To store session data using Django's cache system, set :setting:`SESSION_ENGINE`
 to ``"django.contrib.sessions.backends.cache"``. You'll want to make sure
 you've configured your cache; see the :ref:`cache documentation <topics-cache>` for details.
 …
     datetime.datetime(2005, 8, 20, 13, 35, 0)
     >>> s.save()
 If you're using the ``django.contrib.sessions.backends.db`` backend, each
+If you're using the :mod:`django.contrib.sessions.backends.db` backend, each
 session is just a normal Django model. The ``Session`` model is defined in
 ``django/contrib/sessions/models.py``. Because it's a normal model, you can
 access sessions using the normal Django database API::
 …
     request.session.modified = True
 To change this default behavior, set the ``SESSION_SAVE_EVERY_REQUEST`` setting
+To change this default behavior, set the :setting:`SESSION_SAVE_EVERY_REQUEST` setting
 to ``True``. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, Django will save
 the session to the database on every single request.
 …
 ===============================================
 You can control whether the session framework uses browser-length sessions vs.
 persistent sessions with the ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` setting.
+persistent sessions with the :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` setting.
 By default, ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``False``, which
 means session cookies will be stored in users' browsers for as long as
 ``SESSION_COOKIE_AGE``. Use this if you don't want people to have to log in
+:setting:`SESSION_COOKIE_AGE`. Use this if you don't want people to have to log in
 every time they open a browser.
 If ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``True``, Django will use
 …
 .. versionadded:: 1.0
 Default: ``django.contrib.sessions.backends.db``
+Default: :mod:`django.contrib.sessions.backends.db`
 Controls where Django stores session data. Valid values are:

docs/topics/http/shortcuts.txt

diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt

-              a
 Django shortcut functions
 =========================
 The package ``django.shortcuts`` collects helper functions and classes that
+The package :mod:`django.shortcuts` collects helper functions and classes that
 "span" multiple levels of MVC. In other words, these functions/classes
 introduce controlled coupling for convenience's sake.

docs/topics/http/urls.txt

diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt

-              a
 algorithm the system follows to determine which Python code to execute:
 . Django determines the root URLconf module to use. Ordinarily,
        this is the value of the ``ROOT_URLCONF`` setting, but if the incoming
+       this is the value of the :setting:`ROOT_URLCONF` setting, but if the incoming
        ``HttpRequest`` object has an attribute called ``urlconf``, its value
        will be used in place of the ``ROOT_URLCONF`` setting.
 . Django loads that Python module and looks for the variable
        ``urlpatterns``. This should be a Python list, in the format returned by
        the function ``django.conf.urls.defaults.patterns()``.
 . Django runs through each URL pattern, in order, and stops at the first
        one that matches the requested URL.
 . Once one of the regexes matches, Django imports and calls the given
        view, which is a simple Python function. The view gets passed an
        :class:`~django.http.HttpRequest` as its first argument and any values
 …
 If you need to use something similar to the :ttag:`url` template tag in
 your code, Django provides the following method (in the
 ``django.core.urlresolvers`` module):
+:mod:`django.core.urlresolvers` module):
 .. currentmodule:: django.core.urlresolvers
 .. function:: reverse(viewname, urlconf=None, args=None, kwargs=None)

docs/topics/http/views.txt

diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt

-              a
 Let's step through this code one line at a time:
     * First, we import the class ``HttpResponse``, which lives in the
       ``django.http`` module, along with Python's ``datetime`` library.
+      :mod:`django.http` module, along with Python's ``datetime`` library.
     * Next, we define a function called ``current_datetime``. This is the view
       function. Each view function takes an ``HttpRequest`` object as its first
 …
 .. admonition:: Django's Time Zone
     Django includes a ``TIME_ZONE`` setting that defaults to
+    Django includes a :setting:`TIME_ZONE` setting that defaults to
     ``America/Chicago``. This probably isn't where you live, so you might want
     to change it in your settings file.
 …
       in the 404.
     * The 404 view is passed a ``RequestContext`` and will have access to
       variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g.,
       ``MEDIA_URL``).
+      variables supplied by your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g.,
+      :setting:`MEDIA_URL`).
     * If ``DEBUG`` is set to ``True`` (in your settings module), then your 404
+    * If :setting:`DEBUG` is set to ``True`` (in your settings module), then your 404
       view will never be used, and the traceback will be displayed instead.
 The 500 (server error) view

docs/topics/i18n.txt

diff --git a/docs/topics/i18n.txt b/docs/topics/i18n.txt

-              a
 optimizations so as not to load the internationalization machinery.
 You'll probably also want to remove ``'django.core.context_processors.i18n'``
 from your ``TEMPLATE_CONTEXT_PROCESSORS`` setting.
+from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting.
 If you do need internationalization: three steps
 ================================================
 …
 Each ``RequestContext`` has access to three translation-specific variables:
     * ``LANGUAGES`` is a list of tuples in which the first element is the
+    * :setting:`LANGUAGES` is a list of tuples in which the first element is the
       language code and the second is the language name (translated into the
       currently active locale).
 …
 The allow_lazy() decorator
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 Django offers many utility functions (particularly in ``django.utils``) that
+Django offers many utility functions (particularly in :mod:`django.utils`) that
 take a string as their first argument and do something to that string. These
 functions are used by template filters as well as directly in other code.
 …
 selection based on data from the request. It customizes content for each user.
 To use ``LocaleMiddleware``, add ``'django.middleware.locale.LocaleMiddleware'``
 to your ``MIDDLEWARE_CLASSES`` setting. Because middleware order matters, you
+to your :setting:`MIDDLEWARE_CLASSES` setting. Because middleware order matters, you
 should follow these guidelines:
     * Make sure it's one of the first middlewares installed.
 …
       makes use of session data.
     * If you use ``CacheMiddleware``, put ``LocaleMiddleware`` after it.
 For example, your ``MIDDLEWARE_CLASSES`` might look like this::
+For example, your :setting:`MIDDLEWARE_CLASSES` might look like this::
     MIDDLEWARE_CLASSES = (
        'django.contrib.sessions.middleware.SessionMiddleware',
 …
       In Django version 0.96 and before, the cookie's name is hard-coded to
       ``django_language``. In Django 1,0, The cookie name is set by the
       ``LANGUAGE_COOKIE_NAME`` setting. (The default name is
+      :setting:`LANGUAGE_COOKIE_NAME` setting. (The default name is
       ``django_language``.)
     * Failing that, it looks at the ``Accept-Language`` HTTP header. This
 …
       prefer, in order by priority. Django tries each language in the header
       until it finds one with available translations.
     * Failing that, it uses the global ``LANGUAGE_CODE`` setting.
+    * Failing that, it uses the global :setting:`LANGUAGE_CODE` setting.
 .. _locale-middleware-notes:
 …
     * Only languages listed in the :setting:`LANGUAGES` setting can be selected.
       If you want to restrict the language selection to a subset of provided
       languages (because your application doesn't provide all those languages),
       set ``LANGUAGES`` to a list of languages. For example::
+      set :setting:`LANGUAGES` to a list of languages. For example::
           LANGUAGES = (
             ('de', _('German')),
 …
       .. _LANGUAGES setting: ../settings/#languages
     * If you define a custom ``LANGUAGES`` setting, as explained in the
+    * If you define a custom :setting:`LANGUAGES` setting, as explained in the
       previous bullet, it's OK to mark the languages as translation strings
       -- but use a "dummy" ``ugettext()`` function, not the one in
       ``django.utils.translation``. You should *never* import
       ``django.utils.translation`` from within your settings file, because that
+      :mod:`django.utils.translation`. You should *never* import
+      :mod:`django.utils.translation` from within your settings file, because that
       module in itself depends on the settings, and that would cause a circular
       import.
 …
       With this arrangement, ``django-admin.py makemessages`` will still find
       and mark these strings for translation, but the translation won't happen
       at runtime -- so you'll have to remember to wrap the languages in the
       *real* ``ugettext()`` in any code that uses ``LANGUAGES`` at runtime.
+      *real* ``ugettext()`` in any code that uses :setting:`LANGUAGES` at runtime.
     * The ``LocaleMiddleware`` can only select languages for which there is a
       Django-provided base translation. If you want to provide translations
 …
       Technical message IDs are easily recognized; they're all upper case. You
       don't translate the message ID as with other messages, you provide the
       correct local variant on the provided English value. For example, with
       ``DATETIME_FORMAT`` (or ``DATE_FORMAT`` or ``TIME_FORMAT``), this would
+      :setting:`DATETIME_FORMAT` (or :setting:`DATE_FORMAT` or :setting:`TIME_FORMAT`), this would
       be the format string that you want to use in your language. The format
       is identical to the format strings used by the ``now`` template tag.
 …
     * ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
     * ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
     * All paths listed in ``LOCALE_PATHS`` in your settings file are
+    * All paths listed in :setting:`LOCALE_PATHS` in your settings file are
       searched in that order for ``<language>/LC_MESSAGES/django.(po|mo)``
     * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
 …
 to produce the binary ``django.mo`` files that are used by ``gettext``.
 You can also run ``django-admin.py compilemessages --settings=path.to.settings``
 to make the compiler process all the directories in your ``LOCALE_PATHS``
+to make the compiler process all the directories in your :setting:`LOCALE_PATHS`
 setting.
 Application message files are a bit complicated to discover -- they need the
 …
 parameter set in request. If session support is enabled, the view
 saves the language choice in the user's session. Otherwise, it saves the
 language choice in a cookie that is by default named ``django_language``.
 (The name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting.)
+(The name can be changed through the :setting:`LANGUAGE_COOKIE_NAME` setting.)
 After setting the language choice, Django redirects the user, following this
 algorithm:
 …
+    )
 Each string in ``packages`` should be in Python dotted-package syntax (the
 same format as the strings in ``INSTALLED_APPS``) and should refer to a package
+same format as the strings in :setting:`INSTALLED_APPS`) and should refer to a package
 that contains a ``locale`` directory. If you specify multiple packages, all
 those catalogs are merged into one catalog. This is useful if you have
 JavaScript that uses strings from different applications.
 …
 signs in the URL. This is especially useful if your pages use code from
 different apps and this changes often and you don't want to pull in one big
 catalog file. As a security measure, these values can only be either
 ``django.conf`` or any package from the ``INSTALLED_APPS`` setting.
+``django.conf`` or any package from the :setting:`INSTALLED_APPS` setting.
 Using the JavaScript translation catalog
 ----------------------------------------
 …
       * Add ``;C:\Program Files\gettext-utils\bin`` at the end of the
         ``Variable value`` field
 You may also use ``gettext`` binaries you have obtained elsewhere, so long as
+You may also use ``gettext`` binaries you have obtained elsewhere, so long as
 the ``xgettext --version`` command works properly. Some version 0.14.4 binaries
 have been found to not support this command. Do not attempt to use Django
+have been found to not support this command. Do not attempt to use Django
 translation utilities with a ``gettext`` package if the command ``xgettext
 --version`` entered at a Windows command prompt causes a popup window saying
 "xgettext.exe has generated errors and will be closed by Windows".

docs/topics/templates.txt

diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt

-              a
 ``title`` attribute of the ``section`` object.
 If you use a variable that doesn't exist, the template system will insert
 the value of the ``TEMPLATE_STRING_IF_INVALID`` setting, which is set to ``''``
+the value of the :setting:`TEMPLATE_STRING_IF_INVALID` setting, which is set to ``''``
 (the empty string) by default.
 See `Using the built-in reference`_, below, for help on finding what variables

docs/topics/testing.txt

diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt

-              a
 Overview and a quick example
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 To use the test client, instantiate ``django.test.client.Client`` and retrieve
+To use the test client, instantiate :class:`django.test.client.Client` and retrieve
 Web pages::
     >>> from django.test.client import Client
 …
 Making requests
 ~~~~~~~~~~~~~~~
 Use the ``django.test.client.Client`` class to make requests. It requires no
+Use the :class:`django.test.client.Client` class to make requests. It requires no
 arguments at time of construction:
 .. class:: Client()
 …
 Converting a normal ``unittest.TestCase`` to a Django ``TestCase`` is easy:
 just change the base class of your test from ``unittest.TestCase`` to
 ``django.test.TestCase``. All of the standard Python unit test functionality
+:class:`django.test.TestCase`. All of the standard Python unit test functionality
 will continue to be available, but it will be augmented with some useful
 additions.
 …
 .. attribute:: TestCase.client
 Every test case in a ``django.test.TestCase`` instance has access to an
+Every test case in a :class:`django.test.TestCase` instance has access to an
 instance of a Django test client. This client can be accessed as
 ``self.client``. This client is recreated for each test, so you don't have to
 worry about state (such as cookies) carrying over from one test to another.
 …
 Once you've created a fixture and placed it somewhere in your Django project,
 you can use it in your unit tests by specifying a ``fixtures`` class attribute
 on your ``django.test.TestCase`` subclass::
+on your :class:`django.test.TestCase` subclass::
     from django.test import TestCase
     from myapp.models import Animal
 …
 particular URL.
 In order to provide a reliable URL space for your test,
 ``django.test.TestCase`` provides the ability to customize the URLconf
+:class:`django.test.TestCase` provides the ability to customize the URLconf
 configuration for the duration of the execution of a test suite. If your
 ``TestCase`` instance defines an ``urls`` attribute, the ``TestCase`` will use
 the value of that attribute as the ``ROOT_URLCONF`` for the duration of that
+the value of that attribute as the :setting:`ROOT_URLCONF` for the duration of that
 test.
 For example::
 …
    :synopsis: Helpers to write custom test runners.
 To assist in the creation of your own test runner, Django provides a number of
 utility methods in the ``django.test.utils`` module.
+utility methods in the :mod:`django.test.utils` module.
 .. function:: setup_test_environment()

Download in other formats:

Original Format

Issues

Context Navigation

Ticket #9502: xref-markup-r9475.diff

Download in other formats: