Fixed #15992 -- Added more references to settings. Thanks, aaugustin.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16290 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/faq/admin.txt

@@ -8,8 +8,8 @@ The login cookie isn't being set correctly, because the domain of the cookie
 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
-      to match your domain. For example, if you're going to
+    * 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'``.
 
@@ -17,7 +17,7 @@ things:
       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.
 -----------------------------------------------------------------------------------------------------------------------------------------------------------

docs/faq/models.txt

@@ -6,16 +6,17 @@ FAQ: Databases and models
 How can I see the raw SQL queries Django is running?
 ----------------------------------------------------
 
-Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do
-this::
+Make sure your Django :setting:`DEBUG` setting is set to ``True``.
+Then, just do this::
 
     >>> from django.db import connection
     >>> connection.queries
     [{'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
-of dictionaries in order of query execution. Each dictionary has the following::
+``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.
@@ -89,13 +90,13 @@ Why is Django leaking memory?
 
 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
-Django saves a copy of every SQL statement it has executed.
+sure your :setting:`DEBUG` setting is set to ``False``. If :setting:`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
 `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::

docs/howto/i18n.txt

@@ -55,7 +55,7 @@ message file specific to the project you are composing. The choice is yours.
 
 All message file repositories are structured the same way. They are:
 
-    * All paths listed in ``LOCALE_PATHS`` in your settings file are
+    * All paths listed in :setting:`LOCALE_PATHS` in your settings file are
       searched for ``<language>/LC_MESSAGES/django.(po|mo)``
     * ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)`` --
       deprecated, see above.

docs/internals/contributing/writing-code/unit-tests.txt

@@ -85,7 +85,7 @@ details for each database:
 
 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_CHARSET`` in the settings
+you will need to include a value for :setting:`TEST_CHARSET` in the settings
 dictionary for the applicable database.
 
 Running only some of the tests

docs/internals/deprecation.txt

@@ -170,9 +170,9 @@ their deprecation, as per the :ref:`Django deprecation policy
           and :class:`django.contrib.auth.context_processors.PermLookupDict`,
           respectively.
 
-        * The ``MEDIA_URL`` or ``STATIC_URL`` settings are required to end
-          with a trailing slash to ensure there is a consistent way to
-          combine paths in templates.
+        * The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings are
+          required to end with a trailing slash to ensure there is a consistent
+          way to combine paths in templates.
 
     * 1.6
         * The compatibility modules ``django.utils.copycompat`` and

docs/ref/contrib/admin/index.txt

@@ -1765,7 +1765,7 @@ In this example, we register the default ``AdminSite`` instance
     )
 
 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/gis/geoip.txt

@@ -18,7 +18,7 @@ the GeoIP C libary and either the GeoIP `Country`__ or `City`__
 datasets in binary format (the CSV files will not work!).  These datasets may be 
 `downloaded from MaxMind`__.  Grab the ``GeoIP.dat.gz`` and ``GeoLiteCity.dat.gz``
 and unzip them in a directory corresponding to what you set 
-``GEOIP_PATH`` with in your settings.  See the example and reference below
+:setting:`GEOIP_PATH` with in your settings.  See the example and reference below
 for more details.
 
 __ http://www.maxmind.com/app/c

docs/ref/contrib/gis/install.txt

@@ -184,9 +184,9 @@ If using a binary package of GEOS (e.g., on Ubuntu), you may need to :ref:`binut
 ~~~~~~~~~~~~~~~~~~~~~
 
 If your GEOS library is in a non-standard location, or you don't want to
-modify the system's library path then the :setting:`GEOS_LIBRARY_PATH`  setting
-may be added to your Django settings file with the full path to the GEOS
-C library.  For example::
+modify the system's library path then the :setting:`GEOS_LIBRARY_PATH`
+setting may be added to your Django settings file with the full path to the
+GEOS C library.  For example::
 
     GEOS_LIBRARY_PATH = '/home/bob/local/lib/libgeos_c.so'
 
@@ -592,8 +592,8 @@ Now, the ``spatialite`` command can be used to initialize a spatial database::
 __ http://www.gaia-gis.it/spatialite/resources.html
 
 
-Add ``django.contrib.gis`` to ``INSTALLED_APPS``
-------------------------------------------------
+Add ``django.contrib.gis`` to :setting:`INSTALLED_APPS`
+-------------------------------------------------------
 
 Like other Django contrib applications, you will *only* need to add
 :mod:`django.contrib.gis` to :setting:`INSTALLED_APPS` in your settings.

docs/ref/contrib/index.txt

@@ -14,8 +14,8 @@ those packages have.
 
     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
-    ``manage.py syncdb``.
+    ``'django.contrib.admin'``) to your :setting:`INSTALLED_APPS` setting and
+    re-run ``manage.py syncdb``.
 
 .. _"batteries included" philosophy: http://docs.python.org/tutorial/stdlib.html#batteries-included
 

