Fixed #14112 -- Various Markup fixes for the docs. Thanks to ramiro for the patch.

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

docs/faq/admin.txt

@@ -35,19 +35,22 @@ Set the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting to ``True``. See the
 How do I automatically set a field's value to the user who last edited the object in the admin?
 -----------------------------------------------------------------------------------------------
 
-The :class:`ModelAdmin` class provides customization hooks that allow you to transform
-an object as it saved, using details from the request. By extracting the current user
-from the request, and customizing the :meth:`ModelAdmin.save_model` hook, you can update
-an object to reflect the user that edited it. See :ref:`the documentation on ModelAdmin
-methods <model-admin-methods>` for an example.
+The :class:`~django.contrib.admin.ModelAdmin` class provides customization hooks
+that allow you to transform an object as it saved, using details from the
+request. By extracting the current user from the request, and customizing the
+:meth:`~django.contrib.admin.ModelAdmin.save_model` hook, you can update an
+object to reflect the user that edited it. See :ref:`the documentation on
+ModelAdmin methods <model-admin-methods>` for an example.
 
 How do I limit admin access so that objects can only be edited by the users who created them?
 ---------------------------------------------------------------------------------------------
 
-The :class:`ModelAdmin` class also provides customization hooks that allow you to control the
-visibility and editability of objects in the admin. Using the same trick of extracting the
-user from the request, the :meth:`ModelAdmin.queryset` and :meth:`ModelAdmin.has_change_permission`
-can be used to control the visibility and editability of objects in the admin.
+The :class:`~django.contrib.admin.ModelAdmin` class also provides customization
+hooks that allow you to control the visibility and editability of objects in the
+admin. Using the same trick of extracting the user from the request, the
+:meth:`~django.contrib.admin.ModelAdmin.queryset` and
+:meth:`~django.contrib.admin.ModelAdmin.has_change_permission` can be used to
+control the visibility and editability of objects in the admin.
 
 My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_python.
 ---------------------------------------------------------------------------------------------------------------------------

docs/ref/contrib/admin/index.txt

@@ -5,8 +5,6 @@ The Django admin site
 .. module:: django.contrib.admin
    :synopsis: Django's admin site.
 
-.. currentmodule:: django.contrib.admin
-
 One of the most powerful parts of Django is the automatic admin interface. It
 reads metadata in your model to provide a powerful and production-ready
 interface that content producers can immediately use to start adding content to
@@ -831,7 +829,7 @@ problems:
 
 Since this is usually not what you want, Django provides a convenience wrapper
 to check permissions and mark the view as non-cacheable. This wrapper is
