diff --git a/docs/ref/contrib/comments/index.txt b/docs/ref/contrib/comments/index.txt
index 817871e..e9b14c1 100644
--- a/docs/ref/contrib/comments/index.txt
+++ b/docs/ref/contrib/comments/index.txt
@@ -40,7 +40,7 @@ To get started using the ``comments`` app, follow these steps:
     #. Use the `comment template tags`_ below to embed comments in your
        templates.
 
-You might also want to examine :doc:`/ref/contrib/comments/settings`.
+You might also want to examine :ref:`the available settings <settings-comments>`.
 
 Comment template tags
 =====================
@@ -286,6 +286,13 @@ output the CSRF token and cookie.
 
 .. _honeypot: http://en.wikipedia.org/wiki/Honeypot_(computing)
 
+
+Configuration
+=============
+
+See: :ref:`comment settings <settings-comments>`
+
+
 More information
 ================
 
@@ -293,7 +300,6 @@ More information
    :maxdepth: 1
 
    models
-   settings
    signals
    upgrade
    custom
diff --git a/docs/ref/contrib/comments/settings.txt b/docs/ref/contrib/comments/settings.txt
deleted file mode 100644
index 1f1aeca..0000000
--- a/docs/ref/contrib/comments/settings.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-================
-Comment settings
-================
-
-These settings configure the behavior of the comments framework:
-
-.. setting:: COMMENTS_HIDE_REMOVED
-
-COMMENTS_HIDE_REMOVED
----------------------
-
-If ``True`` (default), removed comments will be excluded from comment
-lists/counts (as taken from template tags). Otherwise, the template author is
-responsible for some sort of a "this comment has been removed by the site staff"
-message.
-
-.. setting:: COMMENT_MAX_LENGTH
-
-COMMENT_MAX_LENGTH
-------------------
-
-The maximum length of the comment field, in characters. Comments longer than
-this will be rejected. Defaults to 3000.
-
-.. setting:: COMMENTS_APP
-
-COMMENTS_APP
-------------
-
-An app which provides :doc:`customization of the comments framework
-</ref/contrib/comments/custom>`.  Use the same dotted-string notation
-as in :setting:`INSTALLED_APPS`.  Your custom :setting:`COMMENTS_APP`
-must also be listed in :setting:`INSTALLED_APPS`.
diff --git a/docs/ref/contrib/messages.txt b/docs/ref/contrib/messages.txt
index 3081f27..66f6162 100644
--- a/docs/ref/contrib/messages.txt
+++ b/docs/ref/contrib/messages.txt
@@ -57,7 +57,7 @@ Storage backends
 ----------------
 
 The messages framework can use different backends to store temporary messages.
-To change which backend is being used, add a `MESSAGE_STORAGE`_ to your
+To change which backend is being used, add a :setting:`MESSAGE_STORAGE` to your
 settings, referencing the module and class of the storage class. For
 example::
 
@@ -114,6 +114,8 @@ first, followed by those stored in a cookie and in the session, if any.  Since
 messages stored in the ``Message`` model do not have a concept of levels, they
 will be assigned the ``INFO`` level by default.
 
+.. _message-level:
+
 Message levels
 --------------
 
@@ -135,7 +137,7 @@ Constant    Purpose
 ``ERROR``   An action was **not** successful or some other failure occurred
 =========== ========
 
-The `MESSAGE_LEVEL`_ setting can be used to change the minimum recorded level
+The :setting:`MESSAGE_LEVEL` setting can be used to change the minimum recorded level
 (or it can be `changed per request`_). Attempts to add messages of a level less
 than this will be ignored.
 
@@ -163,7 +165,7 @@ Level Constant  Tag
 ==============  ===========
 
 To change the default tags for a message level (either built-in or custom),
-set the `MESSAGE_TAGS`_ setting to a dictionary containing the levels
+set the :setting:`MESSAGE_TAGS` setting to a dictionary containing the levels
 you wish to change. As this extends the default tags, you only need to provide
 tags for the levels you wish to override::
 
@@ -193,6 +195,8 @@ used tags (which are usually represented as HTML classes for the message)::
     messages.warning(request, 'Your account expires in three days.')
     messages.error(request, 'Document deleted.')
 
+.. _message-displaying:
+
 Displaying messages
 -------------------
 
@@ -237,7 +241,7 @@ Level Constant  Value
 ==============  =====
 
 If you need to identify the custom levels in your HTML or CSS, you need to
