queryset-refactor: Merged from trunk up to [7216].

git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7219 bcc190cf-cafb-0310-a4f2-bffc1f526a37

6 files changed, 31 insertions, 12 deletions

diff --git a/docs/faq.txt b/docs/faq.txt
index 3d7db36fbc..56c9536eda 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -166,7 +166,7 @@ logical to us.
 We're well aware that there are other awesome Web frameworks out there, and
 we're not averse to borrowing ideas where appropriate. However, Django was
 developed precisely because we were unhappy with the status quo, so please be
-aware that "because <Framework X>" does it is not going to be sufficient reason
+aware that "because <Framework X> does it" is not going to be sufficient reason
 to add a given feature to Django.
 
 Why did you write all of Django from scratch, instead of using other Python libraries?
diff --git a/docs/flatpages.txt b/docs/flatpages.txt
index 7c27fe8793..b6fa8e035f 100644
--- a/docs/flatpages.txt
+++ b/docs/flatpages.txt
@@ -24,11 +24,14 @@ Installation
 
 To install the flatpages app, follow these steps:
 
-    1. Add ``'django.contrib.flatpages'`` to your INSTALLED_APPS_ setting.
-    2. Add ``'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware'``
+    1. Install the `sites framework`_ by adding ``'django.contrib.sites'`` to
+       your INSTALLED_APPS_ setting, if it's not already in there.
+    2. Add ``'django.contrib.flatpages'`` to your INSTALLED_APPS_ setting.
+    3. Add ``'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware'``
        to your MIDDLEWARE_CLASSES_ setting.
-    3. Run the command ``manage.py syncdb``.
+    4. Run the command ``manage.py syncdb``.
 
+.. _sites framework: ../sites/
 .. _INSTALLED_APPS: ../settings/#installed-apps
 .. _MIDDLEWARE_CLASSES: ../settings/#middleware-classes
 
diff --git a/docs/i18n.txt b/docs/i18n.txt
index 78404d4503..bb6cf74ded 100644
--- a/docs/i18n.txt
+++ b/docs/i18n.txt
@@ -547,7 +547,7 @@ following this algorithm:
 
     * First, it looks for a ``django_language`` key in the the current user's
       `session`_.
-    * Failing that, it looks for a cookie called ``django_language``.
+    * Failing that, it looks for a cookie that is named according to your ``LANGUAGE_COOKIE_NAME`` setting (the default name is: ``django_language``).
     * Failing that, it looks at the ``Accept-Language`` HTTP header. This
       header is sent by your browser and tells the server which language(s) you
       prefer, in order by priority. Django tries each language in the header
@@ -719,7 +719,8 @@ Activate this view by adding the following line to your URLconf::
 The view expects to be called via the ``POST`` method, with a ``language``
 parameter set in request. If session support is enabled, the view
 saves the language choice in the user's session. Otherwise, it saves the
-language choice in a ``django_language`` cookie.
+language choice in a cookie that is by default named ``django_language``
+(the name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting).
 
 After setting the language choice, Django redirects the user, following this
 algorithm:
diff --git a/docs/newforms.txt b/docs/newforms.txt
index 19f42cb2ee..9d95d88b9f 100644
--- a/docs/newforms.txt
+++ b/docs/newforms.txt
@@ -243,6 +243,10 @@ object::
     >>> f.cleaned_data
     {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
 
+.. note::
+    **New in Django development version** The ``cleaned_data`` attribute was
+    called ``clean_data`` in earlier releases.
+
 Note that any text-based field -- such as ``CharField`` or ``EmailField`` --
 always cleans the input into a Unicode string. We'll cover the encoding
 implications later in this document.
diff --git a/docs/settings.txt b/docs/settings.txt
index 8478e0ce96..ace893f1b5 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -579,6 +579,16 @@ in standard language format. For example, U.S. English is ``"en-us"``. See the
 
 .. _internationalization docs: ../i18n/
 
+LANGUAGE_COOKIE_NAME
+--------------------
+
+Default: ``'django_language'``
+
+The name of the cookie to use for the language cookie. This can be whatever
+you want (but should be different from SESSION_COOKIE_NAME). See the
+`internationalization docs`_ for details.
+
+
 LANGUAGES
 ---------
 
@@ -822,8 +832,8 @@ SESSION_COOKIE_NAME
 
 Default: ``'sessionid'``
 
-The name of the cookie to use for sessions. This can be whatever you want.
-See the `session docs`_.
+The name of the cookie to use for sessions. This can be whatever you want (but
+should be different from ``LANGUAGE_COOKIE_NAME``). See the `session docs`_.
 
 SESSION_COOKIE_PATH
 -------------------
diff --git a/docs/templates_python.txt b/docs/templates_python.txt
index c6e9223e9f..43ef016ed4 100644
--- a/docs/templates_python.txt
+++ b/docs/templates_python.txt
@@ -629,9 +629,10 @@ the given Python module name, not the name of the app.
 Once you've created that Python module, you'll just have to write a bit of
 Python code, depending on whether you're writing filters or tags.
 
-To be a valid tag library, the module contain a module-level variable named
-``register`` that is a ``template.Library`` instance, in which all the tags and
-filters are registered. So, near the top of your module, put the following::
+To be a valid tag library, the module must contain a module-level variable
+named ``register`` that is a ``template.Library`` instance, in which all the
+tags and filters are registered. So, near the top of your module, put the
+following::
 
     from django import template
 
@@ -983,7 +984,7 @@ Notes:
       exception. It should fail silently, just as template filters should.
 
 Ultimately, this decoupling of compilation and rendering results in an
-efficient template system, because a template can render multiple context
+efficient template system, because a template can render multiple contexts
 without having to be parsed multiple times.
 
 Auto-escaping considerations