Used auto-numbered lists in documentation.

docs/ref/applications.txt

@@ -303,10 +303,10 @@ Django applications require a single base filesystem path where Django
 etc. Thus, namespace packages may only be Django applications if one of the
 following is true:
 
-1. The namespace package actually has only a single location (i.e. is not
+#. The namespace package actually has only a single location (i.e. is not
    spread across more than one directory.)
 
-2. The :class:`~django.apps.AppConfig` class used to configure the application
+#. The :class:`~django.apps.AppConfig` class used to configure the application
    has a :attr:`~django.apps.AppConfig.path` class attribute, which is the
    absolute directory path Django will use as the single base path for the
    application.

docs/ref/class-based-views/base.txt

@@ -24,9 +24,9 @@ MRO is an acronym for Method Resolution Order.
 
     **Method Flowchart**
 
-    1. :meth:`dispatch()`
-    2. :meth:`http_method_not_allowed()`
-    3. :meth:`options()`
+    #. :meth:`dispatch()`
+    #. :meth:`http_method_not_allowed()`
+    #. :meth:`options()`
 
     **Example views.py**::
 
@@ -123,9 +123,9 @@ MRO is an acronym for Method Resolution Order.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`~django.views.generic.base.ContextMixin.get_context_data()`
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`~django.views.generic.base.ContextMixin.get_context_data()`
 
     **Example views.py**::
 
@@ -184,9 +184,9 @@ MRO is an acronym for Method Resolution Order.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`get_redirect_url()`
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`get_redirect_url()`
 
     **Example views.py**::
 

docs/ref/class-based-views/generic-display.txt

@@ -25,16 +25,16 @@ many projects they are typically the most commonly used views.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
-    4. :meth:`~django.views.generic.detail.SingleObjectMixin.get_slug_field()`
-    5. :meth:`~django.views.generic.detail.SingleObjectMixin.get_queryset()`
-    6. :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
-    7. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_object_name()`
-    8. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_data()`
-    9. ``get()``
-    10. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_slug_field()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_queryset()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_object_name()`
+    #. :meth:`~django.views.generic.detail.SingleObjectMixin.get_context_data()`
+    #. ``get()``
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
 
     **Example myapp/views.py**::
 
@@ -95,15 +95,14 @@ many projects they are typically the most commonly used views.
 
     **Method Flowchart**
 
-    1. :meth:`~django.views.generic.base.View.dispatch()`
-    2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
-    3. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
-    4. :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset()`
-    5. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_object_name()`
-    6. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_data()`
-    7. ``get()``
-    8. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
-
+    #. :meth:`~django.views.generic.base.View.dispatch()`
+    #. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
+    #. :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset()`
+    #. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_object_name()`
+    #. :meth:`~django.views.generic.list.MultipleObjectMixin.get_context_data()`
+    #. ``get()``
+    #. :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
 
     **Example views.py**::
 

docs/ref/clickjacking.txt

@@ -40,9 +40,9 @@ loading in a frame no matter which site made the request.
 Django provides a few simple ways to include this header in responses from your
 site:
 
-1. A simple middleware that sets the header in all responses.
+#. A simple middleware that sets the header in all responses.
 
-2. A set of view decorators that can be used to override the middleware or to
+#. A set of view decorators that can be used to override the middleware or to
    only set the header for certain views.
 
 The ``X-Frame-Options`` HTTP header will only be set by the middleware or view

docs/ref/contrib/gis/install/index.txt

@@ -8,9 +8,9 @@ Overview
 ========
 In general, GeoDjango installation requires:
 
-1. :ref:`Python and Django <django>`
-2. :ref:`spatial_database`
-3. :doc:`geolibs`
+#. :ref:`Python and Django <django>`
+#. :ref:`spatial_database`
+#. :doc:`geolibs`
 
 Details for each of the requirements and installation instructions
 are provided in the sections below. In addition, platform-specific

docs/ref/contrib/gis/layermapping.txt