-provide a mapping via the `MESSAGE_TAGS`_ setting.
+provide a mapping via the :setting:`MESSAGE_TAGS` setting.
 
 .. note::
    If you are creating a reusable application, it is recommended to use
@@ -341,71 +345,5 @@ window/tab will have its own browsing context.
 Settings
 ========
 
-A few :doc:`Django settings </ref/settings>` give you control over message
-behavior:
-
-MESSAGE_LEVEL
--------------
-
-Default: ``messages.INFO``
-
-This sets the minimum message that will be saved in the message storage.  See
-`Message levels`_ above for more details.
-
-.. admonition:: Important
-
-   If you override ``MESSAGE_LEVEL`` in your settings file and rely on any of
-   the built-in constants, you must import the constants module directly to
-   avoid the potential for circular imports, e.g.::
-
-       from django.contrib.messages import constants as message_constants
-       MESSAGE_LEVEL = message_constants.DEBUG
-
-   If desired, you may specify the numeric values for the constants directly
-   according to the values in the above :ref:`constants table
-   <message-level-constants>`.
-
-MESSAGE_STORAGE
----------------
-
-Default: ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'``
-
-Controls where Django stores message data. Valid values are:
-
-    * ``'django.contrib.messages.storage.fallback.FallbackStorage'``
-    * ``'django.contrib.messages.storage.session.SessionStorage'``
-    * ``'django.contrib.messages.storage.cookie.CookieStorage'``
-    * ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'``
-
-See `Storage backends`_ for more details.
-
-MESSAGE_TAGS
-------------
-
-Default::
-
-        {messages.DEBUG: 'debug',
-        messages.INFO: 'info',
-        messages.SUCCESS: 'success',
-        messages.WARNING: 'warning',
-        messages.ERROR: 'error',}
-
-This sets the mapping of message level to message tag, which is typically
-rendered as a CSS class in HTML. If you specify a value, it will extend
-the default. This means you only have to specify those values which you need
-to override. See `Displaying messages`_ above for more details.
-
-.. admonition:: Important
-
-   If you override ``MESSAGE_TAGS`` in your settings file and rely on any of
-   the built-in constants, you must import the ``constants`` module directly to
-   avoid the potential for circular imports, e.g.::
-
-       from django.contrib.messages import constants as message_constants
-       MESSAGE_TAGS = {message_constants.INFO: ''}
-
-   If desired, you may specify the numeric values for the constants directly
-   according to the values in the above :ref:`constants table
-   <message-level-constants>`.
-
-.. _Django settings: ../settings/
+A few settings give you control over message behavior. See
+:ref:`Messages settings <messages-comments>`.
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 380fa78..6b095f4 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -6,11 +6,11 @@ Settings
     :local:
     :depth: 1
 
-Available settings
-==================
+Core settings
+=============
 
-Here's a full list of all available settings, in alphabetical order, and their
-default values.
+Here's a list of settings available in Django core, and their default values.
+Settings provided by contrib apps are listed below.
 
 .. setting:: ABSOLUTE_URL_OVERRIDES
 
@@ -106,17 +106,6 @@ The ``APPEND_SLASH`` setting is only used if
 :class:`~django.middleware.common.CommonMiddleware` is installed
 (see :doc:`/topics/http/middleware`). See also :setting:`PREPEND_WWW`.
 
-.. setting:: AUTHENTICATION_BACKENDS
-
-AUTHENTICATION_BACKENDS
------------------------
-
-Default: ``('django.contrib.auth.backends.ModelBackend',)``
-
-A tuple of authentication backend classes (as strings) to use when attempting to
-authenticate a user. See the :doc:`authentication backends documentation
-</ref/authbackends>` for details.
-
 .. setting:: AUTH_PROFILE_MODULE
 
 AUTH_PROFILE_MODULE
@@ -1372,138 +1361,6 @@ Default: ``'root@localhost'``
 The e-mail address that error messages come from, such as those sent to
 ``ADMINS`` and ``MANAGERS``.
 
