Fixed display of lists after website redesign

Thanks Brian Jacobel for the report. refs django/djangoproject.com#197

docs/ref/templates/builtins.txt

@@ -833,13 +833,18 @@ This complex tag is best illustrated by way of an example: say that "places" is
 ...and you'd like to display a hierarchical list that is ordered by country, like this:
 
 * India
-    * Mumbai: 19,000,000
-    * Calcutta: 15,000,000
+
+  * Mumbai: 19,000,000
+  * Calcutta: 15,000,000
+
 * USA
-    * New York: 20,000,000
-    * Chicago: 7,000,000
+
+  * New York: 20,000,000
+  * Chicago: 7,000,000
+
 * Japan
-    * Tokyo: 33,000,000
+
+  * Tokyo: 33,000,000
 
 
 You can use the ``{% regroup %}`` tag to group the list of cities by country.
@@ -893,15 +898,24 @@ With this input for ``cities``, the example ``{% regroup %}`` template code
 above would result in the following output:
 
 * India
-    * Mumbai: 19,000,000
+
+  * Mumbai: 19,000,000
+
 * USA
-    * New York: 20,000,000
+
+  * New York: 20,000,000
+
 * India
-    * Calcutta: 15,000,000
+
+  * Calcutta: 15,000,000
+
 * USA
-    * Chicago: 7,000,000
+
+  * Chicago: 7,000,000
+
 * Japan
-    * Tokyo: 33,000,000
+
+  * Tokyo: 33,000,000
 
 The easiest solution to this gotcha is to make sure in your view code that the
 data is ordered according to how you want to display it.

docs/releases/1.6.txt

@@ -836,11 +836,11 @@ Object Relational Mapper changes
 Django 1.6 contains many changes to the ORM. These changes fall mostly in
 three categories:
 
-  1. Bug fixes (e.g. proper join clauses for generic relations, query
-     combining, join promotion, and join trimming fixes)
-  2. Preparation for new features. For example the ORM is now internally ready
-     for multicolumn foreign keys.
-  3. General cleanup.
+1. Bug fixes (e.g. proper join clauses for generic relations, query combining,
+   join promotion, and join trimming fixes)
+2. Preparation for new features. For example the ORM is now internally ready
+   for multicolumn foreign keys.
+3. General cleanup.
 
 These changes can result in some compatibility problems. For example, some
 queries will now generate different table aliases. This can affect

docs/topics/cache.txt

@@ -169,11 +169,12 @@ got a fast, well-indexed database server.
 
 To use a database table as your cache backend:
 
-    * Set :setting:`BACKEND <CACHES-BACKEND>` to
-      ``django.core.cache.backends.db.DatabaseCache``
-    * Set :setting:`LOCATION <CACHES-LOCATION>` to ``tablename``, the name of
-      the database table. This name can be whatever you want, as long as it's
-      a valid table name that's not already being used in your database.
+* Set :setting:`BACKEND <CACHES-BACKEND>` to
+  ``django.core.cache.backends.db.DatabaseCache``
+
+* Set :setting:`LOCATION <CACHES-LOCATION>` to ``tablename``, the name of the
+  database table. This name can be whatever you want, as long as it's a valid
+  table name that's not already being used in your database.
 
 In this example, the cache table's name is ``my_cache_table``::
 

docs/topics/forms/index.txt

@@ -148,9 +148,9 @@ Instantiating, processing, and rendering forms
 
 When rendering an object in Django, we generally:
 
-    1. get hold of it in the view (fetch it from the database, for example)
-    2. pass it to the template context
-    3. expand it to HTML markup using template variables
+1. get hold of it in the view (fetch it from the database, for example)
+2. pass it to the template context
+3. expand it to HTML markup using template variables
 
 Rendering a form in a template involves nearly the same work as rendering any
 other kind of object, but there are some key differences.