From c7786550c4ed396b8580db58f7da60e850894d19 Mon Sep 17 00:00:00 2001
From: Markus Holtermann <info@markusholtermann.eu>
Date: Wed, 17 Dec 2014 14:01:19 +0100
Subject: [PATCH] Fixed display of lists after website redesign

Thanks Brian Jacobel for the report. refs django/djangoproject.com#197
---
 docs/ref/templates/builtins.txt | 34 +++++++++++++++++++++++----------
 docs/releases/1.6.txt           | 10 +++++-----
 docs/topics/cache.txt           | 11 ++++++-----
 docs/topics/forms/index.txt     |  6 +++---
 4 files changed, 38 insertions(+), 23 deletions(-)

diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index 146f2eacd6..e1ea472f7a 100644
--- a/docs/ref/templates/builtins.txt
+++ b/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.
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 2585de13b8..d261a480ba 100644
--- a/docs/releases/1.6.txt
+++ b/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
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index b515925df2..38d2f26cbe 100644
--- a/docs/topics/cache.txt
+++ b/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``::
 
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index c11b96ba15..85c03a48b8 100644
--- a/docs/topics/forms/index.txt
+++ b/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.