Fixed #14281 -- A few documentation fixes. Thanks, Ramiro and Timo.

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

6 files changed, 21 insertions, 10 deletions

diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt
index a9b665f331..90a85cac5c 100644
--- a/docs/howto/deployment/modpython.txt
+++ b/docs/howto/deployment/modpython.txt
@@ -1,5 +1,3 @@
-.. _howto-deployment-modpython:
-
 ============================================
 How to use Django with Apache and mod_python
 ============================================
diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt
index a7d67c74e3..9c83363ef9 100644
--- a/docs/ref/generic-views.txt
+++ b/docs/ref/generic-views.txt
@@ -96,6 +96,8 @@ If the given URL is ``None``, Django will return an ``HttpResponseGone`` (410).
 .. versionadded:: 1.1
     The ``permanent`` keyword argument is new in Django 1.1.
 
+.. versionadded:: 1.3
+    The ``query_string`` keyword argument is new in Django 1.3.
 
 **Example:**
 
@@ -380,7 +382,7 @@ In addition to ``extra_context``, the template's context will be:
 
     * ``date_list``: A list of ``datetime.date`` objects representing all
       days that have objects available in the given month, according to
-      ``queryset``, in ascending order.    
+      ``queryset``, in ascending order.
 
     * ``month``: A ``datetime.date`` object representing the given month.
 
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index b8b08829e9..064f1201f7 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -40,13 +40,13 @@ All attributes except ``session`` should be considered read-only.
     Under some web server configurations, the portion of the URL after the host
     name is split up into a script prefix portion and a path info portion
     (this happens, for example, when using the ``django.root`` option
-    with the :ref:`modpython handler from Apache <howto-deployment-modpython>`).
+    with the :doc:`modpython handler from Apache </howto/deployment/modpython>`).
     The ``path_info`` attribute always contains the path info portion of the
     path, no matter what web server is being used. Using this instead of
     attr:`~HttpRequest.path` can make your code much easier to move between test
     and deployment servers.
 
-    For example, if the ``django.root`` for your application is set to 
+    For example, if the ``django.root`` for your application is set to
     ``"/minfo"``, then ``path`` might be ``"/minfo/music/bands/the_beatles/"``
     and ``path_info`` would be ``"/music/bands/the_beatles/"``.
 
@@ -542,6 +542,12 @@ Methods
 
     .. _`cookie Morsel`: http://docs.python.org/library/cookie.html#Cookie.Morsel
 
+    .. versionchanged:: 1.3
+
+    Both the possibility of specifying a ``datetime.datetime`` object in
+    ``expires`` and the auto-calculation of ``max_age`` in such case were added
+    in Django 1.3.
+
 .. method:: HttpResponse.delete_cookie(key, path='/', domain=None)
 
     Deletes the cookie with the given key. Fails silently if the key doesn't
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index 1f499909ee..3ba217ba8d 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -939,9 +939,9 @@ Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
 However, if your application constructs part of the URL hierarchy itself, you
 may occasionally need to generate URLs. In that case, you need to be able to
 find the base URL of the Django project within its web server
-(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for 
+(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
 you). In that case, you can call ``get_script_prefix()``, which will return the
 script prefix portion of the URL for your Django project. If your Django
 project is at the root of its webserver, this is always ``"/"``, but it can be
-changed, for instance  by using ``django.root`` (see :ref:`How to use
-Django with Apache and mod_python <howto-deployment-modpython>`).
+changed, for instance  by using ``django.root`` (see :doc:`How to use
+Django with Apache and mod_python </howto/deployment/modpython>`).
diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt
index 78790db071..56700581ca 100644
--- a/docs/topics/signals.txt
+++ b/docs/topics/signals.txt
@@ -89,7 +89,8 @@ manual connect route:
 
     request_finished.connect(my_callback)
 
-Alternatively, you can use a decorator used when you define your receiver:
+Alternatively, you can use a ``receiver`` decorator when you define your
+receiver:
 
 .. code-block:: python
 
@@ -102,6 +103,10 @@ Alternatively, you can use a decorator used when you define your receiver:
 
 Now, our ``my_callback`` function will be called each time a request finishes.
 
+.. versionadded:: 1.3
+
+The ``receiver`` decorator was added in Django 1.3.
+
 .. admonition:: Where should this code live?
 
     You can put signal handling and registration code anywhere you like.
diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt
index c3fdd2cf0e..fb04a3a233 100644
--- a/docs/topics/templates.txt
+++ b/docs/topics/templates.txt
@@ -590,7 +590,7 @@ a model called "comment" with a foreign key relationship to a model called
         {{ comment }}
     {% endfor %}
 
-Similarly, :doc:`QuerySets<ref/models/querysets>` provide a ``count()`` method
+Similarly, :doc:`QuerySets</ref/models/querysets>` provide a ``count()`` method
 to count the number of objects they contain. Therefore, you can obtain a count
 of all comments related to the current task with::