@@ -31,7 +31,7 @@ then inserting into a GeoDjango model.
 Example
 =======
 
-1. You need a GDAL-supported data source, like a shapefile (here we're using
+#. You need a GDAL-supported data source, like a shapefile (here we're using
    a simple polygon shapefile, ``test_poly.shp``, with three features)::
 
     >>> from django.contrib.gis.gdal import DataSource
@@ -50,7 +50,7 @@ Example
         PRIMEM["Greenwich",0],
         UNIT["Degree",0.017453292519943295]]
 
-2. Now we define our corresponding Django model (make sure to use :djadmin:`migrate`)::
+#. Now we define our corresponding Django model (make sure to use :djadmin:`migrate`)::
 
     from django.contrib.gis.db import models
 
@@ -61,7 +61,7 @@ Example
         def __str__(self):
             return 'Name: %s' % self.name
 
-3. Use :class:`LayerMapping` to extract all the features and place them in the
+#. Use :class:`LayerMapping` to extract all the features and place them in the
    database::
 
     >>> from django.contrib.gis.utils import LayerMapping

docs/ref/contrib/postgres/fields.txt

@@ -292,8 +292,8 @@ transform do not change. For example::
 
     To use this field, you'll need to:
 
-    1. Add ``'django.contrib.postgres'`` in your :setting:`INSTALLED_APPS`.
-    2. :ref:`Setup the hstore extension <create-postgresql-extensions>` in
+    #. Add ``'django.contrib.postgres'`` in your :setting:`INSTALLED_APPS`.
+    #. :ref:`Setup the hstore extension <create-postgresql-extensions>` in
        PostgreSQL.
 
     You'll see an error like ``can't adapt type 'dict'`` if you skip the first

docs/ref/contrib/redirects.txt

@@ -14,12 +14,12 @@ Installation
 
 To install the redirects app, follow these steps:
 
-1. Ensure that the ``django.contrib.sites`` framework
+#. Ensure that the ``django.contrib.sites`` framework
    :ref:`is installed <enabling-the-sites-framework>`.
-2. Add ``'django.contrib.redirects'`` to your :setting:`INSTALLED_APPS` setting.
-3. Add ``'django.contrib.redirects.middleware.RedirectFallbackMiddleware'``
+#. Add ``'django.contrib.redirects'`` to your :setting:`INSTALLED_APPS` setting.
+#. Add ``'django.contrib.redirects.middleware.RedirectFallbackMiddleware'``
    to your :setting:`MIDDLEWARE` setting.
-4. Run the command :djadmin:`manage.py migrate <migrate>`.
+#. Run the command :djadmin:`manage.py migrate <migrate>`.
 
 How it works
 ============

docs/ref/contrib/sitemaps.txt

@@ -31,15 +31,13 @@ Installation
 
 To install the sitemap app, follow these steps:
 
-1. Add ``'django.contrib.sitemaps'`` to your :setting:`INSTALLED_APPS`
-   setting.
+#. Add ``'django.contrib.sitemaps'`` to your :setting:`INSTALLED_APPS` setting.
 
-2. Make sure your :setting:`TEMPLATES` setting contains a ``DjangoTemplates``
+#. Make sure your :setting:`TEMPLATES` setting contains a ``DjangoTemplates``
    backend whose ``APP_DIRS`` options is set to ``True``. It's in there by
    default, so you'll only need to change this if you've changed that setting.
 
