Fixed many more ReST indentation errors, somehow accidentally missed from [16955]

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

docs/faq/admin.txt

@@ -8,12 +8,12 @@ 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 :setting:`SESSION_COOKIE_DOMAIN` setting in your admin config
+* 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'``.
 
-    * Some browsers (Firefox?) don't like to accept cookies from domains that
+* Some browsers (Firefox?) don't like to accept cookies from domains that
   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

docs/faq/contributing.txt

@@ -26,15 +26,15 @@ The best way to make sure tickets do not get hung up on the way to checkin is
 to make it dead easy, even for someone who may not be intimately familiar with
 that area of the code, to understand the problem and verify the fix:
 
-    * Are there clear instructions on how to reproduce the bug? If this
+* Are there clear instructions on how to reproduce the bug? If this
   touches a dependency (such as PIL), a contrib module, or a specific
   database, are those instructions clear enough even for someone not
   familiar with it?
 
-    * If there are several patches attached to the ticket, is it clear what
+* If there are several patches attached to the ticket, is it clear what
   each one does, which ones can be ignored and which matter?
 
-    * Does the patch include a unit test? If not, is there a very clear
+* Does the patch include a unit test? If not, is there a very clear
   explanation why not? A test expresses succinctly what the problem is,
   and shows that the patch actually fixes it.
 

docs/faq/install.txt

@@ -4,10 +4,10 @@ FAQ: Installation
 How do I get started?
 ---------------------
 
-    #. `Download the code`_.
+#. `Download the code`_.
-    #. Install Django (read the :doc:`installation guide </intro/install>`).
+#. Install Django (read the :doc:`installation guide </intro/install>`).
-    #. Walk through the :doc:`tutorial </intro/tutorial01>`.
+#. Walk through the :doc:`tutorial </intro/tutorial01>`.
-    #. Check out the rest of the :doc:`documentation </index>`, and `ask questions`_ if you
+#. Check out the rest of the :doc:`documentation </index>`, and `ask questions`_ if you
    run into trouble.
 
 .. _`Download the code`: http://www.djangoproject.com/download/

docs/faq/usage.txt

@@ -6,14 +6,14 @@ Why do I get an error about importing DJANGO_SETTINGS_MODULE?
 
 Make sure that:
 
-    * The environment variable DJANGO_SETTINGS_MODULE is set to a
+* The environment variable DJANGO_SETTINGS_MODULE is set to a
   fully-qualified Python module (i.e. "mysite.settings").
 
-    * Said module is on ``sys.path`` (``import mysite.settings`` should work).
+* Said module is on ``sys.path`` (``import mysite.settings`` should work).
 
-    * The module doesn't contain syntax errors (of course).
+* The module doesn't contain syntax errors (of course).
 
-    * If you're using mod_python but *not* using Django's request handler,
+* If you're using mod_python but *not* using Django's request handler,
   you'll need to work around a mod_python bug related to the use of
   ``SetEnv``; before you import anything from Django you'll need to do
   the following::
@@ -46,20 +46,20 @@ How do I use image and file fields?
 Using a :class:`~django.db.models.FileField` or an
 :class:`~django.db.models.ImageField` in a model takes a few steps:
 
-    #. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as
+#. 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.
 
-    #. Add the :class:`~django.db.models.FileField` or
+#. Add the :class:`~django.db.models.FileField` or
    :class:`~django.db.models.ImageField` to your model, making sure to
    define the :attr:`~django.db.models.FileField.upload_to` option to tell
    Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload
    files.
 
-    #. 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.core.files.File.url` attribute provided by
    Django. For example, if your :class:`~django.db.models.ImageField` is

docs/howto/apache-auth.txt

@@ -14,12 +14,12 @@ dealing with Apache, you can configuring Apache to authenticate against Django's
 :doc:`authentication system </topics/auth>` directly. For example, you
 could:
 
-    * Serve static/media files directly from Apache only to authenticated users.
+* Serve static/media files directly from Apache only to authenticated users.
 
-    * Authenticate access to a Subversion_ repository against Django users with
+* Authenticate access to a Subversion_ repository against Django users with
   a certain permission.
 
-    * Allow certain users to connect to a WebDAV share created with mod_dav_.
+* Allow certain users to connect to a WebDAV share created with mod_dav_.
 
 .. _Subversion: http://subversion.tigris.org/
 .. _mod_dav: http://httpd.apache.org/docs/2.0/mod/mod_dav.html
@@ -93,29 +93,29 @@ By default, the authentication handler will limit access to the ``/example/``
 location to users marked as staff members.  You can use a set of
 ``PythonOption`` directives to modify this behavior:
 
-    ================================  =========================================
+================================  =========================================
-    ``PythonOption``                  Explanation
+``PythonOption``                  Explanation
-    ================================  =========================================
+================================  =========================================
-    ``DjangoRequireStaffStatus``      If set to ``on`` only "staff" users (i.e.
+``DjangoRequireStaffStatus``      If set to ``on`` only "staff" users (i.e.
                                   those with the ``is_staff`` flag set)
                                   will be allowed.
 
                                   Defaults to ``on``.
 
-    ``DjangoRequireSuperuserStatus``  If set to ``on`` only superusers (i.e.
+``DjangoRequireSuperuserStatus``  If set to ``on`` only superusers (i.e.
                                   those with the ``is_superuser`` flag set)
                                   will be allowed.
 
                                   Defaults to ``off``.
 
-    ``DjangoPermissionName``          The name of a permission to require for
+``DjangoPermissionName``          The name of a permission to require for
                                   access. See :ref:`custom permissions
                                   <custom-permissions>` for more
                                   information.
 
                                   By default no specific permission will be
                                   required.
-    ================================  =========================================
+================================  =========================================
 
 Note that sometimes ``SetEnv`` doesn't play well in this mod_python
 configuration, for reasons unknown. If you're having problems getting

docs/howto/custom-file-storage.txt

@@ -37,11 +37,11 @@ You'll need to follow these steps:
 Your custom storage system may override any of the storage methods explained in
 :doc:`/ref/files/storage`, but you **must** implement the following methods:
 
-    * :meth:`Storage.delete`
+* :meth:`Storage.delete`
-    * :meth:`Storage.exists`
+* :meth:`Storage.exists`
-    * :meth:`Storage.listdir`
+* :meth:`Storage.listdir`
-    * :meth:`Storage.size`
+* :meth:`Storage.size`
-    * :meth:`Storage.url`
+* :meth:`Storage.url`
 
 You'll also usually want to use hooks specifically designed for custom storage
 objects. These are:

docs/howto/custom-model-fields.txt

@@ -133,12 +133,12 @@ example). If this sounds a bit tricky, don't worry -- it will become clearer in
 the examples below. Just remember that you will often end up creating two
 classes when you want a custom field:
 
-    * The first class is the Python object that your users will manipulate.
+* The first class is the Python object that your users will manipulate.
   They will assign it to the model attribute, they will read from it for
   displaying purposes, things like that. This is the ``Hand`` class in our
   example.
 
-    * The second class is the ``Field`` subclass. This is the class that knows
+* The second class is the ``Field`` subclass. This is the class that knows
   how to convert your first class back and forth between its permanent
   storage form and the Python form.
 
@@ -198,31 +198,31 @@ card values plus their suits; 104 characters in total.
 The :meth:`~django.db.models.Field.__init__` method takes the following
 parameters:
 
-    * :attr:`~django.db.models.Field.verbose_name`
+* :attr:`~django.db.models.Field.verbose_name`
-    * :attr:`~django.db.models.Field.name`
+* :attr:`~django.db.models.Field.name`
-    * :attr:`~django.db.models.Field.primary_key`
+* :attr:`~django.db.models.Field.primary_key`
-    * :attr:`~django.db.models.Field.max_length`
+* :attr:`~django.db.models.Field.max_length`
-    * :attr:`~django.db.models.Field.unique`
+* :attr:`~django.db.models.Field.unique`
-    * :attr:`~django.db.models.Field.blank`
+* :attr:`~django.db.models.Field.blank`
-    * :attr:`~django.db.models.Field.null`
+* :attr:`~django.db.models.Field.null`
-    * :attr:`~django.db.models.Field.db_index`
+* :attr:`~django.db.models.Field.db_index`
-    * :attr:`~django.db.models.Field.rel`: Used for related fields (like
+* :attr:`~django.db.models.Field.rel`: Used for related fields (like
   :class:`ForeignKey`). For advanced use only.
-    * :attr:`~django.db.models.Field.default`
+* :attr:`~django.db.models.Field.default`
-    * :attr:`~django.db.models.Field.editable`
+* :attr:`~django.db.models.Field.editable`
-    * :attr:`~django.db.models.Field.serialize`: If ``False``, the field will
+* :attr:`~django.db.models.Field.serialize`: If ``False``, the field will
   not be serialized when the model is passed to Django's :doc:`serializers
   </topics/serialization>`. Defaults to ``True``.
-    * :attr:`~django.db.models.Field.unique_for_date`
+* :attr:`~django.db.models.Field.unique_for_date`
-    * :attr:`~django.db.models.Field.unique_for_month`
+* :attr:`~django.db.models.Field.unique_for_month`
-    * :attr:`~django.db.models.Field.unique_for_year`
+* :attr:`~django.db.models.Field.unique_for_year`
-    * :attr:`~django.db.models.Field.choices`
+* :attr:`~django.db.models.Field.choices`
-    * :attr:`~django.db.models.Field.help_text`
+* :attr:`~django.db.models.Field.help_text`
-    * :attr:`~django.db.models.Field.db_column`
+* :attr:`~django.db.models.Field.db_column`
-    * :attr:`~django.db.models.Field.db_tablespace`: Currently only used with
+* :attr:`~django.db.models.Field.db_tablespace`: Currently only used with
   the Oracle backend and only for index creation. You can usually ignore
   this option.
-    * :attr:`~django.db.models.Field.auto_created`: True if the field was
+* :attr:`~django.db.models.Field.auto_created`: True if the field was
   automatically created, as for the `OneToOneField` used by model
   inheritance. For advanced use only.
 
@@ -415,11 +415,11 @@ that are more complex than strings, dates, integers or floats, then you'll need
 to override this method. As a general rule, the method should deal gracefully
 with any of the following arguments:
 
-    * An instance of the correct type (e.g., ``Hand`` in our ongoing example).
+* An instance of the correct type (e.g., ``Hand`` in our ongoing example).
 
-    * A string (e.g., from a deserializer).
+* A string (e.g., from a deserializer).
 
-    * Whatever the database returns for the column type you're using.
+* Whatever the database returns for the column type you're using.
 
 In our ``HandField`` class, we're storing the data as a VARCHAR field in the
 database, so we need to be able to process strings and ``Hand`` instances in
@@ -695,12 +695,12 @@ complex conversions between your Python types and your database and
 serialization formats. Here are a couple of tips to make things go more
 smoothly:
 
-    1. Look at the existing Django fields (in
+1. Look at the existing Django fields (in
    :file:`django/db/models/fields/__init__.py`) for inspiration. Try to find
    a field that's similar to what you want and extend it a little bit,
    instead of creating an entirely new field from scratch.
 
-    2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
+2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
    wrapping up as a field. There are a lot of places where the default
    behavior of the field code is to call
    :func:`~django.utils.encoding.force_unicode` on the value. (In our
@@ -735,12 +735,12 @@ 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.
 
-    1. The source for Django's own ``ImageField`` (in
+1. The source for Django's own ``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.
 
-    2. Cache file attributes wherever possible. Since files may be stored in
+2. Cache file attributes wherever possible. Since files may be stored in
    remote storage systems, retrieving them may cost extra time, or even
    money, that isn't always necessary. Once a file is retrieved to obtain
    some data about its content, cache as much of that data as possible to

docs/howto/custom-template-tags.txt

@@ -77,8 +77,8 @@ Writing custom template filters
 
 Custom filters are just Python functions that take one or two arguments:
 
-    * The value of the variable (input) -- not necessarily a string.
+* The value of the variable (input) -- not necessarily a string.
-    * The value of the argument -- this can have a default value, or be left
+* The value of the argument -- this can have a default value, or be left
   out altogether.
 
 For example, in the filter ``{{ var|foo:"bar" }}``, the filter ``foo`` would be
@@ -124,8 +124,8 @@ your ``Library`` instance, to make it available to Django's template language:
 
 The ``Library.filter()`` method takes two arguments:
 
-    1. The name of the filter -- a string.
+1. The name of the filter -- a string.
-    2. The compilation function -- a Python function (not the name of the
+2. The compilation function -- a Python function (not the name of the
    function as a string).
 
 You can use ``register.filter()`` as a decorator instead:
@@ -173,11 +173,11 @@ When writing a custom filter, give some thought to how the filter will interact
 with Django's auto-escaping behavior. Note that three types of strings can be
 passed around inside the template code:
 
-    * **Raw strings** are the native Python ``str`` or ``unicode`` types. On
+* **Raw strings** are the native Python ``str`` or ``unicode`` types. On
   output, they're escaped if auto-escaping is in effect and presented
   unchanged, otherwise.
 
-    * **Safe strings** are strings that have been marked safe from further
+* **Safe strings** are strings that have been marked safe from further
   escaping at output time. Any necessary escaping has already been done.
   They're commonly used for output that contains raw HTML that is intended
   to be interpreted as-is on the client side.
@@ -192,7 +192,7 @@ passed around inside the template code:
           # Do something with the "safe" string.
           ...
 
-    * **Strings marked as "needing escaping"** are *always* escaped on
+* **Strings marked as "needing escaping"** are *always* escaped on
   output, regardless of whether they are in an :ttag:`autoescape` block or
   not. These strings are only escaped once, however, even if auto-escaping
   applies.
@@ -203,7 +203,7 @@ passed around inside the template code:
 
 Template filter code falls into one of two situations:
 
-    1. Your filter does not introduce any HTML-unsafe characters (``<``, ``>``,
+1. Your filter does not introduce any HTML-unsafe characters (``<``, ``>``,
    ``'``, ``"`` or ``&``) into the result that were not already present. In
    this case, you can let Django take care of all the auto-escaping
    handling for you. All you need to do is put the ``is_safe`` attribute on
@@ -264,7 +264,7 @@ Template filter code falls into one of two situations:
    consequences (such as converting a boolean False to the string
    'False').
 
-    2. Alternatively, your filter code can manually take care of any necessary
+2. Alternatively, your filter code can manually take care of any necessary
    escaping. This is necessary when you're introducing new HTML markup into
    the result. You want to mark the output as safe from further
    escaping so that your HTML markup isn't escaped further, so you'll need
@@ -381,34 +381,34 @@ object:
 
 Notes:
 
-    * ``parser`` is the template parser object. We don't need it in this
+* ``parser`` is the template parser object. We don't need it in this
   example.
 
-    * ``token.contents`` is a string of the raw contents of the tag. In our
+* ``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 ``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
   split on *all* spaces, including those within quoted strings. It's a good
   idea to always use ``token.split_contents()``.
 
-    * This function is responsible for raising
+* This function is responsible for raising
   ``django.template.TemplateSyntaxError``, with helpful messages, for
   any syntax error.
 
-    * The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
+* The ``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
   arguments.
 
-    * The function returns a ``CurrentTimeNode`` with everything the node needs
+* The function returns a ``CurrentTimeNode`` with everything the node needs
   to know about this tag. In this case, it just passes the argument --
   ``"%Y-%m-%d %I:%M %p"``. The leading and trailing quotes from the
   template tag are removed in ``format_string[1:-1]``.
 
-    * The parsing is very low-level. The Django developers have experimented
+* The parsing is very low-level. The Django developers have experimented
   with writing small frameworks on top of this parsing system, using
   techniques such as EBNF grammars, but those experiments made the template
   engine too slow. It's low-level because that's fastest.
@@ -433,13 +433,13 @@ Continuing the above example, we need to define ``CurrentTimeNode``:
 
 Notes:
 
-    * ``__init__()`` gets the ``format_string`` from ``do_current_time()``.
+* ``__init__()`` gets the ``format_string`` from ``do_current_time()``.
   Always pass any options/parameters/arguments to a ``Node`` via its
   ``__init__()``.
 
-    * The ``render()`` method is where the work actually happens.
+* The ``render()`` method is where the work actually happens.
 
-    * ``render()`` should never raise ``TemplateSyntaxError`` or any other
+* ``render()`` should never raise ``TemplateSyntaxError`` or any other
   exception. It should fail silently, just as template filters should.
 
 Ultimately, this decoupling of compilation and rendering results in an
@@ -525,13 +525,13 @@ A naive implementation of ``CycleNode`` might look something like this:
 But, suppose we have two templates rendering the template snippet from above at
 the same time:
 
-    1. Thread 1 performs its first loop iteration, ``CycleNode.render()``
+1. Thread 1 performs its first loop iteration, ``CycleNode.render()``
    returns 'row1'
-    2. Thread 2 performs its first loop iteration, ``CycleNode.render()``
+2. Thread 2 performs its first loop iteration, ``CycleNode.render()``
    returns 'row2'
-    3. Thread 1 performs its second loop iteration, ``CycleNode.render()``
+3. Thread 1 performs its second loop iteration, ``CycleNode.render()``
    returns 'row1'
-    4. Thread 2 performs its second loop iteration, ``CycleNode.render()``
+4. Thread 2 performs its second loop iteration, ``CycleNode.render()``
    returns 'row2'
 
 The CycleNode is iterating, but it's iterating globally. As far as Thread 1
@@ -584,9 +584,9 @@ in "Writing custom template filters" above. Example:
 
 The ``tag()`` method takes two arguments:
 
-    1. The name of the template tag -- a string. If this is left out, the
+1. The name of the template tag -- a string. If this is left out, the
    name of the compilation function will be used.
-    2. The compilation function -- a Python function (not the name of the
+2. The compilation function -- a Python function (not the name of the
    function as a string).
 
 As with filter registration, it is also possible to use this as a decorator:
@@ -623,10 +623,10 @@ tag format that date-time:
 
 Initially, ``token.split_contents()`` will return three values:
 
-    1. The tag name ``format_time``.
+1. The tag name ``format_time``.
-    2. The string ``"blog_entry.date_updated"`` (without the surrounding
+2. The string ``"blog_entry.date_updated"`` (without the surrounding
    quotes).
-    3. The formatting string ``"%Y-%m-%d %I:%M %p"``. The return value from
+3. The formatting string ``"%Y-%m-%d %I:%M %p"``. The return value from
    ``split_contents()`` will include the leading and trailing quotes for
    string literals like this.
 
@@ -706,11 +706,11 @@ The decorator syntax also works:
 
 A few things to note about the ``simple_tag`` helper function:
 
-    * Checking for the required number of arguments, etc., has already been
+* Checking for the required number of arguments, etc., has already been
   done by the time our function is called, so we don't need to do that.
-    * The quotes around the argument (if any) have already been stripped away,
+* The quotes around the argument (if any) have already been stripped away,
   so we just receive a plain string.
-    * If the argument was a template variable, our function is passed the
+* If the argument was a template variable, our function is passed the
   current value of the variable, not the variable itself.
 
 .. versionadded:: 1.3

docs/howto/deployment/fastcgi.txt

@@ -168,9 +168,9 @@ Once you've got that set up, point Apache at your Django FastCGI instance by
 editing the ``httpd.conf`` (Apache configuration) file. You'll need to do two
 things:
 
-    * Use the ``FastCGIExternalServer`` directive to specify the location of
+* Use the ``FastCGIExternalServer`` directive to specify the location of
   your FastCGI server.
-    * Use ``mod_rewrite`` to point URLs at FastCGI as appropriate.
+* Use ``mod_rewrite`` to point URLs at FastCGI as appropriate.
 
 .. _mod_fastcgi: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
 

docs/howto/deployment/modpython.txt

@@ -240,11 +240,11 @@ server you choose.
 We recommend using a separate Web server -- i.e., one that's not also running
 Django -- for serving media. Here are some good choices:
 
-    * lighttpd_
+* lighttpd_
-    * Nginx_
+* Nginx_
-    * TUX_
+* TUX_
-    * A stripped-down version of Apache_
+* A stripped-down version of Apache_
-    * Cherokee_
+* Cherokee_
 
 If, however, you have no option but to serve media or static files on the
 same Apache ``VirtualHost`` as Django, here's how you can turn off mod_python
@@ -299,10 +299,10 @@ Django distribution.
 We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
 the admin files, but here are two other approaches:
 
-    1. Create a symbolic link to the admin static files from within your
+1. Create a symbolic link to the admin static files from within your
    document root.
 
-    2. Or, copy the admin static files so that they live within your Apache
+2. Or, copy the admin static files so that they live within your Apache
    document root.
 
 Using "eggs" with mod_python
@@ -362,11 +362,11 @@ If you get a segmentation fault
 If Apache causes a segmentation fault, there are two probable causes, neither
 of which has to do with Django itself.
 
-    1. It may be because your Python code is importing the "pyexpat" module,
+1. It may be because your Python code is importing the "pyexpat" module,
    which may conflict with the version embedded in Apache. For full
    information, see `Expat Causing Apache Crash`_.
 
-    2. It may be because you're running mod_python and mod_php in the same
+2. It may be because you're running mod_python and mod_php in the same
    Apache instance, with MySQL as your database backend. In some cases,
    this causes a known mod_python issue due to version conflicts in PHP and
    the Python MySQL backend. There's full information in the

docs/howto/deployment/modwsgi.txt

@@ -64,11 +64,11 @@ server you choose.
 We recommend using a separate Web server -- i.e., one that's not also running
 Django -- for serving media. Here are some good choices:
 
-    * lighttpd_
+* lighttpd_
-    * Nginx_
+* Nginx_
-    * TUX_
+* TUX_
-    * A stripped-down version of Apache_
+* A stripped-down version of Apache_
-    * Cherokee_
+* Cherokee_
 
 If, however, you have no option but to serve media files on the same Apache
 ``VirtualHost`` as Django, you can set up Apache to serve some URLs as
@@ -131,10 +131,10 @@ Django distribution.
 We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
 the admin files, but here are two other approaches:
 
-    1. Create a symbolic link to the admin static files from within your
+1. Create a symbolic link to the admin static files from within your
    document root.
 
-    2. Or, copy the admin static files so that they live within your Apache
+2. Or, copy the admin static files so that they live within your Apache
    document root.
 
 Details

docs/howto/error-reporting.txt

@@ -56,11 +56,11 @@ setting.
 Django can also be configured to email errors about broken links (404 "page
 not found" errors). Django sends emails about 404 errors when:
 
-    * :setting:`DEBUG` is ``False``
+* :setting:`DEBUG` is ``False``
 
-    * :setting:`SEND_BROKEN_LINK_EMAILS` is ``True``
+* :setting:`SEND_BROKEN_LINK_EMAILS` is ``True``
 
-    * Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware``
+* Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware``
   (which it does by default).
 
 If those conditions are met, Django will email the users listed in the
@@ -144,9 +144,7 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
     If a function (either a view or any regular callback) in your code uses
     local variables susceptible to contain sensitive information, you may
     prevent the values of those variables from being included in error reports
-    using the ``sensitive_variables`` decorator:
+    using the ``sensitive_variables`` decorator::
-
-        .. code-block:: python
 
         from django.views.decorators.debug import sensitive_variables
 
@@ -163,9 +161,7 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
     disclosed.
 
     To systematically hide all local variables of a function from error logs,
-    do not provide any argument to the ``sensitive_variables`` decorator:
+    do not provide any argument to the ``sensitive_variables`` decorator::
-
-        .. code-block:: python
 
         @sensitive_variables()
         def my_function():
@@ -177,9 +173,7 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
     :attr:`POST parameters<HttpRequest.POST>` susceptible to contain sensitive
     information, you may prevent the values of those parameters from being
     included in the error reports using the ``sensitive_post_parameters``
-    decorator:
+    decorator::
-
-        .. code-block:: python
 
         from django.views.decorators.debug import sensitive_post_parameters
 
@@ -197,9 +191,7 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
     reports, whereas the value of the ``name`` parameter will be disclosed.
 
     To systematically hide all POST parameters of a request in error reports,
-    do not provide any argument to the ``sensitive_post_parameters`` decorator:
+    do not provide any argument to the ``sensitive_post_parameters`` decorator::
-
-        .. code-block:: python
 
         @sensitive_post_parameters()
         def my_view(request):
@@ -231,17 +223,13 @@ decorators' annotations to replace the corresponding values with stars
 (`**********`) when the error reports are produced. If you wish to override or
 customize this default behavior for your entire site, you need to define your
 own filter class and tell Django to use it via the
-:setting:`DEFAULT_EXCEPTION_REPORTER_FILTER` setting:
+:setting:`DEFAULT_EXCEPTION_REPORTER_FILTER` setting::
-
-    .. code-block:: python
 
     DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'
 
 You may also control in a more granular way which filter to use within any
 given view by setting the ``HttpRequest``'s ``exception_reporter_filter``
-attribute:
+attribute::
-
-    .. code-block:: python
 
     def my_view(request):
         if request.user.is_authenticated():

docs/howto/i18n.txt

@@ -10,15 +10,15 @@ the order in which it examines the different file paths to load the compiled
 :term:`message files <message file>` (``.mo``) and the precedence of multiple
 translations for the same literal:
 
-    1. The directories listed in :setting:`LOCALE_PATHS` have the highest
+1. The directories listed in :setting:`LOCALE_PATHS` have the highest
    precedence, with the ones appearing first having higher precedence than
    the ones appearing later.
-    2. Then, it looks for and uses if it exists a ``locale`` directory in each
+2. Then, it looks for and uses if it exists a ``locale`` directory in each
    of the installed apps listed in :setting:`INSTALLED_APPS`.  The ones
    appearing first have higher precedence than the ones appearing later.
-    3. Then, it looks for a ``locale`` directory in the project directory, or
+3. Then, it looks for a ``locale`` directory in the project directory, or
    more accurately, in the directory containing your settings file.
-    4. Finally, the Django-provided base translation in ``django/conf/locale``
+4. Finally, the Django-provided base translation in ``django/conf/locale``
    is used as a fallback.
 
 .. deprecated:: 1.3
@@ -55,12 +55,12 @@ 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 :setting:`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)`` --
+* ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)`` --
   deprecated, see above.
-    * ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
+* ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
-    * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
+* ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
 
 To create message files, you use the :djadmin:`django-admin.py makemessages <makemessages>`
 tool. You only need to be in the same directory where the ``locale/`` directory

docs/howto/jython.txt

@@ -64,10 +64,10 @@ Differences with Django on Jython
 At this point, Django on Jython should behave nearly identically to Django
 running on standard Python. However, are a few differences to keep in mind:
 
-    * Remember to use the ``jython`` command instead of ``python``. The
+* Remember to use the ``jython`` command instead of ``python``. The
   documentation uses ``python`` for consistency, but if you're using Jython
   you'll want to mentally replace ``python`` with ``jython`` every time it
   occurs.
 
-    * Similarly, you'll need to use the ``JYTHONPATH`` environment variable
+* Similarly, you'll need to use the ``JYTHONPATH`` environment variable
   instead of ``PYTHONPATH``.

docs/howto/legacy-databases.txt

@@ -20,12 +20,12 @@ what the name of the database is. Do that by editing the :setting:`DATABASES`
 setting and assigning values to the following keys for the ``'default'``
 connection:
 
-    * :setting:`NAME`
+* :setting:`NAME`
-    * :setting:`ENGINE`
+* :setting:`ENGINE`
-    * :setting:`USER`
+* :setting:`USER`
-    * :setting:`PASSWORD`
+* :setting:`PASSWORD`
-    * :setting:`HOST`
+* :setting:`HOST`
-    * :setting:`PORT`
+* :setting:`PORT`
 
 Auto-generate the models
 ========================

docs/howto/outputting-csv.txt

@@ -32,25 +32,25 @@ Here's an example::
 The code and comments should be self-explanatory, but a few things deserve a
 mention:
 
-    * The response gets a special MIME type, :mimetype:`text/csv`. This tells
+* The response gets a special MIME type, :mimetype:`text/csv`. This tells
   browsers that the document is a CSV file, rather than an HTML file. If
   you leave this off, browsers will probably interpret the output as HTML,
   which will result in ugly, scary gobbledygook in the browser window.
 
-    * The response gets an additional ``Content-Disposition`` header, which
+* The response gets an additional ``Content-Disposition`` header, which
   contains the name of the CSV file. This filename is arbitrary; call it
   whatever you want. It'll be used by browsers in the "Save as..."
   dialogue, etc.
 
-    * Hooking into the CSV-generation API is easy: Just pass ``response`` as the
+* Hooking into the CSV-generation API is easy: Just pass ``response`` as the
   first argument to ``csv.writer``. The ``csv.writer`` function expects a
   file-like object, and :class:`~django.http.HttpResponse` objects fit the
   bill.
 
-    * For each row in your CSV file, call ``writer.writerow``, passing it an
+* For each row in your CSV file, call ``writer.writerow``, passing it an
   iterable object such as a list or tuple.
 
-    * The CSV module takes care of quoting for you, so you don't have to worry
+* The CSV module takes care of quoting for you, so you don't have to worry
   about escaping strings with quotes or commas in them. Just pass
   ``writerow()`` your raw strings, and it'll do the right thing.
 
@@ -62,12 +62,12 @@ Unicode internally this means strings read from sources such as
 :class:`~django.http.HttpRequest` are potentially problematic. There are a few
 options for handling this:
 
-    * Manually encode all Unicode objects to a compatible encoding.
+* Manually encode all Unicode objects to a compatible encoding.
 
-    * Use the ``UnicodeWriter`` class provided in the `csv module's examples
+* Use the ``UnicodeWriter`` class provided in the `csv module's examples
   section`_.
 
-    * Use the `python-unicodecsv module`_, which aims to be a drop-in
+* Use the `python-unicodecsv module`_, which aims to be a drop-in
   replacement for :mod:`csv` that gracefully handles Unicode.
 
 For more information, see the Python documentation of the :mod:`csv` module.

docs/howto/outputting-pdf.txt

@@ -63,18 +63,18 @@ Here's a "Hello World" example::
 The code and comments should be self-explanatory, but a few things deserve a
 mention:
 
-    * The response gets a special MIME type, :mimetype:`application/pdf`. This
+* The response gets a special MIME type, :mimetype:`application/pdf`. This
   tells browsers that the document is a PDF file, rather than an HTML file.
   If you leave this off, browsers will probably interpret the output as
   HTML, which would result in ugly, scary gobbledygook in the browser
   window.
 
-    * The response gets an additional ``Content-Disposition`` header, which
+* The response gets an additional ``Content-Disposition`` header, which
   contains the name of the PDF file. This filename is arbitrary: Call it
   whatever you want. It'll be used by browsers in the "Save as..."
   dialogue, etc.
 
-    * The ``Content-Disposition`` header starts with ``'attachment; '`` in this
+* The ``Content-Disposition`` header starts with ``'attachment; '`` in this
   example. This forces Web browsers to pop-up a dialog box
   prompting/confirming how to handle the document even if a default is set
   on the machine. If you leave off ``'attachment;'``, browsers will handle
@@ -83,15 +83,15 @@ mention:
 
       response['Content-Disposition'] = 'filename=somefilename.pdf'
 
-    * Hooking into the ReportLab API is easy: Just pass ``response`` as the
+* Hooking into the ReportLab API is easy: Just pass ``response`` as the
   first argument to ``canvas.Canvas``. The ``Canvas`` class expects a
   file-like object, and :class:`~django.http.HttpResponse` objects fit the
   bill.
 
-    * Note that all subsequent PDF-generation methods are called on the PDF
+* Note that all subsequent PDF-generation methods are called on the PDF
   object (in this case, ``p``) -- not on ``response``.
 
-    * Finally, it's important to call ``showPage()`` and ``save()`` on the PDF
+* Finally, it's important to call ``showPage()`` and ``save()`` on the PDF
   file.
 
 Complex PDFs
@@ -137,11 +137,11 @@ Here's the above "Hello World" example rewritten to use :mod:`cStringIO`::
 Further resources
 =================
 
-    * PDFlib_ is another PDF-generation library that has Python bindings. To
+* PDFlib_ is another PDF-generation library that has Python bindings. To
   use it with Django, just use the same concepts explained in this article.
-    * `Pisa XHTML2PDF`_ is yet another PDF-generation library. Pisa ships with
+* `Pisa XHTML2PDF`_ is yet another PDF-generation library. Pisa ships with
   an example of how to integrate Pisa with Django.
-    * HTMLdoc_ is a command-line script that can convert HTML to PDF. It
+* HTMLdoc_ is a command-line script that can convert HTML to PDF. It
   doesn't have a Python interface, but you can escape out to the shell
   using ``system`` or ``popen`` and retrieve the output in Python.
 

docs/howto/static-files.txt

@@ -345,10 +345,10 @@ Serving the app and your static files from the same server
 If you want to serve your static files from the same server that's already
 serving your site, the basic outline gets modified to look something like:
 
-    * Push your code up to the deployment server.
+* Push your code up to the deployment server.
-    * On the server, run :djadmin:`collectstatic` to copy all the static files
+* On the server, run :djadmin:`collectstatic` to copy all the static files
   into :setting:`STATIC_ROOT`.
-    * Point your web server at :setting:`STATIC_ROOT`. For example, here's
+* Point your web server at :setting:`STATIC_ROOT`. For example, here's
   :ref:`how to do this under Apache and mod_wsgi <serving-files>`.
 
 You'll probably want to automate this process, especially if you've got
@@ -386,11 +386,11 @@ Most larger Django apps use a separate Web server -- i.e., one that's not also
 running Django -- for serving static files. This server often runs a different
 type of web server -- faster but less full-featured. Some good choices are:
 
-    * lighttpd_
+* lighttpd_
-    * Nginx_
+* Nginx_
-    * TUX_
+* TUX_
-    * Cherokee_
+* Cherokee_
-    * A stripped-down version of Apache_
+* A stripped-down version of Apache_
 
 .. _lighttpd: http://www.lighttpd.net/
 .. _Nginx: http://wiki.nginx.org/Main
@@ -404,8 +404,8 @@ server's respective documentation for instructions.
 Since your static file server won't be running Django, you'll need to modify
 the deployment strategy to look something like:
 
-    * When your static files change, run :djadmin:`collectstatic` locally.
+* When your static files change, run :djadmin:`collectstatic` locally.
-    * Push your local :setting:`STATIC_ROOT` up to the static file server
+* Push your local :setting:`STATIC_ROOT` up to the static file server
   into the directory that's being served. ``rsync`` is a good
   choice for this step since it only needs to transfer the
   bits of static files that have changed.
@@ -479,25 +479,25 @@ Upgrading from ``django-staticfiles``
 you're upgrading from `django-staticfiles`_ older than 1.0 (e.g. 0.3.4) to
 ``django.contrib.staticfiles``, you'll need to make a few changes:
 
-    * Application files should now live in a ``static`` directory in each app
+* Application files should now live in a ``static`` directory in each app
   (`django-staticfiles`_ used the name ``media``, which was slightly
   confusing).
 
-    * The management commands ``build_static`` and ``resolve_static`` are now
+* The management commands ``build_static`` and ``resolve_static`` are now
   called :djadmin:`collectstatic` and :djadmin:`findstatic`.
 
-    * The settings ``STATICFILES_PREPEND_LABEL_APPS``,
+* The settings ``STATICFILES_PREPEND_LABEL_APPS``,
   ``STATICFILES_MEDIA_DIRNAMES`` and ``STATICFILES_EXCLUDED_APPS`` were
   removed.
 
-    * The setting ``STATICFILES_RESOLVERS`` was removed, and replaced by the
+* The setting ``STATICFILES_RESOLVERS`` was removed, and replaced by the
   new :setting:`STATICFILES_FINDERS`.
 
-    * The default for :setting:`STATICFILES_STORAGE` was renamed from
+* The default for :setting:`STATICFILES_STORAGE` was renamed from
   ``staticfiles.storage.StaticFileStorage`` to
   ``staticfiles.storage.StaticFilesStorage``
 
-    * If using :ref:`runserver<staticfiles-runserver>` for local development
+* If using :ref:`runserver<staticfiles-runserver>` for local development
   (and the :setting:`DEBUG` setting is ``True``), you no longer need to add
   anything to your URLconf for serving static files in development.
 

docs/index.txt

@@ -34,11 +34,11 @@ Having trouble? We'd like to help!
 First steps
 ===========
 
-    * **From scratch:**
+* **From scratch:**
   :doc:`Overview <intro/overview>` |
   :doc:`Installation <intro/install>`
 
-    * **Tutorial:**
+* **Tutorial:**
   :doc:`Part 1 <intro/tutorial01>` |
   :doc:`Part 2 <intro/tutorial02>` |
   :doc:`Part 3 <intro/tutorial03>` |
@@ -47,20 +47,20 @@ First steps
 The model layer
 ===============
 
-    * **Models:**
+* **Models:**
   :doc:`Model syntax <topics/db/models>` |
   :doc:`Field types <ref/models/fields>` |
   :doc:`Meta options <ref/models/options>`
 
-    * **QuerySets:**
+* **QuerySets:**
   :doc:`Executing queries <topics/db/queries>` |
   :doc:`QuerySet method reference <ref/models/querysets>`
 
-    * **Model instances:**
+* **Model instances:**
   :doc:`Instance methods <ref/models/instances>` |
   :doc:`Accessing related objects <ref/models/relations>`
 
-    * **Advanced:**
+* **Advanced:**
   :doc:`Managers <topics/db/managers>` |
   :doc:`Raw SQL <topics/db/sql>` |
   :doc:`Transactions <topics/db/transactions>` |
@@ -68,7 +68,7 @@ The model layer
   :doc:`Custom fields <howto/custom-model-fields>` |
   :doc:`Multiple databases <topics/db/multi-db>`
 
-    * **Other:**
+* **Other:**
   :doc:`Supported databases <ref/databases>` |
   :doc:`Legacy databases <howto/legacy-databases>` |
   :doc:`Providing initial data <howto/initial-data>` |
@@ -77,82 +77,82 @@ The model layer
 The template layer
 ==================
 
-    * **For designers:**
+* **For designers:**
   :doc:`Syntax overview <topics/templates>` |
   :doc:`Built-in tags and filters <ref/templates/builtins>`
 
-    * **For programmers:**
+* **For programmers:**
   :doc:`Template API <ref/templates/api>` |
   :doc:`Custom tags and filters <howto/custom-template-tags>`
 
 The view layer
 ==============
 
-    * **The basics:**
+* **The basics:**
   :doc:`URLconfs <topics/http/urls>` |
   :doc:`View functions <topics/http/views>` |
   :doc:`Shortcuts <topics/http/shortcuts>` |
   :doc:`Decorators <topics/http/decorators>`
 
-    * **Reference:**
+* **Reference:**
   :doc:`Request/response objects <ref/request-response>` |
   :doc:`TemplateResponse objects <ref/template-response>`
 
-    * **File uploads:**
+* **File uploads:**
   :doc:`Overview <topics/http/file-uploads>` |
   :doc:`File objects <ref/files/file>` |
   :doc:`Storage API <ref/files/storage>` |
   :doc:`Managing files <topics/files>` |
   :doc:`Custom storage <howto/custom-file-storage>`
 
-    * **Generic views:**
+* **Generic views:**
   :doc:`Overview<topics/class-based-views>` |
   :doc:`Built-in generic views<ref/class-based-views>`
 
-    * **Advanced:**
+* **Advanced:**
   :doc:`Generating CSV <howto/outputting-csv>` |
   :doc:`Generating PDF <howto/outputting-pdf>`
 
-    * **Middleware:**
+* **Middleware:**
   :doc:`Overview <topics/http/middleware>` |
   :doc:`Built-in middleware classes <ref/middleware>`
 
 Forms
 =====
 
-    * **The basics:**
+* **The basics:**
   :doc:`Overview <topics/forms/index>` |
   :doc:`Form API <ref/forms/api>` |
   :doc:`Built-in fields <ref/forms/fields>` |
   :doc:`Built-in widgets <ref/forms/widgets>`
 
-    * **Advanced:**
+* **Advanced:**
   :doc:`Forms for models <topics/forms/modelforms>` |
   :doc:`Integrating media <topics/forms/media>` |
   :doc:`Formsets <topics/forms/formsets>` |
   :doc:`Customizing validation <ref/forms/validation>`
 
-    * **Extras:**
+* **Extras:**
   :doc:`Form preview <ref/contrib/formtools/form-preview>` |
   :doc:`Form wizard <ref/contrib/formtools/form-wizard>`
 
 The development process
 =======================
 
-    * **Settings:**
+* **Settings:**
   :doc:`Overview <topics/settings>` |
   :doc:`Full list of settings <ref/settings>`
 
-    * **Exceptions:**
+* **Exceptions:**
   :doc:`Overview <ref/exceptions>`
 
-    * **django-admin.py and manage.py:**
+* **django-admin.py and manage.py:**
   :doc:`Overview <ref/django-admin>` |
   :doc:`Adding custom commands <howto/custom-management-commands>`
 
-    * **Testing:**  :doc:`Overview <topics/testing>`
+* **Testing:**  :doc:`Overview <topics/testing>`
 
-    * **Deployment:**
+* **Deployment:**
   :doc:`Overview <howto/deployment/index>` |
   :doc:`Apache/mod_wsgi <howto/deployment/modwsgi>` |
   :doc:`uWSGI <howto/deployment/uwsgi>` |
@@ -165,59 +165,59 @@ The development process
 Other batteries included
 ========================
 
-    * :doc:`Admin site <ref/contrib/admin/index>` | :doc:`Admin actions <ref/contrib/admin/actions>` | :doc:`Admin documentation generator<ref/contrib/admin/admindocs>`
+* :doc:`Admin site <ref/contrib/admin/index>` | :doc:`Admin actions <ref/contrib/admin/actions>` | :doc:`Admin documentation generator<ref/contrib/admin/admindocs>`
-    * :doc:`Authentication <topics/auth>`
+* :doc:`Authentication <topics/auth>`
-    * :doc:`Cache system <topics/cache>`
+* :doc:`Cache system <topics/cache>`
-    * :doc:`Clickjacking protection <ref/clickjacking>`
+* :doc:`Clickjacking protection <ref/clickjacking>`
-    * :doc:`Comments <ref/contrib/comments/index>` | :doc:`Moderation <ref/contrib/comments/moderation>` | :doc:`Custom comments <ref/contrib/comments/custom>`
+* :doc:`Comments <ref/contrib/comments/index>` | :doc:`Moderation <ref/contrib/comments/moderation>` | :doc:`Custom comments <ref/contrib/comments/custom>`
-    * :doc:`Conditional content processing <topics/conditional-view-processing>`
+* :doc:`Conditional content processing <topics/conditional-view-processing>`
-    * :doc:`Content types <ref/contrib/contenttypes>`
+* :doc:`Content types <ref/contrib/contenttypes>`
-    * :doc:`Cross Site Request Forgery protection <ref/contrib/csrf>`
+* :doc:`Cross Site Request Forgery protection <ref/contrib/csrf>`
-    * :doc:`Cryptographic signing <topics/signing>`
+* :doc:`Cryptographic signing <topics/signing>`
-    * :doc:`Databrowse <ref/contrib/databrowse>`
+* :doc:`Databrowse <ref/contrib/databrowse>`
-    * :doc:`E-mail (sending) <topics/email>`
+* :doc:`E-mail (sending) <topics/email>`
-    * :doc:`Flatpages <ref/contrib/flatpages>`
+* :doc:`Flatpages <ref/contrib/flatpages>`
-    * :doc:`GeoDjango <ref/contrib/gis/index>`
+* :doc:`GeoDjango <ref/contrib/gis/index>`
-    * :doc:`Humanize <ref/contrib/humanize>`
+* :doc:`Humanize <ref/contrib/humanize>`
-    * :doc:`Internationalization <topics/i18n/index>`
+* :doc:`Internationalization <topics/i18n/index>`
-    * :doc:`Jython support <howto/jython>`
+* :doc:`Jython support <howto/jython>`
-    * :doc:`"Local flavor" <ref/contrib/localflavor>`
+* :doc:`"Local flavor" <ref/contrib/localflavor>`
-    * :doc:`Logging <topics/logging>`
+* :doc:`Logging <topics/logging>`
-    * :doc:`Messages <ref/contrib/messages>`
+* :doc:`Messages <ref/contrib/messages>`
-    * :doc:`Pagination <topics/pagination>`
+* :doc:`Pagination <topics/pagination>`
-    * :doc:`Redirects <ref/contrib/redirects>`
+* :doc:`Redirects <ref/contrib/redirects>`
-    * :doc:`Security <topics/security>`
+* :doc:`Security <topics/security>`
-    * :doc:`Serialization <topics/serialization>`
+* :doc:`Serialization <topics/serialization>`
-    * :doc:`Sessions <topics/http/sessions>`
+* :doc:`Sessions <topics/http/sessions>`
-    * :doc:`Signals <topics/signals>`
+* :doc:`Signals <topics/signals>`
-    * :doc:`Sitemaps <ref/contrib/sitemaps>`
+* :doc:`Sitemaps <ref/contrib/sitemaps>`
-    * :doc:`Sites <ref/contrib/sites>`
+* :doc:`Sites <ref/contrib/sites>`
-    * :doc:`Static Files <ref/contrib/staticfiles>`
+* :doc:`Static Files <ref/contrib/staticfiles>`
-    * :doc:`Syndication feeds (RSS/Atom) <ref/contrib/syndication>`
+* :doc:`Syndication feeds (RSS/Atom) <ref/contrib/syndication>`
-    * :doc:`Unicode in Django <ref/unicode>`
+* :doc:`Unicode in Django <ref/unicode>`
-    * :doc:`Web design helpers <ref/contrib/webdesign>`
+* :doc:`Web design helpers <ref/contrib/webdesign>`
-    * :doc:`Validators <ref/validators>`
+* :doc:`Validators <ref/validators>`
-    * Function-based generic views (Deprecated) :doc:`Overview<topics/generic-views>` | :doc:`Built-in generic views<ref/generic-views>` | :doc:`Migration guide<topics/generic-views-migration>`
+* Function-based generic views (Deprecated) :doc:`Overview<topics/generic-views>` | :doc:`Built-in generic views<ref/generic-views>` | :doc:`Migration guide<topics/generic-views-migration>`
 
 The Django open-source project
 ==============================
 
-    * **Community:**
+* **Community:**
   :doc:`How to get involved <internals/contributing/index>` |
   :doc:`The release process <internals/release-process>` |
   :doc:`Team of committers <internals/committers>` |
   :doc:`The Django source code repository <internals/svn>`
 
-    * **Design philosophies:**
+* **Design philosophies:**
   :doc:`Overview <misc/design-philosophies>`
 
-    * **Documentation:**
+* **Documentation:**
   :doc:`About this documentation <internals/contributing/writing-documentation>`
 
-    * **Third-party distributions:**
+* **Third-party distributions:**
   :doc:`Overview <misc/distributions>`
 
-    * **Django over time:**
+* **Django over time:**
   :doc:`API stability <misc/api-stability>` |
   :doc:`Release notes and upgrading instructions <releases/index>` |
   :doc:`Deprecation Timeline <internals/deprecation>`

docs/internals/contributing/bugs-and-features.txt

@@ -30,20 +30,20 @@ amount of overhead involved in working with any bug tracking system so your
 help in keeping our ticket tracker as useful as possible is appreciated. In
 particular:
 
-    * **Do** read the :doc:`FAQ </faq/index>` to see if your issue might
+* **Do** read the :doc:`FAQ </faq/index>` to see if your issue might
   be a well-known question.
 
-    * **Do** ask on `django-users`_ or `#django`_ *first* if you're not sure if
+* **Do** ask on `django-users`_ or `#django`_ *first* if you're not sure if
   what you're seeing is a bug.
 
-    * **Do** write complete, reproducible, specific bug reports. You must
+* **Do** write complete, reproducible, specific bug reports. You must
   include a clear, concise description of the problem, and a set of
   instructions for replicating it. Add as much debug information as you can:
   code snippets, test cases, exception backtraces, screenshots, etc. A nice
   small test case is the best way to report a bug, as it gives us an easy
   way to confirm the bug quickly.
 
-    * **Don't** post to `django-developers`_ just to announce that you have
+* **Don't** post to `django-developers`_ just to announce that you have
   filed a bug report. All the tickets are mailed to another list,
   `django-updates`_, which is tracked by developers and interested
   community members; we see them as they are filed.
@@ -67,25 +67,25 @@ Reporting security issues
 In the event of a confirmed vulnerability in Django itself, we will take the
 following actions:
 
-    * Acknowledge to the reporter that we've received the report and that a
+* Acknowledge to the reporter that we've received the report and that a
   fix is forthcoming. We'll give a rough timeline and ask the reporter
   to keep the issue confidential until we announce it.
 
-    * Focus on developing a fix as quickly as possible and produce patches
+* Focus on developing a fix as quickly as possible and produce patches
   against the current and two previous releases.
 
-    * Determine a go-public date for announcing the vulnerability and the fix.
+* Determine a go-public date for announcing the vulnerability and the fix.
   To try to mitigate a possible "arms race" between those applying the
   patch and those trying to exploit the hole, we will not announce
   security problems immediately.
 
-    * Pre-notify third-party distributors of Django ("vendors"). We will send
+* Pre-notify third-party distributors of Django ("vendors"). We will send
   these vendor notifications through private email which will include
   documentation of the vulnerability, links to the relevant patch(es), and
   a request to keep the vulnerability confidential until the official
   go-public date.
 
-    * Publicly announce the vulnerability and the fix on the pre-determined
+* Publicly announce the vulnerability and the fix on the pre-determined
   go-public date. This will probably mean a new release of Django, but
   in some cases it may simply be patches against current releases.
 
@@ -95,24 +95,24 @@ Reporting user interface bugs and features
 If your bug or feature request touches on anything visual in nature, there
 are a few additional guidelines to follow:
 
-    * Include screenshots in your ticket which are the visual equivalent of a
+* Include screenshots in your ticket which are the visual equivalent of a
   minimal testcase. Show off the issue, not the crazy customizations
   you've made to your browser.
 
-    * If the issue is difficult to show off using a still image, consider
+* If the issue is difficult to show off using a still image, consider
   capturing a *brief* screencast. If your software permits it, capture only
   the relevant area of the screen.
 
-    * If you're offering a patch which changes the look or behavior of Django's
+* If you're offering a patch which changes the look or behavior of Django's
   UI, you **must** attach before *and* after screenshots/screencasts.
   Tickets lacking these are difficult for triagers and core developers to
   assess quickly.
 
-    * Screenshots don't absolve you of other good reporting practices. Make sure
+* Screenshots don't absolve you of other good reporting practices. Make sure
   to include URLs, code snippets, and step-by-step instructions on how to
   reproduce the behavior visible in the screenshots.
 
-    * Make sure to set the UI/UX flag on the ticket so interested parties can
+* Make sure to set the UI/UX flag on the ticket so interested parties can
   find your ticket.
 
 Requesting features
@@ -121,24 +121,24 @@ Requesting features
 We're always trying to make Django better, and your feature requests are a key
 part of that. Here are some tips on how to make a request most effectively:
 
-    * Make sure the feature actually requires changes in Django's core. If your
+* Make sure the feature actually requires changes in Django's core. If your
   idea can be developed as an independent application or module — for
   instance, you want to support another database engine — we'll probably
   suggest that you to develop it independently. Then, if your project
   gathers sufficient community support, we may consider it for inclusion in
   Django.
 
-    * First request the feature on the `django-developers`_ list, not in the
+* First request the feature on the `django-developers`_ list, not in the
   ticket tracker. It'll get read more closely if it's on the mailing list.
   This is even more important for large-scale feature requests. We like to
   discuss any big changes to Django's core on the mailing list before
   actually working on them.
 
-    * Describe clearly and concisely what the missing feature is and how you'd
+* Describe clearly and concisely what the missing feature is and how you'd
   like to see it implemented. Include example code (non-functional is OK)
   if possible.
 
-    * Explain *why* you'd like the feature. In some cases this is obvious, but
+* Explain *why* you'd like the feature. In some cases this is obvious, but
   since Django is designed to help real developers get real work done,
   you'll need to explain it, if it isn't obvious why the feature would be
   useful.
@@ -165,13 +165,13 @@ have informal votes on `django-developers`_ about a feature. In these votes we
 follow the voting style invented by Apache and used on Python itself, where
 votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:
 
-    * +1: "I love the idea and I'm strongly committed to it."
+* +1: "I love the idea and I'm strongly committed to it."
 
-    * +0: "Sounds OK to me."
+* +0: "Sounds OK to me."
 
-    * -0: "I'm not thrilled, but I won't stand in the way."
+* -0: "I'm not thrilled, but I won't stand in the way."
 
-    * -1: "I strongly disagree and would be very unhappy to see the idea turn
+* -1: "I strongly disagree and would be very unhappy to see the idea turn
   into reality."
 
 Although these votes on `django-developers`_ are informal, they'll be taken very
@@ -186,11 +186,11 @@ Any :doc:`core committer</internals/committers>` may call for a formal vote
 using the same voting mechanism above. A proposition will be considered carried
 by the core team if:
 
-    * There are three "+1" votes from members of the core team.
+* There are three "+1" votes from members of the core team.
 
-    * There is no "-1" vote from any member of the core team.
+* There is no "-1" vote from any member of the core team.
 
-    * The :ref:`BDFLs<django-bdfls>` haven't stepped in and executed their
+* The :ref:`BDFLs<django-bdfls>` haven't stepped in and executed their
   positive or negative veto.
 
 When calling for a vote, the caller should specify a deadline by which

docs/internals/contributing/committing-code.txt

@@ -38,7 +38,7 @@ Committing guidelines
 Please follow these guidelines when committing code to Django's Subversion
 repository:
 
-    * For any medium-to-big changes, where "medium-to-big" is according to
+* For any medium-to-big changes, where "medium-to-big" is according to
   your judgment, please bring things up on the `django-developers`_
   mailing list before making the change.
 
@@ -49,28 +49,28 @@ repository:
   immediately, so you may have to wait a couple of days before getting a
   response.
 
-    * Write detailed commit messages in the past tense, not present tense.
+* Write detailed commit messages in the past tense, not present tense.
 
   * Good: "Fixed Unicode bug in RSS API."
   * Bad: "Fixes Unicode bug in RSS API."
   * Bad: "Fixing Unicode bug in RSS API."
 
-    * For commits to a branch, prefix the commit message with the branch name.
+* For commits to a branch, prefix the commit message with the branch name.
   For example: "magic-removal: Added support for mind reading."
 
-    * Limit commits to the most granular change that makes sense. This means,
+* Limit commits to the most granular change that makes sense. This means,
   use frequent small commits rather than infrequent large commits. For
   example, if implementing feature X requires a small change to library Y,
   first commit the change to library Y, then commit feature X in a
   separate commit. This goes a *long way* in helping all core Django
   developers follow your changes.
 
-    * Separate bug fixes from feature changes.
+* Separate bug fixes from feature changes.
 
   Bug fixes need to be added to the current bugfix branch as well as the
   current trunk.
 
-    * If your commit closes a ticket in the Django `ticket tracker`_, begin
+* If your commit closes a ticket in the Django `ticket tracker`_, begin
   your commit message with the text "Fixed #abc", where "abc" is the
   number of the ticket your commit fixes. Example: "Fixed #123 -- Added
   support for foo". We've rigged Subversion and Trac so that any commit
@@ -85,7 +85,7 @@ repository:
 
   .. _Trac post-commit hook: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
 
-    * If your commit references a ticket in the Django `ticket tracker`_ but
+* If your commit references a ticket in the Django `ticket tracker`_ but
   does *not* close the ticket, include the phrase "Refs #abc", where "abc"
   is the number of the ticket your commit references. We've rigged
   Subversion and Trac so that any commit message in that format will
@@ -97,34 +97,34 @@ Reverting commits
 Nobody's perfect; mistakes will be committed. When a mistaken commit is
 discovered, please follow these guidelines:
 
-    * Try very hard to ensure that mistakes don't happen. Just because we
+* Try very hard to ensure that mistakes don't happen. Just because we
   have a reversion policy doesn't relax your responsibility to aim for
   the highest quality possible. Really: double-check your work before
   you commit it in the first place!
 
-    * If possible, have the original author revert his/her own commit.
+* If possible, have the original author revert his/her own commit.
 
-    * Don't revert another author's changes without permission from the
+* Don't revert another author's changes without permission from the
   original author.
 
-    * If the original author can't be reached (within a reasonable amount
+* If the original author can't be reached (within a reasonable amount
   of time -- a day or so) and the problem is severe -- crashing bug,
   major test failures, etc -- then ask for objections on the
   `django-developers`_ mailing list then revert if there are none.
 
-    * If the problem is small (a feature commit after feature freeze,
+* If the problem is small (a feature commit after feature freeze,
   say), wait it out.
 
-    * If there's a disagreement between the committer and the
+* If there's a disagreement between the committer and the
   reverter-to-be then try to work it out on the `django-developers`_
   mailing list. If an agreement can't be reached then it should
   be put to a vote.
 
-    * If the commit introduced a confirmed, disclosed security
+* If the commit introduced a confirmed, disclosed security
   vulnerability then the commit may be reverted immediately without
   permission from anyone.
 
-    * The release branch maintainer may back out commits to the release
+* The release branch maintainer may back out commits to the release
   branch without permission if the commit breaks the release branch.
 
 .. _django-developers: http://groups.google.com/group/django-developers

docs/internals/contributing/index.txt

@@ -6,20 +6,20 @@ Django is a community that lives on its volunteers. As it keeps growing, we
 always need more people to help others. As soon as you learn Django, you can
 contribute in many ways:
 
-    * Join the `django-users`_ mailing list and answer questions. This
+* Join the `django-users`_ mailing list and answer questions. This
   mailing list has a huge audience, and we really want to maintain a
   friendly and helpful atmosphere. If you're new to the Django community,
   you should read the `posting guidelines`_.
 
-    * Join the `#django IRC channel`_ on Freenode and answer questions. By
+* Join the `#django IRC channel`_ on Freenode and answer questions. By
   explaining Django to other users, you're going to learn a lot about the
   framework yourself.
 
-    * Blog about Django. We syndicate all the Django blogs we know about on
+* Blog about Django. We syndicate all the Django blogs we know about on
   the `community page`_; if you'd like to see your blog on that page you
   can `register it here`_.
 
-    * Contribute to open-source Django projects, write some documentation, or
+* Contribute to open-source Django projects, write some documentation, or
   release your own code as an open-source pluggable application. The
   ecosystem of pluggable applications is a big strength of Django, help us
   build it!
@@ -29,19 +29,19 @@ it. We're passionate about helping Django users make the jump to contributing
 members of the community, so there are several ways you can help Django's
 development:
 
-    * :doc:`Report bugs <bugs-and-features>` in our `ticket tracker`_.
+* :doc:`Report bugs <bugs-and-features>` in our `ticket tracker`_.
 
-    * Join the `django-developers`_ mailing list and share your ideas for how
+* Join the `django-developers`_ mailing list and share your ideas for how
   to improve Django. We're always open to suggestions.
 
-    * :doc:`Submit patches <writing-code/submitting-patches>` for new and/or
+* :doc:`Submit patches <writing-code/submitting-patches>` for new and/or
   fixed behavior. If you're looking for an easy way to start contributing
   to Django have a look at the `easy pickings`_ tickets.
 
-    * :doc:`Improve the documentation <writing-documentation>` or
+* :doc:`Improve the documentation <writing-documentation>` or
   :doc:`write unit tests <writing-code/unit-tests>`.
 
-    * :doc:`Triage tickets and review patches <triaging-tickets>` created by
+* :doc:`Triage tickets and review patches <triaging-tickets>` created by
   other users.
 
 Really, **ANYONE** can do something to help make Django better and greater!

docs/internals/contributing/translations.txt

@@ -19,24 +19,24 @@ go to the `translation team`_ page for that language. If you would like to help
 out with translating or add a language that isn't yet translated, here's what to
 do:
 
-    * Join the `Django i18n mailing list`_ and introduce yourself.
+* Join the `Django i18n mailing list`_ and introduce yourself.
 
-    * Make sure you read the notes about :ref:`specialties-of-django-i18n`.
+* Make sure you read the notes about :ref:`specialties-of-django-i18n`.
 
-    * Signup at `Transifex`_ and visit the `Django project page`_.
+* Signup at `Transifex`_ and visit the `Django project page`_.
 
-    * On the `translation teams`_ page, choose the language team you want
+* On the `translation teams`_ page, choose the language team you want
   to work with, **or** -- in case the language team doesn't exist yet --
   request a new team by clicking on the "Request a new team" button
   and select the appropriate language.
 
-    * Then, click the "Join this Team" button to become a member of this team.
+* Then, click the "Join this Team" button to become a member of this team.
   Every team has at least one coordinator who is responsible to review
   your membership request. You can of course also contact the team
   coordinator to clarify procedural problems and handle the actual
   translation process.
 
-    * Once you are a member of a team choose the translation resource you
+* Once you are a member of a team choose the translation resource you
   want to update on the team page. For example the "core" resource refers
   to the translation catalogue that contains all non-contrib translations.
   Each of the contrib apps also have a resource (prefixed with "contrib").
@@ -55,9 +55,9 @@ the date, time and numbers formatting particularities of your locale. See
 The format files aren't managed by the use of Transifex. To change them, you
 must :doc:`create a patch<writing-code/submitting-patches>` against the Django source tree, as for any code change:
 
-    * Create a diff against the current Subversion trunk.
+* Create a diff against the current Subversion trunk.
 
-    * Open a ticket in Django's ticket system, set its ``Component`` field to
+* Open a ticket in Django's ticket system, set its ``Component`` field to
   ``Translations``, and attach the patch to it.
 
 .. _Transifex: http://www.transifex.net/

docs/internals/contributing/triaging-tickets.txt

@@ -57,12 +57,12 @@ Since a picture is worth a thousand words, let's start there:
 
 We've got two roles in this diagram:
 
-    * :doc:`Committers</internals/committers>` (also called core developers):
+* :doc:`Committers</internals/committers>` (also called core developers):
   people with commit access who are responsible for making the big
   decisions, writing large portions of the code and integrating the
   contributions of the community.
 
-    * Ticket triagers: anyone in the Django community who chooses to
+* Ticket triagers: anyone in the Django community who chooses to
   become involved in Django's development process. Our Trac installation
   is intentionally left open to the public, and anyone can triage tickets.
   Django is a community project, and we encourage :ref:`triage by the
@@ -185,34 +185,38 @@ Other triage attributes
 
 A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
 
-  * Has patch
+* Has patch
     This means the ticket has an associated
     :doc:`patch<writing-code/submitting-patches>`. These will be reviewed
     to see if the patch is "good".
-  * Needs documentation:
+
+* Needs documentation:
     This flag is used for tickets with patches that need associated
     documentation. Complete documentation of features is a prerequisite
     before we can check them into the codebase.
-  * Needs tests
+
+* Needs tests
     This flags the patch as needing associated unit tests. Again, this
     is a required part of a valid patch.
-  * Patch needs improvement
+
+* Patch needs improvement
     This flag means that although the ticket *has* a patch, it's not quite
     ready for checkin. This could mean the patch no longer applies
     cleanly, there is a flaw in the implementation, or that the code
     doesn't meet our standards.
-  * Easy pickings
+
+* Easy pickings
     Tickets that would require small, easy, patches.
 
 Tickets should be categorized by *type* between:
 
-  * New Feature
+* New Feature
     For adding something new.
 
-  * Bug
+* Bug
     For when an existing thing is broken or not behaving as expected.
 
-  * Cleanup/optimization
+* Cleanup/optimization
     For when nothing is broken but something could be made cleaner,
     better, faster, stronger.
 
@@ -243,18 +247,18 @@ leave a comment with your thoughts instead.
 
 If you do close a ticket, you should always make sure of the following:
 
-  * Be certain that the issue is resolved.
+* Be certain that the issue is resolved.
 
-  * Leave a comment explaining the decision to close the ticket.
+* Leave a comment explaining the decision to close the ticket.
 
-  * If there is a way they can improve the ticket to reopen it, let them know.
+* If there is a way they can improve the ticket to reopen it, let them know.
 
-  * If the ticket is a duplicate, reference the original ticket. Also
+* If the ticket is a duplicate, reference the original ticket. Also
   cross-reference the closed ticket by leaving a comment in the original one
   -- this allows to access more related information about the reported bug
   or requested feature.
 
-  * **Be polite.** No one likes having their ticket closed. It can be
+* **Be polite.** No one likes having their ticket closed. It can be
   frustrating or even discouraging. The best way to avoid turning people
   off from contributing to Django is to be polite and friendly and to offer
   suggestions for how they could improve this ticket and other tickets in
@@ -262,18 +266,18 @@ If you do close a ticket, you should always make sure of the following:
 
 A ticket can be resolved in a number of ways:
 
-  * fixed
+* fixed
       Used by the core developers once a patch has been rolled into
       Django and the issue is fixed.
 
-  * invalid
+* invalid
       Used if the ticket is found to be incorrect. This means that the
       issue in the ticket is actually the result of a user error, or
       describes a problem with something other than Django, or isn't
       a bug report or feature request at all (for example, some new users
       submit support queries as tickets).
 
-  * wontfix
+* wontfix
       Used when a core developer decides that this request is not
       appropriate for consideration in Django. This is usually chosen after
       discussion in the `django-developers`_ mailing list. Feel free to
@@ -281,16 +285,16 @@ A ticket can be resolved in a number of ways:
       django-developers_ mailing list, but please do not reopen tickets
       closed as "wontfix" by a :doc:`core developer</internals/committers>`.
 
-  * duplicate
+* duplicate
       Used when another ticket covers the same issue. By closing duplicate
       tickets, we keep all the discussion in one place, which helps
       everyone.
 
-  * worksforme
+* worksforme
       Used when the ticket doesn't contain enough detail to replicate
       the original bug.
 
-  * needsinfo
+* needsinfo
       Used when the ticket does not contain enough information to replicate
       the reported issue but is potentially still valid. The ticket
       should be reopened when more information is supplied.
@@ -315,35 +319,35 @@ forgotten your password, you can reset it using the `password reset page`_.
 
 Then, you can help out by:
 
-    * Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate."
+* Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate."
 
-    * Promoting "Unreviewed" tickets to "Design decision needed" if a design
+* Promoting "Unreviewed" tickets to "Design decision needed" if a design
   decision needs to be made, or "Accepted" in case of obvious bugs or
   sensible, clearly defined, feature requests.
 
-    * Correcting the "Needs tests", "Needs documentation", or "Has patch"
+* Correcting the "Needs tests", "Needs documentation", or "Has patch"
   flags for tickets where they are incorrectly set.
 
-    * Setting the "`Easy pickings`_" flag for tickets that are small and
+* Setting the "`Easy pickings`_" flag for tickets that are small and
   relatively straightforward.
 
-    * Checking that old tickets are still valid. If a ticket hasn't seen
+* Checking that old tickets are still valid. If a ticket hasn't seen
   any activity in a long time, it's possible that the problem has been
   fixed but the ticket hasn't yet been closed.
 
-    * Contacting the owners of tickets that have been claimed but have not
+* Contacting the owners of tickets that have been claimed but have not
   seen any recent activity. If the owner doesn't respond after a week
   or so, remove the owner's claim on the ticket.
 
-    * Identifying trends and themes in the tickets. If there a lot of bug
+* Identifying trends and themes in the tickets. If there a lot of bug
   reports about a particular part of Django, it may indicate we should
   consider refactoring that part of the code. If a trend is emerging,
   you should raise it for discussion (referencing the relevant tickets)
   on `django-developers`_.
 
-    * Set the *type* of tickets that are still uncategorized.
+* Set the *type* of tickets that are still uncategorized.
 
-    * Verify if patches submitted by other users are correct. If they do and
+* Verify if patches submitted by other users are correct. If they do and
   also contain appropriate documentation and tests then move them to the
   "Ready for Checkin" stage. If they don't then leave a comment to explain
   why and set the corresponding flags ("Patch needs improvement",
@@ -362,20 +366,20 @@ Then, you can help out by:
 However, we do ask the following of all general community members working in
 the ticket database:
 
-    * Please **don't** close tickets as "wontfix." The core developers will
+* Please **don't** close tickets as "wontfix." The core developers will
   make the final determination of the fate of a ticket, usually after
   consultation with the community.
 
-    * Please **don't** promote your own tickets to "Ready for checkin". You
+* Please **don't** promote your own tickets to "Ready for checkin". You
   may mark other people's tickets which you've reviewed as "Ready for
   checkin", but you should get at minimum one other community member to
   review a patch that you submit.
 
-    * Please **don't** reverse a decision that has been made by a :doc:`core
+* Please **don't** reverse a decision that has been made by a :doc:`core
   developer</internals/committers>`. If you disagree with a decision that
   has been made, please post a message to `django-developers`_.
 
-    * If you're unsure if you should be making a change, don't make the
+* If you're unsure if you should be making a change, don't make the
   change but instead leave a comment with your concerns on the ticket,
   or post a message to `django-developers`_. It's okay to be unsure,
   but your input is still valuable.

docs/internals/contributing/writing-code/branch-policy.txt

@@ -14,7 +14,7 @@ take more than a single patch, or requires large-scale refactoring -- you need
 to do it on a feature branch. Our development process recognizes two options
 for feature branches:
 
-    1. Feature branches using a distributed revision control system like
+1. Feature branches using a distributed revision control system like
    Git_, Mercurial_, Bazaar_, etc.
 
    If you're familiar with one of these tools, this is probably your best
@@ -31,7 +31,7 @@ for feature branches:
    make it public, please add the branch to the `Django branches`_ wiki
    page.
 
-    2. Feature branches using SVN have a higher bar. If you want a branch
+2. Feature branches using SVN have a higher bar. If you want a branch
    in SVN itself, you'll need a "mentor" among the :doc:`core committers
    </internals/committers>`. This person is responsible for actually
    creating the branch, monitoring your process (see below), and
@@ -60,11 +60,11 @@ Developers with branches in SVN, however, **must** follow these rules. The
 branch mentor will keep on eye on the branch and **will delete it** if these
 rules are broken.
 
-    * Only branch entire copies of the Django tree, even if work is only
+* Only branch entire copies of the Django tree, even if work is only
   happening on part of that tree. This makes it painless to switch to a
   branch.
 
-    * Merge changes from trunk no less than once a week, and preferably every
+* Merge changes from trunk no less than once a week, and preferably every
   couple-three days.
 
   In our experience, doing regular trunk merges is often the difference
@@ -73,7 +73,7 @@ rules are broken.
   If you're working on an SVN branch, you should be using `svnmerge.py`_
   to track merges from trunk.
 
-    * Keep tests passing and documentation up-to-date. As with patches,
+* Keep tests passing and documentation up-to-date. As with patches,
   we'll only merge a branch that comes with tests and documentation.
 
 .. _svnmerge.py: http://www.orcaware.com/svn/wiki/Svnmerge.py
@@ -91,9 +91,9 @@ Using branches
 
 To use a branch, you'll need to do two things:
 
-    * Get the branch's code through Subversion.
+* Get the branch's code through Subversion.
 
-    * Point your Python ``site-packages`` directory at the branch's version of
+* Point your Python ``site-packages`` directory at the branch's version of
   the ``django`` package rather than the version you already have
   installed.
 

docs/internals/contributing/writing-code/coding-style.txt

@@ -7,21 +7,21 @@ Please follow these coding standards when writing code for inclusion in Django.
 Python style
 ------------
 
-    * Unless otherwise specified, follow :pep:`8`.
+* Unless otherwise specified, follow :pep:`8`.
 
   You could use a tool like `pep8`_ to check for some problems in this
   area, but remember that :pep:`8` is only a guide, so respect the style of
   the surrounding code as a primary goal.
 
-    * Use four spaces for indentation.
+* Use four spaces for indentation.
 
-    * Use underscores, not camelCase, for variable, function and method names
+* Use underscores, not camelCase, for variable, function and method names
   (i.e. ``poll.get_unique_voters()``, not ``poll.getUniqueVoters``).
 
-    * Use ``InitialCaps`` for class names (or for factory functions that
+* Use ``InitialCaps`` for class names (or for factory functions that
   return classes).
 
-    * In docstrings, use "action words" such as::
+* In docstrings, use "action words" such as::
 
       def foo():
           """
@@ -40,7 +40,7 @@ Python style
 Template style
 --------------
 
-    * In Django template code, put one (and only one) space between the curly
+* In Django template code, put one (and only one) space between the curly
   brackets and the tag contents.
 
   Do this:
@@ -58,7 +58,7 @@ Template style
 View style
 ----------
 
-    * In Django views, the first parameter in a view function should be called
+* In Django views, the first parameter in a view function should be called
   ``request``.
 
   Do this::
@@ -74,7 +74,7 @@ View style
 Model style
 -----------
 
-    * Field names should be all lowercase, using underscores instead of
+* Field names should be all lowercase, using underscores instead of
   camelCase.
 
   Do this::
@@ -89,7 +89,7 @@ Model style
           FirstName = models.CharField(max_length=20)
           Last_Name = models.CharField(max_length=40)
 
-    * The ``class Meta`` should appear *after* the fields are defined, with
+* The ``class Meta`` should appear *after* the fields are defined, with
   a single blank line separating the fields and the class definition.
 
   Do this::
@@ -118,7 +118,7 @@ Model style
           first_name = models.CharField(max_length=20)
           last_name = models.CharField(max_length=40)
 
-    * The order of model inner classes and standard methods should be as
+* The order of model inner classes and standard methods should be as
   follows (noting that these are not all required):
 
   * All database fields
@@ -130,7 +130,7 @@ Model style
   * ``def get_absolute_url()``
   * Any custom methods
 
-    * If ``choices`` is defined for a given model field, define the choices as
+* If ``choices`` is defined for a given model field, define the choices as
   a tuple of tuples, with an all-uppercase name, either near the top of
   the model module or just above the model class. Example::
 
@@ -178,13 +178,13 @@ as :class:`django.utils.functional.LazyObject`,
 Miscellaneous
 -------------
 
-    * Mark all strings for internationalization; see the :doc:`i18n
+* Mark all strings for internationalization; see the :doc:`i18n
   documentation </topics/i18n/index>` for details.
 
-    * Remove ``import`` statements that are no longer used when you change code.
+* Remove ``import`` statements that are no longer used when you change code.
   The most common tools for this task are `pyflakes`_ and `pylint`_.
 
-    * Systematically remove all trailing whitespaces from your code as those
+* Systematically remove all trailing whitespaces from your code as those
   add unnecessary bytes, add visual clutter to the patches and can also
   occasionally cause unnecessary merge conflicts. Some IDE's can be
   configured to automatically remove them and most VCS tools can be set to
@@ -193,7 +193,7 @@ Miscellaneous
   are likely to be rejected, since they only introduce noise rather than
   code improvement. Tidy up when you're next changing code in the area.
 
-    * Please don't put your name in the code you contribute. Our policy is to
+* Please don't put your name in the code you contribute. Our policy is to
   keep contributors' names in the ``AUTHORS`` file distributed with Django
   -- not scattered throughout the codebase itself. Feel free to include a
   change to the ``AUTHORS`` file in your patch if you make more than a

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -19,24 +19,24 @@ If you have identified a contribution you want to make and you're capable of
 fixing it (as measured by your coding ability, knowledge of Django internals
 and time availability), claim it by following these steps:
 
-    * `Create an account`_ to use in our ticket system. If you have an account
+* `Create an account`_ to use in our ticket system. If you have an account
   but have forgotten your password, you can reset it using the
   `password reset page`_.
 
-    * If a ticket for this issue doesn't exist yet, create one in our
+* If a ticket for this issue doesn't exist yet, create one in our
   `ticket tracker`_.
 
-    * If a ticket for this issue already exists, make sure nobody else has
+* If a ticket for this issue already exists, make sure nobody else has
   claimed it. To do this, look at the "Assigned to" section of the ticket.
   If it's assigned to "nobody," then it's available to be claimed.
   Otherwise, somebody else is working on this ticket, and you either find
   another bug/feature to work on, or contact the developer working on the
   ticket to offer your help.
 
-    * Log into your account, if you haven't already, by clicking "Login" in
+* Log into your account, if you haven't already, by clicking "Login" in
   the upper right of the ticket page.
 
-    * Claim the ticket:
+* Claim the ticket:
 
   1. click the "accept" radio button under "Action" near the bottom of the
      page,
@@ -76,9 +76,9 @@ it.
 Patch style
 -----------
 
-    * Make sure your code matches our :doc:`coding-style`.
+* Make sure your code matches our :doc:`coding-style`.
 
-    * Submit patches in the format returned by the ``svn diff`` command.
+* Submit patches in the format returned by the ``svn diff`` command.
   An exception is for code changes that are described more clearly in
   plain English than in code. Indentation is the most common example; it's
   hard to read patches when the only difference in code is that it's
@@ -86,23 +86,23 @@ Patch style
 
   Patches in ``git diff`` format are also acceptable.
 
-    * When creating patches, always run ``svn diff`` from the top-level
+* When creating patches, always run ``svn diff`` from the top-level
   ``trunk`` directory -- i.e. the one that contains ``django``, ``docs``,
   ``tests``, ``AUTHORS``, etc. This makes it easy for other people to
   apply your patches.
 
-    * Attach patches to a ticket in the `ticket tracker`_, using the "attach
+* Attach patches to a ticket in the `ticket tracker`_, using the "attach
   file" button. Please *don't* put the patch in the ticket description
   or comment unless it's a single line patch.
 
-    * Name the patch file with a ``.diff`` extension; this will let the ticket
+* Name the patch file with a ``.diff`` extension; this will let the ticket
   tracker apply correct syntax highlighting, which is quite helpful.
 
-    * Check the "Has patch" box on the ticket details. This will make it
+* Check the "Has patch" box on the ticket details. This will make it
   obvious that the ticket includes a patch, and it will add the ticket to
   the `list of tickets with patches`_.
 
-    * The code required to fix a problem or add a feature is an essential part
+* The code required to fix a problem or add a feature is an essential part
   of a patch, but it is not the only part. A good patch should also
   include a regression test to validate the behavior that has been fixed
   and to prevent the problem from arising again. Also, if some tickets are
@@ -110,7 +110,7 @@ Patch style
   some comments in the test so that one can easily trace back the relevant
   discussions after your patch gets committed and the tickets get closed.
 
-    * If the code associated with a patch adds a new feature, or modifies
+* If the code associated with a patch adds a new feature, or modifies
   behavior of an existing feature, the patch should also contain
   documentation.
 

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

@@ -7,9 +7,9 @@ code base. It's our policy to make sure all tests pass at all times.
 
 The tests cover:
 
-    * Models and the database API (``tests/modeltests``),
+* Models and the database API (``tests/modeltests``),
-    * Everything else in core Django code (``tests/regressiontests``),
+* Everything else in core Django code (``tests/regressiontests``),
-    * :ref:`contrib-apps` (``django/contrib/<app>/tests``).
+* :ref:`contrib-apps` (``django/contrib/<app>/tests``).
 
 We appreciate any and all contributions to the test suite!
 
@@ -58,10 +58,10 @@ and type:
 The :setting:`DATABASES` setting in this test settings module needs to define
 two databases:
 
-    * A ``default`` database. This database should use the backend that
+* A ``default`` database. This database should use the backend that
   you want to use for primary testing
 
-    * A database with the alias ``other``. The ``other`` database is
+* A database with the alias ``other``. The ``other`` database is
   used to establish that queries can be directed to different
   databases. As a result, this database can use any backend you
   want. It doesn't need to use the same backend as the ``default``
@@ -70,13 +70,13 @@ two databases:
 If you're using a backend that isn't SQLite, you will need to provide other
 details for each database:
 
-    * The :setting:`USER` option for each of your databases needs to
+* The :setting:`USER` option for each of your databases needs to
   specify an existing user account for the database.
 
-    * The :setting:`PASSWORD` option needs to provide the password for
+* The :setting:`PASSWORD` option needs to provide the password for
   the :setting:`USER` that has been specified.
 
-    * The :setting:`NAME` option must be the name of an existing database to
+* The :setting:`NAME` option must be the name of an existing database to
   which the given user has permission to connect. The unit tests will not
   touch this database; the test runner creates a new database whose name
   is :setting:`NAME` prefixed with ``test_``, and this test database is
@@ -128,13 +128,13 @@ Running all the tests
 If you want to run the full suite of tests, you'll need to install a number of
 dependencies:
 
-    *  PyYAML_
+*  PyYAML_
-    *  Markdown_
+*  Markdown_
-    *  Textile_
+*  Textile_
-    *  Docutils_
+*  Docutils_
-    *  setuptools_
+*  setuptools_
-    *  memcached_, plus a :ref:`supported Python binding <memcached>`
+*  memcached_, plus a :ref:`supported Python binding <memcached>`
-    *  gettext_ (:ref:`gettext_on_windows`)
+*  gettext_ (:ref:`gettext_on_windows`)
 
 If you want to test the memcached cache backend, you'll also need to define
 a :setting:`CACHES` setting that points at your memcached instance.

docs/internals/contributing/writing-documentation.txt

@@ -9,10 +9,10 @@ possible.
 
 Documentation changes generally come in two forms:
 
-    * General improvements: typo corrections, error fixes and better
+* General improvements: typo corrections, error fixes and better
   explanations through clearer writing and more examples.
 
-    * New features: documentation of features that have been added to the
+* New features: documentation of features that have been added to the
   framework since the last release.
 
 This section explains how writers can craft their documentation changes
@@ -54,37 +54,37 @@ Commonly used terms
 Here are some style guidelines on commonly used terms throughout the
 documentation:
 
-    * **Django** -- when referring to the framework, capitalize Django. It is
+* **Django** -- when referring to the framework, capitalize Django. It is
   lowercase only in Python code and in the djangoproject.com logo.
 
-    * **email** -- no hyphen.
+* **email** -- no hyphen.
 
-    * **MySQL**, **PostgreSQL**, **SQLite**
+* **MySQL**, **PostgreSQL**, **SQLite**
 
-    * **Python** -- when referring to the language, capitalize Python.
+* **Python** -- when referring to the language, capitalize Python.
 
-    * **realize**, **customize**, **initialize**, etc. -- use the American
+* **realize**, **customize**, **initialize**, etc. -- use the American
   "ize" suffix, not "ise."
 
-    * **subclass** -- it's a single word without a hyphen, both as a verb
+* **subclass** -- it's a single word without a hyphen, both as a verb
   ("subclass that model") and as a noun ("create a subclass").
 
-    * **Web**, **World Wide Web**, **the Web** -- note Web is always
+* **Web**, **World Wide Web**, **the Web** -- note Web is always
   capitalized when referring to the World Wide Web.
 
-    * **Web site** -- use two words, with Web capitalized.
+* **Web site** -- use two words, with Web capitalized.
 
 Django-specific terminology
 ---------------------------
 
-    * **model** -- it's not capitalized.
+* **model** -- it's not capitalized.
 
-    * **template** -- it's not capitalized.
+* **template** -- it's not capitalized.
 
-    * **URLconf** -- use three capitalized letters, with no space before
+* **URLconf** -- use three capitalized letters, with no space before
   "conf."
 
-    * **view** -- it's not capitalized.
+* **view** -- it's not capitalized.
 
 Guidelines for reStructuredText files
 -------------------------------------
@@ -92,13 +92,13 @@ Guidelines for reStructuredText files
 These guidelines regulate the format of our reST (reStructuredText)
 documentation:
 
-    * In section titles, capitalize only initial words and proper nouns.
+* In section titles, capitalize only initial words and proper nouns.
 
-    * Wrap the documentation at 80 characters wide, unless a code example
+* Wrap the documentation at 80 characters wide, unless a code example
   is significantly less readable when split over two lines, or for another
   good reason.
 
-    * The main thing to keep in mind as you write and edit docs is that the
+* The main thing to keep in mind as you write and edit docs is that the
   more semantic markup you can add the better. So::
 
       Add ``django.contrib.auth`` to your ``INSTALLED_APPS``...
@@ -111,7 +111,7 @@ documentation:
   greatly helps readers. There's basically no limit to the amount of
   useful markup you can add.
 
-    * Use :mod:`~sphinx.ext.intersphinx` to reference Python's and Sphinx'
+* Use :mod:`~sphinx.ext.intersphinx` to reference Python's and Sphinx'
   documentation.
 
 Django-specific markup
@@ -122,37 +122,37 @@ description units:
 
 __ http://sphinx.pocoo.org/markup/desc.html
 
-    * Settings::
+* Settings::
 
         .. setting:: INSTALLED_APPS
 
   To link to a setting, use ``:setting:`INSTALLED_APPS```.
 
-    * Template tags::
+* Template tags::
 
         .. templatetag:: regroup
 
   To link, use ``:ttag:`regroup```.
 
-    * Template filters::
+* Template filters::
 
         .. templatefilter:: linebreaksbr
 
   To link, use ``:tfilter:`linebreaksbr```.
 
-    * Field lookups (i.e. ``Foo.objects.filter(bar__exact=whatever)``)::
+* Field lookups (i.e. ``Foo.objects.filter(bar__exact=whatever)``)::
 
         .. fieldlookup:: exact
 
   To link, use ``:lookup:`exact```.
 
-    * ``django-admin`` commands::
+* ``django-admin`` commands::
 
         .. django-admin:: syncdb
 
   To link, use ``:djadmin:`syncdb```.
 
-    * ``django-admin`` command-line options::
+* ``django-admin`` command-line options::
 
         .. django-admin-option:: --traceback
 
@@ -184,7 +184,7 @@ An example
 For a quick example of how it all fits together, consider this hypothetical
 example:
 
-    * First, the ``ref/settings.txt`` document could have an overall layout
+* First, the ``ref/settings.txt`` document could have an overall layout
   like this:
 
   .. code-block:: rst
@@ -209,7 +209,7 @@ example:
 
     ...
 
-    * Next, the ``topics/settings.txt`` document could contain something like
+* Next, the ``topics/settings.txt`` document could contain something like
   this:
 
   .. code-block:: rst
@@ -225,7 +225,7 @@ example:
   link to another document as a whole and the :rst:role:`ref` element when
   we want to link to an arbitrary location in a document.
 
-    * Next, notice how the settings are annotated:
+* Next, notice how the settings are annotated:
 
   .. code-block:: rst
 
@@ -257,13 +257,13 @@ Improving the documentation
 A few small improvements can be made to make the documentation read and
 look better:
 
-    * Most of the various ``index.txt`` documents have *very* short or even
+* Most of the various ``index.txt`` documents have *very* short or even
   non-existent intro text. Each of those documents needs a good short
   intro the content below that point.
 
-    * The glossary is very perfunctory. It needs to be filled out.
+* The glossary is very perfunctory. It needs to be filled out.
 
-    * Add more metadata targets. Lots of places look like::
+* Add more metadata targets. Lots of places look like::
 
         ``File.close()``
         ~~~~~~~~~~~~~~~~
@@ -274,7 +274,7 @@ look better:
 
   That is, use metadata instead of titles.
 
-    * Add more links -- nearly everything that's an inline code literal
+* Add more links -- nearly everything that's an inline code literal
   right now can probably be turned into a xref.
 
   See the ``literals_to_xrefs.py`` file in ``_ext`` -- it's a shell script
@@ -282,14 +282,14 @@ look better:
 
   This will probably be a continuing, never-ending project.
 
-    * Add `info field lists`__ where appropriate.
+* Add `info field lists`__ where appropriate.
 
   __ http://sphinx.pocoo.org/markup/desc.html#info-field-lists
 
-    * Whenever possible, use links. So, use ``:setting:`ADMIN_FOR``` instead
+* Whenever possible, use links. So, use ``:setting:`ADMIN_FOR``` instead
   of ````ADMIN_FOR````.
 
-    * Use directives where appropriate. Some directives
+* Use directives where appropriate. Some directives
   (e.g. ``.. setting::``) are prefix-style directives; they go *before*
   the unit they're describing. These are known as "crossref" directives.
   Others (e.g. ``.. class::``) generate their own markup; these should go
@@ -299,10 +299,10 @@ look better:
   You can tell which are which by looking at in
   :file:`_ext/djangodocs.py`; it registers roles as one of the other.
 
-    * Add ``.. code-block:: <lang>`` to literal blocks so that they get
+* Add ``.. code-block:: <lang>`` to literal blocks so that they get
   highlighted.
 
-    * When referring to classes/functions/modules, etc., you'll want to use
+* When referring to classes/functions/modules, etc., you'll want to use
   the fully-qualified name of the target
   (``:class:`django.contrib.contenttypes.models.ContentType```).
 

docs/internals/deprecation.txt

@@ -13,10 +13,10 @@ about each item can often be found in the release notes of two versions prior.
 See the :doc:`Django 1.1 release notes</releases/1.1>` for more details on
 these changes.
 
-    * ``AdminSite.root()``.  This method of hooking up the admin URLs will be
+* ``AdminSite.root()``.  This method of hooking up the admin URLs will be
   removed in favor of including ``admin.site.urls``.
 
-    * Authentication backends need to define the boolean attributes
+* Authentication backends need to define the boolean attributes
   ``supports_object_permissions`` and ``supports_anonymous_user`` until
   version 1.4, at which point it will be assumed that all backends will
   support these options.
@@ -27,32 +27,32 @@ these changes.
 See the :doc:`Django 1.2 release notes</releases/1.2>` for more details on
 these changes.
 
-    * ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` will be removed.  Use
+* ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` will be removed.  Use
   the {% csrf_token %} template tag inside forms to enable CSRF
   protection. ``CsrfViewMiddleware`` remains and is enabled by default.
 
-    * The old imports for CSRF functionality (``django.contrib.csrf.*``),
+* The old imports for CSRF functionality (``django.contrib.csrf.*``),
   which moved to core in 1.2, will be removed.
 
-    * The :mod:`django.contrib.gis.db.backend` module will be removed in favor
+* The :mod:`django.contrib.gis.db.backend` module will be removed in favor
   of the specific backends.
 
-    * ``SMTPConnection`` will be removed in favor of a generic E-mail backend API.
+* ``SMTPConnection`` will be removed in favor of a generic E-mail backend API.
 
-    * The many to many SQL generation functions on the database backends
+* The many to many SQL generation functions on the database backends
   will be removed.
 
-    * The ability to use the ``DATABASE_*`` family of top-level settings to
+* The ability to use the ``DATABASE_*`` family of top-level settings to
   define database connections will be removed.
 
-    * The ability to use shorthand notation to specify a database backend
+* The ability to use shorthand notation to specify a database backend
   (i.e., ``sqlite3`` instead of ``django.db.backends.sqlite3``) will be
   removed.
 
-    * The ``get_db_prep_save``, ``get_db_prep_value`` and
+* The ``get_db_prep_save``, ``get_db_prep_value`` and
   ``get_db_prep_lookup`` methods will have to support multiple databases.
 
-    * The ``Message`` model (in ``django.contrib.auth``), its related
+* The ``Message`` model (in ``django.contrib.auth``), its related
   manager in the ``User`` model (``user.message_set``), and the
   associated methods (``user.message_set.create()`` and
   ``user.get_and_delete_messages()``), will be removed.  The
@@ -62,53 +62,53 @@ these changes.
   means that the admin application will depend on the messages
   context processor.
 
-    * Authentication backends will need to support the ``obj`` parameter for
+* Authentication backends will need to support the ``obj`` parameter for
   permission checking. The ``supports_object_permissions`` attribute
   will no longer be checked and can be removed from custom backends.
 
-    * Authentication backends will need to support the ``AnonymousUser`` class
+* Authentication backends will need to support the ``AnonymousUser`` class
   being passed to all methods dealing with permissions.  The
   ``supports_anonymous_user`` variable will no longer be checked and can be
   removed from custom backends.
 
-    * The ability to specify a callable template loader rather than a
+* The ability to specify a callable template loader rather than a
   ``Loader`` class will be removed, as will the ``load_template_source``
   functions that are included with the built in template loaders for
   backwards compatibility.
 
-    * ``django.utils.translation.get_date_formats()`` and
+* ``django.utils.translation.get_date_formats()`` and
   ``django.utils.translation.get_partial_date_formats()``. These functions
   will be removed; use the locale-aware
   ``django.utils.formats.get_format()`` to get the appropriate formats.
 
-    * In ``django.forms.fields``, the constants: ``DEFAULT_DATE_INPUT_FORMATS``,
+* In ``django.forms.fields``, the constants: ``DEFAULT_DATE_INPUT_FORMATS``,
   ``DEFAULT_TIME_INPUT_FORMATS`` and
   ``DEFAULT_DATETIME_INPUT_FORMATS`` will be removed. Use
   ``django.utils.formats.get_format()`` to get the appropriate
   formats.
 
-    * The ability to use a function-based test runners will be removed,
+* The ability to use a function-based test runners will be removed,
   along with the ``django.test.simple.run_tests()`` test runner.
 
-    * The ``views.feed()`` view and ``feeds.Feed`` class in
+* The ``views.feed()`` view and ``feeds.Feed`` class in
   ``django.contrib.syndication`` will be removed. The class-based view
   ``views.Feed`` should be used instead.
 
-    * ``django.core.context_processors.auth``.  This release will
+* ``django.core.context_processors.auth``.  This release will
   remove the old method in favor of the new method in
   ``django.contrib.auth.context_processors.auth``.
 
-    * The ``postgresql`` database backend will be removed, use the
+* The ``postgresql`` database backend will be removed, use the
   ``postgresql_psycopg2`` backend instead.
 
-    * The ``no`` language code will be removed and has been replaced by the
+* The ``no`` language code will be removed and has been replaced by the
   ``nb`` language code.
 
-    * Authentication backends will need to define the boolean attribute
+* Authentication backends will need to define the boolean attribute
   ``supports_inactive_user`` until version 1.5 when it will be assumed that
   all backends will handle inactive users.
 
-    * ``django.db.models.fields.XMLField`` will be removed. This was
+* ``django.db.models.fields.XMLField`` will be removed. This was
   deprecated as part of the 1.3 release. An accelerated deprecation
   schedule has been used because the field hasn't performed any role
   beyond that of a simple ``TextField`` since the removal of oldforms.
@@ -121,64 +121,64 @@ these changes.
 See the :doc:`Django 1.3 release notes</releases/1.3>` for more details on
 these changes.
 
-    * The ``mod_python`` request handler will be removed. The ``mod_wsgi``
+* The ``mod_python`` request handler will be removed. The ``mod_wsgi``
   handler should be used instead.
 
-    * The ``template`` attribute on :class:`~django.test.client.Response`
+* The ``template`` attribute on :class:`~django.test.client.Response`
   objects returned by the :ref:`test client <test-client>` will be removed.
   The :attr:`~django.test.client.Response.templates` attribute should be
   used instead.
 
-    * The :class:`~django.test.simple.DjangoTestRunner` will be removed.
+* The :class:`~django.test.simple.DjangoTestRunner` will be removed.
   Instead use a unittest-native class.  The features of the
   :class:`django.test.simple.DjangoTestRunner` (including fail-fast and
   Ctrl-C test termination) can currently be provided by the unittest-native
   :class:`TextTestRunner`.
 
-    * The undocumented function
+* The undocumented function
   :func:`django.contrib.formtools.utils.security_hash` will be removed,
   instead use :func:`django.contrib.formtools.utils.form_hmac`
 
-    * The function-based generic view modules will be removed in favor of their
+* The function-based generic view modules will be removed in favor of their
   class-based equivalents, outlined :doc:`here
   </topics/generic-views-migration>`:
 
-    * The :class:`~django.core.servers.basehttp.AdminMediaHandler` will be
+* The :class:`~django.core.servers.basehttp.AdminMediaHandler` will be
   removed.  In its place use
   :class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.
 
-    * The :ttag:`url` and :ttag:`ssi` template tags will be
+* The :ttag:`url` and :ttag:`ssi` template tags will be
   modified so that the first argument to each tag is a
   template variable, not an implied string. Until then, the new-style
   behavior is provided in the ``future`` template tag library.
 
-    * The :djadmin:`reset` and :djadmin:`sqlreset` management commands
+* The :djadmin:`reset` and :djadmin:`sqlreset` management commands
   will be removed.
 
-    * Authentication backends will need to support an inactive user
+* Authentication backends will need to support an inactive user
   being passed to all methods dealing with permissions.
   The ``supports_inactive_user`` attribute will no longer be checked
   and can be removed from custom backends.
 
-    * :meth:`~django.contrib.gis.geos.GEOSGeometry.transform` will raise
+* :meth:`~django.contrib.gis.geos.GEOSGeometry.transform` will raise
   a :class:`~django.contrib.gis.geos.GEOSException` when called
   on a geometry with no SRID value.
 
-    * :class:`~django.http.CompatCookie` will be removed in favor of
+* :class:`~django.http.CompatCookie` will be removed in favor of
   :class:`~django.http.SimpleCookie`.
 
-    * :class:`django.core.context_processors.PermWrapper` and
+* :class:`django.core.context_processors.PermWrapper` and
   :class:`django.core.context_processors.PermLookupDict` will be removed in
   favor of the corresponding
   :class:`django.contrib.auth.context_processors.PermWrapper` and
   :class:`django.contrib.auth.context_processors.PermLookupDict`,
   respectively.
 
-    * The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings will be
+* The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings will be
   required to end with a trailing slash to ensure there is a consistent
   way to combine paths in templates.
 
-    * ``django.db.models.fields.URLField.verify_exists`` will be removed. The
+* ``django.db.models.fields.URLField.verify_exists`` will be removed. The
   feature was deprecated in 1.3.1 due to intractable security and
   performance issues and will follow a slightly accelerated deprecation
   timeframe.
@@ -189,64 +189,64 @@ these changes.
 See the :doc:`Django 1.4 release notes</releases/1.4>` for more details on
 these changes.
 
-    * The compatibility modules ``django.utils.copycompat`` and
+* The compatibility modules ``django.utils.copycompat`` and
   ``django.utils.hashcompat`` as well as the functions
   ``django.utils.itercompat.all`` and ``django.utils.itercompat.any`` will
   be removed. The Python builtin versions should be used instead.
 
-    * The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
+* The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
   :func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will
   be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it
   returns the same function), and ``csrf_view_exempt`` has been a
   synonym for ``django.views.decorators.csrf.csrf_exempt``, which should
   be used to replace it.
 
-    * The :class:`~django.core.cache.backends.memcached.CacheClass` backend
+* The :class:`~django.core.cache.backends.memcached.CacheClass` backend
   was split into two in Django 1.3 in order to introduce support for
   PyLibMC. The historical :class:`~django.core.cache.backends.memcached.CacheClass`
   will be removed in favor of :class:`~django.core.cache.backends.memcached.MemcachedCache`.
 
-    * The UK-prefixed objects of ``django.contrib.localflavor.uk`` will only
+* The UK-prefixed objects of ``django.contrib.localflavor.uk`` will only
   be accessible through their GB-prefixed names (GB is the correct
   ISO 3166 code for United Kingdom).
 
-    * The :setting:`IGNORABLE_404_STARTS` and :setting:`IGNORABLE_404_ENDS`
+* The :setting:`IGNORABLE_404_STARTS` and :setting:`IGNORABLE_404_ENDS`
   settings have been superseded by :setting:`IGNORABLE_404_URLS` in
   the 1.4 release. They will be removed.
 
-    * The :doc:`form wizard </ref/contrib/formtools/form-wizard>` has been
+* The :doc:`form wizard </ref/contrib/formtools/form-wizard>` has been
   refactored to use class based views with pluggable backends in 1.4.
   The previous implementation will be removed.
 
-    * Legacy ways of calling
+* Legacy ways of calling
   :func:`~django.views.decorators.cache.cache_page` will be removed.
 
-    * The backward-compatibility shim to automatically add a debug-false
+* The backward-compatibility shim to automatically add a debug-false
   filter to the ``'mail_admins'`` logging handler will be removed. The
   :setting:`LOGGING` setting should include this filter explicitly if
   it is desired.
 
-    * The template tag
+* The template tag
   :func:`django.contrib.admin.templatetags.adminmedia.admin_media_prefix`
   will be removed in favor of the generic static files handling.
 
-    * The builtin truncation functions :func:`django.utils.text.truncate_words`
+* The builtin truncation functions :func:`django.utils.text.truncate_words`
   and :func:`django.utils.text.truncate_html_words` will be removed in
   favor of the ``django.utils.text.Truncator`` class.
 
-    * The :class:`~django.contrib.gis.geoip.GeoIP` class was moved to
+* The :class:`~django.contrib.gis.geoip.GeoIP` class was moved to
   :mod:`django.contrib.gis.geoip` in 1.4 -- the shortcut in
   :mod:`django.contrib.gis.utils` will be removed.
 
-    * ``django.conf.urls.defaults`` will be removed. The functions
+* ``django.conf.urls.defaults`` will be removed. The functions
   :func:`~django.conf.urls.include`, :func:`~django.conf.urls.patterns` and
   :func:`~django.conf.urls.url` plus :data:`~django.conf.urls.handler404`,
   :data:`~django.conf.urls.handler500`, are now available through
   :mod:`django.conf.urls` .
 
-    * The Databrowse contrib module will be removed.
+* The Databrowse contrib module will be removed.
 
-    * The functions :func:`~django.core.management.setup_environ` and
+* The functions :func:`~django.core.management.setup_environ` and
   :func:`~django.core.management.execute_manager` will be removed from
   :mod:`django.core.management`. This also means that the old (pre-1.4)
   style of :file:`manage.py` file will no longer work.
@@ -254,7 +254,7 @@ these changes.
 2.0
 ---
 
-    * ``django.views.defaults.shortcut()``. This function has been moved
+* ``django.views.defaults.shortcut()``. This function has been moved
   to ``django.contrib.contenttypes.views.shortcut()`` as part of the
   goal of removing all ``django.contrib`` references from the core
   Django codebase. The old shortcut will be removed in the 2.0

docs/internals/release-process.txt

@@ -9,25 +9,25 @@ Official releases
 
 Since version 1.0, Django's release numbering works as follows:
 
-    * Versions are numbered in the form ``A.B`` or ``A.B.C``.
+* Versions are numbered in the form ``A.B`` or ``A.B.C``.
 
-    * ``A`` is the *major version* number, which is only incremented for major
+* ``A`` is the *major version* number, which is only incremented for major
   changes to Django, and these changes are not necessarily
   backwards-compatible. That is, code you wrote for Django 1.2 may break
   when we release Django 2.0.
 
-    * ``B`` is the *minor version* number, which is incremented for large yet
+* ``B`` is the *minor version* number, which is incremented for large yet
   backwards compatible changes.  Code written for Django 1.2 will continue
   to work under Django 1.3. Exceptions to this rule will be listed in the
   release notes.
 
-    * ``C`` is the *micro version* number, which is incremented for bug and
+* ``C`` is the *micro version* number, which is incremented for bug and
   security fixes. A new micro-release will be 100% backwards-compatible with
   the previous micro-release. The only exception is when a security issue
   can't be fixed without breaking backwards-compatibility. If this happens,
   the release notes will provide detailed upgrade instructions.
 
-    * In some cases, we'll make alpha, beta, or release candidate releases.
+* In some cases, we'll make alpha, beta, or release candidate releases.
   These are of the form ``A.B alpha/beta/rc N``, which means the ``Nth``
   alpha/beta/release candidate of version ``A.B``.
 
@@ -59,15 +59,15 @@ remove the feature entirely.
 
 So, for example, if we decided to remove a function that existed in Django 1.0:
 
-    * Django 1.1 will contain a backwards-compatible replica of the function
+* Django 1.1 will contain a backwards-compatible replica of the function
   which will raise a ``PendingDeprecationWarning``. This warning is silent
   by default; you need to explicitly turn on display of these warnings.
 
-    * Django 1.2 will contain the backwards-compatible replica, but the warning
+* Django 1.2 will contain the backwards-compatible replica, but the warning
   will be promoted to a full-fledged ``DeprecationWarning``. This warning is
   *loud* by default, and will likely be quite annoying.
 
-    * Django 1.3 will remove the feature outright.
+* Django 1.3 will remove the feature outright.
 
 Micro releases
 --------------
@@ -90,10 +90,10 @@ Supported versions
 At any moment in time, Django's developer team will support a set of releases to
 varying levels:
 
-    * The current development trunk will get new features and bug fixes
+* The current development trunk will get new features and bug fixes
   requiring major refactoring.
 
-    * Patches applied to the trunk will also be applied to the last minor
+* Patches applied to the trunk will also be applied to the last minor
   release, to be released as the next micro release, when they fix critical
   problems:
 
@@ -108,18 +108,18 @@ varying levels:
   The rule of thumb is that fixes will be backported to the last minor
   release for bugs that would have prevented a release in the first place.
 
-    * Security fixes will be applied to the current trunk and the previous two
+* Security fixes will be applied to the current trunk and the previous two
   minor releases.
 
 As a concrete example, consider a moment in time halfway between the release of
 Django 1.3 and 1.4. At this point in time:
 
-    * Features will be added to development trunk, to be released as Django 1.4.
+* Features will be added to development trunk, to be released as Django 1.4.
 
-    * Critical bug fixes will be applied to a ``1.3.X`` branch, and released as
+* Critical bug fixes will be applied to a ``1.3.X`` branch, and released as
   1.3.1, 1.3.2, etc.
 
-    * Security fixes will be applied to trunk, a ``1.3.X`` branch and a
+* Security fixes will be applied to trunk, a ``1.3.X`` branch and a
   ``1.2.X`` branch. They will trigger the release of ``1.3.1``, ``1.2.1``,
   etc.
 
@@ -204,15 +204,15 @@ Let's look at a hypothetical example for how this all first together. Imagine,
 if you will, a point about halfway between 1.1 and 1.2. At this point,
 development will be happening in a bunch of places:
 
-    * On trunk, development towards 1.2 proceeds with small additions, bugs
+* On trunk, development towards 1.2 proceeds with small additions, bugs
   fixes, etc. being checked in daily.
 
-    * On the branch "branches/releases/1.1.X", fixes for critical bugs found in
+* On the branch "branches/releases/1.1.X", fixes for critical bugs found in
   the 1.1 release are checked in as needed. At some point, this branch will
   be released as "1.1.1", "1.1.2", etc.
 
-    * On the branch "branches/releases/1.0.X", security fixes are made if
+* On the branch "branches/releases/1.0.X", security fixes are made if
   needed and released as "1.0.2", "1.0.3", etc.
 
-    * On feature branches, development of major features is done. These
+* On feature branches, development of major features is done. These
   branches will be merged into trunk before the end of phase two.

docs/intro/install.txt

@@ -57,15 +57,15 @@ Install Django
 
 You've got three easy options to install Django:
 
-    * Install a version of Django :doc:`provided by your operating system
+* Install a version of Django :doc:`provided by your operating system
   distribution </misc/distributions>`. This is the quickest option for those
   who have operating systems that distribute Django.
 
-    * :ref:`Install an official release <installing-official-release>`. This
+* :ref:`Install an official release <installing-official-release>`. This
   is the best approach for users who want a stable version number and aren't
   concerned about running a slightly older version of Django.
 
-    * :ref:`Install the latest development version
+* :ref:`Install the latest development version
   <installing-development-version>`. This is best for users who want the
   latest-and-greatest features and aren't afraid of running brand-new code.
 

docs/intro/overview.txt

@@ -307,13 +307,13 @@ This is just the surface
 This has been only a quick overview of Django's functionality. Some more useful
 features:
 
-    * A :doc:`caching framework </topics/cache>` that integrates with memcached
+* A :doc:`caching framework </topics/cache>` that integrates with memcached
   or other backends.
 
-    * A :doc:`syndication framework </ref/contrib/syndication>` that makes
+* A :doc:`syndication framework </ref/contrib/syndication>` that makes
   creating RSS and Atom feeds as easy as writing a small Python class.
 
-    * More sexy automatically-generated admin features -- this overview barely
+* More sexy automatically-generated admin features -- this overview barely
   scratched the surface.
 
 The next obvious steps are for you to `download Django`_, read :doc:`the

docs/intro/tutorial01.txt

@@ -9,8 +9,8 @@ poll application.
 
 It'll consist of two parts:
 
-    * A public site that lets people view polls and vote in them.
+* A public site that lets people view polls and vote in them.
-    * An admin site that lets you add, change and delete polls.
+* An admin site that lets you add, change and delete polls.
 
 We'll assume you have :doc:`Django installed </intro/install>` already. You can
 tell Django is installed by running the Python interactive interpreter and
@@ -190,13 +190,13 @@ module-level variables representing Django settings. Change the
 following keys in the :setting:`DATABASES` ``'default'`` item to match
 your databases connection settings.
 
-    * :setting:`ENGINE <DATABASE-ENGINE>` -- Either
+* :setting:`ENGINE <DATABASE-ENGINE>` -- Either
   ``'django.db.backends.postgresql_psycopg2'``,
   ``'django.db.backends.mysql'`` or
   ``'django.db.backends.sqlite3'``. Other backends are
   :setting:`also available <DATABASE-ENGINE>`.
 
-    * :setting:`NAME` -- The name of your database. If you're using
+* :setting:`NAME` -- The name of your database. If you're using
   SQLite, the database will be a file on your computer; in that
   case, :setting:`NAME` should be the full absolute path,
   including filename, of that file. If the file doesn't exist, it
@@ -206,12 +206,12 @@ your databases connection settings.
   When specifying the path, always use forward slashes, even on
   Windows (e.g. ``C:/homes/user/mysite/sqlite3.db``).
 
-    * :setting:`USER` -- Your database username (not used for SQLite).
+* :setting:`USER` -- Your database username (not used for SQLite).
 
-    * :setting:`PASSWORD` -- Your database password (not used for
+* :setting:`PASSWORD` -- Your database password (not used for
   SQLite).
 
-    * :setting:`HOST` -- The host your database is on. Leave this as
+* :setting:`HOST` -- The host your database is on. Leave this as
   an empty string if your database server is on the same physical
   machine (not used for SQLite).
 
@@ -238,18 +238,18 @@ distribute them for use by others in their projects.
 By default, :setting:`INSTALLED_APPS` contains the following apps, all of which
 come with Django:
 
-    * :mod:`django.contrib.auth` -- An authentication system.
+* :mod:`django.contrib.auth` -- An authentication system.
 
-    * :mod:`django.contrib.contenttypes` -- A framework for content types.
+* :mod:`django.contrib.contenttypes` -- A framework for content types.
 
-    * :mod:`django.contrib.sessions` -- A session framework.
+* :mod:`django.contrib.sessions` -- A session framework.
 
-    * :mod:`django.contrib.sites` -- A framework for managing multiple sites
+* :mod:`django.contrib.sites` -- A framework for managing multiple sites
   with one Django installation.
 
-    * :mod:`django.contrib.messages` -- A messaging framework.
+* :mod:`django.contrib.messages` -- A messaging framework.
 
-    * :mod:`django.contrib.staticfiles` -- A framework for managing
+* :mod:`django.contrib.staticfiles` -- A framework for managing
   static files.
 
 These applications are included by default as a convenience for the common case.
@@ -390,8 +390,8 @@ Activating models
 That small bit of model code gives Django a lot of information. With it, Django
 is able to:
 
-    * Create a database schema (``CREATE TABLE`` statements) for this app.
+* Create a database schema (``CREATE TABLE`` statements) for this app.
-    * Create a Python database-access API for accessing Poll and Choice objects.
+* Create a Python database-access API for accessing Poll and Choice objects.
 
 But first we need to tell our project that the ``polls`` app is installed.
 
@@ -441,28 +441,28 @@ statements for the polls app):
 
 Note the following:
 
-    * The exact output will vary depending on the database you are using.
+* The exact output will vary depending on the database you are using.
 
-    * Table names are automatically generated by combining the name of the app
+* Table names are automatically generated by combining the name of the app
   (``polls``) and the lowercase name of the model -- ``poll`` and
   ``choice``. (You can override this behavior.)
 
-    * Primary keys (IDs) are added automatically. (You can override this, too.)
+* Primary keys (IDs) are added automatically. (You can override this, too.)
 
-    * By convention, Django appends ``"_id"`` to the foreign key field name.
+* By convention, Django appends ``"_id"`` to the foreign key field name.
   Yes, you can override this, as well.
 
-    * The foreign key relationship is made explicit by a ``REFERENCES``
+* The foreign key relationship is made explicit by a ``REFERENCES``
   statement.
 
-    * It's tailored to the database you're using, so database-specific field
+* It's tailored to the database you're using, so database-specific field
   types such as ``auto_increment`` (MySQL), ``serial`` (PostgreSQL), or
   ``integer primary key`` (SQLite) are handled for you automatically. Same
   goes for quoting of field names -- e.g., using double quotes or single
   quotes. The author of this tutorial runs PostgreSQL, so the example
   output is in PostgreSQL syntax.
 
-    * The :djadmin:`sql` command doesn't actually run the SQL in your database -
+* The :djadmin:`sql` command doesn't actually run the SQL in your database -
   it just prints it to the screen so that you can see what SQL Django thinks
   is required. If you wanted to, you could copy and paste this SQL into your
   database prompt. However, as we will see shortly, Django provides an
@@ -470,21 +470,21 @@ Note the following:
 
 If you're interested, also run the following commands:
 
-    * :djadmin:`python manage.py validate <validate>` -- Checks for any errors
+* :djadmin:`python manage.py validate <validate>` -- Checks for any errors
   in the construction of your models.
 
-    * :djadmin:`python manage.py sqlcustom polls <sqlcustom>` -- Outputs any
+* :djadmin:`python manage.py sqlcustom polls <sqlcustom>` -- Outputs any
   :ref:`custom SQL statements <initial-sql>` (such as table modifications or
   constraints) that are defined for the application.
 
-    * :djadmin:`python manage.py sqlclear polls <sqlclear>` -- Outputs the
+* :djadmin:`python manage.py sqlclear polls <sqlclear>` -- Outputs the
   necessary ``DROP TABLE`` statements for this app, according to which
   tables already exist in your database (if any).
 
-    * :djadmin:`python manage.py sqlindexes polls <sqlindexes>` -- Outputs the
+* :djadmin:`python manage.py sqlindexes polls <sqlindexes>` -- Outputs the
   ``CREATE INDEX`` statements for this app.
 
-    * :djadmin:`python manage.py sqlall polls <sqlall>` -- A combination of all
+* :djadmin:`python manage.py sqlall polls <sqlall>` -- A combination of all
   the SQL from the :djadmin:`sql`, :djadmin:`sqlcustom`, and
   :djadmin:`sqlindexes` commands.
 

docs/intro/tutorial02.txt

@@ -27,12 +27,12 @@ Activate the admin site
 The Django admin site is not activated by default -- it's an opt-in thing. To
 activate the admin site for your installation, do these three things:
 
-    * Add ``"django.contrib.admin"`` to your :setting:`INSTALLED_APPS` setting.
+* Add ``"django.contrib.admin"`` to your :setting:`INSTALLED_APPS` setting.
 
-    * Run ``python manage.py syncdb``. Since you have added a new application
+* Run ``python manage.py syncdb``. Since you have added a new application
   to :setting:`INSTALLED_APPS`, the database tables need to be updated.
 
-    * Edit your ``mysite/urls.py`` file and uncomment the lines that reference
+* Edit your ``mysite/urls.py`` file and uncomment the lines that reference
   the admin -- there are three lines in total to uncomment. This file is a
   URLconf; we'll dig into URLconfs in the next tutorial. For now, all you
   need to know is that it maps URL roots to applications. In the end, you
@@ -145,29 +145,29 @@ Click the "What's up?" poll to edit it:
 
 Things to note here:
 
-    * The form is automatically generated from the Poll model.
+* The form is automatically generated from the Poll model.
 
-    * The different model field types (:class:`~django.db.models.DateTimeField`,
+* The different model field types (:class:`~django.db.models.DateTimeField`,
   :class:`~django.db.models.CharField`) correspond to the appropriate HTML
   input widget. Each type of field knows how to display itself in the Django
   admin.
 
-    * Each :class:`~django.db.models.DateTimeField` gets free JavaScript
+* Each :class:`~django.db.models.DateTimeField` gets free JavaScript
   shortcuts. Dates get a "Today" shortcut and calendar popup, and times get
   a "Now" shortcut and a convenient popup that lists commonly entered times.
 
 The bottom part of the page gives you a couple of options:
 
-    * Save -- Saves changes and returns to the change-list page for this type of
+* Save -- Saves changes and returns to the change-list page for this type of
   object.
 
-    * Save and continue editing -- Saves changes and reloads the admin page for
+* Save and continue editing -- Saves changes and reloads the admin page for
   this object.
 
-    * Save and add another -- Saves changes and loads a new, blank form for this
+* Save and add another -- Saves changes and loads a new, blank form for this
   type of object.
 
-    * Delete -- Displays a delete confirmation page.
+* Delete -- Displays a delete confirmation page.
 
 Change the "Date published" by clicking the "Today" and "Now" shortcuts. Then
 click "Save and continue editing." Then click "History" in the upper right.

docs/intro/tutorial03.txt

@@ -13,30 +13,30 @@ A view is a "type" of Web page in your Django application that generally serves
 a specific function and has a specific template. For example, in a Weblog
 application, you might have the following views:
 
-    * Blog homepage -- displays the latest few entries.
+* Blog homepage -- displays the latest few entries.
 
-    * Entry "detail" page -- permalink page for a single entry.
+* Entry "detail" page -- permalink page for a single entry.
 
-    * Year-based archive page -- displays all months with entries in the
+* Year-based archive page -- displays all months with entries in the
   given year.
 
-    * Month-based archive page -- displays all days with entries in the
+* Month-based archive page -- displays all days with entries in the
   given month.
 
-    * Day-based archive page -- displays all entries in the given day.
+* Day-based archive page -- displays all entries in the given day.
 
-    * Comment action -- handles posting comments to a given entry.
+* Comment action -- handles posting comments to a given entry.
 
 In our poll application, we'll have the following four views:
 
-    * Poll "index" page -- displays the latest few polls.
+* Poll "index" page -- displays the latest few polls.
 
-    * Poll "detail" page -- displays a poll question, with no results but
+* Poll "detail" page -- displays a poll question, with no results but
   with a form to vote.
 
-    * Poll "results" page -- displays results for a particular poll.
+* Poll "results" page -- displays results for a particular poll.
 
-    * Vote action -- handles voting for a particular choice in a particular
+* Vote action -- handles voting for a particular choice in a particular
   poll.
 
 In Django, each view is represented by a simple Python function.
@@ -375,19 +375,19 @@ in ``django/conf/urls/defaults.py``, ``handler404`` is set to
 
 Four more things to note about 404 views:
 
-    * If :setting:`DEBUG` is set to ``True`` (in your settings module) then your
+* If :setting:`DEBUG` is set to ``True`` (in your settings module) then your
   404 view will never be used (and thus the ``404.html`` template will never
   be rendered) because the traceback will be displayed instead.
 
-    * The 404 view is also called if Django doesn't find a match after checking
+* The 404 view is also called if Django doesn't find a match after checking
   every regular expression in the URLconf.
 
-    * If you don't define your own 404 view -- and simply use the default, which
+* If you don't define your own 404 view -- and simply use the default, which
   is recommended -- you still have one obligation: To create a ``404.html``
   template in the root of your template directory. The default 404 view will
   use that template for all 404 errors.
 
-    * If :setting:`DEBUG` is set to ``False`` (in your settings module) and if
+* If :setting:`DEBUG` is set to ``False`` (in your settings module) and if
   you didn't create a ``404.html`` file, an ``Http500`` is raised instead.
   So remember to create a ``404.html``.
 
@@ -517,9 +517,9 @@ URLconf for further processing.
 
 Here's what happens if a user goes to "/polls/34/" in this system:
 
-    * Django will find the match at ``'^polls/'``
+* Django will find the match at ``'^polls/'``
 
-    * Then, Django will strip off the matching text (``"polls/"``) and send the
+* Then, Django will strip off the matching text (``"polls/"``) and send the
   remaining text -- ``"34/"`` -- to the 'polls.urls' URLconf for
   further processing.
 

docs/intro/tutorial04.txt

@@ -29,23 +29,23 @@ tutorial, so that the template contains an HTML ``<form>`` element:
 
 A quick rundown:
 
-    * The above template displays a radio button for each poll choice. The
+* The above template displays a radio button for each poll choice. The
   ``value`` of each radio button is the associated poll choice's ID. The
   ``name`` of each radio button is ``"choice"``. That means, when somebody
   selects one of the radio buttons and submits the form, it'll send the
   POST data ``choice=3``. This is HTML Forms 101.
 
-    * We set the form's ``action`` to ``/polls/{{ poll.id }}/vote/``, and we
+* We set the form's ``action`` to ``/polls/{{ poll.id }}/vote/``, and we
   set ``method="post"``. Using ``method="post"`` (as opposed to
   ``method="get"``) is very important, because the act of submitting this
   form will alter data server-side. Whenever you create a form that alters
   data server-side, use ``method="post"``. This tip isn't specific to
   Django; it's just good Web development practice.
 
-    * ``forloop.counter`` indicates how many times the :ttag:`for` tag has gone
+* ``forloop.counter`` indicates how many times the :ttag:`for` tag has gone
   through its loop
 
-    * Since we're creating a POST form (which can have the effect of modifying
+* Since we're creating a POST form (which can have the effect of modifying
   data), we need to worry about Cross Site Request Forgeries.
   Thankfully, you don't have to worry too hard, because Django comes with
   a very easy-to-use system for protecting against it. In short, all POST
@@ -102,7 +102,7 @@ create a real version. Add the following to ``polls/views.py``::
 
 This code includes a few things we haven't covered yet in this tutorial:
 
-    * :attr:`request.POST <django.http.HttpRequest.POST>` is a dictionary-like
+* :attr:`request.POST <django.http.HttpRequest.POST>` is a dictionary-like
   object that lets you access submitted data by key name. In this case,
   ``request.POST['choice']`` returns the ID of the selected choice, as a
   string. :attr:`request.POST <django.http.HttpRequest.POST>` values are
@@ -114,11 +114,11 @@ This code includes a few things we haven't covered yet in this tutorial:
   <django.http.HttpRequest.POST>` in our code, to ensure that data is only
   altered via a POST call.
 
-    * ``request.POST['choice']`` will raise :exc:`KeyError` if ``choice`` wasn't
+* ``request.POST['choice']`` will raise :exc:`KeyError` if ``choice`` wasn't
   provided in POST data. The above code checks for :exc:`KeyError` and
   redisplays the poll form with an error message if ``choice`` isn't given.
 
-    * After incrementing the choice count, the code returns an
+* After incrementing the choice count, the code returns an
   :class:`~django.http.HttpResponseRedirect` rather than a normal
   :class:`~django.http.HttpResponse`.
   :class:`~django.http.HttpResponseRedirect` takes a single argument: the
@@ -130,7 +130,7 @@ This code includes a few things we haven't covered yet in this tutorial:
   POST data. This tip isn't specific to Django; it's just good Web
   development practice.
 
-    * We are using the :func:`~django.core.urlresolvers.reverse` function in the
+* We are using the :func:`~django.core.urlresolvers.reverse` function in the
   :class:`~django.http.HttpResponseRedirect` constructor in this example.
   This function helps avoid having to hardcode a URL in the view function.
   It is given the name of the view that we want to pass control to and the
@@ -197,11 +197,11 @@ Let's convert our poll app to use the generic views system, so we can delete a
 bunch of our own code. We'll just have to take a few steps to make the
 conversion. We will:
 
-    1. Convert the URLconf.
+1. Convert the URLconf.
 
-    2. Delete some of the old, unneeded views.
+2. Delete some of the old, unneeded views.
 
-    3. Fix up URL handling for the new views.
+3. Fix up URL handling for the new views.
 
 Read on for details.
 
@@ -257,15 +257,15 @@ We're using two generic views here:
 two views abstract the concepts of "display a list of objects" and
 "display a detail page for a particular type of object."
 
-    * Each generic view needs to know what model it will be acting
+* Each generic view needs to know what model it will be acting
   upon. This is provided using the ``model`` parameter.
 
-    * The :class:`~django.views.generic.list.DetailView` generic view
+* The :class:`~django.views.generic.list.DetailView` generic view
   expects the primary key value captured from the URL to be called
   ``"pk"``, so we've changed ``poll_id`` to ``pk`` for the generic
   views.
 
-    * We've added a name, ``poll_results``, to the results view so
+* We've added a name, ``poll_results``, to the results view so
   that we have a way to refer to its URL later on (see the
   documentation about :ref:`naming URL patterns
   <naming-url-patterns>` for information). We're also using the
@@ -328,12 +328,12 @@ Coming soon
 The tutorial ends here for the time being. Future installments of the tutorial
 will cover:
 
-    * Advanced form processing
+* Advanced form processing
-    * Using the RSS framework
+* Using the RSS framework
-    * Using the cache framework
+* Using the cache framework
-    * Using the comments framework
+* Using the comments framework
-    * Advanced admin features: Permissions
+* Advanced admin features: Permissions
-    * Advanced admin features: Custom JavaScript
+* Advanced admin features: Custom JavaScript
 
 In the meantime, you might want to check out some pointers on :doc:`where to go
 from here </intro/whatsnext>`

docs/intro/whatsnext.txt

@@ -35,12 +35,12 @@ How the documentation is organized
 Django's main documentation is broken up into "chunks" designed to fill
 different needs:
 
-    * The :doc:`introductory material </intro/index>` is designed for people new
+* The :doc:`introductory material </intro/index>` is designed for people new
   to Django -- or to Web development in general. It doesn't cover anything
   in depth, but instead gives a high-level overview of how developing in
   Django "feels".
 
-    * The :doc:`topic guides </topics/index>`, on the other hand, dive deep into
+* The :doc:`topic guides </topics/index>`, on the other hand, dive deep into
   individual parts of Django. There are complete guides to Django's
   :doc:`model system </topics/db/index>`, :doc:`template engine
   </topics/templates>`, :doc:`forms framework </topics/forms/index>`, and much
@@ -50,7 +50,7 @@ different needs:
   your way through these guides you should come out knowing pretty much
   everything there is to know about Django.
 
-    * Web development is often broad, not deep -- problems span many domains.
+* Web development is often broad, not deep -- problems span many domains.
   We've written a set of :doc:`how-to guides </howto/index>` that answer
   common "How do I ...?" questions. Here you'll find information about
   :doc:`generating PDFs with Django </howto/outputting-pdf>`, :doc:`writing
@@ -59,14 +59,14 @@ different needs:
   Answers to really common questions can also be found in the :doc:`FAQ
   </faq/index>`.
 
-    * The guides and how-to's don't cover every single class, function, and
+* The guides and how-to's don't cover every single class, function, and
   method available in Django -- that would be overwhelming when you're
   trying to learn. Instead, details about individual classes, functions,
   methods, and modules are kept in the :doc:`reference </ref/index>`. This is
   where you'll turn to find the details of a particular function or
   whathaveyou.
 
-    * Finally, there's some "specialized" documentation not usually relevant to
+* Finally, there's some "specialized" documentation not usually relevant to
   most developers. This includes the :doc:`release notes </releases/index>`,
   :doc:`documentation of obsolete features </obsolete/index>`,
   :doc:`internals documentation </internals/index>` for those who want to add
@@ -81,15 +81,15 @@ Just as the Django code base is developed and improved on a daily basis, our
 documentation is consistently improving. We improve documentation for several
 reasons:
 
-    * To make content fixes, such as grammar/typo corrections.
+* To make content fixes, such as grammar/typo corrections.
 
-    * To add information and/or examples to existing sections that need to be
+* To add information and/or examples to existing sections that need to be
   expanded.
 
-    * To document Django features that aren't yet documented. (The list of
+* To document Django features that aren't yet documented. (The list of
   such features is shrinking but exists nonetheless.)
 
-    * To add documentation for new features as new features get added, or as
+* To add documentation for new features as new features get added, or as
   Django APIs or behaviors change.
 
 Django's documentation is kept in the same source control system as its code. It
@@ -164,7 +164,7 @@ As HTML, locally
 
 You can get a local copy of the HTML documentation following a few easy steps:
 
-    * Django's documentation uses a system called Sphinx__ to convert from
+* Django's documentation uses a system called Sphinx__ to convert from
   plain text to HTML. You'll need to install Sphinx by either downloading
   and installing the package from the Sphinx Web site, or by Python's
   ``easy_install``:
@@ -173,7 +173,7 @@ You can get a local copy of the HTML documentation following a few easy steps:
 
         $ easy_install Sphinx
 
-    * Then, just use the included ``Makefile`` to turn the documentation into
+* Then, just use the included ``Makefile`` to turn the documentation into
   HTML:
 
   .. code-block:: bash
@@ -190,7 +190,7 @@ You can get a local copy of the HTML documentation following a few easy steps:
         cd path\to\django\docs
         make.bat html
 
-    * The HTML documentation will be placed in ``docs/_build/html``.
+* The HTML documentation will be placed in ``docs/_build/html``.
 
 .. note::
 
@@ -212,19 +212,19 @@ versions of the framework.
 
 We follow this policy:
 
-    * The primary documentation on djangoproject.com is an HTML version of the
+* The primary documentation on djangoproject.com is an HTML version of the
   latest docs in Subversion. These docs always correspond to the latest
   official Django release, plus whatever features we've added/changed in
   the framework *since* the latest release.
 
-    * As we add features to Django's development version, we try to update the
+* As we add features to Django's development version, we try to update the
   documentation in the same Subversion commit transaction.
 
-    * To distinguish feature changes/additions in the docs, we use the phrase:
+* To distinguish feature changes/additions in the docs, we use the phrase:
   "New in version X.Y", being X.Y the next release version (hence, the one
   being developed).
 
-    * Documentation for a particular Django release is frozen once the version
+* Documentation for a particular Django release is frozen once the version
   has been released officially. It remains a snapshot of the docs as of the
   moment of the release. We will make exceptions to this rule in
   the case of retroactive security updates or other such retroactive
@@ -232,7 +232,7 @@ We follow this policy:
   frozen document that says "These docs are frozen for Django version XXX"
   and links to the current version of that document.
 
-    * The `main documentation Web page`_ includes links to documentation for
+* The `main documentation Web page`_ includes links to documentation for
   all previous versions.
 
 .. _main documentation Web page: http://docs.djangoproject.com/en/dev/

docs/misc/api-stability.txt

@@ -12,15 +12,15 @@ What "stable" means
 
 In this context, stable means:
 
-   - All the public APIs -- everything documented in the linked documents below,
+- All the public APIs -- everything documented in the linked documents below,
   and all methods that don't begin with an underscore -- will not be moved or
   renamed without providing backwards-compatible aliases.
 
-   - If new features are added to these APIs -- which is quite possible --
+- If new features are added to these APIs -- which is quite possible --
   they will not break or change the meaning of existing methods. In other
   words, "stable" does not (necessarily) mean "complete."
 
-   - If, for some reason, an API declared stable must be removed or replaced, it
+- If, for some reason, an API declared stable must be removed or replaced, it
   will be declared deprecated but will remain in the API for at least two
   minor version releases. Warnings will be issued when the deprecated method
   is called.
@@ -28,7 +28,7 @@ In this context, stable means:
   See :ref:`official-releases` for more details on how Django's version
   numbering scheme works, and how features will be deprecated.
 
-   - We'll only break backwards compatibility of these APIs if a bug or
+- We'll only break backwards compatibility of these APIs if a bug or
   security hole makes it completely unavoidable.
 
 Stable APIs
@@ -38,58 +38,58 @@ In general, everything covered in the documentation -- with the exception of
 anything in the :doc:`internals area </internals/index>` is considered stable as
 of 1.0. This includes these APIs:
 
-    - :doc:`Authorization </topics/auth>`
+- :doc:`Authorization </topics/auth>`
 
-    - :doc:`Caching </topics/cache>`.
+- :doc:`Caching </topics/cache>`.
 
-    - :doc:`Model definition, managers, querying and transactions
+- :doc:`Model definition, managers, querying and transactions
   </topics/db/index>`
 
-    - :doc:`Sending email </topics/email>`.
+- :doc:`Sending email </topics/email>`.
 
-    - :doc:`File handling and storage </topics/files>`
+- :doc:`File handling and storage </topics/files>`
 
-    - :doc:`Forms </topics/forms/index>`
+- :doc:`Forms </topics/forms/index>`
 
-    - :doc:`HTTP request/response handling </topics/http/index>`, including file
+- :doc:`HTTP request/response handling </topics/http/index>`, including file
   uploads, middleware, sessions, URL resolution, view, and shortcut APIs.
 
-    - :doc:`Generic views </topics/http/generic-views>`.
+- :doc:`Generic views </topics/http/generic-views>`.
 
-    - :doc:`Internationalization </topics/i18n/index>`.
+- :doc:`Internationalization </topics/i18n/index>`.
 
-    - :doc:`Pagination </topics/pagination>`
+- :doc:`Pagination </topics/pagination>`
 
-    - :doc:`Serialization </topics/serialization>`
+- :doc:`Serialization </topics/serialization>`
 
-    - :doc:`Signals </topics/signals>`
+- :doc:`Signals </topics/signals>`
 
-    - :doc:`Templates </topics/templates>`, including the language, Python-level
+- :doc:`Templates </topics/templates>`, including the language, Python-level
   :doc:`template APIs </ref/templates/index>`, and :doc:`custom template tags
   and libraries </howto/custom-template-tags>`. We may add new template
   tags in the future and the names may inadvertently clash with
   external template tags. Before adding any such tags, we'll ensure that
   Django raises an error if it tries to load tags with duplicate names.
 
-    - :doc:`Testing </topics/testing>`
+- :doc:`Testing </topics/testing>`
 
-    - :doc:`django-admin utility </ref/django-admin>`.
+- :doc:`django-admin utility </ref/django-admin>`.
 
-    - :doc:`Built-in middleware </ref/middleware>`
+- :doc:`Built-in middleware </ref/middleware>`
 
-    - :doc:`Request/response objects </ref/request-response>`.
+- :doc:`Request/response objects </ref/request-response>`.
 
-    - :doc:`Settings </ref/settings>`. Note, though that while the :doc:`list of
+- :doc:`Settings </ref/settings>`. Note, though that while the :doc:`list of
   built-in settings </ref/settings>` can be considered complete we may -- and
   probably will -- add new settings in future versions. This is one of those
   places where "'stable' does not mean 'complete.'"
 
-    - :doc:`Built-in signals </ref/signals>`. Like settings, we'll probably add
+- :doc:`Built-in signals </ref/signals>`. Like settings, we'll probably add
   new signals in the future, but the existing ones won't break.
 
-    - :doc:`Unicode handling </ref/unicode>`.
+- :doc:`Unicode handling </ref/unicode>`.
 
-    - Everything covered by the :doc:`HOWTO guides </howto/index>`.
+- Everything covered by the :doc:`HOWTO guides </howto/index>`.
 
 ``django.utils``
 ----------------
@@ -97,15 +97,15 @@ of 1.0. This includes these APIs:
 Most of the modules in ``django.utils`` are designed for internal use. Only
 the following parts of :doc:`django.utils </ref/utils>` can be considered stable:
 
-    - ``django.utils.cache``
+- ``django.utils.cache``
-    - ``django.utils.datastructures.SortedDict`` -- only this single class; the
+- ``django.utils.datastructures.SortedDict`` -- only this single class; the
   rest of the module is for internal use.
-    - ``django.utils.encoding``
+- ``django.utils.encoding``
-    - ``django.utils.feedgenerator``
+- ``django.utils.feedgenerator``
-    - ``django.utils.http``
+- ``django.utils.http``
-    - ``django.utils.safestring``
+- ``django.utils.safestring``
-    - ``django.utils.translation``
+- ``django.utils.translation``
-    - ``django.utils.tzinfo``
+- ``django.utils.tzinfo``
 
 Exceptions
 ==========
@@ -142,11 +142,11 @@ APIs marked as internal
 
 Certain APIs are explicitly marked as "internal" in a couple of ways:
 
-    - Some documentation refers to internals and mentions them as such. If the
+- Some documentation refers to internals and mentions them as such. If the
   documentation says that something is internal, we reserve the right to
   change it.
 
-    - Functions, methods, and other objects prefixed by a leading underscore
+- Functions, methods, and other objects prefixed by a leading underscore
   (``_``). This is the standard Python way of indicating that something is
   private; if any method starts with a single ``_``, it's an internal API.
 
@@ -174,28 +174,28 @@ database -- including values that may no longer be valid.
 Therefore, Django has the following policy with respect to changes in
 local flavor:
 
-    * At the time of a Django release, the data and algorithms
+* At the time of a Django release, the data and algorithms
   contained in :mod:`django.contrib.localflavor` will, to the best
   of our ability, reflect the officially gazetted policies of the
   appropriate local government authority. If a province has been
   added, altered, or removed, that change will be reflected in
   Django's localflavor.
 
-    * These changes will *not* be backported to the previous stable
+* These changes will *not* be backported to the previous stable
   release. Upgrading a minor version of Django should not require
   any data migration or audits for UI changes; therefore, if you
   want to get the latest province list, you will either need to
   upgrade your Django install, or backport the province list you
   need.
 
-    * For one release, the affected localflavor module will raise a
+* For one release, the affected localflavor module will raise a
   ``RuntimeWarning`` when it is imported.
 
-    * The change will be announced in the release notes as a backwards
+* The change will be announced in the release notes as a backwards
   incompatible change requiring attention. The change will also be
   annotated in the documentation for the localflavor module.
 
-    * Where necessary and feasible, a migration script will be provided
+* Where necessary and feasible, a migration script will be provided
   to aid the migration process.
 
 For example, Django 1.2 contains an Indonesian localflavor. It has a

docs/misc/design-philosophies.txt

@@ -254,8 +254,8 @@ Don't invent a programming language
 
 The template system intentionally doesn't allow the following:
 
-    * Assignment to variables
+* Assignment to variables
-    * Advanced logic
+* Advanced logic
 
 The goal is not to invent a programming language. The goal is to offer just
 enough programming-esque functionality, such as branching and looping, that is

docs/ref/class-based-views.txt

@@ -41,11 +41,11 @@ usable generic views.
 For example, the :class:`~django.views.generic.base.detail.DetailView`
 is composed from:
 
-    * :class:`~django.db.views.generic.base.View`, which provides the
+* :class:`~django.db.views.generic.base.View`, which provides the
   basic class-based behavior
-    * :class:`~django.db.views.generic.detail.SingleObjectMixin`, which
+* :class:`~django.db.views.generic.detail.SingleObjectMixin`, which
   provides the utilities for retrieving and displaying a single object
-    * :class:`~django.db.views.generic.detail.SingleObjectTemplateResponseMixin`,
+* :class:`~django.db.views.generic.detail.SingleObjectTemplateResponseMixin`,
   which provides the tools for rendering a single object into a
   template-based response.
 

docs/ref/contrib/admin/actions.txt

@@ -73,9 +73,9 @@ First, we'll need to write a function that gets called when the action is
 trigged from the admin. Action functions are just regular functions that take
 three arguments:
 
-    * The current :class:`ModelAdmin`
+* The current :class:`ModelAdmin`
-    * An :class:`~django.http.HttpRequest` representing the current request,
+* An :class:`~django.http.HttpRequest` representing the current request,
-    * A :class:`~django.db.models.query.QuerySet` containing the set of
+* A :class:`~django.db.models.query.QuerySet` containing the set of
   objects selected by the user.
 
 Our publish-these-articles function won't need the :class:`ModelAdmin` or the

docs/ref/contrib/admin/admindocs.txt

@@ -22,15 +22,15 @@ Overview
 To activate the :mod:`~django.contrib.admindocs`, you will need to do
 the following:
 
-    * Add :mod:`django.contrib.admindocs` to your :setting:`INSTALLED_APPS`.
+* Add :mod:`django.contrib.admindocs` to your :setting:`INSTALLED_APPS`.
-    * Add ``(r'^admin/doc/', include('django.contrib.admindocs.urls'))`` to
+* Add ``(r'^admin/doc/', include('django.contrib.admindocs.urls'))`` to
   your :data:`urlpatterns`. Make sure it's included *before* the
   ``r'^admin/'`` entry, so that requests to ``/admin/doc/`` don't get
   handled by the latter entry.
-    * Install the docutils Python module (http://docutils.sf.net/).
+* Install the docutils Python module (http://docutils.sf.net/).
-    * **Optional:** Linking to templates requires the :setting:`ADMIN_FOR`
+* **Optional:** Linking to templates requires the :setting:`ADMIN_FOR`
   setting to be configured.
-    * **Optional:** Using the admindocs bookmarklets requires the
+* **Optional:** Using the admindocs bookmarklets requires the
   :mod:`XViewMiddleware<django.middleware.doc>` to be installed.
 
 Once those steps are complete, you can start browsing the documentation by
@@ -85,9 +85,9 @@ Each URL in your site has a separate entry in the ``admindocs`` page, and
 clicking on a given URL will show you the corresponding view. Helpful things
 you can document in your view function docstrings include:
 
-    * A short description of what the view does.
+* A short description of what the view does.
-    * The **context**, or a list of variables available in the view's template.
+* The **context**, or a list of variables available in the view's template.
-    * The name of the template or templates that are used for that view.
+* The name of the template or templates that are used for that view.
 
 For example::
 
@@ -141,15 +141,15 @@ Included Bookmarklets
 
 Several useful bookmarklets are available from the ``admindocs`` page:
 
-    Documentation for this page
+Documentation for this page
     Jumps you from any page to the documentation for the view that generates
     that page.
 
-    Show object ID
+Show object ID
     Shows the content-type and unique ID for pages that represent a single
     object.
 
-    Edit this object
+Edit this object
     Jumps to the admin page for pages that represent a single object.
 
 Using these bookmarklets requires that you are either logged into the

docs/ref/contrib/comments/custom.txt

@@ -41,13 +41,13 @@ comment model has no field for that title.
 
 To make this kind of customization, we'll need to do three things:
 
-    #. Create a custom comment :class:`~django.db.models.Model` that adds on the
+#. Create a custom comment :class:`~django.db.models.Model` that adds on the
    "title" field.
 
-    #. Create a custom comment :class:`~django.forms.Form` that also adds this
+#. Create a custom comment :class:`~django.forms.Form` that also adds this
    "title" field.
 
-    #. Inform Django of these objects by defining a few functions in a
+#. Inform Django of these objects by defining a few functions in a
    custom :setting:`COMMENTS_APP`.
 
 So, carrying on the example above, we're dealing with a typical app structure in

docs/ref/contrib/comments/index.txt

@@ -22,12 +22,12 @@ Quick start guide
 
 To get started using the ``comments`` app, follow these steps:
 
-    #. Install the comments framework by adding ``'django.contrib.comments'`` to
+#. Install the comments framework by adding ``'django.contrib.comments'`` to
    :setting:`INSTALLED_APPS`.
 
-    #. Run ``manage.py syncdb`` so that Django will create the comment tables.
+#. Run ``manage.py syncdb`` so that Django will create the comment tables.
 
-    #. Add the comment app's URLs to your project's ``urls.py``:
+#. Add the comment app's URLs to your project's ``urls.py``:
 
    .. code-block:: python
 
@@ -37,7 +37,7 @@ To get started using the ``comments`` app, follow these steps:
             ...
         )
 
-    #. Use the `comment template tags`_ below to embed comments in your
+#. Use the `comment template tags`_ below to embed comments in your
    templates.
 
 You might also want to examine :doc:`/ref/contrib/comments/settings`.
@@ -62,7 +62,7 @@ Django's comments are all "attached" to some parent object. This can be any
 instance of a Django model. Each of the tags below gives you a couple of
 different ways you can specify which object to attach to:
 
-    #. Refer to the object directly -- the more common method. Most of the
+#. Refer to the object directly -- the more common method. Most of the
    time, you'll have some object in the template's context you want
    to attach the comment to; you can simply use that object.
 
@@ -71,7 +71,7 @@ different ways you can specify which object to attach to:
 
         {% get_comment_count for entry as comment_count %}.
 
-    #. Refer to the object by content-type and object id. You'd use this method
+#. Refer to the object by content-type and object id. You'd use this method
    if you, for some reason, don't actually have direct access to the object.
 
    Following the above example, if you knew the object ID was ``14`` but
@@ -262,7 +262,7 @@ Notes on the comment form
 The form used by the comment system has a few important anti-spam attributes you
 should know about:
 
-    * It contains a number of hidden fields that contain timestamps, information
+* It contains a number of hidden fields that contain timestamps, information
   about the object the comment should be attached to, and a "security hash"
   used to validate this information. If someone tampers with this data --
   something comment spammers will try -- the comment submission will fail.
@@ -270,11 +270,11 @@ should know about:
   If you're rendering a custom comment form, you'll need to make sure to
   pass these values through unchanged.
 
-    * The timestamp is used to ensure that "reply attacks" can't continue very
+* The timestamp is used to ensure that "reply attacks" can't continue very
   long. Users who wait too long between requesting the form and posting a
   comment will have their submissions refused.
 
-    * The comment form includes a "honeypot_" field. It's a trap: if any data is
+* The comment form includes a "honeypot_" field. It's a trap: if any data is
   entered in that field, the comment will be considered spam (spammers often
   automatically fill in all fields in an attempt to make valid submissions).
 

docs/ref/contrib/comments/signals.txt

@@ -28,15 +28,15 @@ This signal is sent at more or less the same time (just before, actually) as the
 
 Arguments sent with this signal:
 
-    ``sender``
+``sender``
     The comment model.
 
-    ``comment``
+``comment``
     The comment instance about to be posted. Note that it won't have been
     saved into the database yet, so it won't have a primary key, and any
     relations might not work correctly yet.
 
-    ``request``
+``request``
     The :class:`~django.http.HttpRequest` that posted the comment.
 
 comment_was_posted
@@ -49,15 +49,15 @@ Sent just after the comment is saved.
 
 Arguments sent with this signal:
 
-    ``sender``
+``sender``
     The comment model.
 
-    ``comment``
+``comment``
     The comment instance that was posted. Note that it will have already
     been saved, so if you modify it you'll need to call
     :meth:`~django.db.models.Model.save` again.
 
-    ``request``
+``request``
     The :class:`~django.http.HttpRequest` that posted the comment.
 
 comment_was_flagged
@@ -72,20 +72,20 @@ comment, or some other custom user flag.
 
 Arguments sent with this signal:
 
-    ``sender``
+``sender``
     The comment model.
 
-    ``comment``
+``comment``
     The comment instance that was posted. Note that it will have already
     been saved, so if you modify it you'll need to call
     :meth:`~django.db.models.Model.save` again.
 
-    ``flag``
+``flag``
     The :class:`~django.contrib.comments.models.CommentFlag` that's been
     attached to the comment.
 
-    ``created``
+``created``
     ``True`` if this is a new flag; ``False`` if it's a duplicate flag.
 
-    ``request``
+``request``
     The :class:`~django.http.HttpRequest` that posted the comment.

docs/ref/contrib/comments/upgrade.txt

@@ -7,24 +7,24 @@ new comment system; this guide explains how.
 
 The main changes from the old system are:
 
-    * This new system is documented.
+* This new system is documented.
 
-    * It uses modern Django features like :doc:`forms </topics/forms/index>` and
+* It uses modern Django features like :doc:`forms </topics/forms/index>` and
   :doc:`modelforms </topics/forms/modelforms>`.
 
-    * It has a single ``Comment`` model instead of separate ``FreeComment`` and
+* It has a single ``Comment`` model instead of separate ``FreeComment`` and
   ``Comment`` models.
 
-    * Comments have "email" and "URL" fields.
+* Comments have "email" and "URL" fields.
 
-    * No ratings, photos and karma. This should only effect World Online.
+* No ratings, photos and karma. This should only effect World Online.
 
-    * The ``{% comment_form %}`` tag no longer exists. Instead, there's now two
+* The ``{% comment_form %}`` tag no longer exists. Instead, there's now two
   functions: ``{% get_comment_form %}``, which returns a form for posting a
   new comment, and ``{% render_comment_form %}``, which renders said form
   using the ``comments/form.html`` template.
 
-    * The way comments are include in your URLconf have changed; you'll need to
+* The way comments are include in your URLconf have changed; you'll need to
   replace::
 
         (r'^comments/', include('django.contrib.comments.urls.comments')),

docs/ref/contrib/contenttypes.txt

@@ -45,13 +45,13 @@ but if you've removed it or if you manually set up your
 It's generally a good idea to have the contenttypes framework
 installed; several of Django's other bundled applications require it:
 
-    * The admin application uses it to log the history of each object
+* The admin application uses it to log the history of each object
   added or changed through the admin interface.
 
-    * Django's :mod:`authentication framework <django.contrib.auth>` uses it
+* Django's :mod:`authentication framework <django.contrib.auth>` uses it
   to tie user permissions to specific models.
 
-    * Django's comments system (:mod:`django.contrib.comments`) uses it to
+* Django's comments system (:mod:`django.contrib.comments`) uses it to
   "attach" comments to any installed model.
 
 .. currentmodule:: django.contrib.contenttypes.models
@@ -92,14 +92,14 @@ your database. Along with it a new instance of
 :class:`~django.contrib.contenttypes.models.ContentType` will be
 created with the following values:
 
-    * :attr:`~django.contrib.contenttypes.models.ContentType.app_label`
+* :attr:`~django.contrib.contenttypes.models.ContentType.app_label`
   will be set to ``'sites'`` (the last part of the Python
   path "django.contrib.sites").
 
-    * :attr:`~django.contrib.contenttypes.models.ContentType.model`
+* :attr:`~django.contrib.contenttypes.models.ContentType.model`
   will be set to ``'site'``.
 
-    * :attr:`~django.contrib.contenttypes.models.ContentType.name`
+* :attr:`~django.contrib.contenttypes.models.ContentType.name`
   will be set to ``'site'``.
 
 .. _the verbose_name attribute: ../model-api/#verbose_name
@@ -148,14 +148,14 @@ Together,
 and :meth:`~django.contrib.contenttypes.models.ContentType.model_class` enable
 two extremely important use cases:
 
-    1. Using these methods, you can write high-level generic code that
+1. Using these methods, you can write high-level generic code that
    performs queries on any installed model -- instead of importing and
    using a single specific model class, you can pass an ``app_label`` and
    ``model`` into a
    :class:`~django.contrib.contenttypes.models.ContentType` lookup at
    runtime, and then work with the model class or retrieve objects from it.
 
-    2. You can relate another model to
+2. You can relate another model to
    :class:`~django.contrib.contenttypes.models.ContentType` as a way of
    tying instances of it to particular model classes, and use these methods
    to get access to those model classes.

docs/ref/contrib/csrf.txt

@@ -28,7 +28,7 @@ How to use it
 
 To enable CSRF protection for your views, follow these steps:
 
-    1. Add the middleware
+1. Add the middleware
    ``'django.middleware.csrf.CsrfViewMiddleware'`` to your list of
    middleware classes, :setting:`MIDDLEWARE_CLASSES`.  (It should come
    before any view middleware that assume that CSRF attacks have
@@ -38,7 +38,7 @@ To enable CSRF protection for 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
+2. 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.::
 
        <form action="." method="post">{% csrf_token %}
@@ -46,7 +46,7 @@ To enable CSRF protection for 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 the
+3. In the corresponding view functions, ensure that the
    ``'django.core.context_processors.csrf'`` context processor is
    being used. Usually, this can be done in one of two ways:
 

docs/ref/contrib/databrowse.txt

@@ -17,7 +17,7 @@ introspecting your models.
 How to use Databrowse
 =====================
 
-    1. Point Django at the default Databrowse templates. There are two ways to
+1. Point Django at the default Databrowse templates. There are two ways to
    do this:
 
    * Add ``'django.contrib.databrowse'`` to your :setting:`INSTALLED_APPS`
@@ -30,7 +30,7 @@ How to use Databrowse
      :file:`django/contrib/databrowse/templates` directory, and add that
      directory to your :setting:`TEMPLATE_DIRS` setting.
 
-    2. Register a number of models with the Databrowse site::
+2. Register a number of models with the Databrowse site::
 
        from django.contrib import databrowse
        from myapp.models import SomeModel, SomeOtherModel
@@ -44,7 +44,7 @@ How to use Databrowse
    point. A good place for it is in your :doc:`URLconf file
    </topics/http/urls>` (``urls.py``).
 
-    3. Change your URLconf to import the :mod:`~django.contrib.databrowse` module::
+3. Change your URLconf to import the :mod:`~django.contrib.databrowse` module::
 
        from django.contrib import databrowse
 
@@ -55,7 +55,7 @@ How to use Databrowse
    The prefix doesn't matter -- you can use ``databrowse/`` or ``db/`` or
    whatever you'd like.
 
-    4. Run the Django server and visit ``/databrowse/`` in your browser.
+4. Run the Django server and visit ``/databrowse/`` in your browser.
 
 Requiring user login
 ====================

docs/ref/contrib/flatpages.txt

@@ -22,15 +22,15 @@ content in a custom template.
 
 Here are some examples of flatpages on Django-powered sites:
 
-    * http://www.lawrence.com/about/contact/
+* http://www.lawrence.com/about/contact/
-    * http://www2.ljworld.com/site/rules/
+* http://www2.ljworld.com/site/rules/
 
 Installation
 ============
 
 To install the flatpages app, follow these steps:
 
-    1. Install the :mod:`sites framework <django.contrib.sites>` by adding
+1. Install the :mod:`sites framework <django.contrib.sites>` by adding
    ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS` setting,
    if it's not already in there.
 
@@ -39,13 +39,13 @@ To install the flatpages app, follow these steps:
    ``SITE_ID = 1``, but if you're using the sites framework to manage
    multiple sites, it could be the ID of a different site.
 
-    2. Add ``'django.contrib.flatpages'`` to your :setting:`INSTALLED_APPS`
+2. Add ``'django.contrib.flatpages'`` to your :setting:`INSTALLED_APPS`
    setting.
 
-    3. Add ``'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware'``
+3. Add ``'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware'``
    to your :setting:`MIDDLEWARE_CLASSES` setting.
 
-    4. Run the command :djadmin:`manage.py syncdb <syncdb>`.
+4. Run the command :djadmin:`manage.py syncdb <syncdb>`.
 
 .. currentmodule:: django.contrib.flatpages.middleware
 

docs/ref/contrib/formtools/form-preview.txt

@@ -20,11 +20,11 @@ Overview
 Given a :class:`django.forms.Form` subclass that you define, this
 application takes care of the following workflow:
 
-   1. Displays the form as HTML on a Web page.
+1. Displays the form as HTML on a Web page.
-   2. Validates the form data when it's submitted via POST.
+2. Validates the form data when it's submitted via POST.
    a. If it's valid, displays a preview page.
    b. If it's not valid, redisplays the form with error messages.
-   3. When the "confirmation" form is submitted from the preview page, calls
+3. When the "confirmation" form is submitted from the preview page, calls
    a hook that you define -- a
    :meth:`~django.contrib.formtools.preview.FormPreview.done()` method that gets
    passed the valid data.
@@ -36,7 +36,7 @@ on the preview page, the form submission will fail the hash-comparison test.
 How to use ``FormPreview``
 ==========================
 
-    1. Point Django at the default FormPreview templates. There are two ways to
+1. Point Django at the default FormPreview templates. There are two ways to
    do this:
 
    * Add ``'django.contrib.formtools'`` to your
@@ -50,7 +50,7 @@ How to use ``FormPreview``
      :file:`django/contrib/formtools/templates` directory, and add that
      directory to your :setting:`TEMPLATE_DIRS` setting.
 
-    2. Create a :class:`~django.contrib.formtools.preview.FormPreview` subclass that
+2. Create a :class:`~django.contrib.formtools.preview.FormPreview` subclass that
    overrides the :meth:`~django.contrib.formtools.preview.FormPreview.done()`
    method::
 
@@ -69,7 +69,7 @@ How to use ``FormPreview``
    It should return an :class:`~django.http.HttpResponseRedirect` that
    is the end result of the form being submitted.
 
-    3. Change your URLconf to point to an instance of your
+3. Change your URLconf to point to an instance of your
    :class:`~django.contrib.formtools.preview.FormPreview` subclass::
 
        from myapp.preview import SomeModelFormPreview
@@ -82,7 +82,7 @@ How to use ``FormPreview``
 
    where ``SomeModelForm`` is a Form or ModelForm class for the model.
 
-    4. Run the Django server and visit :file:`/post/` in your browser.
+4. Run the Django server and visit :file:`/post/` in your browser.
 
 ``FormPreview`` classes
 =======================

docs/ref/contrib/formtools/form-wizard.txt

@@ -24,13 +24,13 @@ How it works
 
 Here's the basic workflow for how a user would use a wizard:
 
-    1. The user visits the first page of the wizard, fills in the form and
+1. The user visits the first page of the wizard, fills in the form and
    submits it.
-    2. The server validates the data. If it's invalid, the form is displayed
+2. The server validates the data. If it's invalid, the form is displayed
    again, with error messages. If it's valid, the server saves the current
    state of the wizard in the backend and redirects to the next step.
-    3. Step 1 and 2 repeat, for every subsequent form in the wizard.
+3. Step 1 and 2 repeat, for every subsequent form in the wizard.
-    4. Once the user has submitted all the forms and all the data has been
+4. Once the user has submitted all the forms and all the data has been
    validated, the wizard processes the data -- saving it to the database,
    sending an email, or whatever the application needs to do.
 
@@ -40,21 +40,21 @@ Usage
 This application handles as much machinery for you as possible. Generally,
 you just have to do these things:
 
-    1. Define a number of :class:`~django.forms.Form` classes -- one per
+1. Define a number of :class:`~django.forms.Form` classes -- one per
    wizard page.
 
-    2. Create a :class:`WizardView` subclass that specifies what to do once
+2. Create a :class:`WizardView` subclass that specifies what to do once
    all of your forms have been submitted and validated. This also lets
    you override some of the wizard's behavior.
 
-    3. Create some templates that render the forms. You can define a single,
+3. Create some templates that render the forms. You can define a single,
    generic template to handle every one of the forms, or you can define a
    specific template for each form.
 
-    4. Add ``django.contrib.formtools`` to your
+4. Add ``django.contrib.formtools`` to your
    :setting:`INSTALLED_APPS` list in your settings file.
 
-    5. Point your URLconf at your :class:`WizardView` :meth:`~WizardView.as_view` method.
+5. Point your URLconf at your :class:`WizardView` :meth:`~WizardView.as_view` method.
 
 Defining ``Form`` classes
 -------------------------
@@ -160,10 +160,10 @@ latter one allows you to use a different template for each form.
 This template expects a ``wizard`` object that has various items attached to
 it:
 
-    * ``form`` -- The :class:`~django.forms.Form` instance for the current
+* ``form`` -- The :class:`~django.forms.Form` instance for the current
   step (either empty or with errors).
 
-    * ``steps`` -- A helper object to access the various steps related data:
+* ``steps`` -- A helper object to access the various steps related data:
 
   * ``step0`` -- The current step (zero-based).
   * ``step1`` -- The current step (one-based).
@@ -582,8 +582,8 @@ Below you will see an example of a contact wizard with two steps, step 1 with
 Additionally you have to pass two more arguments to the
 :meth:`~WizardView.as_view` method:
 
-   * ``url_name`` -- the name of the url (as provided in the urls.py)
+* ``url_name`` -- the name of the url (as provided in the urls.py)
-   * ``done_step_name`` -- the name in the url for the done step
+* ``done_step_name`` -- the name in the url for the done step
 
 Example code for the changed ``urls.py`` file::
 

docs/ref/contrib/humanize.txt

@@ -23,9 +23,9 @@ number. This follows Associated Press style.
 
 Examples:
 
-    * ``1`` becomes ``one``.
+* ``1`` becomes ``one``.
-    * ``2`` becomes ``two``.
+* ``2`` becomes ``two``.
-    * ``10`` becomes ``10``.
+* ``10`` becomes ``10``.
 
 You can pass in either an integer or a string representation of an integer.
 
@@ -38,16 +38,16 @@ Converts an integer to a string containing commas every three digits.
 
 Examples:
 
-    * ``4500`` becomes ``4,500``.
+* ``4500`` becomes ``4,500``.
-    * ``45000`` becomes ``45,000``.
+* ``45000`` becomes ``45,000``.
-    * ``450000`` becomes ``450,000``.
+* ``450000`` becomes ``450,000``.
-    * ``4500000`` becomes ``4,500,000``.
+* ``4500000`` becomes ``4,500,000``.
 
 :ref:`Format localization <format-localization>` will be respected if enabled,
 e.g. with the ``'de'`` language:
 
-    * ``45000`` becomes ``'45.000'``.
+* ``45000`` becomes ``'45.000'``.
-    * ``450000`` becomes ``'450.000'``.
+* ``450000`` becomes ``'450.000'``.
 
 You can pass in either an integer or a string representation of an integer.
 
@@ -61,18 +61,18 @@ numbers over 1 million.
 
 Examples:
 
-    * ``1000000`` becomes ``1.0 million``.
+* ``1000000`` becomes ``1.0 million``.
-    * ``1200000`` becomes ``1.2 million``.
+* ``1200000`` becomes ``1.2 million``.
-    * ``1200000000`` becomes ``1.2 billion``.
+* ``1200000000`` becomes ``1.2 billion``.
 
 Values up to 10^100 (Googol) are supported.
 
 :ref:`Format localization <format-localization>` will be respected if enabled,
 e.g. with the ``'de'`` language:
 
-    * ``1000000`` becomes ``'1,0 Million'``.
+* ``1000000`` becomes ``'1,0 Million'``.
-    * ``1200000`` becomes ``'1,2 Million'``.
+* ``1200000`` becomes ``'1,2 Million'``.
-    * ``1200000000`` becomes ``'1,2 Milliarden'``.
+* ``1200000000`` becomes ``'1,2 Milliarden'``.
 
 You can pass in either an integer or a string representation of an integer.
 
@@ -89,10 +89,10 @@ the passed in format string.
 
 Examples (when 'today' is 17 Feb 2007):
 
-    * ``16 Feb 2007`` becomes ``yesterday``.
+* ``16 Feb 2007`` becomes ``yesterday``.
-    * ``17 Feb 2007`` becomes ``today``.
+* ``17 Feb 2007`` becomes ``today``.
-    * ``18 Feb 2007`` becomes ``tomorrow``.
+* ``18 Feb 2007`` becomes ``tomorrow``.
-    * Any other day is formatted according to given argument or the
+* Any other day is formatted according to given argument or the
   :setting:`DATE_FORMAT` setting if no argument is given.
 
 .. templatefilter:: naturaltime
@@ -109,19 +109,19 @@ the return value will automatically use an appropriate phrase.
 
 Examples (when 'now' is 17 Feb 2007 16:30:00):
 
-    * ``17 Feb 2007 16:30:00`` becomes ``now``.
+* ``17 Feb 2007 16:30:00`` becomes ``now``.
-    * ``17 Feb 2007 16:29:31`` becomes ``29 seconds ago``.
+* ``17 Feb 2007 16:29:31`` becomes ``29 seconds ago``.
-    * ``17 Feb 2007 16:29:00`` becomes ``a minute ago``.
+* ``17 Feb 2007 16:29:00`` becomes ``a minute ago``.
-    * ``17 Feb 2007 16:25:35`` becomes ``4 minutes ago``.
+* ``17 Feb 2007 16:25:35`` becomes ``4 minutes ago``.
-    * ``17 Feb 2007 15:30:29`` becomes ``an hour ago``.
+* ``17 Feb 2007 15:30:29`` becomes ``an hour ago``.
-    * ``17 Feb 2007 13:31:29`` becomes ``2 hours ago``.
+* ``17 Feb 2007 13:31:29`` becomes ``2 hours ago``.
-    * ``16 Feb 2007 13:31:29`` becomes ``1 day ago``.
+* ``16 Feb 2007 13:31:29`` becomes ``1 day ago``.
-    * ``17 Feb 2007 16:30:30`` becomes ``29 seconds from now``.
+* ``17 Feb 2007 16:30:30`` becomes ``29 seconds from now``.
-    * ``17 Feb 2007 16:31:00`` becomes ``a minute from now``.
+* ``17 Feb 2007 16:31:00`` becomes ``a minute from now``.
-    * ``17 Feb 2007 16:34:35`` becomes ``4 minutes from now``.
+* ``17 Feb 2007 16:34:35`` becomes ``4 minutes from now``.
-    * ``17 Feb 2007 16:30:29`` becomes ``an hour from now``.
+* ``17 Feb 2007 16:30:29`` becomes ``an hour from now``.
-    * ``17 Feb 2007 18:31:29`` becomes ``2 hours from now``.
+* ``17 Feb 2007 18:31:29`` becomes ``2 hours from now``.
-    * ``18 Feb 2007 16:31:29`` becomes ``1 day from now``.
+* ``18 Feb 2007 16:31:29`` becomes ``1 day from now``.
 
 .. templatefilter:: ordinal
 
@@ -132,8 +132,8 @@ Converts an integer to its ordinal as a string.
 
 Examples:
 
-    * ``1`` becomes ``1st``.
+* ``1`` becomes ``1st``.
-    * ``2`` becomes ``2nd``.
+* ``2`` becomes ``2nd``.
-    * ``3`` becomes ``3rd``.
+* ``3`` becomes ``3rd``.
 
 You can pass in either an integer or a string representation of an integer.

docs/ref/contrib/markup.txt

@@ -8,9 +8,9 @@ django.contrib.markup
 Django provides template filters that implement the following markup
 languages:
 
-    * ``textile`` -- implements `Textile`_ -- requires `PyTextile`_
+* ``textile`` -- implements `Textile`_ -- requires `PyTextile`_
-    * ``markdown`` -- implements `Markdown`_ -- requires `Python-markdown`_
+* ``markdown`` -- implements `Markdown`_ -- requires `Python-markdown`_
-    * ``restructuredtext`` -- implements `reST (reStructured Text)`_
+* ``restructuredtext`` -- implements `reST (reStructured Text)`_
   -- requires `doc-utils`_
 
 In each case, the filter expects formatted markup as a string and

docs/ref/contrib/messages.txt

@@ -23,7 +23,7 @@ class and corresponding :doc:`context processor </ref/templates/api>`.
 
 To enable message functionality, do the following:
 
-    * Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
+* Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
   it contains ``'django.contrib.messages.middleware.MessageMiddleware'``.
 
   If you are using a :ref:`storage backend <message-storage-backends>` that
@@ -32,10 +32,10 @@ To enable message functionality, do the following:
   enabled and appear before ``MessageMiddleware`` in your
   :setting:`MIDDLEWARE_CLASSES`.
 
-    * Edit the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting and make sure
+* Edit the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting and make sure
   it contains ``'django.contrib.messages.context_processors.messages'``.
 
-    * Add ``'django.contrib.messages'`` to your :setting:`INSTALLED_APPS`
+* Add ``'django.contrib.messages'`` to your :setting:`INSTALLED_APPS`
   setting
 
 The default ``settings.py`` created by ``django-admin.py startproject`` has
@@ -349,9 +349,9 @@ Default: ``'django.contrib.messages.storage.user_messages.FallbackStorage'``
 
 Controls where Django stores message data. Valid values are:
 
-    * ``'django.contrib.messages.storage.fallback.FallbackStorage'``
+* ``'django.contrib.messages.storage.fallback.FallbackStorage'``
-    * ``'django.contrib.messages.storage.session.SessionStorage'``
+* ``'django.contrib.messages.storage.session.SessionStorage'``
-    * ``'django.contrib.messages.storage.cookie.CookieStorage'``
+* ``'django.contrib.messages.storage.cookie.CookieStorage'``
 
 See `Storage backends`_ for more details.
 

docs/ref/contrib/redirects.txt

@@ -13,11 +13,11 @@ Installation
 
 To install the redirects app, follow these steps:
 
-    1. Add ``'django.contrib.redirects'`` to your :setting:`INSTALLED_APPS`
+1. Add ``'django.contrib.redirects'`` to your :setting:`INSTALLED_APPS`
    setting.
-    2. Add ``'django.contrib.redirects.middleware.RedirectFallbackMiddleware'``
+2. Add ``'django.contrib.redirects.middleware.RedirectFallbackMiddleware'``
    to your :setting:`MIDDLEWARE_CLASSES` setting.
-    3. Run the command :djadmin:`manage.py syncdb <syncdb>`.
+3. Run the command :djadmin:`manage.py syncdb <syncdb>`.
 
 How it works
 ============
@@ -31,11 +31,11 @@ for the requested URL as a last resort. Specifically, it checks for a redirect
 with the given ``old_path`` with a site ID that corresponds to the
 :setting:`SITE_ID` setting.
 
-    * If it finds a match, and ``new_path`` is not empty, it redirects to
+* If it finds a match, and ``new_path`` is not empty, it redirects to
   ``new_path``.
-    * If it finds a match, and ``new_path`` is empty, it sends a 410 ("Gone")
+* If it finds a match, and ``new_path`` is empty, it sends a 410 ("Gone")
   HTTP header and empty (content-less) response.
-    * If it doesn't find a match, the request continues to be processed as
+* If it doesn't find a match, the request continues to be processed as
   usual.
 
 The middleware only gets activated for 404s -- not for 500s or responses of any

docs/ref/contrib/sitemaps.txt

@@ -31,14 +31,14 @@ Installation
 
 To install the sitemap app, follow these steps:
 
-    1. Add ``'django.contrib.sitemaps'`` to your :setting:`INSTALLED_APPS`
+1. Add ``'django.contrib.sitemaps'`` to your :setting:`INSTALLED_APPS`
    setting.
 
-    2. Make sure ``'django.template.loaders.app_directories.Loader'``
+2. Make sure ``'django.template.loaders.app_directories.Loader'``
    is in your :setting:`TEMPLATE_LOADERS` setting. 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
+3. Make sure you've installed the
    :mod:`sites framework <django.contrib.sites>`.
 
 (Note: The sitemap application doesn't install any database tables. The only
@@ -109,17 +109,17 @@ your sitemap class might look::
 
 Note:
 
-    * :attr:`~Sitemap.changefreq` and :attr:`~Sitemap.priority` are class
+* :attr:`~Sitemap.changefreq` and :attr:`~Sitemap.priority` are class
   attributes corresponding to ``<changefreq>`` and ``<priority>`` elements,
   respectively. They can be made callable as functions, as
   :attr:`~Sitemap.lastmod` was in the example.
-    * :attr:`~Sitemap.items()` is simply a method that returns a list of
+* :attr:`~Sitemap.items()` is simply a method that returns a list of
   objects. The objects returned will get passed to any callable methods
   corresponding to a sitemap property (:attr:`~Sitemap.location`,
   :attr:`~Sitemap.lastmod`, :attr:`~Sitemap.changefreq`, and
   :attr:`~Sitemap.priority`).
-    * :attr:`~Sitemap.lastmod` should return a Python ``datetime`` object.
+* :attr:`~Sitemap.lastmod` should return a Python ``datetime`` object.
-    * There is no :attr:`~Sitemap.location` method in this example, but you
+* There is no :attr:`~Sitemap.location` method in this example, but you
   can provide it in order to specify the URL for your object. By default,
   :attr:`~Sitemap.location()` calls ``get_absolute_url()`` on each object
   and returns the result.
@@ -272,9 +272,9 @@ The sitemap framework also has the ability to create a sitemap index that
 references individual sitemap files, one per each section defined in your
 :data:`sitemaps` dictionary. The only differences in usage are:
 
-    * You use two views in your URLconf: :func:`django.contrib.sitemaps.views.index`
+* You use two views in your URLconf: :func:`django.contrib.sitemaps.views.index`
   and :func:`django.contrib.sitemaps.views.sitemap`.
-    * The :func:`django.contrib.sitemaps.views.sitemap` view should take a
+* The :func:`django.contrib.sitemaps.views.sitemap` view should take a
   :data:`section` keyword argument.
 
 Here's what the relevant URLconf lines would look like for the example above::
@@ -341,11 +341,11 @@ The variable :data:`urlset` is a list of URLs that should appear in the
 sitemap. Each URL exposes attributes as defined in the
 :class:`~django.contrib.sitemaps.Sitemap` class:
 
-    - ``changefreq``
+- ``changefreq``
-    - ``item``
+- ``item``
-    - ``lastmod``
+- ``lastmod``
-    - ``location``
+- ``location``
-    - ``priority``
+- ``priority``
 
 .. versionadded:: 1.4
 

docs/ref/contrib/sites.txt

@@ -70,13 +70,13 @@ that's represented by a :class:`~django.db.models.ManyToManyField` in the
 
 This accomplishes several things quite nicely:
 
-    * It lets the site producers edit all content -- on both sites -- in a
+* It lets the site producers edit all content -- on both sites -- in a
   single interface (the Django admin).
 
-    * It means the same story doesn't have to be published twice in the
+* It means the same story doesn't have to be published twice in the
   database; it only has a single record in the database.
 
-    * It lets the site developers use the same Django view code for both sites.
+* It lets the site developers use the same Django view code for both sites.
   The view code that displays a given story just checks to make sure the
   requested story is on the current site. It looks something like this::
 

docs/ref/contrib/staticfiles.txt

@@ -385,18 +385,18 @@ There are a few other helpers outside of the
 :mod:`staticfiles <django.contrib.staticfiles>` app to work with static
 files:
 
-    - The :func:`django.core.context_processors.static` context processor
+- The :func:`django.core.context_processors.static` context processor
   which adds :setting:`STATIC_URL` to every template context rendered
   with :class:`~django.template.RequestContext` contexts.
 
-    - The builtin template tag :ttag:`static` which takes a path and
+- The builtin template tag :ttag:`static` which takes a path and
   urljoins it with the static prefix :setting:`STATIC_URL`.
 
-    - The builtin template tag :ttag:`get_static_prefix` which populates a
+- The builtin template tag :ttag:`get_static_prefix` which populates a
   template variable with the static prefix :setting:`STATIC_URL` to be
   used as a variable or directly.
 
-    - The similar template tag :ttag:`get_media_prefix` which works like
+- The similar template tag :ttag:`get_media_prefix` which works like
   :ttag:`get_static_prefix` but uses :setting:`MEDIA_URL`.
 
 .. _staticfiles-development-view:

docs/ref/contrib/syndication.txt

@@ -113,7 +113,7 @@ One thing is left to do. In an RSS feed, each ``<item>`` has a ``<title>``,
 ``<link>`` and ``<description>``. We need to tell the framework what data to put
 into those elements.
 
-    * For the contents of ``<title>`` and ``<description>``, Django tries
+* For the contents of ``<title>`` and ``<description>``, Django tries
   calling the methods ``item_title()`` and ``item_description()`` on
   the :class:`~django.contrib.syndication.views.Feed` class. They are passed
   a single parameter, ``item``, which is the object itself. These are
@@ -140,7 +140,7 @@ into those elements.
 
   See `a complex example`_ below that uses a description template.
 
-    * To specify the contents of ``<link>``, you have two options. For each item
+* To specify the contents of ``<link>``, you have two options. For each item
   in ``items()``, Django first tries calling the
   ``item_link()`` method on the
   :class:`~django.contrib.syndication.views.Feed` class. In a similar way to
@@ -170,8 +170,8 @@ items based on information in the feed's URL.
 
 On chicagocrime.org, the police-beat feeds are accessible via URLs like this:
 
-    * :file:`/beats/613/rss/` -- Returns recent crimes for beat 613.
+* :file:`/beats/613/rss/` -- Returns recent crimes for beat 613.
-    * :file:`/beats/1424/rss/` -- Returns recent crimes for beat 1424.
+* :file:`/beats/1424/rss/` -- Returns recent crimes for beat 1424.
 
 These can be matched with a :doc:`URLconf </topics/http/urls>` line such as::
 
@@ -213,12 +213,12 @@ illustrates that they can be either strings *or* methods. For each of
 ``title``, ``link`` and ``description``, Django follows this
 algorithm:
 
-    * First, it tries to call a method, passing the ``obj`` argument, where
+* First, it tries to call a method, passing the ``obj`` argument, where
   ``obj`` is the object returned by ``get_object()``.
 
-    * Failing that, it tries to call a method with no arguments.
+* Failing that, it tries to call a method with no arguments.
 
-    * Failing that, it uses the class attribute.
+* Failing that, it uses the class attribute.
 
 Also note that ``items()`` also follows the same algorithm -- first, it
 tries ``items(obj)``, then ``items()``, then finally an ``items``
@@ -252,9 +252,9 @@ Note that you set ``feed_type`` to a class object, not an instance.
 
 Currently available feed types are:
 
-    * :class:`django.utils.feedgenerator.Rss201rev2Feed` (RSS 2.01. Default.)
+* :class:`django.utils.feedgenerator.Rss201rev2Feed` (RSS 2.01. Default.)
-    * :class:`django.utils.feedgenerator.RssUserland091Feed` (RSS 0.91.)
+* :class:`django.utils.feedgenerator.RssUserland091Feed` (RSS 0.91.)
-    * :class:`django.utils.feedgenerator.Atom1Feed` (Atom 1.0.)
+* :class:`django.utils.feedgenerator.Atom1Feed` (Atom 1.0.)
 
 Enclosures
 ----------
@@ -788,13 +788,13 @@ also create custom feed generator subclasses for use with the ``feed_type``
 
 The :mod:`~django.utils.feedgenerator` module contains a base class:
 
-  * :class:`django.utils.feedgenerator.SyndicationFeed`
+* :class:`django.utils.feedgenerator.SyndicationFeed`
 
 and several subclasses:
 
-  * :class:`django.utils.feedgenerator.RssUserland091Feed`
+* :class:`django.utils.feedgenerator.RssUserland091Feed`
-  * :class:`django.utils.feedgenerator.Rss201rev2Feed`
+* :class:`django.utils.feedgenerator.Rss201rev2Feed`
-  * :class:`django.utils.feedgenerator.Atom1Feed`
+* :class:`django.utils.feedgenerator.Atom1Feed`
 
 Each of these three classes knows how to render a certain type of feed as XML.
 They share this interface:

docs/ref/contrib/webdesign.txt

@@ -36,21 +36,21 @@ Usage::
 The ``{% lorem %}`` tag can be used with zero, one, two or three arguments.
 The arguments are:
 
-    ===========  =============================================================
+===========  =============================================================
-    Argument     Description
+Argument     Description
-    ===========  =============================================================
+===========  =============================================================
-    ``count``    A number (or variable) containing the number of paragraphs or
+``count``    A number (or variable) containing the number of paragraphs or
              words to generate (default is 1).
-    ``method``   Either ``w`` for words, ``p`` for HTML paragraphs or ``b``
+``method``   Either ``w`` for words, ``p`` for HTML paragraphs or ``b``
              for plain-text paragraph blocks (default is ``b``).
-    ``random``   The word ``random``, which if given, does not use the common
+``random``   The word ``random``, which if given, does not use the common
              paragraph ("Lorem ipsum dolor sit amet...") when generating
              text.
-    ===========  =============================================================
+===========  =============================================================
 
 Examples:
 
-    * ``{% lorem %}`` will output the common "lorem ipsum" paragraph.
+* ``{% lorem %}`` will output the common "lorem ipsum" paragraph.
-    * ``{% lorem 3 p %}`` will output the common "lorem ipsum" paragraph
+* ``{% lorem 3 p %}`` will output the common "lorem ipsum" paragraph
   and two random paragraphs each wrapped in HTML ``<p>`` tags.
-    * ``{% lorem 2 w random %}`` will output two random Latin words.
+* ``{% lorem 2 w random %}`` will output two random Latin words.

docs/ref/databases.txt

@@ -257,10 +257,10 @@ Refer to the :doc:`settings documentation </ref/settings>`.
 
 Connection settings are used in this order:
 
-    1. :setting:`OPTIONS`.
+1. :setting:`OPTIONS`.
-    2. :setting:`NAME`, :setting:`USER`, :setting:`PASSWORD`,
+2. :setting:`NAME`, :setting:`USER`, :setting:`PASSWORD`,
    :setting:`HOST`, :setting:`PORT`
-    3. MySQL option files.
+3. 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
@@ -304,14 +304,14 @@ default storage engine to the desired engine.
 If you're using a hosting service and can't change your server's default
 storage engine, you have a couple of options.
 
-    * After the tables are created, execute an ``ALTER TABLE`` statement to
+* After the tables are created, execute an ``ALTER TABLE`` statement to
   convert a table to a new storage engine (such as InnoDB)::
 
       ALTER TABLE <tablename> ENGINE=INNODB;
 
   This can be tedious if you have a lot of tables.
 
-    * Another option is to use the ``init_command`` option for MySQLdb prior to
+* Another option is to use the ``init_command`` option for MySQLdb prior to
   creating your tables::
 
       'OPTIONS': {
@@ -321,7 +321,7 @@ storage engine, you have a couple of options.
   This sets the default storage engine upon connecting to the database.
   After your tables have been created, you should remove this option.
 
-    * Another method for changing the storage engine is described in
+* Another method for changing the storage engine is described in
   AlterModelOnSyncDB_.
 
 .. _AlterModelOnSyncDB: http://code.djangoproject.com/wiki/AlterModelOnSyncDB
@@ -422,12 +422,12 @@ SQLite 3.3.6 or newer strongly recommended
 
 Versions of SQLite 3.3.5 and older contains the following bugs:
 
- * A bug when `handling`_ ``ORDER BY`` parameters. This can cause problems when
+* A bug when `handling`_ ``ORDER BY`` parameters. This can cause problems when
   you use the ``select`` parameter for the ``extra()`` QuerySet method. The bug
   can be identified by the error message ``OperationalError: ORDER BY terms
   must not be non-integer constants``.
 
- * A bug when handling `aggregation`_ together with DateFields and
+* A bug when handling `aggregation`_ together with DateFields and
   DecimalFields.
 
 .. _handling: http://www.sqlite.org/cvstrac/tktview?tn=1768
@@ -507,14 +507,14 @@ is locked`` error.
 
 If you're getting this error, you can solve it by:
 
-    * Switching to another database backend. At a certain point SQLite becomes
+* Switching to another database backend. At a certain point SQLite becomes
   too "lite" for real-world applications, and these sorts of concurrency
   errors indicate you've reached that point.
 
-    * Rewriting your code to reduce concurrency and ensure that database
+* Rewriting your code to reduce concurrency and ensure that database
   transactions are short-lived.
 
-    * Increase the default timeout value by setting the ``timeout`` database
+* Increase the default timeout value by setting the ``timeout`` database
   option option::
 
       'OPTIONS': {
@@ -567,19 +567,19 @@ required.
 In order for the ``python manage.py syncdb`` command to work, your Oracle
 database user must have privileges to run the following commands:
 
-    * CREATE TABLE
+* CREATE TABLE
-    * CREATE SEQUENCE
+* CREATE SEQUENCE
-    * CREATE PROCEDURE
+* CREATE PROCEDURE
-    * CREATE TRIGGER
+* CREATE TRIGGER
 
 To run Django's test suite, the user needs these *additional* privileges:
 
-    * CREATE USER
+* CREATE USER
-    * DROP USER
+* DROP USER
-    * CREATE TABLESPACE
+* CREATE TABLESPACE
-    * DROP TABLESPACE
+* DROP TABLESPACE
-    * CONNECT WITH ADMIN OPTION
+* CONNECT WITH ADMIN OPTION
-    * RESOURCE WITH ADMIN OPTION
+* RESOURCE WITH ADMIN OPTION
 
 Connecting to the database
 --------------------------
@@ -721,16 +721,16 @@ assumption.
 The Oracle backend stores ``TextFields`` as ``NCLOB`` columns. Oracle imposes
 some limitations on the usage of such LOB columns in general:
 
-  * LOB columns may not be used as primary keys.
+* LOB columns may not be used as primary keys.
 
-  * LOB columns may not be used in indexes.
+* LOB columns may not be used in indexes.
 
-  * LOB columns may not be used in a ``SELECT DISTINCT`` list. This means that
+* LOB columns may not be used in a ``SELECT DISTINCT`` list. This means that
-    attempting to use the ``QuerySet.distinct`` method on a model that
+attempting to use the ``QuerySet.distinct`` method on a model that
-    includes ``TextField`` columns will result in an error when run against
+includes ``TextField`` columns will result in an error when run against
-    Oracle. As a workaround, use the ``QuerySet.defer`` method in conjunction
+Oracle. As a workaround, use the ``QuerySet.defer`` method in conjunction
-    with ``distinct()`` to prevent ``TextField`` columns from being included in
+with ``distinct()`` to prevent ``TextField`` columns from being included in
-    the ``SELECT DISTINCT`` list.
+the ``SELECT DISTINCT`` list.
 
 .. _third-party-notes:
 

docs/ref/django-admin.txt

@@ -9,9 +9,9 @@ In addition, ``manage.py`` is automatically created in each Django project.
 ``manage.py`` is a thin wrapper around ``django-admin.py`` that takes care of
 two things for you before delegating to ``django-admin.py``:
 
-    * It puts your project's package on ``sys.path``.
+* It puts your project's package on ``sys.path``.
 
-    * It sets the :envvar:`DJANGO_SETTINGS_MODULE` environment variable so that
+* It sets the :envvar:`DJANGO_SETTINGS_MODULE` environment variable so that
   it points to your project's ``settings.py`` file.
 
 The ``django-admin.py`` script should be on your system path if you installed
@@ -128,9 +128,9 @@ Runs the command-line client for the database engine specified in your
 ``ENGINE`` setting, with the connection parameters specified in your
 :setting:`USER`, :setting:`PASSWORD`, etc., settings.
 
-    * For PostgreSQL, this runs the ``psql`` command-line client.
+* For PostgreSQL, this runs the ``psql`` command-line client.
-    * For MySQL, this runs the ``mysql`` command-line client.
+* For MySQL, this runs the ``mysql`` command-line client.
-    * For SQLite, this runs the ``sqlite3`` command-line client.
+* For SQLite, this runs the ``sqlite3`` command-line client.
 
 This command assumes the programs are on your ``PATH`` so that a simple call to
 the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
@@ -257,12 +257,12 @@ As you might expect, the created models will have an attribute for every field
 in the table. Note that ``inspectdb`` has a few special cases in its field-name
 output:
 
-    * If ``inspectdb`` cannot map a column's type to a model field type, it'll
+* If ``inspectdb`` cannot map a column's type to a model field type, it'll
   use ``TextField`` and will insert the Python comment
   ``'This field type is a guess.'`` next to the field in the generated
   model.
 
-    * If the database column name is a Python reserved word (such as
+* If the database column name is a Python reserved word (such as
   ``'pass'``, ``'class'`` or ``'for'``), ``inspectdb`` will append
   ``'_field'`` to the attribute name. For example, if a table has a column
   ``'for'``, the generated model will have a field ``'for_field'``, with
@@ -309,9 +309,9 @@ 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
+1. In the ``fixtures`` directory of every installed application
-   2. In any directory named in the :setting:`FIXTURE_DIRS` setting
+2. In any directory named in the :setting:`FIXTURE_DIRS` setting
-   3. In the literal path named by the fixture
+3. In the literal path named by the fixture
 
 Django will load any and all fixtures it finds in these locations that match
 the provided fixture names.
@@ -438,8 +438,8 @@ Example usage::
 Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
 Currently supported:
 
-    * ``django`` for all ``*.py``, ``*.html`` and ``*.txt`` files (default)
+* ``django`` for all ``*.py``, ``*.html`` and ``*.txt`` files (default)
-    * ``djangojs`` for ``*.js`` files
+* ``djangojs`` for ``*.js`` files
 
 .. django-admin-option:: --symlinks
 
@@ -984,19 +984,19 @@ For example, this command::
 
 ...would perform the following steps:
 
-    1. Create a test database, as described in :doc:`/topics/testing`.
+1. Create a test database, as described in :doc:`/topics/testing`.
-    2. Populate the test database with fixture data from the given fixtures.
+2. Populate the test database with fixture data from the given fixtures.
    (For more on fixtures, see the documentation for ``loaddata`` above.)
-    3. Runs the Django development server (as in ``runserver``), pointed at
+3. Runs the Django development server (as in ``runserver``), pointed at
    this newly created test database instead of your production database.
 
 This is useful in a number of ways:
 
-    * When you're writing :doc:`unit tests </topics/testing>` of how your views
+* When you're writing :doc:`unit tests </topics/testing>` of how your views
   act with certain fixture data, you can use ``testserver`` to interact with
   the views in a Web browser, manually.
 
-    * Let's say you're developing your Django application and have a "pristine"
+* Let's say you're developing your Django application and have a "pristine"
   copy of a database that you'd like to interact with. You can dump your
   database to a fixture (using the ``dumpdata`` command, explained above),
   then use ``testserver`` to run your Web application with that data. With
@@ -1197,10 +1197,10 @@ Example usage::
 Use ``--verbosity`` to specify the amount of notification and debug information
 that ``django-admin.py`` should print to the console.
 
-    * ``0`` means no output.
+* ``0`` means no output.
-    * ``1`` means normal output (default).
+* ``1`` means normal output (default).
-    * ``2`` means verbose output.
+* ``2`` means verbose output.
-    * ``3`` means *very* verbose output.
+* ``3`` means *very* verbose output.
 
 Common options
 ==============
@@ -1259,13 +1259,13 @@ another program.
 The colors used for syntax highlighting can be customized. Django
 ships with three color palettes:
 
-    * ``dark``, suited to terminals that show white text on a black
+* ``dark``, suited to terminals that show white text on a black
   background. This is the default palette.
 
-    * ``light``, suited to terminals that show black text on a white
+* ``light``, suited to terminals that show black text on a white
   background.
 
-    * ``nocolor``, which disables syntax highlighting.
+* ``nocolor``, which disables syntax highlighting.
 
 You select a palette by setting a ``DJANGO_COLORS`` environment
 variable to specify the palette you want to use. For example, to
@@ -1277,47 +1277,47 @@ would run the following at a command prompt::
 You can also customize the colors that are used. Django specifies a
 number of roles in which color is used:
 
-    * ``error`` - A major error.
+* ``error`` - A major error.
-    * ``notice`` - A minor error.
+* ``notice`` - A minor error.
-    * ``sql_field`` - The name of a model field in SQL.
+* ``sql_field`` - The name of a model field in SQL.
-    * ``sql_coltype`` - The type of a model field in SQL.
+* ``sql_coltype`` - The type of a model field in SQL.
-    * ``sql_keyword`` - A SQL keyword.
+* ``sql_keyword`` - A SQL keyword.
-    * ``sql_table`` - The name of a model in SQL.
+* ``sql_table`` - The name of a model in SQL.
-    * ``http_info`` - A 1XX HTTP Informational server response.
+* ``http_info`` - A 1XX HTTP Informational server response.
-    * ``http_success`` - A 2XX HTTP Success server response.
+* ``http_success`` - A 2XX HTTP Success server response.
-    * ``http_not_modified`` - A 304 HTTP Not Modified server response.
+* ``http_not_modified`` - A 304 HTTP Not Modified server response.
-    * ``http_redirect`` - A 3XX HTTP Redirect server response other than 304.
+* ``http_redirect`` - A 3XX HTTP Redirect server response other than 304.
-    * ``http_not_found`` - A 404 HTTP Not Found server response.
+* ``http_not_found`` - A 404 HTTP Not Found server response.
-    * ``http_bad_request`` - A 4XX HTTP Bad Request server response other than 404.
+* ``http_bad_request`` - A 4XX HTTP Bad Request server response other than 404.
-    * ``http_server_error`` - A 5XX HTTP Server Error response.
+* ``http_server_error`` - A 5XX HTTP Server Error response.
 
 Each of these roles can be assigned a specific foreground and
 background color, from the following list:
 
-    * ``black``
+* ``black``
-    * ``red``
+* ``red``
-    * ``green``
+* ``green``
-    * ``yellow``
+* ``yellow``
-    * ``blue``
+* ``blue``
-    * ``magenta``
+* ``magenta``
-    * ``cyan``
+* ``cyan``
-    * ``white``
+* ``white``
 
 Each of these colors can then be modified by using the following
 display options:
 
-    * ``bold``
+* ``bold``
-    * ``underscore``
+* ``underscore``
-    * ``blink``
+* ``blink``
-    * ``reverse``
+* ``reverse``
-    * ``conceal``
+* ``conceal``
 
 A color specification follows one of the following patterns:
 
-    * ``role=fg``
+* ``role=fg``
-    * ``role=fg/bg``
+* ``role=fg/bg``
-    * ``role=fg,option,option``
+* ``role=fg,option,option``
-    * ``role=fg/bg,option,option``
+* ``role=fg/bg,option,option``
 
 where ``role`` is the name of a valid color role, ``fg`` is the
 foreground color, ``bg`` is the background color and each ``option``
@@ -1348,9 +1348,9 @@ script, which lives in ``extras/django_bash_completion`` in the Django
 distribution. It enables tab-completion of ``django-admin.py`` and
 ``manage.py`` commands, so you can, for instance...
 
-    * Type ``django-admin.py``.
+* Type ``django-admin.py``.
-    * Press [TAB] to see all available options.
+* Press [TAB] to see all available options.
-    * Type ``sql``, then [TAB], to see all available options whose names start
+* Type ``sql``, then [TAB], to see all available options whose names start
   with ``sql``.
 
 

docs/ref/forms/api.txt

@@ -19,10 +19,10 @@ Bound and unbound forms
 
 A :class:`Form` instance is either **bound** to a set of data, or **unbound**.
 
-    * If it's **bound** to a set of data, it's capable of validating that data
+* If it's **bound** to a set of data, it's capable of validating that data
   and rendering the form as HTML with the data displayed in the HTML.
 
-    * If it's **unbound**, it cannot do validation (because there's no data to
+* If it's **unbound**, it cannot do validation (because there's no data to
   validate!), but it can still render the blank form as HTML.
 
 .. class:: Form
@@ -292,25 +292,25 @@ include ``checked="checked"`` if appropriate::
 This default output is a two-column HTML table, with a ``<tr>`` for each field.
 Notice the following:
 
-    * For flexibility, the output does *not* include the ``<table>`` and
+* For flexibility, the output does *not* include the ``<table>`` and
   ``</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
+* 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
   these are merely sensible defaults; you can specify which HTML to use for
   a given field by using widgets, which we'll explain shortly.
 
-    * The HTML ``name`` for each tag is taken directly from its attribute name
+* The HTML ``name`` for each tag is taken directly from its attribute name
   in the ``ContactForm`` class.
 
-    * The text label for each field -- e.g. ``'Subject:'``, ``'Message:'`` and
+* The text label for each field -- e.g. ``'Subject:'``, ``'Message:'`` and
   ``'Cc myself:'`` is generated from the field name by converting all
   underscores to spaces and upper-casing the first letter. Again, note
   these are merely sensible defaults; you can also specify labels manually.
 
-    * Each text label is surrounded in an HTML ``<label>`` tag, which points
+* Each text label is surrounded in an HTML ``<label>`` tag, which points
   to the appropriate form field via its ``id``. Its ``id``, in turn, is
   generated by prepending ``'id_'`` to the field name. The ``id``
   attributes and ``<label>`` tags are included in the output by default, to

docs/ref/forms/fields.txt

@@ -302,7 +302,7 @@ For each field, we describe the default widget used if you don't specify
       the field has ``required=True``.
     * Error message keys: ``required``
 
-.. note::
+    .. note::
 
         Since all ``Field`` subclasses have ``required=True`` by default, the
         validation condition here is important. If you want to include a boolean
@@ -322,10 +322,10 @@ For each field, we describe the default widget used if you don't specify
       Otherwise, all inputs are valid.
     * Error message keys: ``required``, ``max_length``, ``min_length``
 
-Has two optional arguments for validation:
+    Has two optional arguments for validation:
 
-.. attribute:: CharField.max_length
+    .. attribute:: max_length
-.. attribute:: CharField.min_length
+    .. attribute:: min_length
 
     If provided, these arguments ensure that the string is at most or at least
     the given length.
@@ -341,12 +341,12 @@ Has two optional arguments for validation:
     * Validates that the given value exists in the list of choices.
     * Error message keys: ``required``, ``invalid_choice``
 
-The ``invalid_choice`` error message may contain ``%(value)s``, which will be
+    The ``invalid_choice`` error message may contain ``%(value)s``, which will be
-replaced with the selected choice.
+    replaced with the selected choice.
 
-Takes one extra required argument:
+    Takes one extra required argument:
 
-.. attribute:: ChoiceField.choices
+    .. attribute:: choices
 
         An iterable (e.g., a list or tuple) of 2-tuples to use as choices for this
         field. This argument accepts the same formats as the ``choices`` argument
@@ -358,8 +358,8 @@ Takes one extra required argument:
 
 .. class:: TypedChoiceField(**kwargs)
 
-Just like a :class:`ChoiceField`, except :class:`TypedChoiceField` takes two
+    Just like a :class:`ChoiceField`, except :class:`TypedChoiceField` takes two
-extra arguments, ``coerce`` and ``empty_value``.
+    extra arguments, ``coerce`` and ``empty_value``.
 
     * Default widget: ``Select``
     * Empty value: Whatever you've given as ``empty_value``
@@ -368,15 +368,15 @@ extra arguments, ``coerce`` and ``empty_value``.
       coerced.
     * Error message keys: ``required``, ``invalid_choice``
 
-Takes extra arguments:
+    Takes extra arguments:
 
-.. attribute:: TypedChoiceField.coerce
+    .. attribute:: coerce
 
         A function that takes one argument and returns a coerced value. Examples
         include the built-in ``int``, ``float``, ``bool`` and other types. Defaults
         to an identity function.
 
-.. attribute:: TypedChoiceField.empty_value
+    .. attribute:: empty_value
 
         The value to use to represent "empty." Defaults to the empty string;
         ``None`` is another common choice here. Note that this value will not be
@@ -395,14 +395,14 @@ Takes extra arguments:
       ``datetime.datetime`` or string formatted in a particular date format.
     * Error message keys: ``required``, ``invalid``
 
-Takes one optional argument:
+    Takes one optional argument:
 
-.. attribute:: DateField.input_formats
+    .. attribute:: input_formats
 
         A list of formats used to attempt to convert a string to a valid
         ``datetime.date`` object.
 
-If no ``input_formats`` argument is provided, the default input formats are::
+    If no ``input_formats`` argument is provided, the default input formats are::
 
         '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
         '%b %d %Y', '%b %d, %Y',            # 'Oct 25 2006', 'Oct 25, 2006'
@@ -422,14 +422,14 @@ If no ``input_formats`` argument is provided, the default input formats are::
       ``datetime.date`` or string formatted in a particular datetime format.
     * Error message keys: ``required``, ``invalid``
 
-Takes one optional argument:
+    Takes one optional argument:
 
-.. attribute:: DateTimeField.input_formats
+    .. attribute:: input_formats
 
         A list of formats used to attempt to convert a string to a valid
         ``datetime.datetime`` object.
 
-If no ``input_formats`` argument is provided, the default input formats are::
+    If no ``input_formats`` argument is provided, the default input formats are::
 
         '%Y-%m-%d %H:%M:%S',     # '2006-10-25 14:30:59'
         '%Y-%m-%d %H:%M',        # '2006-10-25 14:30'
@@ -455,24 +455,24 @@ If no ``input_formats`` argument is provided, the default input formats are::
       ``min_value``, ``max_digits``, ``max_decimal_places``,
       ``max_whole_digits``
 
-The ``max_value`` and ``min_value`` error messages may contain
+    The ``max_value`` and ``min_value`` error messages may contain
-``%(limit_value)s``, which will be substituted by the appropriate limit.
+    ``%(limit_value)s``, which will be substituted by the appropriate limit.
 
-Takes four optional arguments:
+    Takes four optional arguments:
 
-.. attribute:: DecimalField.max_value
+    .. attribute:: max_value
-.. attribute:: DecimalField.min_value
+    .. attribute:: min_value
 
         These control the range of values permitted in the field, and should be
         given as ``decimal.Decimal`` values.
 
-.. attribute:: DecimalField.max_digits
+    .. attribute:: max_digits
 
         The maximum number of digits (those before the decimal point plus those
         after the decimal point, with leading zeros stripped) permitted in the
         value.
 
-.. attribute:: DecimalField.decimal_places
+    .. attribute:: decimal_places
 
         The maximum number of decimal places permitted.
 
@@ -488,9 +488,9 @@ Takes four optional arguments:
       moderately complex regular expression.
     * Error message keys: ``required``, ``invalid``
 
-Has two optional arguments for validation, ``max_length`` and ``min_length``.
+    Has two optional arguments for validation, ``max_length`` and ``min_length``.
-If provided, these arguments ensure that the string is at most or at least the
+    If provided, these arguments ensure that the string is at most or at least the
-given length.
+    given length.
 
 .. versionchanged:: 1.2
    The EmailField previously did not recognize email addresses as valid that
@@ -510,20 +510,20 @@ given length.
     * Error message keys: ``required``, ``invalid``, ``missing``, ``empty``,
       ``max_length``
 
-Has two optional arguments for validation, ``max_length`` and
+    Has two optional arguments for validation, ``max_length`` and
-``allow_empty_file``. If provided, these ensure that the file name is at
+    ``allow_empty_file``. If provided, these ensure that the file name is at
-most the given length, and that validation will succeed even if the file
+    most the given length, and that validation will succeed even if the file
-content is empty.
+    content is empty.
 
-To learn more about the ``UploadedFile`` object, see the :doc:`file uploads
+    To learn more about the ``UploadedFile`` object, see the :doc:`file uploads
-documentation </topics/http/file-uploads>`.
+    documentation </topics/http/file-uploads>`.
 
-When you use a ``FileField`` in a form, you must also remember to
+    When you use a ``FileField`` in a form, you must also remember to
-:ref:`bind the file data to the form <binding-uploaded-files>`.
+    :ref:`bind the file data to the form <binding-uploaded-files>`.
 
-The ``max_length`` error refers to the length of the filename. In the error
+    The ``max_length`` error refers to the length of the filename. In the error
-message for that key, ``%(max)d`` will be replaced with the maximum filename
+    message for that key, ``%(max)d`` will be replaced with the maximum filename
-length and ``%(length)d`` will be replaced with the current filename length.
+    length and ``%(length)d`` will be replaced with the current filename length.
 
 ``FilePathField``
 ~~~~~~~~~~~~~~~~~
@@ -536,21 +536,21 @@ length and ``%(length)d`` will be replaced with the current filename length.
     * Validates that the selected choice exists in the list of choices.
     * Error message keys: ``required``, ``invalid_choice``
 
-The field allows choosing from files inside a certain directory. It takes three
+    The field allows choosing from files inside a certain directory. It takes three
-extra arguments; only ``path`` is required:
+    extra arguments; only ``path`` is required:
 
-.. attribute:: FilePathField.path
+    .. attribute:: path
 
         The absolute path to the directory whose contents you want listed. This
         directory must exist.
 
-.. attribute:: FilePathField.recursive
+    .. attribute:: recursive
 
         If ``False`` (the default) only the direct contents of ``path`` will be
         offered as choices. If ``True``, the directory will be descended into
         recursively and all descendants will be listed as choices.
 
-.. attribute:: FilePathField.match
+    .. attribute:: match
 
         A regular expression pattern; only files with names matching this expression
         will be allowed as choices.
@@ -558,6 +558,8 @@ extra arguments; only ``path`` is required:
 ``FloatField``
 ~~~~~~~~~~~~~~
 
+.. class:: FloatField(**kwargs)
+
     * Default widget: ``TextInput``
     * Empty value: ``None``
     * Normalizes to: A Python float.
@@ -566,8 +568,8 @@ extra arguments; only ``path`` is required:
     * Error message keys: ``required``, ``invalid``, ``max_value``,
       ``min_value``
 
-Takes two optional arguments for validation, ``max_value`` and ``min_value``.
+    Takes two optional arguments for validation, ``max_value`` and ``min_value``.
-These control the range of values permitted in the field.
+    These control the range of values permitted in the field.
 
 ``ImageField``
 ~~~~~~~~~~~~~~
@@ -583,10 +585,10 @@ These control the range of values permitted in the field.
     * Error message keys: ``required``, ``invalid``, ``missing``, ``empty``,
       ``invalid_image``
 
-Using an ImageField requires that the `Python Imaging Library`_ is installed.
+    Using an ImageField requires that the `Python Imaging Library`_ is installed.
 
-When you use an ``ImageField`` on a form, you must also remember to
+    When you use an ``ImageField`` on a form, you must also remember to
-:ref:`bind the file data to the form <binding-uploaded-files>`.
+    :ref:`bind the file data to the form <binding-uploaded-files>`.
 
 .. _Python Imaging Library: http://www.pythonware.com/products/pil/
 
@@ -603,13 +605,13 @@ When you use an ``ImageField`` on a form, you must also remember to
     * Error message keys: ``required``, ``invalid``, ``max_value``,
       ``min_value``
 
-The ``max_value`` and ``min_value`` error messages may contain
+    The ``max_value`` and ``min_value`` error messages may contain
-``%(limit_value)s``, which will be substituted by the appropriate limit.
+    ``%(limit_value)s``, which will be substituted by the appropriate limit.
 
-Takes two optional arguments for validation:
+    Takes two optional arguments for validation:
 
-.. attribute:: IntegerField.max_value
+    .. attribute:: max_value
-.. attribute:: IntegerField.min_value
+    .. attribute:: min_value
 
     These control the range of values permitted in the field.
 
@@ -628,11 +630,11 @@ Takes two optional arguments for validation:
 ``GenericIPAddressField``
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. class:: GenericIPAddressField(**kwargs)
-
 .. versionadded:: 1.4
 
-A field containing either an IPv4 or an IPv6 address.
+.. class:: GenericIPAddressField(**kwargs)
+
+    A field containing either an IPv4 or an IPv6 address.
 
     * Default widget: ``TextInput``
     * Empty value: ``''`` (an empty string)
@@ -641,21 +643,21 @@ A field containing either an IPv4 or an IPv6 address.
     * Validates that the given value is a valid IP address.
     * Error message keys: ``required``, ``invalid``
 
-The IPv6 address normalization follows :rfc:`4291#section-2.2` section 2.2,
+    The IPv6 address normalization follows :rfc:`4291#section-2.2` section 2.2,
-including using the IPv4 format suggested in paragraph 3 of that section, like
+    including using the IPv4 format suggested in paragraph 3 of that section, like
-``::ffff:192.0.2.0``. For example, ``2001:0::0:01`` would be normalized to
+    ``::ffff:192.0.2.0``. For example, ``2001:0::0:01`` would be normalized to
-``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All characters
+    ``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All characters
-are converted to lowercase.
+    are converted to lowercase.
 
-Takes two optional arguments:
+    Takes two optional arguments:
 
-.. attribute:: GenericIPAddressField.protocol
+    .. attribute:: protocol
 
         Limits valid inputs to the specified protocol.
         Accepted values are ``both`` (default), ``IPv4``
         or ``IPv6``. Matching is case insensitive.
 
-.. attribute:: GenericIPAddressField.unpack_ipv4
+    .. attribute:: unpack_ipv4
 
         Unpacks IPv4 mapped addresses like ``::ffff::192.0.2.1``.
         If this option is enabled that address would be unpacked to
@@ -674,20 +676,20 @@ Takes two optional arguments:
       of choices.
     * Error message keys: ``required``, ``invalid_choice``, ``invalid_list``
 
-The ``invalid_choice`` error message may contain ``%(value)s``, which will be
+    The ``invalid_choice`` error message may contain ``%(value)s``, which will be
-replaced with the selected choice.
+    replaced with the selected choice.
 
-Takes one extra required argument, ``choices``, as for ``ChoiceField``.
+    Takes one extra required argument, ``choices``, as for ``ChoiceField``.
 
 ``TypedMultipleChoiceField``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. class:: TypedMultipleChoiceField(**kwargs)
-
 .. versionadded:: 1.3
 
-Just like a :class:`MultipleChoiceField`, except :class:`TypedMultipleChoiceField`
+.. class:: TypedMultipleChoiceField(**kwargs)
-takes two extra arguments, ``coerce`` and ``empty_value``.
+
+    Just like a :class:`MultipleChoiceField`, except :class:`TypedMultipleChoiceField`
+    takes two extra arguments, ``coerce`` and ``empty_value``.
 
     * Default widget: ``SelectMultiple``
     * Empty value: Whatever you've given as ``empty_value``
@@ -697,10 +699,10 @@ takes two extra arguments, ``coerce`` and ``empty_value``.
       coerced.
     * Error message keys: ``required``, ``invalid_choice``
 
-The ``invalid_choice`` error message may contain ``%(value)s``, which will be
+    The ``invalid_choice`` error message may contain ``%(value)s``, which will be
-replaced with the selected choice.
+    replaced with the selected choice.
 
-Takes two extra arguments, ``coerce`` and ``empty_value``, as for ``TypedChoiceField``.
+    Takes two extra arguments, ``coerce`` and ``empty_value``, as for ``TypedChoiceField``.
 
 ``NullBooleanField``
 ~~~~~~~~~~~~~~~~~~~~
@@ -724,20 +726,20 @@ Takes two extra arguments, ``coerce`` and ``empty_value``, as for ``TypedChoiceF
       expression.
     * Error message keys: ``required``, ``invalid``
 
-Takes one required argument:
+    Takes one required argument:
 
-.. attribute:: RegexField.regex
+    .. attribute:: regex
 
         A regular expression specified either as a string or a compiled regular
         expression object.
 
-Also takes ``max_length`` and ``min_length``, which work just as they do for
+    Also takes ``max_length`` and ``min_length``, which work just as they do for
-``CharField``.
+    ``CharField``.
 
-The optional argument ``error_message`` is also accepted for backwards
+    The optional argument ``error_message`` is also accepted for backwards
-compatibility. The preferred way to provide an error message is to use the
+    compatibility. The preferred way to provide an error message is to use the
-``error_messages`` argument, passing a dictionary with ``'invalid'`` as a key
+    ``error_messages`` argument, passing a dictionary with ``'invalid'`` as a key
-and the error message as the value.
+    and the error message as the value.
 
 ``SlugField``
 ~~~~~~~~~~~~~
@@ -751,8 +753,8 @@ and the error message as the value.
      underscores, and hyphens.
    * Error messages: ``required``, ``invalid``
 
-This field is intended for use in representing a model
+   This field is intended for use in representing a model
-:class:`~django.db.models.SlugField` in forms.
+   :class:`~django.db.models.SlugField` in forms.
 
 ``TimeField``
 ~~~~~~~~~~~~~
@@ -766,14 +768,14 @@ This field is intended for use in representing a model
       formatted in a particular time format.
     * Error message keys: ``required``, ``invalid``
 
-Takes one optional argument:
+    Takes one optional argument:
 
-.. attribute:: TimeField.input_formats
+    .. attribute:: input_formats
 
         A list of formats used to attempt to convert a string to a valid
         ``datetime.time`` object.
 
-If no ``input_formats`` argument is provided, the default input formats are::
+    If no ``input_formats`` argument is provided, the default input formats are::
 
         '%H:%M:%S',     # '14:30:59'
         '%H:%M',        # '14:30'
@@ -789,24 +791,23 @@ If no ``input_formats`` argument is provided, the default input formats are::
     * Validates that the given value is a valid URL.
     * Error message keys: ``required``, ``invalid``, ``invalid_link``
 
-Takes the following optional arguments:
+    Takes the following optional arguments:
 
-.. attribute:: URLField.max_length
+    .. attribute:: max_length
-.. attribute:: URLField.min_length
+    .. attribute:: min_length
 
-    Same as ``CharField.max_length`` and ``CharField.min_length``.
+    These are the same as ``CharField.max_length`` and ``CharField.min_length``.
 
-.. attribute:: URLField.verify_exists
+    .. attribute:: verify_exists
 
         If ``True``, the validator will attempt to load the given URL, raising
         ``ValidationError`` if the page gives a 404. Defaults to ``False``.
 
-.. deprecated:: 1.4
+        .. deprecated:: 1.4
-
             ``verify_exists`` was deprecated for security reasons and will be removed in
             Django 1.5. This deprecation also removes ``validator_user_agent``.
 
-.. attribute:: URLField.validator_user_agent
+    .. attribute:: validator_user_agent
 
         String used as the user-agent used when checking for a URL's existence.
         Defaults to the value of the :setting:`URL_VALIDATOR_USER_AGENT` setting.
@@ -832,9 +833,9 @@ Slightly complex built-in ``Field`` classes
       as an argument to the ``ComboField``.
     * Error message keys: ``required``, ``invalid``
 
-Takes one extra required argument:
+    Takes one extra required argument:
 
-.. attribute:: ComboField.fields
+    .. attribute:: fields
 
         The list of fields that should be used to validate the field's value (in
         the order in which they are provided).
@@ -866,9 +867,9 @@ Takes one extra required argument:
     :class:`SplitDateTimeField` is a subclass which combines a time field and
     a date field into a datetime object.
 
-Takes one extra required argument:
+    Takes one extra required argument:
 
-.. attribute:: MultiValueField.fields
+    .. attribute:: fields
 
         A list of fields which are cleaned into a single field. Each value in
         ``clean`` is cleaned by the corresponding field in ``fields`` -- the first
@@ -889,23 +890,23 @@ Takes one extra required argument:
     * Error message keys: ``required``, ``invalid``, ``invalid_date``,
       ``invalid_time``
 
-Takes two optional arguments:
+    Takes two optional arguments:
 
-.. attribute:: SplitDateTimeField.input_date_formats
+    .. attribute:: input_date_formats
 
         A list of formats used to attempt to convert a string to a valid
         ``datetime.date`` object.
 
-If no ``input_date_formats`` argument is provided, the default input formats
+    If no ``input_date_formats`` argument is provided, the default input formats
-for ``DateField`` are used.
+    for ``DateField`` are used.
 
-.. attribute:: SplitDateTimeField.input_time_formats
+    .. attribute:: input_time_formats
 
         A list of formats used to attempt to convert a string to a valid
         ``datetime.time`` object.
 
-If no ``input_time_formats`` argument is provided, the default input formats
+    If no ``input_time_formats`` argument is provided, the default input formats
-for ``TimeField`` are used.
+    for ``TimeField`` are used.
 
 Fields which handle relationships
 ---------------------------------
@@ -930,18 +931,18 @@ objects (in the case of ``ModelMultipleChoiceField``) into the
     * Validates that the given id exists in the queryset.
     * Error message keys: ``required``, ``invalid_choice``
 
-Allows the selection of a single model object, suitable for
+    Allows the selection of a single model object, suitable for
-representing a foreign key.  A single argument is required:
+    representing a foreign key.  A single argument is required:
 
-.. attribute:: ModelChoiceField.queryset
+    .. attribute:: queryset
 
         A ``QuerySet`` of model objects from which the choices for the
         field will be derived, and which will be used to validate the
         user's selection.
 
-``ModelChoiceField`` also takes one optional argument:
+    ``ModelChoiceField`` also takes one optional argument:
 
-.. attribute:: ModelChoiceField.empty_label
+    .. attribute:: empty_label
 
         By default the ``<select>`` widget used by ``ModelChoiceField`` will have an
         empty choice at the top of the list. You can change the text of this
@@ -959,12 +960,12 @@ representing a foreign key.  A single argument is required:
         initial value, no empty choice is created (regardless of the value
         of ``empty_label``).
 
-The ``__unicode__`` method of the model will be called to generate
+    The ``__unicode__`` method of the model will be called to generate
-string representations of the objects for use in the field's choices;
+    string representations of the objects for use in the field's choices;
-to provide customized representations, subclass ``ModelChoiceField``
+    to provide customized representations, subclass ``ModelChoiceField``
-and override ``label_from_instance``. This method will receive a model
+    and override ``label_from_instance``. This method will receive a model
-object, and should return a string suitable for representing it. For
+    object, and should return a string suitable for representing it. For
-example::
+    example::
 
         class MyModelChoiceField(ModelChoiceField):
             def label_from_instance(self, obj):
@@ -983,12 +984,12 @@ example::
     * Error message keys: ``required``, ``list``, ``invalid_choice``,
       ``invalid_pk_value``
 
-Allows the selection of one or more model objects, suitable for
+    Allows the selection of one or more model objects, suitable for
-representing a many-to-many relation. As with :class:`ModelChoiceField`,
+    representing a many-to-many relation. As with :class:`ModelChoiceField`,
-you can use ``label_from_instance`` to customize the object
+    you can use ``label_from_instance`` to customize the object
-representations, and ``queryset`` is a required parameter:
+    representations, and ``queryset`` is a required parameter:
 
-.. attribute:: ModelMultipleChoiceField.queryset
+    .. attribute:: queryset
 
         A ``QuerySet`` of model objects from which the choices for the
         field will be derived, and which will be used to validate the

docs/ref/forms/validation.txt

@@ -28,32 +28,32 @@ after the field's ``to_python`` and ``validate`` methods have been called.
 Validation of a Form is split into several steps, which can be customized or
 overridden:
 
-    * The ``to_python()`` method on a Field is the first step in every
+* The ``to_python()`` method on a Field is the first step in every
   validation. It coerces the value to correct datatype and raises
   ``ValidationError`` if that is not possible. This method accepts the raw
   value from the widget and returns the converted value. For example, a
   FloatField will turn the data into a Python ``float`` or raise a
   ``ValidationError``.
 
-    * The ``validate()`` method on a Field handles field-specific validation
+* The ``validate()`` method on a Field handles field-specific validation
   that is not suitable for a validator, It takes a value that has been
   coerced to correct datatype and raises ``ValidationError`` on any error.
   This method does not return anything and shouldn't alter the value. You
   should override it to handle validation logic that you can't or don't
   want to put in a validator.
 
-    * The ``run_validators()`` method on a Field runs all of the field's
+* The ``run_validators()`` method on a Field runs all of the field's
   validators and aggregates all the errors into a single
   ``ValidationError``. You shouldn't need to override this method.
 
-    * The ``clean()`` method on a Field subclass. This is responsible for
+* The ``clean()`` method on a Field subclass. This is responsible for
   running ``to_python``, ``validate`` and ``run_validators`` in the correct
   order and propagating their errors. If, at any time, any of the methods
   raise ``ValidationError``, the validation stops and that error is raised.
   This method returns the clean data, which is then inserted into the
   ``cleaned_data`` dictionary of the form.
 
-    * The ``clean_<fieldname>()`` method in a form subclass -- where
+* The ``clean_<fieldname>()`` method in a form subclass -- where
   ``<fieldname>`` is replaced with the name of the form field attribute.
   This method does any cleaning that is specific to that particular
   attribute, unrelated to the type of field that it is. This method is not
@@ -74,7 +74,7 @@ overridden:
   should return the cleaned data, regardless of whether it changed
   anything or not.
 
-    * The Form subclass's ``clean()`` method. This method can perform
+* The Form subclass's ``clean()`` method. This method can perform
   any validation that requires access to multiple fields from the form at
   once. This is where you might put in things to check that if field ``A``
   is supplied, field ``B`` must contain a valid email address and the

docs/ref/forms/widgets.txt

@@ -21,9 +21,7 @@ which widget is used on which field, see the documentation about
 
 However, if you want to use a different widget for a field, you can
 just use the :attr:`~Field.widget` argument on the field definition. For
-example:
+example::
-
-    .. code-block:: python
 
     from django import forms
 
@@ -42,9 +40,7 @@ Setting arguments for widgets
 Many widgets have optional extra arguments; they can be set when defining the
 widget on the field. In the following example, the
 :attr:`~SelectDateWidget.years` attribute is set for a
-:class:`~django.forms.extras.widgets.SelectDateWidget`:
+:class:`~django.forms.extras.widgets.SelectDateWidget`::
-
-    .. code-block:: python
 
     from django.forms.fields import DateField, ChoiceField, MultipleChoiceField
     from django.forms.widgets import RadioSelect, CheckboxSelectMultiple
@@ -78,9 +74,7 @@ buttons.
 :class:`Select` widgets are used by default on :class:`ChoiceField` fields. The
 choices displayed on the widget are inherited from the :class:`ChoiceField` and
 changing :attr:`ChoiceField.choices` will update :attr:`Select.choices`. For
-example:
+example::
-
-    .. code-block:: python
 
     >>> from django import forms
     >>> CHOICES = (('1', 'First',), ('2', 'Second',)))
@@ -113,9 +107,7 @@ specify additional attributes for each widget. When you specify a
 widget, you can provide a list of attributes that will be added to the
 rendered HTML for the widget.
 
-For example, take the following simple form:
+For example, take the following simple form::
-
-    .. code-block:: python
 
     from django import forms
 
@@ -126,9 +118,7 @@ For example, take the following simple form:
 
 This form will include three default :class:`TextInput` widgets, with default
 rendering -- no CSS class, no extra attributes. This means that the input boxes
-provided for each widget will be rendered exactly the same:
+provided for each widget will be rendered exactly the same::
-
-    .. code-block:: python
 
     >>> f = CommentForm(auto_id=False)
     >>> f.as_table()
@@ -136,15 +126,12 @@ provided for each widget will be rendered exactly the same:
     <tr><th>Url:</th><td><input type="text" name="url"/></td></tr>
     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
 
-
 On a real Web page, you probably don't want every widget to look the same. You
 might want a larger input element for the comment, and you might want the
 'name' widget to have some special CSS class. To do this, you use the
 :attr:`Widget.attrs` argument when creating the widget:
 
-For example:
+For example::
-
-    .. code-block:: python
 
     class CommentForm(forms.Form):
         name = forms.CharField(
@@ -155,8 +142,6 @@ For example:
 
 Django will then include the extra attributes in the rendered output:
 
-    .. code-block:: python
-
     >>> f = CommentForm(auto_id=False)
     >>> f.as_table()
     <tr><th>Name:</th><td><input type="text" name="name" class="special"/></td></tr>
@@ -411,9 +396,7 @@ commonly used groups of widgets:
     :class:`MultiWidget`'s subclasses must implement. This method takes a
     single "compressed" value and returns a ``list``. An example of this is how
     :class:`SplitDateTimeWidget` turns a :class:`datetime` value into a list
-    with date and time split into two seperate values:
+    with date and time split into two seperate values::
-
-    .. code-block:: python
 
         class SplitDateTimeWidget(MultiWidget):
 

docs/ref/generic-views.txt

@@ -48,16 +48,16 @@ which is a dictionary of the parameters captured in the URL.
 
 **Required arguments:**
 
-    * ``template``: The full name of a template to use.
+* ``template``: The full name of a template to use.
 
 **Optional arguments:**
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
 **Example:**
@@ -92,17 +92,17 @@ If the given URL is ``None``, Django will return an ``HttpResponseGone`` (410).
 
 **Required arguments:**
 
-    * ``url``: The URL to redirect to, as a string. Or ``None`` to raise a 410
+* ``url``: The URL to redirect to, as a string. Or ``None`` to raise a 410
   (Gone) HTTP error.
 
 **Optional arguments:**
 
-    * ``permanent``: Whether the redirect should be permanent. The only
+* ``permanent``: Whether the redirect should be permanent. The only
   difference here is the HTTP status code returned. If ``True``, then the
   redirect will use status code 301. If ``False``, then the redirect will
   use status code 302. By default, ``permanent`` is ``True``.
 
-    * ``query_string``: Whether to pass along the GET query string to
+* ``query_string``: Whether to pass along the GET query string to
   the new location. If ``True``, then the query string is appended
   to the URL. If ``False``, then the query string is discarded. By
   default, ``query_string`` is ``False``.
@@ -167,45 +167,45 @@ a date in the *future* are not included unless you set ``allow_future`` to
 
 **Required arguments:**
 
-    * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
 
-    * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
   the ``QuerySet``'s model that the date-based archive should use to
   determine the objects on the page.
 
 **Optional arguments:**
 
-    * ``num_latest``: The number of latest objects to send to the template
+* ``num_latest``: The number of latest objects to send to the template
   context. By default, it's 15.
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``allow_empty``: A boolean specifying whether to display the page if no
+* ``allow_empty``: A boolean specifying whether to display the page if no
   objects are available. If this is ``False`` and no objects are available,
   the view will raise a 404 instead of displaying an empty page. By
   default, this is ``True``.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    * ``allow_future``: A boolean specifying whether to include "future"
+* ``allow_future``: A boolean specifying whether to include "future"
   objects on this page, where "future" means objects in which the field
   specified in ``date_field`` is greater than the current date/time. By
   default, this is ``False``.
 
-    * ``template_object_name``: Designates the name of the template variable
+* ``template_object_name``: Designates the name of the template variable
   to use in the template context. By default, this is ``'latest'``.
 
 **Template name:**
@@ -213,10 +213,10 @@ a date in the *future* are not included unless you set ``allow_future`` to
 If ``template_name`` isn't specified, this view will use the template
 ``<app_label>/<model_name>_archive.html`` by default, where:
 
-    * ``<model_name>`` is your model's name in all lowercase. For a model
+* ``<model_name>`` is your model's name in all lowercase. For a model
   ``StaffMember``, that'd be ``staffmember``.
 
-    * ``<app_label>`` is the right-most part of the full Python path to
+* ``<app_label>`` is the right-most part of the full Python path to
   your model's app. For example, if your model lives in
   ``apps/blog/models.py``, that'd be ``blog``.
 
@@ -224,12 +224,12 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``date_list``: A ``DateQuerySet`` object containing all years that have
+* ``date_list``: A ``DateQuerySet`` object containing all years that have
   have objects available according to ``queryset``, represented as
   ``datetime.datetime`` objects. These are ordered in reverse. This is
   equivalent to ``queryset.dates(date_field, 'year')[::-1]``.
 
-    * ``latest``: The ``num_latest`` objects in the system, ordered descending
+* ``latest``: The ``num_latest`` objects in the system, ordered descending
   by ``date_field``. For example, if ``num_latest`` is ``10``, then
   ``latest`` will be a list of the latest 10 objects in ``queryset``.
 
@@ -248,51 +248,51 @@ to ``True``.
 
 **Required arguments:**
 
-    * ``year``: The four-digit year for which the archive serves.
+* ``year``: The four-digit year for which the archive serves.
 
-    * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
 
-    * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
   the ``QuerySet``'s model that the date-based archive should use to
   determine the objects on the page.
 
 **Optional arguments:**
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``allow_empty``: A boolean specifying whether to display the page if no
+* ``allow_empty``: A boolean specifying whether to display the page if no
   objects are available. If this is ``False`` and no objects are available,
   the view will raise a 404 instead of displaying an empty page. By
   default, this is ``False``.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``. The
   view will append ``'_list'`` to the value of this parameter in
   determining the variable's name.
 
-    * ``make_object_list``: A boolean specifying whether to retrieve the full
+* ``make_object_list``: A boolean specifying whether to retrieve the full
   list of objects for this year and pass those to the template. If ``True``,
   this list of objects will be made available to the template as
   ``object_list``. (The name ``object_list`` may be different; see the docs
   for ``object_list`` in the "Template context" section below.) By default,
   this is ``False``.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    * ``allow_future``: A boolean specifying whether to include "future"
+* ``allow_future``: A boolean specifying whether to include "future"
   objects on this page, where "future" means objects in which the field
   specified in ``date_field`` is greater than the current date/time. By
   default, this is ``False``.
@@ -306,13 +306,13 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``date_list``: A ``DateQuerySet`` object containing all months that have
+* ``date_list``: A ``DateQuerySet`` object containing all months that have
   have objects available according to ``queryset``, represented as
   ``datetime.datetime`` objects, in ascending order.
 
-    * ``year``: The given year, as a four-character string.
+* ``year``: The given year, as a four-character string.
 
-    * ``object_list``: If the ``make_object_list`` parameter is ``True``, this
+* ``object_list``: If the ``make_object_list`` parameter is ``True``, this
   will be set to a list of objects available for the given year, ordered by
   the date field. This variable's name depends on the
   ``template_object_name`` parameter, which is ``'object'`` by default. If
@@ -333,53 +333,53 @@ date in the *future* are not displayed unless you set ``allow_future`` to
 
 **Required arguments:**
 
-    * ``year``: The four-digit year for which the archive serves (a string).
+* ``year``: The four-digit year for which the archive serves (a string).
 
-    * ``month``: The month for which the archive serves, formatted according to
+* ``month``: The month for which the archive serves, formatted according to
   the ``month_format`` argument.
 
-    * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
 
-    * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
   the ``QuerySet``'s model that the date-based archive should use to
   determine the objects on the page.
 
 **Optional arguments:**
 
-    * ``month_format``: A format string that regulates what format the ``month``
+* ``month_format``: A format string that regulates what format the ``month``
   parameter uses. This should be in the syntax accepted by Python's
   :func:`~time.strftime`. It's set to ``"%b"`` by default, which is a
   three-letter month abbreviation. To change it to use numbers, use
   ``"%m"``.
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``allow_empty``: A boolean specifying whether to display the page if no
+* ``allow_empty``: A boolean specifying whether to display the page if no
   objects are available. If this is ``False`` and no objects are available,
   the view will raise a 404 instead of displaying an empty page. By
   default, this is ``False``.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``. The
   view will append ``'_list'`` to the value of this parameter in
   determining the variable's name.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    * ``allow_future``: A boolean specifying whether to include "future"
+* ``allow_future``: A boolean specifying whether to include "future"
   objects on this page, where "future" means objects in which the field
   specified in ``date_field`` is greater than the current date/time. By
   default, this is ``False``.
@@ -396,21 +396,21 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``date_list``: A ``DateQuerySet`` object containing all days that have
+* ``date_list``: A ``DateQuerySet`` object containing all days that have
   have objects available in the given month, according to ``queryset``,
   represented as ``datetime.datetime`` objects, in ascending order.
 
-    * ``month``: A ``datetime.date`` object representing the given month.
+* ``month``: A ``datetime.date`` object representing the given month.
 
-    * ``next_month``: A ``datetime.date`` object representing the first day of
+* ``next_month``: A ``datetime.date`` object representing the first day of
   the next month. If the next month is in the future, this will be
   ``None``.
 
-    * ``previous_month``: A ``datetime.date`` object representing the first day
+* ``previous_month``: A ``datetime.date`` object representing the first day
   of the previous month. Unlike ``next_month``, this will never be
   ``None``.
 
-    * ``object_list``: A list of objects available for the given month. This
+* ``object_list``: A list of objects available for the given month. This
   variable's name depends on the ``template_object_name`` parameter, which
   is ``'object'`` by default. If ``template_object_name`` is ``'foo'``,
   this variable's name will be ``foo_list``.
@@ -425,47 +425,47 @@ in the *future* are not displayed unless you set ``allow_future`` to ``True``.
 
 **Required arguments:**
 
-    * ``year``: The four-digit year for which the archive serves (a string).
+* ``year``: The four-digit year for which the archive serves (a string).
 
-    * ``week``: The week of the year for which the archive serves (a string).
+* ``week``: The week of the year for which the archive serves (a string).
   Weeks start with Sunday.
 
-    * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
 
-    * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
   the ``QuerySet``'s model that the date-based archive should use to
   determine the objects on the page.
 
 **Optional arguments:**
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``allow_empty``: A boolean specifying whether to display the page if no
+* ``allow_empty``: A boolean specifying whether to display the page if no
   objects are available. If this is ``False`` and no objects are available,
   the view will raise a 404 instead of displaying an empty page. By
   default, this is ``True``.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``. The
   view will append ``'_list'`` to the value of this parameter in
   determining the variable's name.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    * ``allow_future``: A boolean specifying whether to include "future"
+* ``allow_future``: A boolean specifying whether to include "future"
   objects on this page, where "future" means objects in which the field
   specified in ``date_field`` is greater than the current date/time. By
   default, this is ``False``.
@@ -479,10 +479,10 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``week``: A ``datetime.date`` object representing the first day of the
+* ``week``: A ``datetime.date`` object representing the first day of the
   given week.
 
-    * ``object_list``: A list of objects available for the given week. This
+* ``object_list``: A list of objects available for the given week. This
   variable's name depends on the ``template_object_name`` parameter, which
   is ``'object'`` by default. If ``template_object_name`` is ``'foo'``,
   this variable's name will be ``foo_list``.
@@ -498,59 +498,59 @@ you set ``allow_future`` to ``True``.
 
 **Required arguments:**
 
-    * ``year``: The four-digit year for which the archive serves (a string).
+* ``year``: The four-digit year for which the archive serves (a string).
 
-    * ``month``: The month for which the archive serves, formatted according to
+* ``month``: The month for which the archive serves, formatted according to
   the ``month_format`` argument.
 
-    * ``day``: The day for which the archive serves, formatted according to the
+* ``day``: The day for which the archive serves, formatted according to the
   ``day_format`` argument.
 
-    * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
 
-    * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
   the ``QuerySet``'s model that the date-based archive should use to
   determine the objects on the page.
 
 **Optional arguments:**
 
-    * ``month_format``: A format string that regulates what format the ``month``
+* ``month_format``: A format string that regulates what format the ``month``
   parameter uses. This should be in the syntax accepted by Python's
   :func:`~time.strftime`. It's set to ``"%b"`` by default, which is a
   three-letter month abbreviation. To change it to use numbers, use
   ``"%m"``.
 
-    * ``day_format``: Like ``month_format``, but for the ``day`` parameter.
+* ``day_format``: Like ``month_format``, but for the ``day`` parameter.
   It defaults to ``"%d"`` (day of the month as a decimal number, 01-31).
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``allow_empty``: A boolean specifying whether to display the page if no
+* ``allow_empty``: A boolean specifying whether to display the page if no
   objects are available. If this is ``False`` and no objects are available,
   the view will raise a 404 instead of displaying an empty page. By
   default, this is ``False``.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``. The
   view will append ``'_list'`` to the value of this parameter in
   determining the variable's name.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    * ``allow_future``: A boolean specifying whether to include "future"
+* ``allow_future``: A boolean specifying whether to include "future"
   objects on this page, where "future" means objects in which the field
   specified in ``date_field`` is greater than the current date/time. By
   default, this is ``False``.
@@ -564,15 +564,15 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``day``: A ``datetime.date`` object representing the given day.
+* ``day``: A ``datetime.date`` object representing the given day.
 
-    * ``next_day``: A ``datetime.date`` object representing the next day. If
+* ``next_day``: A ``datetime.date`` object representing the next day. If
   the next day is in the future, this will be ``None``.
 
-    * ``previous_day``: A ``datetime.date`` object representing the previous day.
+* ``previous_day``: A ``datetime.date`` object representing the previous day.
   Unlike ``next_day``, this will never be ``None``.
 
-    * ``object_list``: A list of objects available for the given day. This
+* ``object_list``: A list of objects available for the given day. This
   variable's name depends on the ``template_object_name`` parameter, which
   is ``'object'`` by default. If ``template_object_name`` is ``'foo'``,
   this variable's name will be ``foo_list``.
@@ -597,21 +597,21 @@ future, the view will throw a 404 error by default, unless you set
 
 **Required arguments:**
 
-    * ``year``: The object's four-digit year (a string).
+* ``year``: The object's four-digit year (a string).
 
-    * ``month``: The object's month , formatted according to the
+* ``month``: The object's month , formatted according to the
   ``month_format`` argument.
 
-    * ``day``: The object's day , formatted according to the ``day_format``
+* ``day``: The object's day , formatted according to the ``day_format``
   argument.
 
-    * ``queryset``: A ``QuerySet`` that contains the object.
+* ``queryset``: A ``QuerySet`` that contains the object.
 
-    * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in
   the ``QuerySet``'s model that the generic view should use to look up the
   object according to ``year``, ``month`` and ``day``.
 
-    * Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
+* Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
 
   If you provide ``object_id``, it should be the value of the primary-key
   field for the object being displayed on this page.
@@ -622,19 +622,19 @@ future, the view will throw a 404 error by default, unless you set
 
 **Optional arguments:**
 
-    * ``month_format``: A format string that regulates what format the ``month``
+* ``month_format``: A format string that regulates what format the ``month``
   parameter uses. This should be in the syntax accepted by Python's
   :func:`~time.strftime`. It's set to ``"%b"`` by default, which is a
   three-letter month abbreviation. To change it to use numbers, use
   ``"%m"``.
 
-    * ``day_format``: Like ``month_format``, but for the ``day`` parameter.
+* ``day_format``: Like ``month_format``, but for the ``day`` parameter.
   It defaults to ``"%d"`` (day of the month as a decimal number, 01-31).
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_name_field``: The name of a field on the object whose value is
+* ``template_name_field``: The name of a field on the object whose value is
   the template name to use. This lets you store template names in the data.
   In other words, if your object has a field ``'the_template'`` that
   contains a string ``'foo.html'``, and you set ``template_name_field`` to
@@ -643,24 +643,24 @@ future, the view will throw a 404 error by default, unless you set
 
   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_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    * ``allow_future``: A boolean specifying whether to include "future"
+* ``allow_future``: A boolean specifying whether to include "future"
   objects on this page, where "future" means objects in which the field
   specified in ``date_field`` is greater than the current date/time. By
   default, this is ``False``.
@@ -674,7 +674,7 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``object``: The object. This variable's name depends on the
+* ``object``: The object. This variable's name depends on the
   ``template_object_name`` parameter, which is ``'object'`` by default. If
   ``template_object_name`` is ``'foo'``, this variable's name will be
   ``foo``.
@@ -698,44 +698,44 @@ A page representing a list of objects.
 
 **Required arguments:**
 
-    * ``queryset``: A ``QuerySet`` that represents the objects.
+* ``queryset``: A ``QuerySet`` that represents the objects.
 
 **Optional arguments:**
 
-    * ``paginate_by``: An integer specifying how many objects should be
+* ``paginate_by``: An integer specifying how many objects should be
   displayed per page. If this is given, the view will paginate objects with
   ``paginate_by`` objects per page. The view will expect either a ``page``
   query string parameter (via ``GET``) or a ``page`` variable specified in
   the URLconf. See `Notes on pagination`_ below.
 
-    * ``page``: The current page number, as an integer, or the string
+* ``page``: The current page number, as an integer, or the string
   ``'last'``. This is 1-based. See `Notes on pagination`_ below.
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``allow_empty``: A boolean specifying whether to display the page if no
+* ``allow_empty``: A boolean specifying whether to display the page if no
   objects are available. If this is ``False`` and no objects are available,
   the view will raise a 404 instead of displaying an empty page. By
   default, this is ``True``.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``. The
   view will append ``'_list'`` to the value of this parameter in
   determining the variable's name.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
 **Template name:**
@@ -747,20 +747,20 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``object_list``: The list of objects. This variable's name depends on the
+* ``object_list``: The list of objects. This variable's name depends on the
   ``template_object_name`` parameter, which is ``'object'`` by default. If
   ``template_object_name`` is ``'foo'``, this variable's name will be
   ``foo_list``.
 
-    * ``is_paginated``: A boolean representing whether the results are
+* ``is_paginated``: A boolean representing whether the results are
   paginated. Specifically, this is set to ``False`` if the number of
   available objects is less than or equal to ``paginate_by``.
 
 If the results are paginated, the context will contain these extra variables:
 
-    * ``paginator``: An instance of ``django.core.paginator.Paginator``.
+* ``paginator``: An instance of ``django.core.paginator.Paginator``.
 
-    * ``page_obj``: An instance of ``django.core.paginator.Page``.
+* ``page_obj``: An instance of ``django.core.paginator.Page``.
 
 Notes on pagination
 ~~~~~~~~~~~~~~~~~~~
@@ -768,17 +768,17 @@ Notes on pagination
 If ``paginate_by`` is specified, Django will paginate the results. You can
 specify the page number in the URL in one of two ways:
 
-    * Use the ``page`` parameter in the URLconf. For example, this is what
+* Use the ``page`` parameter in the URLconf. For example, this is what
   your URLconf might look like::
 
     (r'^objects/page(?P<page>[0-9]+)/$', 'object_list', dict(info_dict))
 
-    * Pass the page number via the ``page`` query-string parameter. For
+* Pass the page number via the ``page`` query-string parameter. For
   example, a URL would look like this::
 
     /objects/?page=3
 
-    * To loop over all the available page numbers, use the ``page_range``
+* To loop over all the available page numbers, use the ``page_range``
   variable. You can iterate over the list provided by ``page_range``
   to create a link to every page of results.
 
@@ -810,9 +810,9 @@ A page representing an individual object.
 
 **Required arguments:**
 
-    * ``queryset``: A ``QuerySet`` that contains the object.
+* ``queryset``: A ``QuerySet`` that contains the object.
 
-    * Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
+* Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
 
   If you provide ``object_id``, it should be the value of the primary-key
   field for the object being displayed on this page.
@@ -823,10 +823,10 @@ A page representing an individual object.
 
 **Optional arguments:**
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_name_field``: The name of a field on the object whose value is
+* ``template_name_field``: The name of a field on the object whose value is
   the template name to use. This lets you store template names in the data.
   In other words, if your object has a field ``'the_template'`` that
   contains a string ``'foo.html'``, and you set ``template_name_field`` to
@@ -835,21 +835,21 @@ A page representing an individual object.
 
   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_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``.
 
-    * ``mimetype``: The MIME type to use for the resulting document. Defaults
+* ``mimetype``: The MIME type to use for the resulting document. Defaults
   to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
 **Template name:**
@@ -861,7 +861,7 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``object``: The object. This variable's name depends on the
+* ``object``: The object. This variable's name depends on the
   ``template_object_name`` parameter, which is ``'object'`` by default. If
   ``template_object_name`` is ``'foo'``, this variable's name will be
   ``foo``.
@@ -884,7 +884,7 @@ validation errors (if there are any) and saving the object.
 
 **Required arguments:**
 
-    * Either ``form_class`` or ``model`` is required.
+* Either ``form_class`` or ``model`` is required.
 
   If you provide ``form_class``, it should be a ``django.forms.ModelForm``
   subclass. Use this argument when you need to customize the model's form.
@@ -896,14 +896,14 @@ validation errors (if there are any) and saving the object.
 
 **Optional arguments:**
 
-    * ``post_save_redirect``: A URL to which the view will redirect after
+* ``post_save_redirect``: A URL to which the view will redirect after
   saving the object. By default, it's ``object.get_absolute_url()``.
 
   ``post_save_redirect`` may contain dictionary string formatting, which
   will be interpolated against the object's field attributes. For example,
   you could use ``post_save_redirect="/polls/%(slug)s/"``.
 
-    * ``login_required``: A boolean that designates whether a user must be
+* ``login_required``: A boolean that designates whether a user must be
   logged in, in order to see the page and save changes. This hooks into the
   Django :doc:`authentication system </topics/auth>`. By default, this is
   ``False``.
@@ -911,18 +911,18 @@ validation errors (if there are any) and saving the object.
   If this is ``True``, and a non-logged-in user attempts to visit this page
   or save the form, Django will redirect the request to ``/accounts/login/``.
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
 **Template name:**
@@ -934,7 +934,7 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``form``: A ``django.forms.ModelForm`` instance representing the form
+* ``form``: A ``django.forms.ModelForm`` instance representing the form
   for creating the object. This lets you refer to form fields easily in the
   template system.
 
@@ -960,7 +960,7 @@ model class.
 
 **Required arguments:**
 
-    * Either ``form_class`` or ``model`` is required.
+* Either ``form_class`` or ``model`` is required.
 
   If you provide ``form_class``, it should be a ``django.forms.ModelForm``
   subclass. Use this argument when you need to customize the model's form.
@@ -970,7 +970,7 @@ model class.
   Otherwise, ``model`` should be a Django model class and the form used
   will be a standard ``ModelForm`` for ``model``.
 
-    * Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
+* Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
 
   If you provide ``object_id``, it should be the value of the primary-key
   field for the object being displayed on this page.
@@ -981,14 +981,14 @@ model class.
 
 **Optional arguments:**
 
-    * ``post_save_redirect``: A URL to which the view will redirect after
+* ``post_save_redirect``: A URL to which the view will redirect after
   saving the object. By default, it's ``object.get_absolute_url()``.
 
   ``post_save_redirect`` may contain dictionary string formatting, which
   will be interpolated against the object's field attributes. For example,
   you could use ``post_save_redirect="/polls/%(slug)s/"``.
 
-    * ``login_required``: A boolean that designates whether a user must be
+* ``login_required``: A boolean that designates whether a user must be
   logged in, in order to see the page and save changes. This hooks into the
   Django :doc:`authentication system </topics/auth>`. By default, this is
   ``False``.
@@ -997,21 +997,21 @@ model class.
   or save the form, Django will redirect to :setting:`LOGIN_URL` (which
   defaults to ``/accounts/login/``).
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``.
 
 **Template name:**
@@ -1023,7 +1023,7 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``form``: A ``django.forms.ModelForm`` instance representing the form
+* ``form``: A ``django.forms.ModelForm`` instance representing the form
   for editing the object. This lets you refer to form fields easily in the
   template system.
 
@@ -1037,7 +1037,7 @@ In addition to ``extra_context``, the template's context will be:
   See the :doc:`forms documentation </topics/forms/index>` for more
   information about using ``Form`` objects in templates.
 
-    * ``object``: The original object being edited. This variable's name
+* ``object``: The original object being edited. This variable's name
   depends on the ``template_object_name`` parameter, which is ``'object'``
   by default. If ``template_object_name`` is ``'foo'``, this variable's
   name will be ``foo``.
@@ -1054,10 +1054,10 @@ contain a form that POSTs to the same URL.
 
 **Required arguments:**
 
-    * ``model``: The Django model class of the object that the form will
+* ``model``: The Django model class of the object that the form will
   delete.
 
-    * Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
+* Either ``object_id`` or (``slug`` *and* ``slug_field``) is required.
 
   If you provide ``object_id``, it should be the value of the primary-key
   field for the object being displayed on this page.
@@ -1066,12 +1066,12 @@ contain a form that POSTs to the same URL.
   ``slug_field`` should be the name of the slug field in the ``QuerySet``'s
   model. By default, ``slug_field`` is ``'slug'``.
 
-    * ``post_delete_redirect``: A URL to which the view will redirect after
+* ``post_delete_redirect``: A URL to which the view will redirect after
   deleting the object.
 
 **Optional arguments:**
 
-    * ``login_required``: A boolean that designates whether a user must be
+* ``login_required``: A boolean that designates whether a user must be
   logged in, in order to see the page and save changes. This hooks into the
   Django :doc:`authentication system </topics/auth>`. By default, this is
   ``False``.
@@ -1080,21 +1080,21 @@ contain a form that POSTs to the same URL.
   or save the form, Django will redirect to :setting:`LOGIN_URL` (which
   defaults to ``/accounts/login/``).
 
-    * ``template_name``: The full name of a template to use in rendering the
+* ``template_name``: The full name of a template to use in rendering the
   page. This lets you override the default template name (see below).
 
-    * ``template_loader``: The template loader to use when loading the
+* ``template_loader``: The template loader to use when loading the
   template. By default, it's ``django.template.loader``.
 
-    * ``extra_context``: A dictionary of values to add to the template
+* ``extra_context``: A dictionary of values to add to the template
   context. By default, this is an empty dictionary. If a value in the
   dictionary is callable, the generic view will call it
   just before rendering the template.
 
-    * ``context_processors``: A list of template-context processors to apply to
+* ``context_processors``: A list of template-context processors to apply to
   the view's template.
 
-    * ``template_object_name``:  Designates the name of the template variable
+* ``template_object_name``:  Designates the name of the template variable
   to use in the template context. By default, this is ``'object'``.
 
 **Template name:**
@@ -1106,7 +1106,7 @@ If ``template_name`` isn't specified, this view will use the template
 
 In addition to ``extra_context``, the template's context will be:
 
-    * ``object``: The original object that's about to be deleted. This
+* ``object``: The original object that's about to be deleted. This
   variable's name depends on the ``template_object_name`` parameter, which
   is ``'object'`` by default. If ``template_object_name`` is ``'foo'``,
   this variable's name will be ``foo``.

docs/ref/middleware.txt

@@ -36,10 +36,10 @@ defines. See the :doc:`cache documentation </topics/cache>`.
 
 Adds a few conveniences for perfectionists:
 
-    * Forbids access to user agents in the :setting:`DISALLOWED_USER_AGENTS`
+* Forbids access to user agents in the :setting:`DISALLOWED_USER_AGENTS`
   setting, which should be a list of strings.
 
-    * Performs URL rewriting based on the :setting:`APPEND_SLASH` and
+* Performs URL rewriting based on the :setting:`APPEND_SLASH` and
   :setting:`PREPEND_WWW` settings.
 
   If :setting:`APPEND_SLASH` is ``True`` and the initial URL doesn't end
@@ -61,10 +61,10 @@ Adds a few conveniences for perfectionists:
   indexer would treat them as separate URLs -- so it's best practice to
   normalize URLs.
 
-    * Sends broken link notification emails to :setting:`MANAGERS` if
+* Sends broken link notification emails to :setting:`MANAGERS` if
   :setting:`SEND_BROKEN_LINK_EMAILS` is set to ``True``.
 
-    * Handles ETags based on the :setting:`USE_ETAGS` setting. If
+* Handles ETags based on the :setting:`USE_ETAGS` setting. If
   :setting:`USE_ETAGS` is set to ``True``, Django will calculate an ETag
   for each request by MD5-hashing the page content, and it'll take care of
   sending ``Not Modified`` responses, if appropriate.

docs/ref/models/fields.txt

@@ -541,17 +541,17 @@ widget).
 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
+1. 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, making
+2. Add the :class:`FileField` or :class:`ImageField` to your model, making
    sure to define the :attr:`~FileField.upload_to` option to tell Django
    to which subdirectory of :setting:`MEDIA_ROOT` it should upload files.
 
-    3. All that will be stored in your database is a path to the file
+3. 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.core.files.File.url` function provided by
    Django. For example, if your :class:`ImageField` is called ``mug_shot``,

docs/ref/models/instances.txt

@@ -34,9 +34,9 @@ Validating objects
 
 There are three steps involved in validating a model:
 
-    1. Validate the model fields
+1. Validate the model fields
-    2. Validate the model as a whole
+2. Validate the model as a whole
-    3. Validate the field uniqueness
+3. Validate the field uniqueness
 
 All three steps are performed when you call a model's
 :meth:`~Model.full_clean()` method.
@@ -211,12 +211,12 @@ What happens when you save?
 
 When you save an object, Django performs the following steps:
 
-    1. **Emit a pre-save signal.** The :doc:`signal </ref/signals>`
+1. **Emit a pre-save signal.** The :doc:`signal </ref/signals>`
    :attr:`django.db.models.signals.pre_save` is sent, allowing any
    functions listening for that signal to take some customized
    action.
 
-    2. **Pre-process the data.** Each field on the object is asked to
+2. **Pre-process the data.** Each field on the object is asked to
    perform any automated data modification that the field may need
    to perform.
 
@@ -228,7 +228,7 @@ When you save an object, Django performs the following steps:
    documentation doesn't yet include a list of all the fields with this
    "special behavior.")
 
-    3. **Prepare the data for the database.** Each field is asked to provide
+3. **Prepare the data for the database.** Each field is asked to provide
    its current value in a data type that can be written to the database.
 
    Most fields require *no* data preparation. Simple data types, such as
@@ -240,11 +240,11 @@ When you save an object, Django performs the following steps:
    objects, so the field value must be converted into an ISO-compliant date
    string for insertion into the database.
 
-    4. **Insert the data into the database.** The pre-processed, prepared
+4. **Insert the data into the database.** The pre-processed, prepared
    data is then composed into an SQL statement for insertion into the
    database.
 
-    5. **Emit a post-save signal.** The signal
+5. **Emit a post-save signal.** The signal
    :attr:`django.db.models.signals.post_save` is sent, allowing
    any functions listening for that signal to take some customized
    action.
@@ -257,13 +257,13 @@ for creating and changing objects. Django abstracts the need to use ``INSERT``
 or ``UPDATE`` SQL statements. Specifically, when you call ``save()``, Django
 follows this algorithm:
 
-    * If the object's primary key attribute is set to a value that evaluates to
+* If the object's primary key attribute is set to a value that evaluates to
   ``True`` (i.e., a value other than ``None`` or the empty string), Django
   executes a ``SELECT`` query to determine whether a record with the given
   primary key already exists.
-    * If the record with the given primary key does already exist, Django
+* If the record with the given primary key does already exist, Django
   executes an ``UPDATE`` query.
-    * If the object's primary key attribute is *not* set, or if it's set but a
+* If the object's primary key attribute is *not* set, or if it's set but a
   record doesn't exist, Django executes an ``INSERT``.
 
 The one gotcha here is that you should be careful not to specify a primary-key

docs/ref/request-response.txt

@@ -549,8 +549,8 @@ Passing iterators
 Finally, you can pass ``HttpResponse`` an iterator rather than passing it
 hard-coded strings. If you use this technique, follow these guidelines:
 
-    * The iterator should return strings.
+* The iterator should return strings.
-    * If an :class:`HttpResponse` has been initialized with an iterator as its
+* 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
   object. Doing so will raise ``Exception``.
 

docs/ref/settings.txt

@@ -147,12 +147,12 @@ Default: ``''`` (Empty string)
 
 The cache backend to use. The built-in cache backends are:
 
-    * ``'django.core.cache.backends.db.DatabaseCache'``
+* ``'django.core.cache.backends.db.DatabaseCache'``
-    * ``'django.core.cache.backends.dummy.DummyCache'``
+* ``'django.core.cache.backends.dummy.DummyCache'``
-    * ``'django.core.cache.backends.filebased.FileBasedCache'``
+* ``'django.core.cache.backends.filebased.FileBasedCache'``
-    * ``'django.core.cache.backends.locmem.LocMemCache'``
+* ``'django.core.cache.backends.locmem.LocMemCache'``
-    * ``'django.core.cache.backends.memcached.MemcachedCache'``
+* ``'django.core.cache.backends.memcached.MemcachedCache'``
-    * ``'django.core.cache.backends.memcached.PyLibMCCache'``
+* ``'django.core.cache.backends.memcached.PyLibMCCache'``
 
 You can use a cache backend that doesn't ship with Django by setting
 :setting:`BACKEND <CACHE-BACKEND>` to a fully-qualified path of a cache
@@ -412,10 +412,10 @@ Default: ``''`` (Empty string)
 
 The database backend to use. The built-in database backends are:
 
-    * ``'django.db.backends.postgresql_psycopg2'``
+* ``'django.db.backends.postgresql_psycopg2'``
-    * ``'django.db.backends.mysql'``
+* ``'django.db.backends.mysql'``
-    * ``'django.db.backends.sqlite3'``
+* ``'django.db.backends.sqlite3'``
-    * ``'django.db.backends.oracle'``
+* ``'django.db.backends.oracle'``
 
 You can use a database backend that doesn't ship with Django by setting
 ``ENGINE`` to a fully-qualified path (i.e.
@@ -1165,8 +1165,8 @@ Default: ``()`` (Empty tuple)
 
 A tuple of IP addresses, as strings, that:
 
-    * See debug comments, when :setting:`DEBUG` is ``True``
+* See debug comments, when :setting:`DEBUG` is ``True``
-    * Receive X headers if the ``XViewMiddleware`` is installed (see
+* Receive X headers if the ``XViewMiddleware`` is installed (see
   :doc:`/topics/http/middleware`)
 
 .. setting:: LANGUAGE_CODE
@@ -1649,10 +1649,10 @@ Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
 
-    * ``'django.contrib.sessions.backends.db'``
+* ``'django.contrib.sessions.backends.db'``
-    * ``'django.contrib.sessions.backends.file'``
+* ``'django.contrib.sessions.backends.file'``
-    * ``'django.contrib.sessions.backends.cache'``
+* ``'django.contrib.sessions.backends.cache'``
-    * ``'django.contrib.sessions.backends.cached_db'``
+* ``'django.contrib.sessions.backends.cached_db'``
 
 See :doc:`/topics/http/sessions`.
 
@@ -1989,11 +1989,11 @@ and models will automatically operate in the correct time zone.
 However, Django won't set the ``TZ`` environment variable under the
 following conditions:
 
- * If you're using the manual configuration option as described in
+* If you're using the manual configuration option as described in
   :ref:`manually configuring settings
   <settings-without-django-settings-module>`, or
 
- * If you specify ``TIME_ZONE = None``. This will cause Django to fall
+* If you specify ``TIME_ZONE = None``. This will cause Django to fall
   back to using the system timezone.
 
 If Django doesn't set the ``TZ`` environment variable, it's up to you

docs/ref/signals.txt

@@ -62,24 +62,22 @@ Arguments sent with this signal:
     A dictionary of keyword arguments passed to
     :meth:`~django.db.models.Model.__init__`:.
 
-For example, the :doc:`tutorial </intro/tutorial01>` has this line:
+For example, the :doc:`tutorial </intro/tutorial01>` has this line::
-
-.. code-block:: python
 
     p = Poll(question="What's up?", pub_date=datetime.now())
 
 The arguments sent to a :data:`pre_init` handler would be:
 
-    ==========  ===============================================================
+==========  ===============================================================
-    Argument    Value
+Argument    Value
-    ==========  ===============================================================
+==========  ===============================================================
-    ``sender``  ``Poll`` (the class itself)
+``sender``  ``Poll`` (the class itself)
 
-    ``args``    ``[]`` (an empty list because there were no positional
+``args``    ``[]`` (an empty list because there were no positional
             arguments passed to ``__init__``.)
 
-    ``kwargs``  ``{'question': "What's up?", 'pub_date': datetime.now()}``
+``kwargs``  ``{'question': "What's up?", 'pub_date': datetime.now()}``
-    ==========  ===============================================================
+==========  ===============================================================
 
 post_init
 ---------
@@ -269,12 +267,11 @@ Arguments sent with this signal:
     The database alias being used.
 
 For example, if a ``Pizza`` can have multiple ``Topping`` objects, modeled
-like this:
+like this::
-
-.. code-block:: python
 
     class Topping(models.Model):
         # ...
+        pass
 
     class Pizza(models.Model):
         # ...
@@ -282,62 +279,58 @@ like this:
 
 If we would do something like this:
 
-.. code-block:: python
-
     >>> p = Pizza.object.create(...)
     >>> t = Topping.objects.create(...)
     >>> p.toppings.add(t)
 
 the arguments sent to a :data:`m2m_changed` handler would be:
 
-    ==============  ============================================================
+==============  ============================================================
-    Argument        Value
+Argument        Value
-    ==============  ============================================================
+==============  ============================================================
-    ``sender``      ``Pizza.toppings.through`` (the intermediate m2m class)
+``sender``      ``Pizza.toppings.through`` (the intermediate m2m class)
 
-    ``instance``    ``p`` (the ``Pizza`` instance being modified)
+``instance``    ``p`` (the ``Pizza`` instance being modified)
 
-    ``action``      ``"pre_add"`` (followed by a separate signal with ``"post_add"``)
+``action``      ``"pre_add"`` (followed by a separate signal with ``"post_add"``)
 
-    ``reverse``     ``False`` (``Pizza`` contains the :class:`ManyToManyField`,
+``reverse``     ``False`` (``Pizza`` contains the :class:`ManyToManyField`,
                 so this call modifies the forward relation)
 
-    ``model``       ``Topping`` (the class of the objects added to the
+``model``       ``Topping`` (the class of the objects added to the
                 ``Pizza``)
 
-    ``pk_set``      ``[t.id]`` (since only ``Topping t`` was added to the relation)
+``pk_set``      ``[t.id]`` (since only ``Topping t`` was added to the relation)
 
-    ``using``       ``"default"`` (since the default router sends writes here)
+``using``       ``"default"`` (since the default router sends writes here)
-    ==============  ============================================================
+==============  ============================================================
 
-And if we would then do something like this:
+And if we would then do something like this::
-
-.. code-block:: python
 
     >>> t.pizza_set.remove(p)
 
 the arguments sent to a :data:`m2m_changed` handler would be:
 
-    ==============  ============================================================
+==============  ============================================================
-    Argument        Value
+Argument        Value
-    ==============  ============================================================
+==============  ============================================================
-    ``sender``      ``Pizza.toppings.through`` (the intermediate m2m class)
+``sender``      ``Pizza.toppings.through`` (the intermediate m2m class)
 
-    ``instance``    ``t`` (the ``Topping`` instance being modified)
+``instance``    ``t`` (the ``Topping`` instance being modified)
 
-    ``action``      ``"pre_remove"`` (followed by a separate signal with ``"post_remove"``)
+``action``      ``"pre_remove"`` (followed by a separate signal with ``"post_remove"``)
 
-    ``reverse``     ``True`` (``Pizza`` contains the :class:`ManyToManyField`,
+``reverse``     ``True`` (``Pizza`` contains the :class:`ManyToManyField`,
                 so this call modifies the reverse relation)
 
-    ``model``       ``Pizza`` (the class of the objects removed from the
+``model``       ``Pizza`` (the class of the objects removed from the
                 ``Topping``)
 
-    ``pk_set``      ``[p.id]`` (since only ``Pizza p`` was removed from the
+``pk_set``      ``[p.id]`` (since only ``Pizza p`` was removed from the
                 relation)
 
-    ``using``       ``"default"`` (since the default router sends writes here)
+``using``       ``"default"`` (since the default router sends writes here)
-    ==============  ============================================================
+==============  ============================================================
 
 class_prepared
 --------------

docs/ref/template-response.txt

@@ -193,13 +193,13 @@ final byte stream that can be served to the client.
 There are three circumstances under which a TemplateResponse will be
 rendered:
 
-    * When the TemplateResponse instance is explicitly rendered, using
+* When the TemplateResponse instance is explicitly rendered, using
   the :meth:`SimpleTemplateResponse.render()` method.
 
-    * When the content of the response is explicitly set by assigning
+* When the content of the response is explicitly set by assigning
   :attr:`response.content`.
 
-    * After passing through template response middleware, but before
+* After passing through template response middleware, but before
   passing through response middleware.
 
 A TemplateResponse can only be rendered once. The first call to

docs/ref/templates/api.txt

@@ -56,8 +56,8 @@ Using the template system
 
 Using the template system in Python is a two-step process:
 
-    * First, you compile the raw template code into a ``Template`` object.
+* First, you compile the raw template code into a ``Template`` object.
-    * Then, you call the ``render()`` method of the ``Template`` object with a
+* Then, you call the ``render()`` method of the ``Template`` object with a
   given context.
 
 Compiling a string
@@ -91,9 +91,9 @@ multiple contexts -- with it. The ``Context`` class lives at
 :class:`django.template.Context`, and the constructor takes two (optional)
 arguments:
 
-    * A dictionary mapping variable names to variable values.
+* A dictionary mapping variable names to variable values.
 
-    * The name of the current application. This application name is used
+* The name of the current application. This application name is used
   to help :ref:`resolve namespaced URLs<topics-http-reversing-url-namespaces>`.
   If you're not using namespaced URLs, you can ignore this argument.
 
@@ -118,9 +118,9 @@ Dots have a special meaning in template rendering. A dot in a variable name
 signifies a **lookup**. Specifically, when the template system encounters a
 dot in a variable name, it tries the following lookups, in this order:
 
-    * Dictionary lookup. Example: ``foo["bar"]``
+* Dictionary lookup. Example: ``foo["bar"]``
-    * Attribute lookup. Example: ``foo.bar``
+* Attribute lookup. Example: ``foo.bar``
-    * List-index lookup. Example: ``foo[bar]``
+* List-index lookup. Example: ``foo[bar]``
 
 The template system uses the first lookup type that works. It's short-circuit
 logic. Here are a few examples::
@@ -161,7 +161,7 @@ it. Example::
 Callable variables are slightly more complex than variables which only require
 straight lookups. Here are some things to keep in mind:
 
-    * If the variable raises an exception when called, the exception will be
+* If the variable raises an exception when called, the exception will be
   propagated, unless the exception has an attribute
   ``silent_variable_failure`` whose value is ``True``. If the exception
   *does* have a ``silent_variable_failure`` attribute whose value is
@@ -192,10 +192,10 @@ straight lookups. Here are some things to keep in mind:
   with Django model objects, any ``DoesNotExist`` exception will fail
   silently.
 
-    * A variable can only be called if it has no required arguments. Otherwise,
+* A variable can only be called if it has no required arguments. Otherwise,
   the system will return an empty string.
 
-    * Obviously, there can be side effects when calling some variables, and
+* Obviously, there can be side effects when calling some variables, and
   it'd be either foolish or a security hole to allow the template system
   to access them.
 
@@ -217,7 +217,7 @@ straight lookups. Here are some things to keep in mind:
         self.database_record.delete()
     sensitive_function.alters_data = True
 
-    * .. versionadded:: 1.4
+* .. versionadded:: 1.4
      Occasionally you may want to turn off this feature for other reasons,
      and tell the template system to leave a variable un-called no matter
      what.  To do so, set a ``do_not_call_in_templates`` attribute on the
@@ -427,11 +427,11 @@ django.contrib.auth.context_processors.auth
 If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
 ``RequestContext`` will contain these three variables:
 
-    * ``user`` -- An ``auth.User`` instance representing the currently
+* ``user`` -- An ``auth.User`` instance representing the currently
   logged-in user (or an ``AnonymousUser`` instance, if the client isn't
   logged in).
 
-    * ``perms`` -- An instance of
+* ``perms`` -- An instance of
   ``django.contrib.auth.context_processors.PermWrapper``, representing the
   permissions that the currently logged-in user has.
 
@@ -452,9 +452,9 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
 :setting:`DEBUG` setting is set to ``True`` and the request's IP address
 (``request.META['REMOTE_ADDR']``) is in the :setting:`INTERNAL_IPS` setting:
 
-    * ``debug`` -- ``True``. You can use this in templates to test whether
+* ``debug`` -- ``True``. You can use this in templates to test whether
   you're in :setting:`DEBUG` mode.
-    * ``sql_queries`` -- A list of ``{'sql': ..., 'time': ...}`` dictionaries,
+* ``sql_queries`` -- A list of ``{'sql': ..., 'time': ...}`` dictionaries,
   representing every SQL query that has happened so far during the request
   and how long it took. The list is in order by query.
 
@@ -464,8 +464,8 @@ django.core.context_processors.i18n
 If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
 ``RequestContext`` will contain these two variables:
 
-    * ``LANGUAGES`` -- The value of the :setting:`LANGUAGES` setting.
+* ``LANGUAGES`` -- The value of the :setting:`LANGUAGES` setting.
-    * ``LANGUAGE_CODE`` -- ``request.LANGUAGE_CODE``, if it exists. Otherwise,
+* ``LANGUAGE_CODE`` -- ``request.LANGUAGE_CODE``, if it exists. Otherwise,
   the value of the :setting:`LANGUAGE_CODE` setting.
 
 See :doc:`/topics/i18n/index` for more.
@@ -511,7 +511,7 @@ django.contrib.messages.context_processors.messages
 If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
 ``RequestContext`` will contain a single additional variable:
 
-    * ``messages`` -- A list of messages (as strings) that have been set
+* ``messages`` -- A list of messages (as strings) that have been set
   via the user model (using ``user.message_set.create``) or through
   the :doc:`messages framework </ref/contrib/messages>`.
 
@@ -589,16 +589,16 @@ For example, if you call ``get_template('story_detail.html')`` and have the
 above :setting:`TEMPLATE_DIRS` setting, here are the files Django will look for,
 in order:
 
-    * ``/home/html/templates/lawrence.com/story_detail.html``
+* ``/home/html/templates/lawrence.com/story_detail.html``
-    * ``/home/html/templates/default/story_detail.html``
+* ``/home/html/templates/default/story_detail.html``
 
 If you call ``select_template(['story_253_detail.html', 'story_detail.html'])``,
 here's what Django will look for:
 
-    * ``/home/html/templates/lawrence.com/story_253_detail.html``
+* ``/home/html/templates/lawrence.com/story_253_detail.html``
-    * ``/home/html/templates/default/story_253_detail.html``
+* ``/home/html/templates/default/story_253_detail.html``
-    * ``/home/html/templates/lawrence.com/story_detail.html``
+* ``/home/html/templates/lawrence.com/story_detail.html``
-    * ``/home/html/templates/default/story_detail.html``
+* ``/home/html/templates/default/story_detail.html``
 
 When Django finds a template that exists, it stops looking.
 
@@ -628,8 +628,8 @@ To load a template that's within a subdirectory, just use a slash, like so::
 Using the same :setting:`TEMPLATE_DIRS` setting from above, this example
 ``get_template()`` call will attempt to load the following templates:
 
-    * ``/home/html/templates/lawrence.com/news/story_detail.html``
+* ``/home/html/templates/lawrence.com/news/story_detail.html``
-    * ``/home/html/templates/default/news/story_detail.html``
+* ``/home/html/templates/default/news/story_detail.html``
 
 .. _template-loaders:
 
@@ -739,12 +739,12 @@ The ``render_to_string`` shortcut takes one required argument --
 and render (or a list of template names, in which case Django will use
 the first template in the list that exists) -- and two optional arguments:
 
-    dictionary
+dictionary
     A dictionary to be used as variables and values for the
     template's context. This can also be passed as the second
     positional argument.
 
-    context_instance
+context_instance
     An instance of ``Context`` or a subclass (e.g., an instance of
     ``RequestContext``) to use as the template's context. This can
     also be passed as the third positional argument.

docs/ref/templates/builtins.txt

@@ -201,10 +201,10 @@ Signals that this template extends a parent template.
 
 This tag can be used in two ways:
 
-   * ``{% extends "base.html" %}`` (with quotes) uses the literal value
+* ``{% extends "base.html" %}`` (with quotes) uses the literal value
   ``"base.html"`` as the name of the parent template to extend.
 
-   * ``{% extends variable %}`` uses the value of ``variable``. If the variable
+* ``{% extends variable %}`` uses the value of ``variable``. If the variable
   evaluates to a string, Django will use that string as the name of the
   parent template. If the variable evaluates to a ``Template`` object,
   Django will use that object as the parent template.
@@ -303,20 +303,20 @@ would display the keys and values of the dictionary::
 
 The for loop sets a number of variables available within the loop:
 
-    ==========================  ===============================================
+==========================  ===============================================
-    Variable                    Description
+Variable                    Description
-    ==========================  ===============================================
+==========================  ===============================================
-    ``forloop.counter``         The current iteration of the loop (1-indexed)
+``forloop.counter``         The current iteration of the loop (1-indexed)
-    ``forloop.counter0``        The current iteration of the loop (0-indexed)
+``forloop.counter0``        The current iteration of the loop (0-indexed)
-    ``forloop.revcounter``      The number of iterations from the end of the
+``forloop.revcounter``      The number of iterations from the end of the
                             loop (1-indexed)
-    ``forloop.revcounter0``     The number of iterations from the end of the
+``forloop.revcounter0``     The number of iterations from the end of the
                             loop (0-indexed)
-    ``forloop.first``           True if this is the first time through the loop
+``forloop.first``           True if this is the first time through the loop
-    ``forloop.last``            True if this is the last time through the loop
+``forloop.last``            True if this is the last time through the loop
-    ``forloop.parentloop``      For nested loops, this is the loop "above" the
+``forloop.parentloop``      For nested loops, this is the loop "above" the
                             current one
-    ==========================  ===============================================
+==========================  ===============================================
 
 for ... empty
 ^^^^^^^^^^^^^
@@ -526,11 +526,11 @@ expressions, it can be important to know how the operators are grouped when the
 expression is evaluated - that is, the precedence rules.  The precedence of the
 operators, from lowest to highest, is as follows:
 
- * ``or``
+* ``or``
- * ``and``
+* ``and``
- * ``not``
+* ``not``
- * ``in``
+* ``in``
- * ``==``, ``!=``, ``<``, ``>``, ``<=``, ``>=``
+* ``==``, ``!=``, ``<``, ``>``, ``<=``, ``>=``
 
 (This follows Python exactly). So, for example, the following complex
 :ttag:`if` tag:
@@ -660,12 +660,12 @@ the variable ``template_name``::
 An included template is rendered with the context of the template that's
 including it. This example produces the output ``"Hello, John"``:
 
-    * Context: variable ``person`` is set to ``"john"``.
+* Context: variable ``person`` is set to ``"john"``.
-    * Template::
+* Template::
 
     {% include "name_snippet.html" %}
 
-    * The ``name_snippet.html`` template::
+* The ``name_snippet.html`` template::
 
     {{ greeting }}, {{ person|default:"friend" }}!
 
@@ -771,13 +771,13 @@ is a list of people represented by dictionaries with ``first_name``,
 ...and you'd like to display a hierarchical list that is ordered by gender,
 like this:
 
-    * Male:
+* Male:
   * George Bush
   * Bill Clinton
-    * Female:
+* Female:
   * Margaret Thatcher
   * Condoleezza Rice
-    * Unknown:
+* Unknown:
   * Pat Smith
 
 You can use the ``{% regroup %}`` tag to group the list of people by gender.
@@ -805,9 +805,9 @@ attribute and calling the result ``gender_list``.
 ``{% regroup %}`` produces a list (in this case, ``gender_list``) of
 **group objects**. Each group object has two attributes:
 
-    * ``grouper`` -- the item that was grouped by (e.g., the string "Male" or
+* ``grouper`` -- the item that was grouped by (e.g., the string "Male" or
   "Female").
-    * ``list`` -- a list of all items in this group (e.g., a list of all people
+* ``list`` -- a list of all items in this group (e.g., a list of all people
   with gender='Male').
 
 Note that ``{% regroup %}`` does not order its input! Our example relies on
@@ -830,15 +830,15 @@ grouped together):
 With this input for ``people``, the example ``{% regroup %}`` template code
 above would result in the following output:
 
-    * Male:
+* Male:
   * Bill Clinton
-    * Unknown:
+* Unknown:
   * Pat Smith
-    * Female:
+* Female:
   * Margaret Thatcher
-    * Male:
+* Male:
   * George Bush
-    * Female:
+* Female:
   * Condoleezza Rice
 
 The easiest solution to this gotcha is to make sure in your view code that the
@@ -959,18 +959,18 @@ bits used in template tags, you must use the ``{% templatetag %}`` tag.
 
 The argument tells which template bit to output:
 
-    ==================  =======
+==================  =======
-    Argument            Outputs
+Argument            Outputs
-    ==================  =======
+==================  =======
-    ``openblock``       ``{%``
+``openblock``       ``{%``
-    ``closeblock``      ``%}``
+``closeblock``      ``%}``
-    ``openvariable``    ``{{``
+``openvariable``    ``{{``
-    ``closevariable``   ``}}``
+``closevariable``   ``}}``
-    ``openbrace``       ``{``
+``openbrace``       ``{``
-    ``closebrace``      ``}``
+``closebrace``      ``}``
-    ``opencomment``     ``{#``
+``opencomment``     ``{#``
-    ``closecomment``    ``#}``
+``closecomment``    ``#}``
-    ==================  =======
+==================  =======
 
 .. templatetag:: url
 
@@ -1250,75 +1250,75 @@ with some custom extensions.
 
 Available format strings:
 
-    ================  ========================================  =====================
+================  ========================================  =====================
-    Format character  Description                               Example output
+Format character  Description                               Example output
-    ================  ========================================  =====================
+================  ========================================  =====================
-    a                 ``'a.m.'`` or ``'p.m.'`` (Note that       ``'a.m.'``
+a                 ``'a.m.'`` or ``'p.m.'`` (Note that       ``'a.m.'``
                   this is slightly different than PHP's
                   output, because this includes periods
                   to match Associated Press style.)
-    A                 ``'AM'`` or ``'PM'``.                     ``'AM'``
+A                 ``'AM'`` or ``'PM'``.                     ``'AM'``
-    b                 Month, textual, 3 letters, lowercase.     ``'jan'``
+b                 Month, textual, 3 letters, lowercase.     ``'jan'``
-    B                 Not implemented.
+B                 Not implemented.
-    c                 ISO 8601 format. (Note: unlike others     ``2008-01-02T10:30:00.000123+02:00``,
+c                 ISO 8601 format. (Note: unlike others     ``2008-01-02T10:30:00.000123+02:00``,
                   formatters, such as "Z", "O" or "r",      or ``2008-01-02T10:30:00.000123`` if the datetime is naive
                   the "c" formatter will not add timezone
                   offset if value is a naive datetime
                   (see :class:`datetime.tzinfo`).
-    d                 Day of the month, 2 digits with           ``'01'`` to ``'31'``
+d                 Day of the month, 2 digits with           ``'01'`` to ``'31'``
                   leading zeros.
-    D                 Day of the week, textual, 3 letters.      ``'Fri'``
+D                 Day of the week, textual, 3 letters.      ``'Fri'``
-    E                 Month, locale specific alternative
+E                 Month, locale specific alternative
                   representation usually used for long
                   date representation.                      ``'listopada'`` (for Polish locale, as opposed to ``'Listopad'``)
-    f                 Time, in 12-hour hours and minutes,       ``'1'``, ``'1:30'``
+f                 Time, in 12-hour hours and minutes,       ``'1'``, ``'1:30'``
                   with minutes left off if they're zero.
                   Proprietary extension.
-    F                 Month, textual, long.                     ``'January'``
+F                 Month, textual, long.                     ``'January'``
-    g                 Hour, 12-hour format without leading      ``'1'`` to ``'12'``
+g                 Hour, 12-hour format without leading      ``'1'`` to ``'12'``
                   zeros.
-    G                 Hour, 24-hour format without leading      ``'0'`` to ``'23'``
+G                 Hour, 24-hour format without leading      ``'0'`` to ``'23'``
                   zeros.
-    h                 Hour, 12-hour format.                     ``'01'`` to ``'12'``
+h                 Hour, 12-hour format.                     ``'01'`` to ``'12'``
-    H                 Hour, 24-hour format.                     ``'00'`` to ``'23'``
+H                 Hour, 24-hour format.                     ``'00'`` to ``'23'``
-    i                 Minutes.                                  ``'00'`` to ``'59'``
+i                 Minutes.                                  ``'00'`` to ``'59'``
-    I                 Not implemented.
+I                 Not implemented.
-    j                 Day of the month without leading          ``'1'`` to ``'31'``
+j                 Day of the month without leading          ``'1'`` to ``'31'``
                   zeros.
-    l                 Day of the week, textual, long.           ``'Friday'``
+l                 Day of the week, textual, long.           ``'Friday'``
-    L                 Boolean for whether it's a leap year.     ``True`` or ``False``
+L                 Boolean for whether it's a leap year.     ``True`` or ``False``
-    m                 Month, 2 digits with leading zeros.       ``'01'`` to ``'12'``
+m                 Month, 2 digits with leading zeros.       ``'01'`` to ``'12'``
-    M                 Month, textual, 3 letters.                ``'Jan'``
+M                 Month, textual, 3 letters.                ``'Jan'``
-    n                 Month without leading zeros.              ``'1'`` to ``'12'``
+n                 Month without leading zeros.              ``'1'`` to ``'12'``
-    N                 Month abbreviation in Associated Press    ``'Jan.'``, ``'Feb.'``, ``'March'``, ``'May'``
+N                 Month abbreviation in Associated Press    ``'Jan.'``, ``'Feb.'``, ``'March'``, ``'May'``
                   style. Proprietary extension.
-    O                 Difference to Greenwich time in hours.    ``'+0200'``
+O                 Difference to Greenwich time in hours.    ``'+0200'``
-    P                 Time, in 12-hour hours, minutes and       ``'1 a.m.'``, ``'1:30 p.m.'``, ``'midnight'``, ``'noon'``, ``'12:30 p.m.'``
+P                 Time, in 12-hour hours, minutes and       ``'1 a.m.'``, ``'1:30 p.m.'``, ``'midnight'``, ``'noon'``, ``'12:30 p.m.'``
                   'a.m.'/'p.m.', with minutes left off
                   if they're zero and the special-case
                   strings 'midnight' and 'noon' if
                   appropriate. Proprietary extension.
-    r                 :rfc:`2822` formatted date.               ``'Thu, 21 Dec 2000 16:01:07 +0200'``
+r                 :rfc:`2822` formatted date.               ``'Thu, 21 Dec 2000 16:01:07 +0200'``
-    s                 Seconds, 2 digits with leading zeros.     ``'00'`` to ``'59'``
+s                 Seconds, 2 digits with leading zeros.     ``'00'`` to ``'59'``
-    S                 English ordinal suffix for day of the     ``'st'``, ``'nd'``, ``'rd'`` or ``'th'``
+S                 English ordinal suffix for day of the     ``'st'``, ``'nd'``, ``'rd'`` or ``'th'``
                   month, 2 characters.
-    t                 Number of days in the given month.        ``28`` to ``31``
+t                 Number of days in the given month.        ``28`` to ``31``
-    T                 Time zone of this machine.                ``'EST'``, ``'MDT'``
+T                 Time zone of this machine.                ``'EST'``, ``'MDT'``
-    u                 Microseconds.                             ``0`` to ``999999``
+u                 Microseconds.                             ``0`` to ``999999``
-    U                 Seconds since the Unix Epoch
+U                 Seconds since the Unix Epoch
                   (January 1 1970 00:00:00 UTC).
-    w                 Day of the week, digits without           ``'0'`` (Sunday) to ``'6'`` (Saturday)
+w                 Day of the week, digits without           ``'0'`` (Sunday) to ``'6'`` (Saturday)
                   leading zeros.
-    W                 ISO-8601 week number of year, with        ``1``, ``53``
+W                 ISO-8601 week number of year, with        ``1``, ``53``
                   weeks starting on Monday.
-    y                 Year, 2 digits.                           ``'99'``
+y                 Year, 2 digits.                           ``'99'``
-    Y                 Year, 4 digits.                           ``'1999'``
+Y                 Year, 4 digits.                           ``'1999'``
-    z                 Day of the year.                          ``0`` to ``365``
+z                 Day of the year.                          ``0`` to ``365``
-    Z                 Time zone offset in seconds. The          ``-43200`` to ``43200``
+Z                 Time zone offset in seconds. The          ``-43200`` to ``43200``
                   offset for timezones west of UTC is
                   always negative, and for those east of
                   UTC is always positive.
-    ================  ========================================  =====================
+================  ========================================  =====================
 
 .. versionadded:: 1.2
 
@@ -1448,11 +1448,11 @@ escape
 
 Escapes a string's HTML. Specifically, it makes these replacements:
 
-    * ``<`` is converted to ``&lt;``
+* ``<`` is converted to ``&lt;``
-    * ``>`` is converted to ``&gt;``
+* ``>`` is converted to ``&gt;``
-    * ``'`` (single quote) is converted to ``&#39;``
+* ``'`` (single quote) is converted to ``&#39;``
-    * ``"`` (double quote) is converted to ``&quot;``
+* ``"`` (double quote) is converted to ``&quot;``
-    * ``&`` is converted to ``&amp;``
+* ``&`` is converted to ``&amp;``
 
 The escaping is only applied when the string is output, so it does not matter
 where in a chained sequence of filters you put ``escape``: it will always be
@@ -2320,9 +2320,9 @@ django.contrib.markup
 
 A collection of template filters that implement these common markup languages:
 
-    * Textile
+* Textile
-    * Markdown
+* Markdown
-    * reST (reStructuredText)
+* reST (reStructuredText)
 
 See the :doc:`markup documentation </ref/contrib/markup>`.
 

docs/ref/unicode.txt

@@ -17,13 +17,13 @@ data. Normally, this means giving it an encoding of UTF-8 or UTF-16. If you use
 a more restrictive encoding -- for example, latin1 (iso8859-1) -- you won't be
 able to store certain characters in the database, and information will be lost.
 
- * MySQL users, refer to the `MySQL manual`_ (section 9.1.3.2 for MySQL 5.1)
+* MySQL users, refer to the `MySQL manual`_ (section 9.1.3.2 for MySQL 5.1)
   for details on how to set or alter the database character set encoding.
 
- * PostgreSQL users, refer to the `PostgreSQL manual`_ (section 21.2.2 in
+* PostgreSQL users, refer to the `PostgreSQL manual`_ (section 21.2.2 in
   PostgreSQL 8) for details on creating databases with the correct encoding.
 
- * SQLite users, there is nothing you need to do. SQLite always uses UTF-8
+* SQLite users, there is nothing you need to do. SQLite always uses UTF-8
   for internal encoding.
 
 .. _MySQL manual: http://dev.mysql.com/doc/refman/5.1/en/charset-database.html
@@ -106,7 +106,7 @@ Conversion functions
 The ``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')``
+* ``smart_unicode(s, encoding='utf-8', strings_only=False, errors='strict')``
   converts its input to a Unicode string. The ``encoding`` parameter
   specifies the input encoding. (For example, Django uses this internally
   when processing form input data, which might not be UTF-8 encoded.) The
@@ -119,7 +119,7 @@ for converting back and forth between Unicode and bytestrings.
   If you pass ``smart_unicode()`` an object that has a ``__unicode__``
   method, it will use that method to do the conversion.
 
-    * ``force_unicode(s, encoding='utf-8', strings_only=False,
+* ``force_unicode(s, encoding='utf-8', strings_only=False,
   errors='strict')`` is identical to ``smart_unicode()`` in almost all
   cases. The difference is when the first argument is a :ref:`lazy
   translation <lazy-translations>` instance. While ``smart_unicode()``
@@ -129,7 +129,7 @@ for converting back and forth between Unicode and bytestrings.
   template tags and filters that absolutely *must* have a string to work
   with, not just something that can be converted to a string.
 
-    * ``smart_str(s, encoding='utf-8', strings_only=False, errors='strict')``
+* ``smart_str(s, encoding='utf-8', strings_only=False, errors='strict')``
   is essentially the opposite of ``smart_unicode()``. It forces the first
   argument to a bytestring. The ``strings_only`` parameter has the same
   behavior as for ``smart_unicode()`` and ``force_unicode()``. This is
@@ -152,10 +152,10 @@ URL from an IRI_ -- very loosely speaking, a URI_ that can contain Unicode
 characters. Quoting and converting an IRI to URI can be a little tricky, so
 Django provides some assistance.
 
-    * The function ``django.utils.encoding.iri_to_uri()`` implements the
+* The function ``django.utils.encoding.iri_to_uri()`` implements the
   conversion from IRI to URI as required by the specification (:rfc:`3987`).
 
-    * The functions ``django.utils.http.urlquote()`` and
+* The functions ``django.utils.http.urlquote()`` and
   ``django.utils.http.urlquote_plus()`` are versions of Python's standard
   ``urllib.quote()`` and ``urllib.quote_plus()`` that work with non-ASCII
   characters. (The data is converted to UTF-8 prior to encoding.)
@@ -295,10 +295,10 @@ Template tags and filters
 
 A couple of tips to remember when writing your own template tags and filters:
 
-    * Always return Unicode strings from a template tag's ``render()`` method
+* Always return Unicode strings from a template tag's ``render()`` method
   and from template filters.
 
-    * Use ``force_unicode()`` in preference to ``smart_unicode()`` in these
+* Use ``force_unicode()`` in preference to ``smart_unicode()`` in these
   places. Tag rendering and filter calls occur as the template is being
   rendered, so there is no advantage to postponing the conversion of lazy
   translation objects into strings. It's easier to work solely with Unicode

docs/releases/0.95.txt

@@ -44,42 +44,42 @@ etc., to improve developers' quality of life.
 
 The new features and changes introduced in 0.95 include:
 
-    * Django now uses a more consistent and natural filtering interface for
+* Django now uses a more consistent and natural filtering interface for
   retrieving objects from the database.
 
-    * User-defined models, functions and constants now appear in the module
+* User-defined models, functions and constants now appear in the module
   namespace they were defined in. (Previously everything was magically
   transferred to the django.models.* namespace.)
 
-    * Some optional applications, such as the FlatPage, Sites and Redirects
+* Some optional applications, such as the FlatPage, Sites and Redirects
   apps, have been decoupled and moved into django.contrib. If you don't
   want to use these applications, you no longer have to install their
   database tables.
 
-    * Django now has support for managing database transactions.
+* Django now has support for managing database transactions.
 
-    * We've added the ability to write custom authentication and authorization
+* We've added the ability to write custom authentication and authorization
   backends for authenticating users against alternate systems, such as
   LDAP.
 
-    * We've made it easier to add custom table-level functions to models,
+* We've made it easier to add custom table-level functions to models,
   through a new "Manager" API.
 
-    * It's now possible to use Django without a database. This simply means
+* It's now possible to use Django without a database. This simply means
   that the framework no longer requires you to have a working database set
   up just to serve dynamic pages. In other words, you can just use
   URLconfs/views on their own. Previously, the framework required that a
   database be configured, regardless of whether you actually used it.
 
-    * It's now more explicit and natural to override save() and delete()
+* It's now more explicit and natural to override save() and delete()
   methods on models, rather than needing to hook into the pre_save() and
   post_save() method hooks.
 
-    * Individual pieces of the framework now can be configured without
+* Individual pieces of the framework now can be configured without
   requiring the setting of an environment variable. This permits use of,
   for example, the Django templating system inside other applications.
 
-    * More and more parts of the framework have been internationalized, as
+* More and more parts of the framework have been internationalized, as
   we've expanded internationalization (i18n) support. The Django
   codebase, including code and templates, has now been translated, at least
   in part, into 31 languages. From Arabic to Chinese to Hungarian to Welsh,

docs/releases/0.96.txt

@@ -72,11 +72,11 @@ to raise an error message about modifying non-existent constraints.
 
 If you need to work around this, there are two methods available:
 
-    1. Redirect the output of ``manage.py`` to a file, and edit the
+1. Redirect the output of ``manage.py`` to a file, and edit the
    generated SQL to use the correct constraint names before
    executing it.
 
-    2. Examine the output of ``manage.py sqlall`` to see the new-style
+2. Examine the output of ``manage.py sqlall`` to see the new-style
    constraint names, and use that as a guide to rename existing
    constraints in your database.
 
@@ -86,16 +86,16 @@ Name changes in ``manage.py``
 A few of the options to ``manage.py`` have changed with the addition of fixture
 support:
 
-    * There are new ``dumpdata`` and ``loaddata`` commands which, as
+* There are new ``dumpdata`` and ``loaddata`` commands which, as
   you might expect, will dump and load data to/from the
   database. These commands can operate against any of Django's
   supported serialization formats.
 
-    * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
+* The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
   emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
   other custom SQL -- views, stored procedures, etc.).
 
-    * The vestigial ``install`` command has been removed. Use ``syncdb``.
+* The vestigial ``install`` command has been removed. Use ``syncdb``.
 
 Backslash escaping changed
 --------------------------
@@ -142,7 +142,7 @@ deprecate and remove the old system.
 
 There are three elements to this transition:
 
-    * We've copied the current ``django.forms`` to
+* We've copied the current ``django.forms`` to
   ``django.oldforms``. This allows you to upgrade your code *now*
   rather than waiting for the backwards-incompatible change and
   rushing to fix your code after the fact.  Just change your
@@ -151,13 +151,13 @@ There are three elements to this transition:
       from django import forms             # 0.95-style
       from django import oldforms as forms # 0.96-style
 
-    * The next official release of Django will move the current
+* The next official release of Django will move the current
   ``django.newforms`` to ``django.forms``. This will be a
   backwards-incompatible change, and anyone still using the old
   version of ``django.forms`` at that time will need to change
   their import statements as described above.
 
-    * The next release after that will completely remove
+* The next release after that will completely remove
   ``django.oldforms``.
 
 Although the ``newforms`` library will continue to evolve, it's ready for use
@@ -242,19 +242,19 @@ Since 0.95, a number of people have stepped forward and taken a major
 new role in Django's development. We'd like to thank these people for
 all their hard work:
 
-    * Russell Keith-Magee and Malcolm Tredinnick for their major code
+* Russell Keith-Magee and Malcolm Tredinnick for their major code
   contributions. This release wouldn't have been possible without them.
 
-    * Our new release manager, James Bennett, for his work in getting out
+* Our new release manager, James Bennett, for his work in getting out
   0.95.1, 0.96, and (hopefully) future release.
 
-    * Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill,
+* Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill,
   Michael Radziej, and Gary Wilson. They agreed to take on the monumental
   task of wrangling our tickets into nicely cataloged submission. Figuring
   out what to work on is now about a million times easier; thanks again,
   guys.
 
-    * Everyone who submitted a bug report, patch or ticket comment. We can't
+* Everyone who submitted a bug report, patch or ticket comment. We can't
   possibly thank everyone by name -- over 200 developers submitted patches
   that went into 0.96 -- but everyone who's contributed to Django is listed
   in AUTHORS_.

docs/releases/1.0-porting-guide.txt

@@ -562,15 +562,15 @@ following, replacing ``<app>`` in the code below with each app's name:
 
 Notes:
 
-  1. It's important that you remember to use XML format in the first step of
+1. It's important that you remember to use XML format in the first step of
    this process. We are exploiting a feature of the XML data dumps that makes
    porting floats to decimals with SQLite possible.
 
-  2. In the second step you will be asked to confirm that you are prepared to
+2. In the second step you will be asked to confirm that you are prepared to
    lose the data for the application(s) in question. Say yes; we'll restore
    this data in the third step, of course.
 
-  3. ``DecimalField`` is not used in any of the apps shipped with Django prior
+3. ``DecimalField`` is not used in any of the apps shipped with Django prior
    to this change being made, so you do not need to worry about performing
    this procedure for any of the standard Django models.
 
@@ -717,10 +717,10 @@ a sequence of tuples.
 
 To update your code:
 
-     1. Use :class:`django.utils.datastructures.SortedDict` wherever you were
+1. Use :class:`django.utils.datastructures.SortedDict` wherever you were
    using ``django.newforms.forms.SortedDictFromList``.
 
-     2. Because :meth:`django.utils.datastructures.SortedDict.copy` doesn't
+2. Because :meth:`django.utils.datastructures.SortedDict.copy` doesn't
    return a deepcopy as ``SortedDictFromList.copy()`` did, you will need
    to update your code if you were relying on a deepcopy. Do this by using
    ``copy.deepcopy`` directly.

docs/releases/1.1-alpha-1.txt

@@ -134,7 +134,7 @@ Django team by trying out the alpha codebase in a safe test environment and
 reporting any bugs or issues you encounter. The Django ticket tracker is the
 central place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open new tickets if no existing ticket corresponds to a problem you're
 running into.
@@ -142,7 +142,7 @@ running into.
 Additionally, discussion of Django development, including progress toward the
 1.1 release, takes place daily on the django-developers mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -151,7 +151,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.1-beta-1.txt

@@ -104,11 +104,11 @@ Testing improvements
 A couple of small but very useful improvements have been made to the
 :doc:`testing framework </topics/testing>`:
 
-    * The test :class:`Client` now can automatically follow redirects with the
+* The test :class:`Client` now can automatically follow redirects with the
   ``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This
   makes testing views that issue redirects simpler.
 
-    * It's now easier to get at the template context in the response returned
+* It's now easier to get at the template context in the response returned
   the test client: you'll simply access the context as
   ``request.context[key]``. The old way, which treats ``request.context``
   as a list of contexts, one for each rendered template, is still
@@ -129,27 +129,27 @@ Other improvements
 Finally, a grab-bag of other neat features made their way into this beta
 release, including:
 
-    * The :djadmin:`dumpdata` management command now accepts individual
+* The :djadmin:`dumpdata` management command now accepts individual
   model names as arguments, allowing you to export the data just from
   particular models.
 
-    * There's a new :tfilter:`safeseq` template filter which works just like
+* There's a new :tfilter:`safeseq` template filter which works just like
   :tfilter:`safe` for lists, marking each item in the list as safe.
 
-    * :doc:`Cache backends </topics/cache>` now support ``incr()`` and
+* :doc:`Cache backends </topics/cache>` now support ``incr()`` and
   ``decr()`` commands to increment and decrement the value of a cache key.
   On cache backends that support atomic increment/decrement -- most
   notably, the memcached backend -- these operations will be atomic, and
   quite fast.
 
-    * Django now can :doc:`easily delegate authentication to the Web server
+* Django now can :doc:`easily delegate authentication to the Web server
   </howto/auth-remote-user>` via a new authentication backend that supports
   the standard ``REMOTE_USER`` environment variable used for this purpose.
 
-    * There's a new :func:`django.shortcuts.redirect` function that makes it
+* There's a new :func:`django.shortcuts.redirect` function that makes it
   easier to issue redirects given an object, a view name, or a URL.
 
-    * The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL
+* The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL
   autocommit <postgresql-notes>`. This is an advanced, PostgreSQL-specific
   feature, that can make certain read-heavy applications a good deal
   faster.
@@ -179,7 +179,7 @@ Django team by trying out the beta codebase in a safe test environment and
 reporting any bugs or issues you encounter. The Django ticket tracker is the
 central place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open new tickets if no existing ticket corresponds to a problem you're
 running into.
@@ -187,7 +187,7 @@ running into.
 Additionally, discussion of Django development, including progress toward the
 1.1 release, takes place daily on the django-developers mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -196,7 +196,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.1-rc-1.txt

@@ -84,7 +84,7 @@ release candidate in a safe testing environment and reporting any bugs
 or issues you encounter. The Django ticket tracker is the central
 place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open a new ticket only if no existing ticket corresponds to a
 problem you're running into.
@@ -93,7 +93,7 @@ Additionally, discussion of Django development, including progress
 toward the 1.1 release, takes place daily on the django-developers
 mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -102,7 +102,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django: 
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.1.4.txt

@@ -28,13 +28,13 @@ token's presence on form submission, and validates it.
 Prior to Django 1.2.5, our CSRF protection made an exception for AJAX
 requests, on the following basis:
 
-    * Many AJAX toolkits add an X-Requested-With header when using
+* Many AJAX toolkits add an X-Requested-With header when using
   XMLHttpRequest.
 
-    * Browsers have strict same-origin policies regarding
+* Browsers have strict same-origin policies regarding
   XMLHttpRequest.
 
-    * In the context of a browser, the only way that a custom header
+* In the context of a browser, the only way that a custom header
   of this nature can be added is with XMLHttpRequest.
 
 Therefore, for ease of use, we did not apply CSRF checks to requests

docs/releases/1.1.txt

@@ -93,12 +93,12 @@ other than raise a ``DeprecationWarning``.
 
 If you've been relying on this middleware, the easiest upgrade path is:
 
-    * Examine `the code as it existed before it was removed`__.
+* Examine `the code as it existed before it was removed`__.
 
-    * Verify that it works correctly with your upstream proxy, modifying
+* Verify that it works correctly with your upstream proxy, modifying
   it to support your particular proxy (if necessary).
 
-    * Introduce your modified version of ``SetRemoteAddrFromForwardedFor`` as a
+* Introduce your modified version of ``SetRemoteAddrFromForwardedFor`` as a
   piece of middleware in your own project.
 
 __ http://code.djangoproject.com/browser/django/trunk/django/middleware/http.py?rev=11000#L33
@@ -157,7 +157,7 @@ Features deprecated in 1.1
 
 One feature has been marked as deprecated in Django 1.1:
 
-    * You should no longer use ``AdminSite.root()`` to register that admin
+* You should no longer use ``AdminSite.root()`` to register that admin
   views. That is, if your URLconf contains the line::
 
         (r'^admin/(.*)', admin.site.root),
@@ -289,11 +289,11 @@ Test client improvements
 A couple of small -- but highly useful -- improvements have been made to the
 test client:
 
-    * The test :class:`Client` now can automatically follow redirects with the
+* The test :class:`Client` now can automatically follow redirects with the
   ``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This
   makes testing views that issue redirects simpler.
 
-    * It's now easier to get at the template context in the response returned
+* It's now easier to get at the template context in the response returned
   the test client: you'll simply access the context as
   ``request.context[key]``. The old way, which treats ``request.context`` as
   a list of contexts, one for each rendered template in the inheritance
@@ -352,16 +352,16 @@ GeoDjango
 In Django 1.1, GeoDjango_ (i.e. ``django.contrib.gis``) has several new
 features:
 
-    * Support for SpatiaLite_ -- a spatial database for SQLite -- as a spatial
+* Support for SpatiaLite_ -- a spatial database for SQLite -- as a spatial
   backend.
 
-    * Geographic aggregates (``Collect``, ``Extent``, ``MakeLine``, ``Union``)
+* Geographic aggregates (``Collect``, ``Extent``, ``MakeLine``, ``Union``)
   and ``F`` expressions.
 
-    * New ``GeoQuerySet`` methods: ``collect``, ``geojson``, and
+* New ``GeoQuerySet`` methods: ``collect``, ``geojson``, and
   ``snap_to_grid``.
 
-    * A new list interface methods for ``GEOSGeometry`` objects.
+* A new list interface methods for ``GEOSGeometry`` objects.
 
 For more details, see the `GeoDjango documentation`_.
 
@@ -446,7 +446,7 @@ the weary! If you'd like to help, discussion of Django development, including
 progress toward the 1.2 release, takes place daily on the django-developers
 mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. Feel free to
 join the discussions!
@@ -454,7 +454,7 @@ join the discussions!
 Django's online documentation also includes pointers on how to contribute to
 Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.2-alpha-1.txt

@@ -26,11 +26,11 @@ There have been large changes to the way that CSRF protection works, detailed in
 :doc:`the CSRF documentation </ref/contrib/csrf>`.  The following are the major
 changes that developers must be aware of:
 
- * ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated, and
+* ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated, and
   **will be removed completely in Django 1.4**, in favor of a template tag that
   should be inserted into forms.
 
- * All contrib apps use a ``csrf_protect`` decorator to protect the view. This
+* All contrib apps use a ``csrf_protect`` decorator to protect the view. This
   requires the use of the ``csrf_token`` template tag in the template, so if you
   have used custom templates for contrib views, you MUST READ THE UPGRADE
   INSTRUCTIONS to fix those templates.
@@ -40,12 +40,12 @@ changes that developers must be aware of:
      The upgrade notes have been removed in current Django docs. Please refer
      to the docs for Django 1.3 or older to find these instructions.
 
- * ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
+* ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
   default. This turns on CSRF protection by default, so that views that accept
   POST requests need to be written to work with the middleware. Instructions
   on how to do this are found in the CSRF docs.
 
- * CSRF-related code has moved from ``contrib`` to ``core`` (with
+* CSRF-related code has moved from ``contrib`` to ``core`` (with
   backwards compatible imports in the old locations, which are
   deprecated).
 
@@ -70,13 +70,13 @@ If you used ``LazyObject`` in your own code, and implemented the
 ``get_all_members()`` method for wrapped objects, you need to make the following
 changes:
 
- * If your class does not have special requirements for introspection (i.e. you
+* If your class does not have special requirements for introspection (i.e. you
   have not implemented ``__getattr__()`` or other methods that allow for
   attributes not discoverable by normal mechanisms), you can simply remove the
   ``get_all_members()`` method.  The default implementation on ``LazyObject``
   will do the right thing.
 
- * If you have more complex requirements for introspection, first rename the
+* If you have more complex requirements for introspection, first rename the
   ``get_all_members()`` method to ``__dir__()``.  This is the standard method,
   from Python 2.6 onwards, for supporting introspection.  If you are require
   support for Python < 2.6, add the following code to the class::
@@ -282,20 +282,20 @@ The sample settings given previously would now be stored using::
 
 This affects the following settings:
 
-    =========================================  ==========================
+=========================================  ==========================
  Old setting                                New Setting
-    =========================================  ==========================
+=========================================  ==========================
-    :setting:`DATABASE_ENGINE`                 :setting:`ENGINE`
+:setting:`DATABASE_ENGINE`                 :setting:`ENGINE`
-    :setting:`DATABASE_HOST`                   :setting:`HOST`
+:setting:`DATABASE_HOST`                   :setting:`HOST`
-    :setting:`DATABASE_NAME`                   :setting:`NAME`
+:setting:`DATABASE_NAME`                   :setting:`NAME`
-    :setting:`DATABASE_OPTIONS`                :setting:`OPTIONS`
+:setting:`DATABASE_OPTIONS`                :setting:`OPTIONS`
-    :setting:`DATABASE_PASSWORD`               :setting:`PASSWORD`
+:setting:`DATABASE_PASSWORD`               :setting:`PASSWORD`
-    :setting:`DATABASE_PORT`                   :setting:`PORT`
+:setting:`DATABASE_PORT`                   :setting:`PORT`
-    :setting:`DATABASE_USER`                   :setting:`USER`
+:setting:`DATABASE_USER`                   :setting:`USER`
-    :setting:`TEST_DATABASE_CHARSET`           :setting:`TEST_CHARSET`
+:setting:`TEST_DATABASE_CHARSET`           :setting:`TEST_CHARSET`
-    :setting:`TEST_DATABASE_COLLATION`         :setting:`TEST_COLLATION`
+:setting:`TEST_DATABASE_COLLATION`         :setting:`TEST_COLLATION`
-    :setting:`TEST_DATABASE_NAME`              :setting:`TEST_NAME`
+:setting:`TEST_DATABASE_NAME`              :setting:`TEST_NAME`
-    =========================================  ==========================
+=========================================  ==========================
 
 These changes are also required if you have manually created a database
 connection using ``DatabaseWrapper()`` from your database backend of choice.
@@ -367,9 +367,9 @@ or, when directly formatting a date value::
 
 The same applies to the globals found in ``django.forms.fields``:
 
-  * ``DEFAULT_DATE_INPUT_FORMATS``
+* ``DEFAULT_DATE_INPUT_FORMATS``
-  * ``DEFAULT_TIME_INPUT_FORMATS``
+* ``DEFAULT_TIME_INPUT_FORMATS``
-  * ``DEFAULT_DATETIME_INPUT_FORMATS``
+* ``DEFAULT_DATETIME_INPUT_FORMATS``
 
 Use ``django.utils.formats.get_format()`` to get the appropriate formats.
 
@@ -559,7 +559,7 @@ Django team by trying out the alpha codebase in a safe test environment and
 reporting any bugs or issues you encounter. The Django ticket tracker is the
 central place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open new tickets if no existing ticket corresponds to a problem you're
 running into.
@@ -567,7 +567,7 @@ running into.
 Additionally, discussion of Django development, including progress toward the
 1.2 release, takes place daily on the django-developers mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -576,7 +576,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.2-beta-1.txt

@@ -143,7 +143,7 @@ codebase in a safe test environment and reporting any bugs or issues
 you encounter. The Django ticket tracker is the central place to
 search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open new tickets if no existing ticket corresponds to a problem
 you're running into.
@@ -152,7 +152,7 @@ Additionally, discussion of Django development, including progress
 toward the 1.2 release, takes place daily on the django-developers
 mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -161,7 +161,7 @@ discussions there.
 Django's online documentation also includes pointers on how to
 contribute to Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation
 or simply triaging tickets and helping to test proposed bugfixes --

docs/releases/1.2-rc-1.txt

@@ -76,7 +76,7 @@ release candidate in a safe testing environment and reporting any bugs
 or issues you encounter. The Django ticket tracker is the central
 place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open a new ticket only if no existing ticket corresponds to a
 problem you're running into.
@@ -85,7 +85,7 @@ Additionally, discussion of Django development, including progress
 toward the 1.2 release, takes place daily on the django-developers
 mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -94,7 +94,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django: 
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.2.5.txt

@@ -28,13 +28,13 @@ token's presence on form submission, and validates it.
 Prior to Django 1.2.5, our CSRF protection made an exception for AJAX
 requests, on the following basis:
 
-    * Many AJAX toolkits add an X-Requested-With header when using
+* Many AJAX toolkits add an X-Requested-With header when using
   XMLHttpRequest.
 
-    * Browsers have strict same-origin policies regarding
+* Browsers have strict same-origin policies regarding
   XMLHttpRequest.
 
-    * In the context of a browser, the only way that a custom header
+* In the context of a browser, the only way that a custom header
   of this nature can be added is with XMLHttpRequest.
 
 Therefore, for ease of use, we did not apply CSRF checks to requests

docs/releases/1.2.txt

@@ -18,21 +18,21 @@ Overview
 
 Django 1.2 introduces several large, important new features, including:
 
-    * Support for `multiple database connections`_ in a single Django instance.
+* Support for `multiple database connections`_ in a single Django instance.
 
-    * `Model validation`_ inspired by Django's form validation.
+* `Model validation`_ inspired by Django's form validation.
 
-    * Vastly `improved protection against Cross-Site Request Forgery`_ (CSRF).
+* Vastly `improved protection against Cross-Site Request Forgery`_ (CSRF).
 
-    * A new `user "messages" framework`_ with support for cookie- and session-based
+* A new `user "messages" framework`_ with support for cookie- and session-based
   message for both anonymous and authenticated users.
 
-    * Hooks for `object-level permissions`_, `permissions for anonymous users`_,
+* Hooks for `object-level permissions`_, `permissions for anonymous users`_,
   and `more flexible username requirements`_.
 
-    * Customization of email sending via `email backends`_.
+* Customization of email sending via `email backends`_.
 
-    * New :ref:`"smart" if template tag <new-in-1.2-smart-if>` which supports
+* New :ref:`"smart" if template tag <new-in-1.2-smart-if>` which supports
   comparison operators.
 
 .. _multiple database connections: `support for multiple databases`_
@@ -58,10 +58,10 @@ manner per :doc:`our API stability policy </misc/api-stability>` policy.
 However, a handful of features *have* changed in ways that, for some users, will be
 backwards-incompatible. The big changes are:
 
-    * Support for Python 2.3 has been dropped. See the full notes
+* Support for Python 2.3 has been dropped. See the full notes
   below.
 
-    * The new CSRF protection framework is not backwards-compatible with
+* The new CSRF protection framework is not backwards-compatible with
   the old system. Users of the old system will not be affected until
   the old system is removed in Django 1.4.
 
@@ -69,16 +69,16 @@ backwards-incompatible. The big changes are:
   important backwards-incompatible changes, detailed in `CSRF Protection`_,
   below.
 
-    * Authors of custom :class:`~django.db.models.Field` subclasses should be
+* Authors of custom :class:`~django.db.models.Field` subclasses should be
   aware that a number of methods have had a change in prototype, detailed
   under `get_db_prep_*() methods on Field`_, below.
 
-    * The internals of template tags have changed somewhat; authors of custom
+* The internals of template tags have changed somewhat; authors of custom
   template tags that need to store state (e.g. custom control flow tags)
   should ensure that their code follows the new rules for `stateful template
   tags`_
 
-    * The :func:`~django.contrib.auth.decorators.user_passes_test`,
+* The :func:`~django.contrib.auth.decorators.user_passes_test`,
   :func:`~django.contrib.auth.decorators.login_required`, and
   :func:`~django.contrib.auth.decorators.permission_required`, decorators
   from :mod:`django.contrib.auth` only apply to functions and no longer
@@ -429,11 +429,11 @@ We've made large changes to the way CSRF protection works, detailed in
 :doc:`the CSRF documentation </ref/contrib/csrf>`. Here are the major changes you
 should be aware of:
 
- * ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated and
+* ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated and
   will be removed completely in Django 1.4, in favor of a template tag that
   should be inserted into forms.
 
- * All contrib apps use a ``csrf_protect`` decorator to protect the view. This
+* All contrib apps use a ``csrf_protect`` decorator to protect the view. This
   requires the use of the ``csrf_token`` template tag in the template. If you
   have used custom templates for contrib views, you MUST READ THE UPGRADE
   INSTRUCTIONS to fix those templates.
@@ -443,12 +443,12 @@ should be aware of:
      The upgrade notes have been removed in current Django docs. Please refer
      to the docs for Django 1.3 or older to find these instructions.
 
- * ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
+* ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
   default. This turns on CSRF protection by default, so views that accept
   POST requests need to be written to work with the middleware. Instructions
   on how to do this are found in the CSRF docs.
 
- * All of the CSRF has moved from contrib to core (with backwards
+* All of the CSRF has moved from contrib to core (with backwards
   compatible imports in the old locations, which are deprecated and
   will cease to be supported in Django 1.4).
 
@@ -816,20 +816,20 @@ shortened. The previous sample settings would now look like this::
 
 This affects the following settings:
 
-    =========================================  ==========================
+=========================================  ==========================
  Old setting                                New Setting
-    =========================================  ==========================
+=========================================  ==========================
-    :setting:`DATABASE_ENGINE`                 :setting:`ENGINE`
+:setting:`DATABASE_ENGINE`                 :setting:`ENGINE`
-    :setting:`DATABASE_HOST`                   :setting:`HOST`
+:setting:`DATABASE_HOST`                   :setting:`HOST`
-    :setting:`DATABASE_NAME`                   :setting:`NAME`
+:setting:`DATABASE_NAME`                   :setting:`NAME`
-    :setting:`DATABASE_OPTIONS`                :setting:`OPTIONS`
+:setting:`DATABASE_OPTIONS`                :setting:`OPTIONS`
-    :setting:`DATABASE_PASSWORD`               :setting:`PASSWORD`
+:setting:`DATABASE_PASSWORD`               :setting:`PASSWORD`
-    :setting:`DATABASE_PORT`                   :setting:`PORT`
+:setting:`DATABASE_PORT`                   :setting:`PORT`
-    :setting:`DATABASE_USER`                   :setting:`USER`
+:setting:`DATABASE_USER`                   :setting:`USER`
-    :setting:`TEST_DATABASE_CHARSET`           :setting:`TEST_CHARSET`
+:setting:`TEST_DATABASE_CHARSET`           :setting:`TEST_CHARSET`
-    :setting:`TEST_DATABASE_COLLATION`         :setting:`TEST_COLLATION`
+:setting:`TEST_DATABASE_COLLATION`         :setting:`TEST_COLLATION`
-    :setting:`TEST_DATABASE_NAME`              :setting:`TEST_NAME`
+:setting:`TEST_DATABASE_NAME`              :setting:`TEST_NAME`
-    =========================================  ==========================
+=========================================  ==========================
 
 These changes are also required if you have manually created a database
 connection using ``DatabaseWrapper()`` from your database backend of choice.
@@ -967,9 +967,9 @@ Or, when directly formatting a date value::
 
 The same applies to the globals found in ``django.forms.fields``:
 
-  * ``DEFAULT_DATE_INPUT_FORMATS``
+* ``DEFAULT_DATE_INPUT_FORMATS``
-  * ``DEFAULT_TIME_INPUT_FORMATS``
+* ``DEFAULT_TIME_INPUT_FORMATS``
-  * ``DEFAULT_DATETIME_INPUT_FORMATS``
+* ``DEFAULT_DATETIME_INPUT_FORMATS``
 
 Use ``django.utils.formats.get_format()`` to get the appropriate formats.
 

docs/releases/1.3-alpha-1.txt

@@ -150,13 +150,13 @@ To compensate for this, the focus of the Django 1.3 development
 process has been on adding lots of smaller, long standing feature
 requests. These include:
 
-    * Improved tools for accessing and manipulating the current Site via
+* Improved tools for accessing and manipulating the current Site via
   :func:`django.contrib.sites.models.get_current_site`.
 
-    * A :class:`~django.test.client.RequestFactory` for mocking
+* A :class:`~django.test.client.RequestFactory` for mocking
   requests in tests.
 
-    * A new test assertion --
+* A new test assertion --
   :meth:`~django.test.client.Client.assertNumQueries` -- making it
   easier to test the database activity associated with a view.
 
@@ -265,7 +265,7 @@ Localflavor changes
 Django 1.3 introduces the following backwards-incompatible changes to
 local flavors:
 
-    * Indonesia (id) -- The province "Nanggroe Aceh Darussalam (NAD)"
+* Indonesia (id) -- The province "Nanggroe Aceh Darussalam (NAD)"
   has been removed from the province list in favor of the new
   official designation "Aceh (ACE)".
 
@@ -312,10 +312,10 @@ As a result of the introduction of class-based generic views, the
 function-based generic views provided by Django have been deprecated.
 The following modules and the views they contain have been deprecated:
 
-      * :mod:`django.views.generic.create_update`
+* :mod:`django.views.generic.create_update`
-      * :mod:`django.views.generic.date_based`
+* :mod:`django.views.generic.date_based`
-      * :mod:`django.views.generic.list_detail`
+* :mod:`django.views.generic.list_detail`
-      * :mod:`django.views.generic.simple`
+* :mod:`django.views.generic.simple`
 
 Test client response ``template`` attribute
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -373,7 +373,7 @@ Django team by trying out the alpha codebase in a safe test environment and
 reporting any bugs or issues you encounter. The Django ticket tracker is the
 central place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open new tickets if no existing ticket corresponds to a problem you're
 running into.
@@ -381,7 +381,7 @@ running into.
 Additionally, discussion of Django development, including progress toward the
 1.3 release, takes place daily on the django-developers mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -390,7 +390,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.3-beta-1.txt

@@ -29,10 +29,10 @@ setting is ``True``) when using the :djadmin:`runserver` management command.
 Based on feedback from the community this release adds two new options to the
 :djadmin:`runserver` command to modify this behavior:
 
-    * ``--nostatic``: prevents the :djadmin:`runserver` command from serving
+* ``--nostatic``: prevents the :djadmin:`runserver` command from serving
   files completely.
 
-    * ``--insecure``: enables serving of static files even if running with
+* ``--insecure``: enables serving of static files even if running with
   :setting:`DEBUG` set to False. (This is **not** recommended!)
 
 See the :doc:`staticfiles reference documentation </ref/contrib/staticfiles>`
@@ -100,25 +100,25 @@ desired outside the use of the optional :mod:`~django.contrib.staticfiles` app.
 
 As a result, we took the following steps to rectify the issue:
 
-  * Two new global settings were added that will be used by, **but are not
+* Two new global settings were added that will be used by, **but are not
-    limited to**, the :doc:`staticfiles</ref/contrib/staticfiles>` app:
+limited to**, the :doc:`staticfiles</ref/contrib/staticfiles>` app:
 
-    * :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
+* :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
 
-    * :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
+* :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
 
-  * The ``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
+* The ``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
-    template tag was moved to Django's core (``django.templatetags.static``) and
+template tag was moved to Django's core (``django.templatetags.static``) and
-    renamed to :ttag:`get_static_prefix`.
+renamed to :ttag:`get_static_prefix`.
 
-  * The ``django.contrib.staticfiles.context_processors.staticfiles``
+* The ``django.contrib.staticfiles.context_processors.staticfiles``
-    context processor was moved to Django's core
+context processor was moved to Django's core
-    (``django.core.context_processors.static``) and renamed to
+(``django.core.context_processors.static``) and renamed to
-    :func:`~django.core.context_processors.static`.
+:func:`~django.core.context_processors.static`.
 
-  * :ref:`form-media-paths` now uses :setting:`STATIC_URL` as the prefix
+* :ref:`form-media-paths` now uses :setting:`STATIC_URL` as the prefix
-    **if the value is not None**, and falls back to the previously used
+**if the value is not None**, and falls back to the previously used
-    :setting:`MEDIA_URL` setting otherwise.
+:setting:`MEDIA_URL` setting otherwise.
 
 Changes to the login methods of the admin
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -209,7 +209,7 @@ Django team by trying out the beta codebase in a safe test environment and
 reporting any bugs or issues you encounter. The Django ticket tracker is the
 central place to search for open issues:
 
-    * http://code.djangoproject.com/timeline
+* http://code.djangoproject.com/timeline
 
 Please open new tickets if no existing ticket corresponds to a problem you're
 running into.
@@ -217,7 +217,7 @@ running into.
 Additionally, discussion of Django development, including progress toward the
 1.3 release, takes place daily on the django-developers mailing list:
 
-    * http://groups.google.com/group/django-developers
+* http://groups.google.com/group/django-developers
 
 ... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
 interested in helping out with Django's development, feel free to join the
@@ -226,7 +226,7 @@ discussions there.
 Django's online documentation also includes pointers on how to contribute to
 Django:
 
-    * :doc:`How to contribute to Django </internals/contributing/index>`
+* :doc:`How to contribute to Django </internals/contributing/index>`
 
 Contributions on any level -- developing code, writing documentation or simply
 triaging tickets and helping to test proposed bugfixes -- are always welcome and

docs/releases/1.3.txt

@@ -188,16 +188,16 @@ Improvements to built-in template tags
 
 A number of improvements have been made to Django's built-in template tags:
 
-    * The :ttag:`include` tag now accepts a ``with`` option, allowing
+* The :ttag:`include` tag now accepts a ``with`` option, allowing
   you to specify context variables to the included template
 
-    * The :ttag:`include` tag now accepts an ``only`` option, allowing
+* The :ttag:`include` tag now accepts an ``only`` option, allowing
   you to exclude the current context from the included context
 
-    * The :ttag:`with` tag now allows you to define multiple context
+* The :ttag:`with` tag now allows you to define multiple context
   variables in a single :ttag:`with` block.
 
-    * The :ttag:`load` tag now accepts a ``from`` argument, allowing
+* The :ttag:`load` tag now accepts a ``from`` argument, allowing
   you to load a single tag or filter from a library.
 
 TemplateResponse
@@ -573,20 +573,20 @@ found on disk, namely:
 For translatable literals found in Python code and templates (``'django'``
 gettext domain):
 
- * Priorities of translations included with applications listed in the
+* Priorities of translations included with applications listed in the
   :setting:`INSTALLED_APPS` setting were changed. To provide a behavior
   consistent with other parts of Django that also use such setting (templates,
   etc.) now, when building the translation that will be made available, the
   apps listed first have higher precedence than the ones listed later.
 
- * Now it is possible to override the translations shipped with applications by
+* 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 :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.
 
- * The ``locale`` subdirectory of the directory containing the settings, that
+* 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 :setting:`LOCALE_PATHS`
@@ -596,14 +596,14 @@ gettext domain):
 For translatable literals found in Javascript code (``'djangojs'`` gettext
 domain):
 
- * Similarly to the ``'django'`` domain translations: Overriding of
+* Similarly to the ``'django'`` domain translations: Overriding of
   translations shipped with applications by using the :setting:`LOCALE_PATHS`
   setting is now possible for this domain too. These translations have higher
   precedence than the translations of Python packages passed to the
   :ref:`javascript_catalog view <javascript_catalog-view>`.  Paths listed first
   have higher precedence than the ones listed later.
 
- * Translations under the ``locale`` subdirectory of the *project directory*
+* Translations under the ``locale`` subdirectory of the *project directory*
   have never been taken in account for JavaScript translations and remain in
   the same situation considering the deprecation of such location.
 

docs/topics/cache.txt

@@ -94,12 +94,12 @@ two most common are `python-memcached`_ and `pylibmc`_.
 
 To use Memcached with Django:
 
-    * Set :setting:`BACKEND <CACHES-BACKEND>` to
+* Set :setting:`BACKEND <CACHES-BACKEND>` to
   ``django.core.cache.backends.memcached.MemcachedCache`` or
   ``django.core.cache.backends.memcached.PyLibMCCache`` (depending
   on your chosen memcached binding)
 
-    * Set :setting:`LOCATION <CACHES-LOCATION>` to ``ip:port`` values,
+* Set :setting:`LOCATION <CACHES-LOCATION>` to ``ip:port`` values,
   where ``ip`` is the IP address of the Memcached daemon and ``port`` is the
   port on which Memcached is running, or to a ``unix:path`` value, where
   ``path`` is the path to a Memcached Unix socket file.
@@ -358,11 +358,11 @@ backend, each cache backend can be given additional arguments to
 control caching behavior. These arguments are provided as additional
 keys in the :setting:`CACHES` setting. Valid arguments are as follows:
 
-    * :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
+* :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
   seconds, to use for the cache. This argument defaults to 300
   seconds (5 minutes).
 
-    * :setting:`OPTIONS <CACHES-OPTIONS>`: Any options that should be
+* :setting:`OPTIONS <CACHES-OPTIONS>`: Any options that should be
   passed to cache backend. The list options understood by each
   backend vary with each backend.
 
@@ -388,20 +388,20 @@ keys in the :setting:`CACHES` setting. Valid arguments are as follows:
   options directly to the underlying cache library. As a result,
   the list of valid options depends on the library in use.
 
-    * :setting:`KEY_PREFIX <CACHES-KEY_PREFIX>`: A string that will be
+* :setting:`KEY_PREFIX <CACHES-KEY_PREFIX>`: A string that will be
   automatically included (prepended by default) to all cache keys
   used by the Django server.
 
   See the :ref:`cache documentation <cache_key_prefixing>` for
   more information.
 
-    * :setting:`VERSION <CACHES-VERSION>`: The default version number
+* :setting:`VERSION <CACHES-VERSION>`: The default version number
   for cache keys generated by the Django server.
 
   See the :ref:`cache documentation <cache_versioning>` for more
   information.
 
-    * :setting:`KEY_FUNCTION <CACHES-KEY_FUNCTION>`
+* :setting:`KEY_FUNCTION <CACHES-KEY_FUNCTION>`
   A string containing a dotted path to a function that defines how
   to compose a prefix, version and key into a final cache key.
 
@@ -470,13 +470,13 @@ response for HEAD request.
 Additionally, the cache middleware automatically sets a few headers in each
 :class:`~django.http.HttpResponse`:
 
-    * Sets the ``Last-Modified`` header to the current date/time when a fresh
+* 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
+* Sets the ``Expires`` header to the current date/time plus the defined
   :setting:`CACHE_MIDDLEWARE_SECONDS`.
 
-    * Sets the ``Cache-Control`` header to give a max age for the page --
+* Sets the ``Cache-Control`` header to give a max age for the page --
   again, from the :setting:`CACHE_MIDDLEWARE_SECONDS` setting.
 
 See :doc:`/topics/http/middleware` for more on middleware.
@@ -932,18 +932,18 @@ reaches your Web site.
 
 Here are a few examples of upstream caches:
 
-    * Your ISP may cache certain pages, so if you requested a page from
+* Your ISP may cache certain pages, so if you requested a page from
   http://example.com/, your ISP would send you the page without having to
   access example.com directly. The maintainers of example.com have no
   knowledge of this caching; the ISP sits between example.com and your Web
   browser, handling all of the caching transparently.
 
-    * Your Django Web site may sit behind a *proxy cache*, such as Squid Web
+* Your Django Web site may sit behind a *proxy cache*, such as Squid Web
   Proxy Cache (http://www.squid-cache.org/), that caches pages for
   performance. In this case, each request first would be handled by the
   proxy, and it would be passed to your application only if needed.
 
-    * Your Web browser caches pages, too. If a Web page sends out the
+* Your Web browser caches pages, too. If a Web page sends out the
   appropriate headers, your browser will use the local cached copy for
   subsequent requests to that page, without even contacting the Web page
   again to see whether it has changed.
@@ -1099,9 +1099,9 @@ entries may be cached on any shared cache. The following code uses
 There are a few other ways to control cache parameters. For example, HTTP
 allows applications to do the following:
 
-    * Define the maximum time a page should be cached.
+* Define the maximum time a page should be cached.
 
-    * Specify whether a cache should always check for newer versions, only
+* Specify whether a cache should always check for newer versions, only
   delivering the cached content when there are no changes. (Some caches
   might deliver cached content even if the server page changed, simply
   because the cache copy isn't yet expired.)
@@ -1119,14 +1119,14 @@ cache on every access and to store cached versions for, at most, 3,600 seconds::
 Any valid ``Cache-Control`` HTTP directive is valid in ``cache_control()``.
 Here's a full list:
 
-    * ``public=True``
+* ``public=True``
-    * ``private=True``
+* ``private=True``
-    * ``no_cache=True``
+* ``no_cache=True``
-    * ``no_transform=True``
+* ``no_transform=True``
-    * ``must_revalidate=True``
+* ``must_revalidate=True``
-    * ``proxy_revalidate=True``
+* ``proxy_revalidate=True``
-    * ``max_age=num_seconds``
+* ``max_age=num_seconds``
-    * ``s_maxage=num_seconds``
+* ``s_maxage=num_seconds``
 
 For explanation of Cache-Control HTTP directives, see the `Cache-Control spec`_.
 
@@ -1154,11 +1154,11 @@ Other optimizations
 Django comes with a few other pieces of middleware that can help optimize your
 site's performance:
 
-    * ``django.middleware.http.ConditionalGetMiddleware`` adds support for
+* ``django.middleware.http.ConditionalGetMiddleware`` adds support for
   modern browsers to conditionally GET responses based on the ``ETag``
   and ``Last-Modified`` headers.
 
-    * :class:`django.middleware.gzip.GZipMiddleware` compresses responses for all
+* :class:`django.middleware.gzip.GZipMiddleware` compresses responses for all
   modern browsers, saving bandwidth and transfer time.
 
 Order of MIDDLEWARE_CLASSES
@@ -1175,9 +1175,9 @@ response phase. Thus, you need to make sure that ``UpdateCacheMiddleware``
 appears *before* any other middleware that might add something to the ``Vary``
 header. The following middleware modules do so:
 
-    * ``SessionMiddleware`` adds ``Cookie``
+* ``SessionMiddleware`` adds ``Cookie``
-    * ``GZipMiddleware`` adds ``Accept-Encoding``
+* ``GZipMiddleware`` adds ``Accept-Encoding``
-    * ``LocaleMiddleware`` adds ``Accept-Language``
+* ``LocaleMiddleware`` adds ``Accept-Language``
 
 ``FetchFromCacheMiddleware``, on the other hand, runs during the request phase,
 where middleware is applied first-to-last, so an item at the top of the list

docs/topics/class-based-views.txt

@@ -29,21 +29,21 @@ be passed as an extra argument to the URLconf.
 
 Django ships with generic views to do the following:
 
-    * Perform common "simple" tasks: redirect to a different page and
+* Perform common "simple" tasks: redirect to a different page and
   render a given template.
 
-    * Display list and detail pages for a single object. If we were creating an
+* Display list and detail pages for a single object. If we were creating an
   application to manage conferences then a ``TalkListView`` and a
   ``RegisteredUserListView`` would be examples of list views. A single
   talk page is an example of what we call a "detail" view.
 
-    * Present date-based objects in year/month/day archive pages,
+* Present date-based objects in year/month/day archive pages,
   associated detail, and "latest" pages.
   `The Django Weblog <http://www.djangoproject.com/weblog/>`_'s
   year, month, and day archives are built with these, as would be a typical
   newspaper's archives.
 
-    * Allow users to create, update, and delete objects -- with or
+* Allow users to create, update, and delete objects -- with or
   without authorization.
 
 Taken together, these views provide easy interfaces to perform the most common

docs/topics/conditional-view-processing.txt

@@ -154,16 +154,16 @@ trying to change has been altered in the meantime.
 
 For example, consider the following exchange between the client and server:
 
-    1. Client requests ``/foo/``.
+1. Client requests ``/foo/``.
-    2. Server responds with some content with an ETag of ``"abcd1234"``.
+2. Server responds with some content with an ETag of ``"abcd1234"``.
-    3. Client sends an HTTP ``PUT`` request to ``/foo/`` to update the
+3. Client sends an HTTP ``PUT`` request to ``/foo/`` to update the
    resource. It also sends an ``If-Match: "abcd1234"`` header to specify
    the version it is trying to update.
-    4. Server checks to see if the resource has changed, by computing the ETag
+4. Server checks to see if the resource has changed, by computing the ETag
    the same way it does for a ``GET`` request (using the same function).
    If the resource *has* changed, it will return a 412 status code code,
    meaning "precondition failed".
-    5. Client sends a ``GET`` request to ``/foo/``, after receiving a 412
+5. Client sends a ``GET`` request to ``/foo/``, after receiving a 412
    response, to retrieve an updated version of the content before updating
    it.
 
@@ -182,10 +182,10 @@ conditional ``GET`` handling via the
 easy to use and suitable for many situations, those pieces of middleware
 functionality have limitations for advanced usage:
 
-    * They are applied globally to all views in your project
+* They are applied globally to all views in your project
-    * They don't save you from generating the response itself, which may be
+* They don't save you from generating the response itself, which may be
   expensive
-    * They are only appropriate for HTTP ``GET`` requests.
+* They are only appropriate for HTTP ``GET`` requests.
 
 You should choose the most appropriate tool for your particular problem here.
 If you have a way to compute ETags and modification times quickly and if some

docs/topics/db/managers.txt

@@ -205,7 +205,7 @@ first manager declared is the *default manager*, it is important to allow that
 to be controlled. So here's how Django handles custom managers and
 :ref:`model inheritance <model-inheritance>`:
 
-    1. Managers defined on non-abstract base classes are *not* inherited by
+1. Managers defined on non-abstract base classes are *not* inherited by
    child classes. If you want to reuse a manager from a non-abstract base,
    redeclare it explicitly on the child class. These sorts of managers are
    likely to be fairly specific to the class they are defined on, so
@@ -213,14 +213,14 @@ to be controlled. So here's how Django handles custom managers and
    far as the default manager goes). Therefore, they aren't passed onto
    child classes.
 
-    2. Managers from abstract base classes are always inherited by the child
+2. Managers from abstract base classes are always inherited by the child
    class, using Python's normal name resolution order (names on the child
    class override all others; then come names on the first parent class,
    and so on). Abstract base classes are designed to capture information
    and behavior that is common to their child classes. Defining common
    managers is an appropriate part of this common information.
 
-    3. The default manager on a class is either the first manager declared on
+3. The default manager on a class is either the first manager declared on
    the class, if that exists, or the default manager of the first abstract
    base class in the parent hierarchy, if that exists. If no default
    manager is explicitly declared, Django's normal default manager is

docs/topics/db/models.txt

@@ -10,12 +10,12 @@ model maps to a single database table.
 
 The basics:
 
-    * Each model is a Python class that subclasses
+* Each model is a Python class that subclasses
   :class:`django.db.models.Model`.
 
-    * Each attribute of the model represents a database field.
+* Each attribute of the model represents a database field.
 
-    * With all of this, Django gives you an automatically-generated
+* With all of this, Django gives you an automatically-generated
   database-access API; see :doc:`/topics/db/queries`.
 
 .. seealso::
@@ -53,14 +53,14 @@ The above ``Person`` model would create a database table like this:
 
 Some technical notes:
 
-    * The name of the table, ``myapp_person``, is automatically derived from
+* The name of the table, ``myapp_person``, is automatically derived from
   some model metadata but can be overridden. See :ref:`table-names` for more
   details..
 
-    * An ``id`` field is added automatically, but this behavior can be
+* An ``id`` field is added automatically, but this behavior can be
   overridden. See :ref:`automatic-primary-key-fields`.
 
-    * The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
+* The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
   syntax, but it's worth noting Django uses SQL tailored to the database
   backend specified in your :doc:`settings file </topics/settings>`.
 
@@ -113,12 +113,12 @@ Each field in your model should be an instance of the appropriate
 :class:`~django.db.models.Field` class. Django uses the field class types to
 determine a few things:
 
-    * The database column type (e.g. ``INTEGER``, ``VARCHAR``).
+* The database column type (e.g. ``INTEGER``, ``VARCHAR``).
 
-    * The :doc:`widget </ref/forms/widgets>` to use in Django's admin interface,
+* The :doc:`widget </ref/forms/widgets>` to use in Django's admin interface,
   if you care to use it (e.g. ``<input type="text">``, ``<select>``).
 
-    * The minimal validation requirements, used in Django's admin and in
+* The minimal validation requirements, used in Django's admin and in
   automatically-generated forms.
 
 Django ships with dozens of built-in field types; you can find the complete list
@@ -140,11 +140,11 @@ optional. They're fully explained in the :ref:`reference
 <common-model-field-options>`, but here's a quick summary of the most often-used
 ones:
 
-    :attr:`~Field.null`
+:attr:`~Field.null`
     If ``True``, Django will store empty values as ``NULL`` in the database.
     Default is ``False``.
 
-    :attr:`~Field.blank`
+:attr:`~Field.blank`
     If ``True``, the field is allowed to be blank. Default is ``False``.
 
     Note that this is different than :attr:`~Field.null`.
@@ -154,7 +154,7 @@ ones:
     allow entry of an empty value. If a field has :attr:`blank=False
     <Field.blank>`, the field will be required.
 
-    :attr:`~Field.choices`
+:attr:`~Field.choices`
     An iterable (e.g., a list or tuple) of 2-tuples to use as choices for
     this field. If this is given, Django's admin will use a select box
     instead of the standard text field and will limit choices to the choices
@@ -195,17 +195,17 @@ ones:
         >>> p.get_gender_display()
         u'Male'
 
-    :attr:`~Field.default`
+:attr:`~Field.default`
     The default value for the field. This can be a value or a callable
     object. If callable it will be called every time a new object is
     created.
 
-    :attr:`~Field.help_text`
+:attr:`~Field.help_text`
     Extra "help" text to be displayed under the field on the object's admin
     form. It's useful for documentation even if your object doesn't have an
     admin form.
 
-    :attr:`~Field.primary_key`
+:attr:`~Field.primary_key`
     If ``True``, this field is the primary key for the model.
 
     If you don't specify :attr:`primary_key=True <Field.primary_key>` for
@@ -215,7 +215,7 @@ ones:
     unless you want to override the default primary-key behavior. For more,
     see :ref:`automatic-primary-key-fields`.
 
-    :attr:`~Field.unique`
+:attr:`~Field.unique`
     If ``True``, this field must be unique throughout the table.
 
 Again, these are just short descriptions of the most common field options. Full
@@ -435,21 +435,21 @@ explicit declaration defines how the two models are related.
 
 There are a few restrictions on the intermediate model:
 
-    * Your intermediate model must contain one - and *only* one - foreign key
+* Your intermediate model must contain one - and *only* one - foreign key
   to the target model (this would be ``Person`` in our example). If you
   have more than one foreign key, a validation error will be raised.
 
-    * Your intermediate model must contain one - and *only* one - foreign key
+* Your intermediate model must contain one - and *only* one - foreign key
   to the source model (this would be ``Group`` in our example). If you
   have more than one foreign key, a validation error will be raised.
 
-    * The only exception to this is a model which has a many-to-many
+* The only exception to this is a model which has a many-to-many
   relationship to itself, through an intermediary model. In this
   case, two foreign keys to the same model are permitted, but they
   will be treated as the two (different) sides of the many-to-many
   relation.
 
-    * When defining a many-to-many relationship from a model to
+* When defining a many-to-many relationship from a model to
   itself, using an intermediary model, you *must* use
   :attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
   :ref:`the model field reference <manytomany-arguments>`).
@@ -601,13 +601,13 @@ Field name restrictions
 
 Django places only two restrictions on model field names:
 
-    1. A field name cannot be a Python reserved word, because that would result
+1. A field name cannot be a Python reserved word, because that would result
    in a Python syntax error. For example::
 
        class Example(models.Model):
            pass = models.IntegerField() # 'pass' is a reserved word!
 
-    2. A field name cannot contain more than one underscore in a row, due to
+2. A field name cannot contain more than one underscore in a row, due to
    the way Django's query lookup syntax works. For example::
 
        class Example(models.Model):
@@ -702,7 +702,7 @@ of :ref:`methods automatically given to each model <model-instance-methods>`.
 You can override most of these -- see `overriding predefined model methods`_,
 below -- but there are a couple that you'll almost always want to define:
 
-    :meth:`~Model.__unicode__`
+:meth:`~Model.__unicode__`
     A Python "magic method" that returns a unicode "representation" of any
     object. This is what Python and Django will use whenever a model
     instance needs to be coerced and displayed as a plain string. Most
@@ -712,7 +712,7 @@ below -- but there are a couple that you'll almost always want to define:
     You'll always want to define this method; the default isn't very helpful
     at all.
 
-    :meth:`~Model.get_absolute_url`
+:meth:`~Model.get_absolute_url`
     This tells Django how to calculate the URL for an object. Django uses
     this in its admin interface, and any time it needs to figure out a URL
     for an object.
@@ -800,14 +800,14 @@ models.
 
 There are three styles of inheritance that are possible in Django.
 
- 1. Often, you will just want to use the parent class to hold information that
+1. Often, you will just want to use the parent class to hold information that
    you don't want to have to type out for each child model. This class isn't
    going to ever be used in isolation, so :ref:`abstract-base-classes` are
    what you're after.
- 2. If you're subclassing an existing model (perhaps something from another
+2. If you're subclassing an existing model (perhaps something from another
    application entirely) and want each model to have its own database table,
    :ref:`multi-table-inheritance` is the way to go.
- 3. Finally, if you only want to modify the Python-level behavior of a model,
+3. Finally, if you only want to modify the Python-level behavior of a model,
    without changing the models fields in any way, you can use
    :ref:`proxy-models`.
 
@@ -1197,11 +1197,11 @@ were needed in any case, so the current separation arose.
 
 So, the general rules are:
 
-    1. If you are mirroring an existing model or database table and don't want
+1. If you are mirroring an existing model or database table and don't want
    all the original database table columns, use ``Meta.managed=False``.
    That option is normally useful for modeling database views and tables
    not under the control of Django.
-    2. If you are wanting to change the Python-only behavior of a model, but
+2. If you are wanting to change the Python-only behavior of a model, but
    keep all the same fields as in the original, use ``Meta.proxy=True``.
    This sets things up so that the proxy model is an exact copy of the
    storage structure of the original model when data is saved.