Made a bunch of small doc rewordings from changes over the past couple of weeks

git-svn-id: http://code.djangoproject.com/svn/django/trunk@7122 bcc190cf-cafb-0310-a4f2-bffc1f526a37

5 files changed, 25 insertions, 21 deletions

diff --git a/docs/modelforms.txt b/docs/modelforms.txt
index b9f0d88165..853fb3159e 100644
--- a/docs/modelforms.txt
+++ b/docs/modelforms.txt
@@ -323,17 +323,18 @@ parameter when declaring the form field::
 
 Form inheritance
 ----------------
-As with the basic forms, you can extend and reuse ``ModelForms`` by inheriting
-them. Normally, this will be useful if you need to declare some extra fields
-or extra methods on a parent class for use in a number of forms derived from
-models. For example, using the previous ``ArticleForm`` class::
+
+As with basic forms, you can extend and reuse ``ModelForms`` by inheriting
+them. This is useful if you need to declare extra fields or extra methods on a
+parent class for use in a number of forms derived from models. For example,
+using the previous ``ArticleForm`` class::
 
     >>> class EnhancedArticleForm(ArticleForm):
     ...     def clean_pub_date(self):
     ...         ...
 
-This creates a form that behaves identically to ``ArticleForm``, except there
-is some extra validation and cleaning for the ``pub_date`` field.
+This creates a form that behaves identically to ``ArticleForm``, except there's
+some extra validation and cleaning for the ``pub_date`` field.
 
 You can also subclass the parent's ``Meta`` inner class if you want to change
 the ``Meta.fields`` or ``Meta.excludes`` lists::
@@ -342,17 +343,18 @@ the ``Meta.fields`` or ``Meta.excludes`` lists::
     ...     class Meta(ArticleForm.Meta):
     ...         exclude = ['body']
 
-This adds in the extra method from the ``EnhancedArticleForm`` and modifies
+This adds the extra method from the ``EnhancedArticleForm`` and modifies
 the original ``ArticleForm.Meta`` to remove one field.
 
-There are a couple of things to note, however. Most of these won't normally be
-of concern unless you are trying to do something tricky with subclassing.
+There are a couple of things to note, however.
 
  * Normal Python name resolution rules apply. If you have multiple base
    classes that declare a ``Meta`` inner class, only the first one will be
-   used.  This means the child's ``Meta``, if it exists, otherwise the
+   used. This means the child's ``Meta``, if it exists, otherwise the
    ``Meta`` of the first parent, etc.
 
- * For technical reasons, you cannot have a subclass that is inherited from
-   both a ``ModelForm`` and a ``Form`` simultaneously.
+ * For technical reasons, a subclass cannot inherit from both a ``ModelForm``
+   and a ``Form`` simultaneously.
 
+Chances are these notes won't affect you unless you're trying to do something
+tricky with subclassing.
diff --git a/docs/request_response.txt b/docs/request_response.txt
index 47c66355e8..e50cfc5ea3 100644
--- a/docs/request_response.txt
+++ b/docs/request_response.txt
@@ -576,7 +576,7 @@ Three things to note about 404 views:
       in the 404.
 
     * The 404 view is passed a ``RequestContext`` and will have access to
-      variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` (e.g.
+      variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g.,
       ``MEDIA_URL``).
 
     * If ``DEBUG`` is set to ``True`` (in your settings module), then your 404
diff --git a/docs/shortcuts.txt b/docs/shortcuts.txt
index f1d7f38ffa..005fdc3029 100644
--- a/docs/shortcuts.txt
+++ b/docs/shortcuts.txt
@@ -30,9 +30,9 @@ Optional arguments
 ``context_instance``
     The context instance to render the template with. By default, the template
     will be rendered with a ``Context`` instance (filled with values from
-    ``dictionary``). If you need to use `context processors`_, you will want to
-    render the template with a ``RequestContext`` instance instead. Your code
-    might look something like this::
+    ``dictionary``). If you need to use `context processors`_, render the
+    template with a ``RequestContext`` instance instead. Your code might look
+    something like this::
 
         return render_to_response('my_template.html',
                                   my_data_dictionary,
diff --git a/docs/templates.txt b/docs/templates.txt
index c351c951c9..d473a6f06f 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -1406,6 +1406,8 @@ Joins a list with a string, like Python's ``str.join(list)``.
 last
 ~~~~
 
+**New in Django development version.**
+
 Returns the last item in a list.
 
 length
diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt
index 952763f078..789399de8d 100644
--- a/docs/url_dispatch.txt
+++ b/docs/url_dispatch.txt
@@ -191,12 +191,12 @@ The remaining arguments should be tuples in this format::
 `Passing extra options to view functions`_ below.)
 
 .. note::
-    Since `patterns()` is a function call, it accepts a maximum of 255
+    Because `patterns()` is a function call, it accepts a maximum of 255
     arguments (URL patterns, in this case). This is a limit for all Python
-    function calls. This will rarely be  problem in practice, since you'll
+    function calls. This is rarely a problem in practice, because you'll
     typically structure your URL patterns modularly by using `include()`
     sections. However, on the off-chance you do hit the 255-argument limit,
-    realise that `patterns()` returns a Python list, so you can split up the
+    realize that `patterns()` returns a Python list, so you can split up the
     construction of the list.
 
     ::
@@ -209,8 +209,8 @@ The remaining arguments should be tuples in this format::
             )
 
     Python lists have unlimited size, so there's no limit to how many URL
-    patterns you can construct; merely that you may only create 254 at a time
-    (the 255-th argument is the initial prefix argument).
+    patterns you can construct. The only limit is that you can only create 254
+    at a time (the 255th argument is the initial prefix argument).
 
 url
 ---