[1.0.X]: Fixed #10389, #10501, #10502, #10540, #10562, #10563, #10564, #10565, #10568, #10569, #10614, #10617, #10619 -- Fixed several typos as well as a couple minor issues in the docs, patches from timo, nih, bthomas, rduffield, UloPe, and sebleier@gmail.com.

Backport of r10242 from trunk.


git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10243 bcc190cf-cafb-0310-a4f2-bffc1f526a37

3 files changed, 16 insertions, 20 deletions

diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt
index 056a54e193..6fe589f4a2 100644
--- a/docs/howto/custom-model-fields.txt
+++ b/docs/howto/custom-model-fields.txt
@@ -45,7 +45,7 @@ something like this::
             self.east = east
             self.south = south
             self.west = west
-        
+
         # ... (other possibly useful methods omitted) ...
 
 .. _Bridge: http://en.wikipedia.org/wiki/Contract_bridge
@@ -203,7 +203,7 @@ parameters:
       :class:`ForeignKey`). For advanced use only.
     * :attr:`~django.db.models.Field.default`
     * :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 :ref:`serializers
       <topics-serialization>`. Defaults to ``True``.
     * :attr:`~django.db.models.Field.prepopulate_from`
@@ -254,7 +254,7 @@ called when the attribute is initialized.
 Useful methods
 --------------
 
-Once you've created your :class:`~django.db.models.Field` subclass and set up up
+Once you've created your :class:`~django.db.models.Field` subclass and set up
 the ``__metaclass__``, you might consider overriding a few standard methods,
 depending on your field's behavior. The list of methods below is in
 approximately decreasing order of importance, so start from the top.
@@ -419,9 +419,9 @@ For example::
 
 Same as the above, but called when the Field value must be *saved* to the
 database. As the default implementation just calls ``get_db_prep_value``, you
-shouldn't need to implement this method unless your custom field need a special
-conversion when being saved that is not the same as the used for normal query
-parameters (which is implemented by ``get_db_prep_value``).
+shouldn't need to implement this method unless your custom field needs a
+special conversion when being saved that is not the same as the conversion used
+for normal query parameters (which is implemented by ``get_db_prep_value``).
 
 Preprocessing values before saving
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -522,7 +522,7 @@ Continuing our ongoing example, we can write the :meth:`formfield` method as::
             defaults.update(kwargs)
             return super(HandField, self).formfield(**defaults)
 
-This assumes we're imported a ``MyFormField`` field class (which has its own
+This assumes we've imported a ``MyFormField`` field class (which has its own
 default widget). This document doesn't cover the details of writing custom form
 fields.
 
diff --git a/docs/howto/deployment/fastcgi.txt b/docs/howto/deployment/fastcgi.txt
index 63f44eae19..2049cacf2a 100644
--- a/docs/howto/deployment/fastcgi.txt
+++ b/docs/howto/deployment/fastcgi.txt
@@ -1,8 +1,8 @@
 .. _howto-deployment-fastcgi:
 
-===========================================
-How to use Django with FastCGI, SCGI or AJP
-===========================================
+============================================
+How to use Django with FastCGI, SCGI, or AJP
+============================================
 
 .. highlight:: bash
 
@@ -379,5 +379,3 @@ have different script names in this case, but that is a rare situation.
 As an example of how to use it, if your Django configuration is serving all of
 the URLs under ``'/'`` and you wanted to use this setting, you would set
 ``FORCE_SCRIPT_NAME = ''`` in your settings file.
-
-
diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt
index 8799b390fe..70f1e37749 100644
--- a/docs/howto/deployment/modpython.txt
+++ b/docs/howto/deployment/modpython.txt
@@ -17,8 +17,8 @@ performance gains over other server arrangements.
 Django requires Apache 2.x and mod_python 3.x, and you should use Apache's
 `prefork MPM`_, as opposed to the `worker MPM`_.
 
-You may also be interested in :ref:`How to use Django with FastCGI, SCGI or AJP
-<howto-deployment-fastcgi>` (which also covers SCGI and AJP).
+You may also be interested in :ref:`How to use Django with FastCGI, SCGI, or
+AJP <howto-deployment-fastcgi>`.
 
 .. _Apache: http://httpd.apache.org/
 .. _mod_python: http://www.modpython.org/
@@ -38,7 +38,7 @@ Then edit your ``httpd.conf`` file and add the following::
         SetHandler python-program
         PythonHandler django.core.handlers.modpython
         SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-        PythonOption django.root /mysite        
+        PythonOption django.root /mysite
         PythonDebug On
     </Location>
 
@@ -84,7 +84,7 @@ computer, you'll have to tell mod_python where your project can be found:
         SetHandler python-program
         PythonHandler django.core.handlers.modpython
         SetEnv DJANGO_SETTINGS_MODULE mysite.settings
-        PythonOption django.root /mysite        
+        PythonOption django.root /mysite
         PythonDebug On
         **PythonPath "['/path/to/project'] + sys.path"**
     </Location>
@@ -273,7 +273,7 @@ Here are two recommended approaches:
        document root. This way, all of your Django-related files -- code **and**
        templates -- stay in one place, and you'll still be able to ``svn
        update`` your code to get the latest admin templates, if they change.
-       
+
     2. Or, copy the admin media files so that they live within your Apache
        document root.
 
@@ -337,7 +337,7 @@ of which has to do with Django itself.
     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
        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
@@ -361,5 +361,3 @@ as necessary.
 .. _Expat Causing Apache Crash: http://www.dscpl.com.au/articles/modpython-006.html
 .. _mod_python FAQ entry: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
 .. _Getting mod_python Working: http://www.dscpl.com.au/articles/modpython-001.html
-
-