-3. Make sure you've installed the
-   :mod:`sites framework <django.contrib.sites>`.
+#. Make sure you've installed the :mod:`sites framework<django.contrib.sites>`.
 
 (Note: The sitemap application doesn't install any database tables. The only
 reason it needs to go into :setting:`INSTALLED_APPS` is so that the

docs/ref/contrib/sites.txt

@@ -261,14 +261,13 @@ Enabling the sites framework
 
 To enable the sites framework, follow these steps:
 
-1. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS`
-   setting.
+#. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS` setting.
 
-2. Define a :setting:`SITE_ID` setting::
+#. Define a :setting:`SITE_ID` setting::
 
     SITE_ID = 1
 
-3. Run :djadmin:`migrate`.
+#. Run :djadmin:`migrate`.
 
 ``django.contrib.sites`` registers a
 :data:`~django.db.models.signals.post_migrate` signal handler which creates a

docs/ref/csrf.txt

@@ -27,7 +27,7 @@ How to use it
 
 To take advantage of CSRF protection in your views, follow these steps:
 
-1. The CSRF middleware is activated by default in the :setting:`MIDDLEWARE`
+#. The CSRF middleware is activated by default in the :setting:`MIDDLEWARE`
    setting. If you override that setting, remember that
    ``'django.middleware.csrf.CsrfViewMiddleware'`` should come before any view
    middleware that assume that CSRF attacks have been dealt with.
@@ -36,7 +36,7 @@ To take advantage of CSRF protection in your views, follow these steps:
    :func:`~django.views.decorators.csrf.csrf_protect` on particular views
    you want to protect (see below).
 
-2. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside
+#. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside
    the ``<form>`` element if the form is for an internal URL, e.g.:
 
    .. code-block:: html+django
@@ -46,7 +46,7 @@ To take advantage of CSRF protection in your views, follow these steps:
    This should not be done for POST forms that target external URLs, since
    that would cause the CSRF token to be leaked, leading to a vulnerability.
 
-3. In the corresponding view functions, ensure that
+#. In the corresponding view functions, ensure that
    :class:`~django.template.RequestContext` is used to render the response so
    that ``{% csrf_token %}`` will work properly. If you're using the
    :func:`~django.shortcuts.render` function, generic views, or contrib apps,
@@ -241,7 +241,7 @@ How it works
 
 The CSRF protection is based on the following things:
 
-1. A CSRF cookie that is based on a random secret value, which other sites
+#. A CSRF cookie that is based on a random secret value, which other sites
    will not have access to.
 
    This cookie is set by ``CsrfViewMiddleware``. It is sent with every
@@ -255,7 +255,7 @@ The CSRF protection is based on the following things:
    For security reasons, the value of the secret is changed each time a
    user logs in.
 
-2. A hidden form field with the name 'csrfmiddlewaretoken' present in all
+#. A hidden form field with the name 'csrfmiddlewaretoken' present in all
    outgoing POST forms. The value of this field is, again, the value of the
    secret, with a salt which is both added to it and used to scramble it. The
    salt is regenerated on every call to ``get_token()`` so that the form field
@@ -263,7 +263,7 @@ The CSRF protection is based on the following things:
 
    This part is done by the template tag.
 
-3. For all incoming requests that are not using HTTP GET, HEAD, OPTIONS or
+#. For all incoming requests that are not using HTTP GET, HEAD, OPTIONS or
    TRACE, a CSRF cookie must be present, and the 'csrfmiddlewaretoken' field
    must be present and correct. If it isn't, the user will get a 403 error.
 
@@ -274,7 +274,7 @@ The CSRF protection is based on the following things:
 
    This check is done by ``CsrfViewMiddleware``.
 
-4. In addition, for HTTPS requests, strict referer checking is done by
+#. In addition, for HTTPS requests, strict referer checking is done by
    ``CsrfViewMiddleware``. This means that even if a subdomain can set or
    modify cookies on your domain, it can't force a user to post to your
    application since that request won't come from your own exact domain.

docs/ref/databases.txt

@@ -415,10 +415,10 @@ Refer to the :doc:`settings documentation </ref/settings>`.
 
 Connection settings are used in this order:
 
-1. :setting:`OPTIONS`.
-2. :setting:`NAME`, :setting:`USER`, :setting:`PASSWORD`,
-   :setting:`HOST`, :setting:`PORT`
-3. MySQL option files.
+#. :setting:`OPTIONS`.
+#. :setting:`NAME`, :setting:`USER`, :setting:`PASSWORD`, :setting:`HOST`,
+   :setting:`PORT`
+#. MySQL option files.
 
 In other words, if you set the name of the database in :setting:`OPTIONS`,
 this will take precedence over :setting:`NAME`, which would override

docs/ref/django-admin.txt

@@ -1400,10 +1400,10 @@ For example, this command::
 
 ...would perform the following steps:
 
-1. Create a test database, as described in :ref:`the-test-database`.
-2. Populate the test database with fixture data from the given fixtures.
+#. Create a test database, as described in :ref:`the-test-database`.
+#. Populate the test database with fixture data from the given fixtures.
    (For more on fixtures, see the documentation for :djadmin:`loaddata` above.)
-3. Runs the Django development server (as in :djadmin:`runserver`), pointed at
+#. Runs the Django development server (as in :djadmin:`runserver`), pointed at
    this newly created test database instead of your production database.
 
 This is useful in a number of ways:

docs/ref/models/fields.txt

@@ -697,17 +697,17 @@ The default form widget for this field is a
 Using a :class:`FileField` or an :class:`ImageField` (see below) in a model
 takes a few steps:
 
-1. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as the
+#. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as the
    full path to a directory where you'd like Django to store uploaded files.
    (For performance, these files are not stored in the database.) Define
    :setting:`MEDIA_URL` as the base public URL of that directory. Make sure
    that this directory is writable by the Web server's user account.
 
-2. Add the :class:`FileField` or :class:`ImageField` to your model, defining
+#. Add the :class:`FileField` or :class:`ImageField` to your model, defining
    the :attr:`~FileField.upload_to` option to specify a subdirectory of
    :setting:`MEDIA_ROOT` to use for uploaded files.
 
-3. All that will be stored in your database is a path to the file
+#. All that will be stored in your database is a path to the file
    (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
    convenience :attr:`~django.db.models.fields.files.FieldFile.url` attribute
    provided by Django. For example, if your :class:`ImageField` is called

docs/ref/models/instances.txt

@@ -32,7 +32,7 @@ that, you need to :meth:`~Model.save()`.
     signature as any change may prevent the model instance from being saved.
     Rather than overriding ``__init__``, try using one of these approaches:
 
-    1. Add a classmethod on the model class::
+    #. Add a classmethod on the model class::
 
         from django.db import models
 
@@ -47,7 +47,7 @@ that, you need to :meth:`~Model.save()`.
 
         book = Book.create("Pride and Prejudice")
 
-    2. Add a method on a custom manager (usually preferred)::
+    #. Add a method on a custom manager (usually preferred)::
 
         class BookManager(models.Manager):
             def create_book(self, title):
@@ -135,9 +135,9 @@ If you need to reload a model's values from the database, you can use the
 ``refresh_from_db()`` method. When this method is called without arguments the
 following is done:
 
-1. All non-deferred fields of the model are updated to the values currently
+#. All non-deferred fields of the model are updated to the values currently
    present in the database.
-2. Any cached relations are cleared from the reloaded instance.
+#. Any cached relations are cleared from the reloaded instance.
 
 Only fields of the model are reloaded from the database. Other
 database-dependent values such as annotations aren't reloaded. Any

docs/ref/models/options.txt

@@ -163,12 +163,12 @@ Django quotes column and table names behind the scenes.
     the *only* difference when ``managed=False``. All other aspects of
     model handling are exactly the same as normal. This includes
 
-    1. Adding an automatic primary key field to the model if you don't
+    #. Adding an automatic primary key field to the model if you don't
        declare it.  To avoid confusion for later code readers, it's
        recommended to specify all the columns from the database table you
        are modeling when using unmanaged models.
 
-    2. If a model with ``managed=False`` contains a
+    #. If a model with ``managed=False`` contains a
        :class:`~django.db.models.ManyToManyField` that points to another
        unmanaged model, then the intermediate table for the many-to-many
        join will also not be created. However, the intermediary table