-:meth:`AdminSite.admin_view` (i.e.  ``self.admin_site.admin_view`` inside a
+:meth:`AdminSite.admin_view` (i.e. ``self.admin_site.admin_view`` inside a
 ``ModelAdmin`` instance); use it like so::
 
     class MyModelAdmin(admin.ModelAdmin):
@@ -1010,6 +1008,8 @@ information.
 ``InlineModelAdmin`` objects
 ============================
 
+.. class:: InlineModelAdmin
+
 The admin interface has the ability to edit models on the same page as a
 parent model. These are called inlines. Suppose you have these two models::
 

docs/ref/contrib/contenttypes.txt

@@ -112,7 +112,7 @@ Methods on ``ContentType`` instances
 
     Takes a set of valid :ref:`lookup arguments <field-lookups-intro>` for the
     model the :class:`~django.contrib.contenttypes.models.ContentType`
-    represents, and does :ref:`a get() lookup <get-kwargs>` on that model,
+    represents, and does :lookup:`a get() lookup <get>` on that model,
     returning the corresponding object.
 
 .. method:: models.ContentType.model_class()
@@ -370,7 +370,7 @@ This enables the use of generic relations in forms and the admin. See the
 
     The :class:`~django.contrib.contenttypes.generic.GenericInlineModelAdmin`
     class inherits all properties from an
-    :class:`~django.contrib.admin.options.InlineModelAdmin` class. However,
+    :class:`~django.contrib.admin.InlineModelAdmin` class. However,
     it adds a couple of its own for working with the generic relation:
 
     .. attribute:: generic.GenericInlineModelAdmin.ct_field

docs/ref/contrib/gis/testing.txt

@@ -166,8 +166,8 @@ must be used.  To use this runner, configure :setting:`TEST_RUNNER` as follows::
 
 .. note::
 
-    In order to create a spatial database, the :setting:`DATABASE_USER` setting
-    (or :setting:`TEST_DATABASE_USER`, if optionally defined on Oracle) requires
+    In order to create a spatial database, the :setting:`USER` setting
+    (or :setting:`TEST_USER`, if optionally defined on Oracle) requires
     elevated privileges.  When using PostGIS or MySQL, the database user
     must have at least the ability to create databases.  When testing on Oracle,
     the user should be a superuser.

docs/ref/contrib/index.txt

@@ -166,8 +166,9 @@ For more documentation, read the source code in
 ReStructured Text
 -----------------
 
-When using the `restructuredtext` markup filter you can define a :setting:`RESTRUCTUREDTEXT_FORMAT_SETTINGS`
-in your django settings to override the default writer settings. See the `restructuredtext writer settings`_ for
+When using the ``restructuredtext`` markup filter you can define a
+:setting:`RESTRUCTUREDTEXT_FILTER_SETTINGS` in your django settings to override
+the default writer settings. See the `restructuredtext writer settings`_ for
 details on what these settings are.
 
 .. _restructuredtext writer settings: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer

docs/ref/django-admin.txt

@@ -104,7 +104,7 @@ compilemessages
 Compiles .po files created with ``makemessages`` to .mo files for use with
 the builtin gettext support. See :doc:`/topics/i18n/index`.
 
-Use the :djadminopt:`--locale`` option to specify the locale to process.
+Use the :djadminopt:`--locale` option to specify the locale to process.
 If not provided, all locales are processed.
 
 Example usage::

docs/ref/models/fields.txt

@@ -291,8 +291,6 @@ A human-readable name for the field. If the verbose name isn't given, Django
 will automatically create it using the field's attribute name, converting
 underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
 
-.. _model-field-types:
-
 ``validators``
 -------------------
 
@@ -303,6 +301,7 @@ underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
 A list of validators to run for this field.See the :doc:`validators
 documentation </ref/validators>` for more information.
 
+.. _model-field-types:
 
 Field types
 ===========

docs/ref/models/querysets.txt

@@ -962,8 +962,6 @@ something *other than* a ``QuerySet``.
 These methods do not use a cache (see :ref:`caching-and-querysets`). Rather,
 they query the database each time they're called.
 
-.. _get-kwargs:
-
 ``get(**kwargs)``
 ~~~~~~~~~~~~~~~~~
 

docs/ref/settings.txt

@@ -130,6 +130,22 @@ Default: ``'locmem://'``
 
 The cache backend to use. See :doc:`/topics/cache`.
 
+.. setting:: CACHE_MIDDLEWARE_ANONYMOUS_ONLY
+
+CACHE_MIDDLEWARE_ANONYMOUS_ONLY
+-------------------------------
+
+Default: ``False``
+
+If the value of this setting is ``True``, only anonymous requests (i.e., not
+those made by a logged-in user) will be cached.  Otherwise, the middleware
+caches every page that doesn't have GET or POST parameters.
+
+If you set the value of this setting to ``True``, you should make sure you've
+activated ``AuthenticationMiddleware``.
+
+See the :doc:`cache documentation </topics/cache>` for more information.
+
 .. setting:: CACHE_MIDDLEWARE_KEY_PREFIX
 
 CACHE_MIDDLEWARE_KEY_PREFIX
@@ -385,6 +401,17 @@ test database will use the name ``'test_' + DATABASE_NAME``.
 
 See :doc:`/topics/testing`.
 
+.. setting:: TEST_USER
+
+TEST_USER
+~~~~~~~~~
+
+Default: ``None``
+
+This is an Oracle-specific setting.
+
+The username to use when connecting to the Oracle database that will be used
+when running tests.
 
 .. setting:: DATABASE_ROUTERS
 
@@ -553,7 +580,7 @@ Default content type to use for all ``HttpResponse`` objects, if a MIME type
 isn't manually specified. Used with ``DEFAULT_CHARSET`` to construct the
 ``Content-Type`` header.
 
-.. setting:: DEFAULT_FROM_EMAIL
+.. setting:: DEFAULT_FILE_STORAGE
 
 DEFAULT_FILE_STORAGE
 --------------------
@@ -563,6 +590,8 @@ Default: ``'django.core.files.storage.FileSystemStorage'``
 Default file storage class to be used for any file-related operations that don't
 specify a particular storage system. See :doc:`/topics/files`.
 
+.. setting:: DEFAULT_FROM_EMAIL
+
 DEFAULT_FROM_EMAIL
 ------------------
 
@@ -1166,6 +1195,21 @@ We don't list the default values here, because that would be profane. To see
 the default values, see the file `django/conf/global_settings.py`_.
 
 .. _django/conf/global_settings.py: http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py
+
+.. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS
+
+RESTRUCTUREDTEXT_FILTER_SETTINGS
+--------------------------------
+
+Default: ``{}``
+
+A dictionary containing settings for the ``restructuredtext`` markup filter from
+the :doc:`django.contrib.markup application </ref/contrib/markup>`. They override
+the default writer settings. See the Docutils restructuredtext `writer settings
+docs`_ for details.
+
+.. _writer settings docs: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer
+
 .. setting:: ROOT_URLCONF
 
 ROOT_URLCONF

docs/ref/templates/api.txt

@@ -700,7 +700,7 @@ Configuring the template system in standalone mode
 
 Normally, Django will load all the configuration information it needs from its
 own default configuration file, combined with the settings in the module given
-in the :setting:`DJANGO_SETTINGS_MODULE` environment variable. But if you're
+in the :envvar:`DJANGO_SETTINGS_MODULE` environment variable. But if you're
 using the template system independently of the rest of Django, the environment
 variable approach isn't very convenient, because you probably want to configure
 the template system in line with the rest of your application rather than

docs/topics/testing.txt

@@ -310,7 +310,7 @@ but not gracefully. No details of the tests run before the interruption will
 be reported, and any test databases created by the run will not be destroyed.
 
 Running tests outside the test runner
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 If you want to run tests outside of ``./manage.py test`` -- for example,
 from a shell prompt -- you will need to set up the test
@@ -417,7 +417,7 @@ Other test conditions
 ---------------------
 
 Regardless of the value of the :setting:`DEBUG` setting in your configuration
-file, all Django tests run with :setting:`DEBUG=False`. This is to ensure that
+file, all Django tests run with :setting:`DEBUG`\=False. This is to ensure that
 the observed output of your code matches what will be seen in a production
 setting.