docs/ref/contrib/messages.txt

@@ -386,7 +386,7 @@ SESSION_COOKIE_DOMAIN
 Default: ``None``
 
 The storage backends that use cookies -- ``CookieStorage`` and
-``FallbackStorage`` -- use the value of ``SESSION_COOKIE_DOMAIN`` in
+``FallbackStorage`` -- use the value of :setting:`SESSION_COOKIE_DOMAIN` in
 setting their cookies. See the :doc:`settings documentation </ref/settings>`
 for more information on how this works and why you might need to set it.
 

docs/ref/databases.txt

@@ -262,8 +262,8 @@ Connection settings are used in this order:
        :setting:`HOST`, :setting:`PORT`
     3. MySQL option files.
 
-In other words, if you set the name of the database in ``OPTIONS``,
-this will take precedence over ``NAME``, which would override
+In other words, if you set the name of the database in :setting:`OPTIONS`,
+this will take precedence over :setting:`NAME`, which would override
 anything in a `MySQL option file`_.
 
 Here's a sample configuration which uses a MySQL option file::
@@ -574,7 +574,7 @@ Your Django settings.py file should look something like this for Oracle::
 
 If you don't use a ``tnsnames.ora`` file or a similar naming method that
 recognizes the SID ("xe" in this example), then fill in both
-``HOST`` and ``PORT`` like so::
+:setting:`HOST` and :setting:`PORT` like so::
 
     DATABASES = {
         'default': {
@@ -587,7 +587,7 @@ recognizes the SID ("xe" in this example), then fill in both
         }
     }
 
-You should supply both ``HOST`` and ``PORT``, or leave both
+You should supply both :setting:`HOST` and :setting:`PORT`, or leave both
 as empty strings.
 
 Threaded option

docs/ref/django-admin.txt

@@ -57,7 +57,7 @@ App names
 ---------
 
 Many commands 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
@@ -126,7 +126,7 @@ dbshell
 
 Runs the command-line client for the database engine specified in your
 ``ENGINE`` setting, with the connection parameters specified in your
-``USER``, ``PASSWORD``, etc., settings.
+:setting:`USER`, :setting:`PASSWORD`, etc., settings.
 
     * For PostgreSQL, this runs the ``psql`` command-line client.
     * For MySQL, this runs the ``mysql`` command-line client.
@@ -151,8 +151,9 @@ Displays differences between the current settings file and Django's default
 settings.
 
 Settings that don't appear in the defaults are followed by ``"###"``. For
-example, the default settings don't define ``ROOT_URLCONF``, so
-``ROOT_URLCONF`` is followed by ``"###"`` in the output of ``diffsettings``.
+example, the default settings don't define :setting:`ROOT_URLCONF`, so
+:setting:`ROOT_URLCONF` is followed by ``"###"`` in the output of
+``diffsettings``.
 
 Note that Django's default settings live in ``django/conf/global_settings.py``,
 if you're ever curious to see the full list of defaults.
@@ -245,7 +246,7 @@ inspectdb
 .. django-admin:: inspectdb
 
 Introspects the database tables in the database pointed-to by the