-.. setting:: SESSION_COOKIE_AGE
-
-SESSION_COOKIE_AGE
-------------------
-
-Default: ``1209600`` (2 weeks, in seconds)
-
-The age of session cookies, in seconds. See :doc:`/topics/http/sessions`.
-
-.. setting:: SESSION_COOKIE_DOMAIN
-
-SESSION_COOKIE_DOMAIN
----------------------
-
-Default: ``None``
-
-The domain to use for session cookies. Set this to a string such as
-``".lawrence.com"`` for cross-domain cookies, or use ``None`` for a standard
-domain cookie. See the :doc:`/topics/http/sessions`.
-
-.. setting:: SESSION_COOKIE_HTTPONLY
-
-SESSION_COOKIE_HTTPONLY
------------------------
-
-Default: ``False``
-
-Whether to use HTTPOnly flag on the session cookie. If this is set to
-``True``, client-side JavaScript will not to be able to access the
-session cookie.
-
-HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
-is not part of the RFC2109 standard for cookies, and it isn't honored
-consistently by all browsers. However, when it is honored, it can be a
-useful way to mitigate the risk of client side script accessing the
-protected cookie data.
-
-.. _HTTPOnly: http://www.owasp.org/index.php/HTTPOnly
-
-.. setting:: SESSION_COOKIE_NAME
-
-SESSION_COOKIE_NAME
--------------------
-
-Default: ``'sessionid'``
-
-The name of the cookie to use for sessions. This can be whatever you want (but
-should be different from ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/sessions`.
-
-.. setting:: SESSION_COOKIE_PATH
-
-SESSION_COOKIE_PATH
--------------------
-
-.. versionadded:: 1.0
-
-Default: ``'/'``
-
-The path set on the session cookie. This should either match the URL path of your
-Django installation or be parent of that path.
-
-This is useful if you have multiple Django instances running under the same
-hostname. They can use different cookie paths, and each instance will only see
-its own session cookie.
-
-.. setting:: SESSION_COOKIE_SECURE
-
-SESSION_COOKIE_SECURE
----------------------
-
-Default: ``False``
-
-Whether to use a secure cookie for the session cookie. If this is set to
-``True``, the cookie will be marked as "secure," which means browsers may
-ensure that the cookie is only sent under an HTTPS connection.
-See the :doc:`/topics/http/sessions`.
-
-.. setting:: SESSION_ENGINE
-
-SESSION_ENGINE
---------------
-
-.. versionadded:: 1.0
-
-.. versionchanged:: 1.1
-   The ``cached_db`` backend was added
-
-Default: ``django.contrib.sessions.backends.db``
-
-Controls where Django stores session data. Valid values are:
-
-    * ``'django.contrib.sessions.backends.db'``
-    * ``'django.contrib.sessions.backends.file'``
-    * ``'django.contrib.sessions.backends.cache'``
-    * ``'django.contrib.sessions.backends.cached_db'``
-
-See :doc:`/topics/http/sessions`.
-
-.. setting:: SESSION_EXPIRE_AT_BROWSER_CLOSE
-
-SESSION_EXPIRE_AT_BROWSER_CLOSE
--------------------------------
-
-Default: ``False``
-
-Whether to expire the session when the user closes his or her browser.
-See the :doc:`/topics/http/sessions`.
-
-.. setting:: SESSION_FILE_PATH
-
-SESSION_FILE_PATH
------------------
-
-.. versionadded:: 1.0
-
-Default: ``None``
-
-If you're using file-based session storage, this sets the directory in
-which Django will store session data. See :doc:`/topics/http/sessions`. When
-the default value (``None``) is used, Django will use the standard temporary
-directory for the system.
-
-.. setting:: SESSION_SAVE_EVERY_REQUEST
-
-SESSION_SAVE_EVERY_REQUEST
---------------------------
-
-Default: ``False``
-
-Whether to save the session data on every request. See
-:doc:`/topics/http/sessions`.
-
 .. setting:: SHORT_DATE_FORMAT
 
 SHORT_DATE_FORMAT
@@ -1536,21 +1393,6 @@ See :tfilter:`allowed date format strings <date>`.
 
 See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``.
 
-.. setting:: SITE_ID
-
-SITE_ID
--------
-
-Default: Not defined
-
-The ID, as an integer, of the current site in the ``django_site`` database
-table. This is used so that application data can hook into specific site(s)
-and a single database can manage content for multiple sites.
-
-See :doc:`/ref/contrib/sites`.
-
-.. _site framework docs: ../sites/
-
 .. setting:: STATIC_ROOT
 
 STATIC_ROOT
@@ -1878,9 +1720,305 @@ Different locales have different formats. For example, U.S. English would say
 See :tfilter:`allowed date format strings <date>`. See also ``DATE_FORMAT``,
 ``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``MONTH_DAY_FORMAT``.
 
+
+Contrib settings
+================
+
+Settings provided by contrib apps are grouped by app below.
+
+Auth
+----
+
+Settings for :mod:`django.contrib.auth`.
+
+.. setting:: AUTHENTICATION_BACKENDS
+
+AUTHENTICATION_BACKENDS
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``('django.contrib.auth.backends.ModelBackend',)``
+
+A tuple of authentication backend classes (as strings) to use when attempting to
+authenticate a user. See the :doc:`authentication backends documentation
+</ref/authbackends>` for details.
+
+.. _settings-comments:
+
+Comments
+--------
+
+Settings for :mod:`django.contrib.comments`.
+
+.. setting:: COMMENT_MAX_LENGTH
+
+COMMENT_MAX_LENGTH
+~~~~~~~~~~~~~~~~~~
+
+Default: ``3000`` (characters)
+
+The maximum length of the comment field, in characters. Comments longer than
+this will be rejected.
+
+.. setting:: COMMENTS_APP
+
+COMMENTS_APP
+~~~~~~~~~~~~
+
+An app which provides :doc:`customization of the comments framework
+</ref/contrib/comments/custom>`.  Use the same dotted-string notation
+as in :setting:`INSTALLED_APPS`.  Your custom :setting:`COMMENTS_APP`
+must also be listed in :setting:`INSTALLED_APPS`.
+
+.. setting:: COMMENTS_HIDE_REMOVED
+
+COMMENTS_HIDE_REMOVED
+~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``True``
+
+If ``True``, removed comments will be excluded from comment
+lists and counts (as taken from template tags). Otherwise, the template author
+isresponsible for some sort of a "this comment has been removed by the site
+staff" message.
+
+
+.. _messages-comments:
+
+Messages
+--------
+
+Settings for :mod:`django.contrib.messages`.
+
+.. setting:: MESSAGE_LEVEL
+
+MESSAGE_LEVEL
+~~~~~~~~~~~~~
+
+Default: ``messages.INFO``
+
+This sets the minimum message that will be saved in the message storage.  See
+:ref:`message levels <message-level>` for more details.
+
+.. admonition:: Important
+
+   If you override ``MESSAGE_LEVEL`` in your settings file and rely on any of
+   the built-in constants, you must import the constants module directly to
+   avoid the potential for circular imports, e.g.::
+
+       from django.contrib.messages import constants as message_constants
+       MESSAGE_LEVEL = message_constants.DEBUG
+
+   If desired, you may specify the numeric values for the constants directly
+   according to the values in the :ref:`constants table
+   <message-level-constants>`.
+
+.. setting:: MESSAGE_STORAGE
+
+MESSAGE_STORAGE
+~~~~~~~~~~~~~~~
+
+Default: ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'``
+
+Controls where Django stores message data. Valid values are:
+
+    * ``'django.contrib.messages.storage.fallback.FallbackStorage'``
+    * ``'django.contrib.messages.storage.session.SessionStorage'``
+    * ``'django.contrib.messages.storage.cookie.CookieStorage'``
+    * ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'``
+
+See :ref:`message storage backends <message-storage-backends>` for more details.
+
+.. setting:: MESSAGE_TAGS
+
+MESSAGE_TAGS
+~~~~~~~~~~~~
+
+Default::
+
+        {messages.DEBUG: 'debug',
+        messages.INFO: 'info',
+        messages.SUCCESS: 'success',
+        messages.WARNING: 'warning',
+        messages.ERROR: 'error',}
+
+This sets the mapping of message level to message tag, which is typically
+rendered as a CSS class in HTML. If you specify a value, it will extend
+the default. This means you only have to specify those values which you need
+to override. See :ref:`displaying messages <message-displaying>` for more details.
+
+.. admonition:: Important
+
+   If you override ``MESSAGE_TAGS`` in your settings file and rely on any of
+   the built-in constants, you must import the ``constants`` module directly to
+   avoid the potential for circular imports, e.g.::
+
+       from django.contrib.messages import constants as message_constants
+       MESSAGE_TAGS = {message_constants.INFO: ''}
+
+   If desired, you may specify the numeric values for the constants directly
+   according to the values in the above :ref:`constants table
+   <message-level-constants>`.
+
+
+Sessions
+--------
+
+Settings for :mod:`django.contrib.sessions`.
+
+.. setting:: SESSION_COOKIE_AGE
+
+SESSION_COOKIE_AGE
+~~~~~~~~~~~~~~~~~~
+
+Default: ``1209600`` (2 weeks, in seconds)
+
+The age of session cookies, in seconds. See :doc:`/topics/http/sessions`.
+
+.. setting:: SESSION_COOKIE_DOMAIN
+
+SESSION_COOKIE_DOMAIN
+~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``None``
+
+The domain to use for session cookies. Set this to a string such as
+``".lawrence.com"`` for cross-domain cookies, or use ``None`` for a standard
+domain cookie. See the :doc:`/topics/http/sessions`.
+
+.. setting:: SESSION_COOKIE_HTTPONLY
+
+SESSION_COOKIE_HTTPONLY
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``False``
+
+Whether to use HTTPOnly flag on the session cookie. If this is set to
+``True``, client-side JavaScript will not to be able to access the
+session cookie.
+
+HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
+is not part of the RFC2109 standard for cookies, and it isn't honored
+consistently by all browsers. However, when it is honored, it can be a
+useful way to mitigate the risk of client side script accessing the
+protected cookie data.
+
+.. _HTTPOnly: http://www.owasp.org/index.php/HTTPOnly
+
+.. setting:: SESSION_COOKIE_NAME
+
+SESSION_COOKIE_NAME
+~~~~~~~~~~~~~~~~~~~
+
+Default: ``'sessionid'``
+
+The name of the cookie to use for sessions. This can be whatever you want (but
+should be different from ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/sessions`.
+
+.. setting:: SESSION_COOKIE_PATH
+
+SESSION_COOKIE_PATH
+~~~~~~~~~~~~~~~~~~~
+
+.. versionadded:: 1.0
+
+Default: ``'/'``
+
+The path set on the session cookie. This should either match the URL path of your
+Django installation or be parent of that path.
+
+This is useful if you have multiple Django instances running under the same
+hostname. They can use different cookie paths, and each instance will only see
+its own session cookie.
+
+.. setting:: SESSION_COOKIE_SECURE
+
+SESSION_COOKIE_SECURE
+~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``False``
+
+Whether to use a secure cookie for the session cookie. If this is set to
+``True``, the cookie will be marked as "secure," which means browsers may
+ensure that the cookie is only sent under an HTTPS connection.
+See the :doc:`/topics/http/sessions`.
+
+.. setting:: SESSION_ENGINE
+
+SESSION_ENGINE
+~~~~~~~~~~~~~~
+
+.. versionadded:: 1.0
+
+.. versionchanged:: 1.1
+   The ``cached_db`` backend was added
+
+Default: ``django.contrib.sessions.backends.db``
+
+Controls where Django stores session data. Valid values are:
+
+    * ``'django.contrib.sessions.backends.db'``
+    * ``'django.contrib.sessions.backends.file'``
+    * ``'django.contrib.sessions.backends.cache'``
+    * ``'django.contrib.sessions.backends.cached_db'``
+
+See :doc:`/topics/http/sessions`.
+
+.. setting:: SESSION_EXPIRE_AT_BROWSER_CLOSE
+
+SESSION_EXPIRE_AT_BROWSER_CLOSE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``False``
+
+Whether to expire the session when the user closes his or her browser.
+See the :doc:`/topics/http/sessions`.
+
+.. setting:: SESSION_FILE_PATH
+
+SESSION_FILE_PATH
+~~~~~~~~~~~~~~~~~
+
+.. versionadded:: 1.0
+
+Default: ``None``
+
+If you're using file-based session storage, this sets the directory in
+which Django will store session data. See :doc:`/topics/http/sessions`. When
+the default value (``None``) is used, Django will use the standard temporary
+directory for the system.
+
+.. setting:: SESSION_SAVE_EVERY_REQUEST
+
+SESSION_SAVE_EVERY_REQUEST
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Default: ``False``
+
+Whether to save the session data on every request. See
+:doc:`/topics/http/sessions`.
+
+Sites
+-----
+
+Settings for :mod:`django.contrib.sites`.
+
+.. setting:: SITE_ID
+
+SITE_ID
+~~~~~~~
+
+Default: Not defined
+
+The ID, as an integer, of the current site in the ``django_site`` database
+table. This is used so that application data can hook into specific sites
+and a single database can manage content for multiple sites.
+
+
 Deprecated settings
 ===================
 
+The settings in this setion are deprecated.
+
 .. setting:: DATABASE_ENGINE
 
 DATABASE_ENGINE
@@ -1970,4 +2108,3 @@ TEST_DATABASE_NAME
 .. deprecated:: 1.2
    This setting has been replaced by :setting:`TEST_NAME` in
    :setting:`DATABASES`.
-
