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

1 files changed, 45 insertions, 45 deletions

diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index 5356af3563..08f738c879 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -17,14 +17,14 @@ 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)
-   for details on how to set or alter the database character set encoding.
+* 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 8) for details on creating databases with the correct encoding.
+* 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
-   for internal encoding.
+* 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
 .. _PostgreSQL manual: http://www.postgresql.org/docs/8.2/static/multibyte.html#AEN24104
@@ -106,35 +106,35 @@ 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')``
-      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
-      ``strings_only`` parameter, if set to True, will result in Python
-      numbers, booleans and ``None`` not being converted to a string (they keep
-      their original types). The ``errors`` parameter takes any of the values
-      that are accepted by Python's ``unicode()`` function for its error
-      handling.
+* ``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
+  ``strings_only`` parameter, if set to True, will result in Python
+  numbers, booleans and ``None`` not being converted to a string (they keep
+  their original types). The ``errors`` parameter takes any of the values
+  that are accepted by Python's ``unicode()`` function for its error
+  handling.
 
-      If you pass ``smart_unicode()`` an object that has a ``__unicode__``
-      method, it will use that method to do the conversion.
+  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,
-      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()``
-      preserves lazy translations, ``force_unicode()`` forces those objects to a
-      Unicode string (causing the translation to occur). Normally, you'll want
-      to use ``smart_unicode()``. However, ``force_unicode()`` is useful in
-      template tags and filters that absolutely *must* have a string to work
-      with, not just something that can be converted to a string.
+* ``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()``
+  preserves lazy translations, ``force_unicode()`` forces those objects to a
+  Unicode string (causing the translation to occur). Normally, you'll want
+  to use ``smart_unicode()``. However, ``force_unicode()`` is useful in
+  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')``
-      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
-      slightly different semantics from Python's builtin ``str()`` function,
-      but the difference is needed in a few places within Django's internals.
+* ``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
+  slightly different semantics from Python's builtin ``str()`` function,
+  but the difference is needed in a few places within Django's internals.
 
 Normally, you'll only need to use ``smart_unicode()``. Call it as early as
 possible on any input data that might be either Unicode or a bytestring, and
@@ -152,13 +152,13 @@ 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
-      conversion from IRI to URI as required by the specification (:rfc:`3987`).
+* 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
-      ``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.)
+* 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.)
 
 These two groups of functions have slightly different purposes, and it's
 important to keep them straight. Normally, you would use ``urlquote()`` on the
@@ -295,14 +295,14 @@ 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
-      and from template filters.
+* 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
-      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
-      strings at that point.
+* 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
+  strings at that point.
 
 Email
 =====