-``NAME`` setting and outputs a Django model module (a ``models.py``
+:setting:`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.
@@ -309,7 +310,7 @@ fixture can be distributed over multiple directories, in multiple applications.
 Django will search in three locations for fixtures:
 
    1. In the ``fixtures`` directory of every installed application
-   2. In any directory named in the ``FIXTURE_DIRS`` setting
+   2. In any directory named in the :setting:`FIXTURE_DIRS` setting
    3. In the literal path named by the fixture
 
 Django will load any and all fixtures it finds in these locations that match
@@ -340,7 +341,7 @@ directories will be included in the search path. For example::
 
 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``.
 
 When fixture files are processed, the data is saved to the database as is.
 Model defined ``save`` methods and ``pre_save`` signals are not called.
@@ -742,7 +743,7 @@ Serving static files with the development server
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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 :doc:`/howto/static-files`.
 
 shell
@@ -912,13 +913,13 @@ syncdb
 
 .. django-admin:: syncdb
 
-Creates the database tables for all apps in ``INSTALLED_APPS`` whose tables
-have not already been created.
+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
-this command to install the default apps.
+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
 
@@ -1032,8 +1033,8 @@ validate
 
 .. django-admin:: validate
 
-Validates all installed models (according to the ``INSTALLED_APPS`` setting)
-and prints validation errors to standard output.
+Validates all installed models (according to the :setting:`INSTALLED_APPS`
+setting) and prints validation errors to standard output.
 
 Commands provided by applications
 =================================

docs/ref/forms/fields.txt

@@ -764,7 +764,7 @@ Takes the following optional arguments:
 .. 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.
 
 .. versionchanged:: 1.2
    The URLField previously did not recognize URLs as valid that contained an IDN

docs/ref/generic-views.txt

@@ -58,7 +58,7 @@ which is a dictionary of the parameters captured in the URL.
       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:**
 
@@ -198,7 +198,7 @@ a date in the *future* are not included unless you set ``allow_future`` to
       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
@@ -290,7 +290,7 @@ to ``True``.
       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
@@ -377,7 +377,7 @@ date in the *future* are not displayed unless you set ``allow_future`` to
       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
@@ -465,7 +465,7 @@ in the *future* are not displayed unless you set ``allow_future`` to ``True``.
       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
@@ -550,7 +550,7 @@ you set ``allow_future`` to ``True``.
       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
@@ -660,7 +660,7 @@ future, the view will throw a 404 error by default, unless you set
       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
@@ -738,7 +738,7 @@ A page representing a list of objects.
       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:**
 
@@ -852,7 +852,7 @@ A page representing an individual object.
       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:**
 

docs/ref/templates/builtins.txt

@@ -1307,10 +1307,11 @@ If ``value`` is a ``datetime`` object (e.g., the result of
 ``datetime.datetime.now()``), the output will be the string
 ``'Wed 09 Jan 2008'``.
 
-The format passed can be one of the predefined ones ``DATE_FORMAT``,
-``DATETIME_FORMAT``, ``SHORT_DATE_FORMAT`` or ``SHORT_DATETIME_FORMAT``, or a
-custom format that uses the format specifiers shown in the table above. Note
-that predefined formats may vary depending on the current locale.
+The format passed can be one of the predefined ones :setting:`DATE_FORMAT`,
+:setting:`DATETIME_FORMAT`, :setting:`SHORT_DATE_FORMAT` or
+:setting:`SHORT_DATETIME_FORMAT`, or a custom format that uses the format
+specifiers shown in the table above. Note that predefined formats may vary
+depending on the current locale.
 
 Assuming that :setting:`USE_L10N` is ``True`` and :setting:`LANGUAGE_CODE` is,
 for example, ``"es"``, then for::
@@ -1941,9 +1942,9 @@ time
 
 Formats a time according to the given format.
 
-Given format can be the predefined one ``TIME_FORMAT``, or a custom format,
-same as the :tfilter:`date` filter. Note that the predefined format is locale-
-dependant.
+Given format can be the predefined one :setting:`TIME_FORMAT`, or a custom
+format, same as the :tfilter:`date` filter. Note that the predefined format
+is locale-dependant.
 
 The time filter will only accept parameters in the format string that relate
 to the time of day, not the date (for obvious reasons). If you need to
@@ -2243,7 +2244,7 @@ Other tags and filter libraries
 -------------------------------
 
 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
@@ -2274,15 +2275,18 @@ i18n
 
 Provides a couple of templatetags that allow specifying translatable text in
 Django templates. It is slightly different from the libraries described
-above because you don't need to add any application to the ``INSTALLED_APPS``
-setting but rather set :setting:`USE_I18N` to True, then loading it with
-``{% load i18n %}``. See :ref:`specifying-translation-strings-in-template-code`.
+above because you don't need to add any application to the
+:setting:`INSTALLED_APPS` setting but rather set :setting:`USE_I18N` to True,
+then loading it with ``{% load i18n %}``.
+
+See :ref:`specifying-translation-strings-in-template-code`.
 
 l10n
 ~~~~
 
 Provides a couple of templatetags that allow control over the localization of
 values in Django templates. It is slightly different from the libraries described
-above because you don't need to add any application to the ``INSTALLED_APPS``;
-you only need to load the library using ``{% load l10n %}``. See
-:ref:`topic-l10n-templates`.
+above because you don't need to add any application to the :setting:`INSTALLED_APPS`;
+you only need to load the library using ``{% load l10n %}``.
+
+See :ref:`topic-l10n-templates`.

docs/ref/utils.txt

@@ -61,8 +61,8 @@ to distinguish caches by the ``Accept-language`` header.
 
     Each header is only added if it isn't already set.
 
-    ``cache_timeout`` is in seconds. The ``CACHE_MIDDLEWARE_SECONDS`` setting
-    is used by default.
+    ``cache_timeout`` is in seconds. The :setting:`CACHE_MIDDLEWARE_SECONDS`
+    setting is used by default.
 
 .. function:: add_never_cache_headers(response)
 

docs/releases/1.0-porting-guide.txt

@@ -443,10 +443,10 @@ The old :exc:`EnvironmentError` has split into an :exc:`ImportError` when
 Django fails to find the settings module and a :exc:`RuntimeError` when you try
 to reconfigure settings after having already used them
 
-``LOGIN_URL`` has moved
-~~~~~~~~~~~~~~~~~~~~~~~
+:setting:`LOGIN_URL` has moved
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``LOGIN_URL`` constant moved from ``django.contrib.auth`` into the
+The :setting:`LOGIN_URL` constant moved from ``django.contrib.auth`` into the
 ``settings`` module. Instead of using ``from django.contrib.auth import
 LOGIN_URL`` refer to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
 
@@ -454,11 +454,11 @@ LOGIN_URL`` refer to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In 0.96, if a URL didn't end in a slash or have a period in the final
-component of its path, and ``APPEND_SLASH`` was True, Django would redirect
-to the same URL, but with a slash appended to the end. Now, Django checks to
-see whether the pattern without the trailing slash would be matched by
-something in your URL patterns. If so, no redirection takes place, because it
-is assumed you deliberately wanted to catch that pattern.
+component of its path, and :setting:`APPEND_SLASH` was True, Django would
+redirect to the same URL, but with a slash appended to the end. Now, Django
+checks to see whether the pattern without the trailing slash would be matched
+by something in your URL patterns. If so, no redirection takes place, because
+it is assumed you deliberately wanted to catch that pattern.
 
 For most people, this won't require any changes. Some people, though, have URL
 patterns that look like this::
@@ -548,8 +548,8 @@ need to reload your data. Do this after you have made the change to using
   **Back up your database first!**
 
   For SQLite, this means making a copy of the single file that stores the
-  database (the name of that file is the ``DATABASE_NAME`` in your settings.py
-  file).
+  database (the name of that file is the :setting:`DATABASE_NAME` in your
+  settings.py file).
 
 To upgrade each application to use a ``DecimalField``, you can do the
 following, replacing ``<app>`` in the code below with each app's name:

docs/releases/1.2.txt

@@ -1076,8 +1076,8 @@ Up to version 1.1 Django used technical message IDs
 to provide localizers the possibility to translate date and time formats. They
 were translatable :term:`translation strings <translation string>` that could
 be recognized because they were all upper case (for example
-``DATETIME_FORMAT``, ``DATE_FORMAT``, ``TIME_FORMAT``). They have been
-deprecated in favor of the new :ref:`Format localization
+:setting:`DATETIME_FORMAT`, :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`).
+They have been deprecated in favor of the new :ref:`Format localization
 <format-localization>` infrastructure that allows localizers to specify that
 information in a ``formats.py`` file in the corresponding
 ``django/conf/locale/<locale name>/`` directory.

docs/releases/1.3-alpha-1.txt

@@ -249,7 +249,7 @@ framework, we have "fixed" the problem by making the list of
 prohibited words an empty list.
 
 If you want to restore the old behavior, simply put a
-``PROFANITIES_LIST`` setting in your settings file that includes the
+:setting:`PROFANITIES_LIST` setting in your settings file that includes the
 words that you want to prohibit (see the `commit that implemented this
 change`_ if you want to see the list of words that was historically
 prohibited). However, if avoiding profanities is important to you, you

docs/releases/1.3.txt

@@ -264,8 +264,8 @@ The GeoDjango test suite is now included when
 :ref:`running the Django test suite <running-unit-tests>` with ``runtests.py``
 when using :ref:`spatial database backends <spatial-backends>`.
 
-``MEDIA_URL`` and ``STATIC_URL`` must end in a slash
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+:setting:`MEDIA_URL` and :setting:`STATIC_URL` must end in a slash
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Previously, the :setting:`MEDIA_URL` setting only required a trailing slash if
 it contained a suffix beyond the domain name.
@@ -581,7 +581,7 @@ gettext domain):
 
  * Now it is possible to override the translations shipped with applications by
    using the :setting:`LOCALE_PATHS` setting whose translations have now higher
-   precedence than the translations of ``INSTALLED_APPS`` applications.
+   precedence than the translations of :setting:`INSTALLED_APPS` applications.
    The relative priority among the values listed in this setting has also been
    modified so the paths listed first have higher precedence than the
    ones listed later.
@@ -589,7 +589,7 @@ gettext domain):
  * The ``locale`` subdirectory of the directory containing the settings, that
    usually coincides with and is know as the *project directory* is being
    deprecated in this release as a source of translations. (the precedence of
-   these translations is intermediate between applications and ``LOCALE_PATHS``
+   these translations is intermediate between applications and :setting:`LOCALE_PATHS`
    translations). See the `corresponding deprecated features section`_
    of this document.
 

docs/topics/cache.txt

@@ -420,7 +420,7 @@ Once the cache is set up, the simplest way to use caching is to cache your
 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',

docs/topics/email.txt

@@ -509,8 +509,8 @@ Defining a custom email backend
 -------------------------------
 
 If you need to change how emails are sent you can write your own email
-backend. The ``EMAIL_BACKEND`` setting in your settings file is then the
-Python import path for your backend class.
+backend. The :setting:`EMAIL_BACKEND` setting in your settings file is then
+the Python import path for your backend class.
 
 Custom email backends should subclass ``BaseEmailBackend`` that is located in
 the ``django.core.mail.backends.base`` module. A custom email backend must

docs/topics/http/file-uploads.txt

@@ -225,8 +225,8 @@ Upload Handlers
 
 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
-defaults to::
+handlers are initially defined in the :setting:`FILE_UPLOAD_HANDLERS` setting,
+which defaults to::
 
     ("django.core.files.uploadhandler.MemoryFileUploadHandler",
      "django.core.files.uploadhandler.TemporaryFileUploadHandler",)
@@ -246,8 +246,8 @@ Modifying upload handlers on the fly
 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
-would any other list.
+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
 provides feedback on upload progress to some sort of AJAX widget. You'd add this

docs/topics/http/sessions.txt

@@ -23,7 +23,7 @@ To enable session functionality, do the following:
       has ``SessionMiddleware`` activated.
 
 If you don't want to use sessions, you might as well remove the
-``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and
+``SessionMiddleware`` line from :setting:`MIDDLEWARE_CLASSES` and
 ``'django.contrib.sessions'`` from your :setting:`INSTALLED_APPS`.
 It'll save you a small bit of overhead.
 
@@ -39,7 +39,7 @@ Using database-backed sessions
 ------------------------------
 
 If you want to use a database-backed session, you need to add
-``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting.
+``'django.contrib.sessions'`` to your :setting:`INSTALLED_APPS` setting.
 
 Once you have configured your installation, run ``manage.py syncdb``
 to install the single database table that stores session data.
@@ -359,8 +359,8 @@ setting to ``True``. When set to ``True``, Django will save the session to the
 database on every single request.
 
 Note that the session cookie is only sent when a session has been created or
-modified. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, the session cookie
-will be sent on every request.
+modified. If :setting:`SESSION_SAVE_EVERY_REQUEST` is ``True``, the session
+cookie will be sent on every request.
 
 Similarly, the ``expires`` part of a session cookie is updated each time the
 session cookie is sent.
@@ -372,15 +372,15 @@ You can control whether the session framework uses browser-length sessions vs.
 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
+By default, :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``False``,
+which means session cookies will be stored in users' browsers for as long as
 :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
-browser-length cookies -- cookies that expire as soon as the user closes his or
-her browser. Use this if you want people to have to log in every time they open
-a browser.
+If :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``True``, Django will
+use browser-length cookies -- cookies that expire as soon as the user closes
+his or her browser. Use this if you want people to have to log in every time
+they open a browser.
 
 This setting is a global default and can be overwritten at a per-session level
 by explicitly calling the :meth:`~backends.base.SessionBase.set_expiry` method

docs/topics/http/views.txt

@@ -48,7 +48,7 @@ Let's step through this code one line at a time:
 
 .. 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.
 

docs/topics/i18n/deployment.txt

@@ -13,7 +13,7 @@ use internationalization, you should take the two seconds to set
 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.
 
 .. note::
 
@@ -47,22 +47,22 @@ Django uses this language as the default translation -- the final attempt if no
 other translator finds a translation.
 
 If all you want to do is run Django with your native language, and a language
-file is available for it, all you need to do is set ``LANGUAGE_CODE``.
+file is available for it, all you need to do is set :setting:`LANGUAGE_CODE`.
 
 If you want to let each individual user specify which language he or she
 prefers, use ``LocaleMiddleware``. ``LocaleMiddleware`` enables language
 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
-should follow these guidelines:
+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.
     * It should come after ``SessionMiddleware``, because ``LocaleMiddleware``
       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',
@@ -81,7 +81,7 @@ following this algorithm:
 
     * Failing that, it looks for a cookie.
 
-      The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME``
+      The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME`
       setting. (The default name is ``django_language``.)
 
     * Failing that, it looks at the ``Accept-Language`` HTTP header. This
@@ -89,7 +89,7 @@ following this algorithm:
       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:
 
@@ -107,7 +107,7 @@ 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')),
@@ -118,7 +118,7 @@ Notes:
       selection to German and English (and any sublanguage, like de-ch or
       en-us).
 
-    * 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
@@ -139,7 +139,8 @@ Notes:
       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

docs/topics/i18n/internationalization.txt

@@ -674,9 +674,9 @@ You hook it up like this::
     )
 
 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
