[1.7.x] Fixed display of lists after website redesign

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

Backport of c7786550c4 from master

docs/ref/templates/builtins.txt

@@ -821,12 +821,17 @@ 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
+
 * USA
+
   * New York: 20,000,000
   * Chicago: 7,000,000
+
 * Japan
+
   * Tokyo: 33,000,000
 
 
@@ -881,14 +886,23 @@ With this input for ``cities``, the example ``{% regroup %}`` template code
 above would result in the following output:
 
 * India
+
   * Mumbai: 19,000,000
+
 * USA
+
   * New York: 20,000,000
+
 * India
+
   * Calcutta: 15,000,000
+
 * USA
+
   * Chicago: 7,000,000
+
 * Japan
+
   * Tokyo: 33,000,000
 
 The easiest solution to this gotcha is to make sure in your view code that the

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
+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.
+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

@@ -168,11 +168,12 @@ got a fast, well-indexed database server.
 
 To use a database table as your cache backend:
 
-    * Set :setting:`BACKEND <CACHES-BACKEND>` to
+* 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:`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.