-that contains a ``locale`` directory. If you specify multiple packages, all
-those catalogs are merged into one catalog. This is useful if you have
+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.
 
 The precedence of translations is such that the packages appearing later in the
@@ -707,8 +707,8 @@ the ones appearing first having higher precedence than the ones appearing
 later.
 
 .. versionchanged:: 1.3
-    Directories listed in ``LOCALE_PATHS`` weren't included in the lookup
-    algorithm until version 1.3.
+    Directories listed in :setting:`LOCALE_PATHS` weren't included in the
+    lookup algorithm until version 1.3.
 
 Using the JavaScript translation catalog
 ----------------------------------------

docs/topics/logging.txt

@@ -486,7 +486,7 @@ Python logging module.
     The ``include_html`` argument of ``AdminEmailHandler`` is used to
     control whether the traceback email includes an HTML attachment
     containing the full content of the debug Web page that would have been
-    produced if ``DEBUG`` were ``True``. To set this value in your
+    produced if :setting:`DEBUG` were ``True``. To set this value in your
     configuration, include it in the handler definition for
     ``django.utils.log.AdminEmailHandler``, like this::
 

docs/topics/settings.txt

@@ -209,7 +209,7 @@ provides the default settings as the ``default_settings`` argument (or as the
 first positional argument) in the call to ``configure()``.
 
 In this example, default settings are taken from ``myapp_defaults``, and the
-``DEBUG`` setting is set to ``True``, regardless of its value in
+:setting:`DEBUG` setting is set to ``True``, regardless of its value in
 ``myapp_defaults``::
 
     from django.conf import settings

docs/topics/templates.txt

@@ -101,8 +101,8 @@ In the above example, ``{{ section.title }}`` will be replaced with the
 ``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 empty string) by default.
+the value of the :setting:`TEMPLATE_STRING_IF_INVALID` setting, which is set
+to ``''`` (the empty string) by default.
 
 Filters
 =======

docs/topics/testing.txt

@@ -383,7 +383,7 @@ entirely!). If you want to use a different database name, specify
 Aside from using a separate database, the test runner will otherwise
 use all of the same database settings you have in your settings file:
 :setting:`ENGINE`, :setting:`USER`, :setting:`HOST`, etc. The test
-database is created by the user specified by ``USER``, so you'll need
+database is created by the user specified by :setting:`USER`, so you'll need
 to make sure that the given user account has sufficient privileges to
 create a new database on the system.
 
@@ -1309,8 +1309,8 @@ In order to provide a reliable URL space for your test,
 ``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
-test.
+the value of that attribute as the :setting:`ROOT_URLCONF` for the duration
+of that test.
 
 For example::