Merge remote-tracking branch 'core/master' into schema-alteration

Conflicts:
	django/core/management/commands/flush.py
	django/core/management/commands/syncdb.py
	django/db/models/loading.py
	docs/internals/deprecation.txt
	docs/ref/django-admin.txt
	docs/releases/1.7.txt

docs/topics/auth/default.txt

@@ -561,13 +561,33 @@ Most built-in authentication views provide a URL name for easier reference. See
 patterns.
 
 
-.. function:: login(request, [template_name, redirect_field_name, authentication_form])
+.. function:: login(request, [template_name, redirect_field_name, authentication_form, current_app, extra_context])
 
     **URL name:** ``login``
 
     See :doc:`the URL documentation </topics/http/urls>` for details on using
     named URL patterns.
 
+    **Optional arguments:**
+
+    * ``template_name``: The name of a template to display for the view used to
+      log the user in. Defaults to :file:`registration/login.html`.
+
+    * ``redirect_field_name``: The name of a ``GET`` field containing the
+      URL to redirect to after login. Overrides ``next`` if the given
+      ``GET`` parameter is passed.
+
+    * ``authentication_form``: A callable (typically just a form class) to
+      use for authentication. Defaults to
+      :class:`~django.contrib.auth.forms.AuthenticationForm`.
+
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
     Here's what ``django.contrib.auth.views.login`` does:
 
     * If called via ``GET``, it displays a login form that POSTs to the
@@ -657,7 +677,7 @@ patterns.
     .. _site framework docs: ../sites/
 
 
-.. function:: logout(request, [next_page, template_name, redirect_field_name])
+.. function:: logout(request, [next_page, template_name, redirect_field_name, current_app, extra_context])
 
     Logs a user out.
 
@@ -675,6 +695,13 @@ patterns.
       URL to redirect to after log out. Overrides ``next_page`` if the given
       ``GET`` parameter is passed.
 
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
     **Template context:**
 
     * ``title``: The string "Logged out", localized.
@@ -691,7 +718,14 @@ patterns.
       :attr:`request.META['SERVER_NAME'] <django.http.HttpRequest.META>`.
       For more on sites, see :doc:`/ref/contrib/sites`.
 
-.. function:: logout_then_login(request[, login_url])
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
+.. function:: logout_then_login(request[, login_url, current_app, extra_context])
 
     Logs a user out, then redirects to the login page.
 
@@ -702,7 +736,14 @@ patterns.
     * ``login_url``: The URL of the login page to redirect to.
       Defaults to :setting:`settings.LOGIN_URL <LOGIN_URL>` if not supplied.
 
-.. function:: password_change(request[, template_name, post_change_redirect, password_change_form])
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
+.. function:: password_change(request[, template_name, post_change_redirect, password_change_form, current_app, extra_context])
 
     Allows a user to change their password.
 
@@ -722,11 +763,18 @@ patterns.
       actually changing the user's password. Defaults to
       :class:`~django.contrib.auth.forms.PasswordChangeForm`.
 
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
     **Template context:**
 
     * ``form``: The password change form (see ``password_change_form`` above).
 
-.. function:: password_change_done(request[, template_name])
+.. function:: password_change_done(request[, template_name, current_app, extra_context])
 
     The page shown after a user has changed their password.
 
@@ -738,7 +786,14 @@ patterns.
       Defaults to :file:`registration/password_change_done.html` if not
       supplied.
 
-.. function:: password_reset(request[, is_admin_site, template_name, email_template_name, password_reset_form, token_generator, post_reset_redirect, from_email])
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
+.. function:: password_reset(request[, is_admin_site, template_name, email_template_name, password_reset_form, token_generator, post_reset_redirect, from_email, current_app, extra_context, html_email_template_name])
 
     Allows a user to reset their password by generating a one-time use link
     that can be used to reset the password, and sending that link to the
@@ -794,6 +849,21 @@ patterns.
     * ``from_email``: A valid email address. By default Django uses
       the :setting:`DEFAULT_FROM_EMAIL`.
 
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
+    * ``html_email_template_name``: The full name of a template to use
+      for generating a ``text/html`` multipart email with the password reset
+      link. By default, HTML email is not sent.
+
+    .. versionadded:: 1.7
+
+        ``html_email_template_name`` was added.
+
     **Template context:**
 
     * ``form``: The form (see ``password_reset_form`` above) for resetting
@@ -838,7 +908,7 @@ patterns.
     single line plain text string.
 
 
-.. function:: password_reset_done(request[, template_name])
+.. function:: password_reset_done(request[, template_name, current_app, extra_context])
 
     The page shown after a user has been emailed a link to reset their
     password. This view is called by default if the :func:`password_reset` view
@@ -852,7 +922,14 @@ patterns.
       Defaults to :file:`registration/password_reset_done.html` if not
       supplied.
 
-.. function:: password_reset_confirm(request[, uidb64, token, template_name, token_generator, set_password_form, post_reset_redirect])
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
+.. function:: password_reset_confirm(request[, uidb64, token, template_name, token_generator, set_password_form, post_reset_redirect, current_app, extra_context])
 
     Presents a form for entering a new password.
 
@@ -883,6 +960,13 @@ patterns.
     * ``post_reset_redirect``: URL to redirect after the password reset
       done. Defaults to ``None``.
 
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
     **Template context:**
 
     * ``form``: The form (see ``set_password_form`` above) for setting the
@@ -891,7 +975,7 @@ patterns.
     * ``validlink``: Boolean, True if the link (combination of ``uidb64`` and
       ``token``) is valid or unused yet.
 
-.. function:: password_reset_complete(request[,template_name])
+.. function:: password_reset_complete(request[,template_name, current_app, extra_context])
 
    Presents a view which informs the user that the password has been
    successfully changed.
@@ -903,6 +987,13 @@ patterns.
    * ``template_name``: The full name of a template to display the view.
      Defaults to :file:`registration/password_reset_complete.html`.
 
+    * ``current_app``: A hint indicating which application contains the current
+      view. See the :ref:`namespaced URL resolution strategy
+      <topics-http-reversing-url-namespaces>` for more information.
+
+    * ``extra_context``: A dictionary of context data that will be added to the
+      default context data passed to the template.
+
 Helper functions
 ----------------
 
@@ -959,6 +1050,40 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
     Takes ``request`` as its first positional argument, which is stored on the
     form instance for use by sub-classes.
 
+    .. method:: confirm_login_allowed(user)
+
+    .. versionadded:: 1.7
+
+    By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag
+    is set to ``False``. You may override this behavior with a custom policy to
+    determine which users can log in. Do this with a custom form that subclasses
+    ``AuthenticationForm`` and overrides the ``confirm_login_allowed`` method.
+    This method should raise a :exc:`~django.core.exceptions.ValidationError`
+    if the given user may not log in.
+
+    For example, to allow all users to log in, regardless of "active" status::
+
+        from django.contrib.auth.forms import AuthenticationForm
+
+        class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
+            def confirm_login_allowed(self, user):
+                pass
+
+    Or to allow only some active users to log in::
+
+        class PickyAuthenticationForm(AuthenticationForm):
+            def confirm_login_allowed(self, user):
+                if not user.is_active:
+                    raise forms.ValidationError(
+                        _("This account is inactive."),
+                        code='inactive',
+                    )
+                if user.username.startswith('b'):
+                    raise forms.ValidationError(
+                        _("Sorry, accounts starting with 'b' aren't welcome here."),
+                        code='no_b_users',
+                    )
+
 .. class:: PasswordChangeForm
 
     A form for allowing a user to change their password.

docs/topics/cache.txt

@@ -39,6 +39,8 @@ Django also works well with "upstream" caches, such as `Squid
 caches that you don't directly control but to which you can provide hints (via
 HTTP headers) about which parts of your site should be cached, and how.
 
+.. _setting-up-the-cache:
+
 Setting up the cache
 ====================
 
@@ -152,6 +154,8 @@ permanent storage -- they're all intended to be solutions for caching, not
 storage -- but we point this out here because memory-based caching is
 particularly temporary.
 
+.. _database-caching:
+
 Database caching
 ----------------
 

docs/topics/class-based-views/mixins.txt

@@ -170,7 +170,7 @@ being taken from the
 :attr:`~django.views.generic.list.MultipleObjectTemplateResponseMixin.template_name_suffix`
 attribute. (The date based generic views use suffixes such as ``_archive``,
 ``_archive_year`` and so on to use different templates for the various
-specialised date-based list views.)
+specialized date-based list views.)
 
 Using Django's class-based view mixins
 ======================================
@@ -288,7 +288,7 @@ object. In order to do this, we need to have two different querysets:
 
 ``Book`` queryset for use by :class:`~django.views.generic.list.ListView`
     Since we have access to the ``Publisher`` whose books we want to list, we
-    simply override ``get_queryset()`` and use the ``Publisher``'s
+    simply override ``get_queryset()`` and use the ``Publisher``’s
     :ref:`reverse foreign key manager<backwards-related-objects>`.
 
 ``Publisher`` queryset for use in :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
@@ -345,7 +345,7 @@ The ``paginate_by`` is deliberately small in the example so you don't
 have to create lots of books to see the pagination working! Here's the
 template you'd want to use:
 
-.. code-block: html+django
+.. code-block:: html+django
 
     {% extends "base.html" %}
 

docs/topics/db/managers.txt

@@ -100,7 +100,7 @@ access ``self.model`` to get the model class to which they're attached.
 Modifying initial Manager QuerySets
 -----------------------------------
 
-A ``Manager``'s base ``QuerySet`` returns all objects in the system. For
+A ``Manager``’s base ``QuerySet`` returns all objects in the system. For
 example, using this model::
 
     from django.db import models
@@ -111,7 +111,7 @@ example, using this model::
 
 ...the statement ``Book.objects.all()`` will return all books in the database.
 
-You can override a ``Manager``\'s base ``QuerySet`` by overriding the
+You can override a ``Manager``’s base ``QuerySet`` by overriding the
 ``Manager.get_queryset()`` method. ``get_queryset()`` should return a
 ``QuerySet`` with the properties you require.
 
@@ -201,6 +201,125 @@ attribute on the manager class. This is documented fully below_.
 
 .. _below: manager-types_
 
+.. _calling-custom-queryset-methods-from-manager:
+
+Calling custom ``QuerySet`` methods from the ``Manager``
+--------------------------------------------------------
+
+While most methods from the standard ``QuerySet`` are accessible directly from
+the ``Manager``, this is only the case for the extra methods defined on a
+custom ``QuerySet`` if you also implement them on the ``Manager``::
+
+    class PersonQuerySet(models.QuerySet):
+        def male(self):
+            return self.filter(sex='M')
+
+        def female(self):
+            return self.filter(sex='F')
+
+    class PersonManager(models.Manager):
+        def get_queryset(self):
+            return PersonQuerySet()
+
+        def male(self):
+            return self.get_queryset().male()
+
+        def female(self):
+            return self.get_queryset().female()
+
+    class Person(models.Model):
+        first_name = models.CharField(max_length=50)
+        last_name = models.CharField(max_length=50)
+        sex = models.CharField(max_length=1, choices=(('M', 'Male'), ('F', 'Female')))
+        people = PersonManager()
+
+This example allows you to call both ``male()`` and ``female()`` directly from
+the manager ``Person.people``.
+
+.. _create-manager-with-queryset-methods:
+
+Creating ``Manager`` with ``QuerySet`` methods
+----------------------------------------------
+
+.. versionadded:: 1.7
+
+In lieu of the above approach which requires duplicating methods on both the
+``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
+<django.db.models.query.QuerySet.as_manager>` can be used to create an instance
+of ``Manager`` with a copy of a custom ``QuerySet``’s methods::
+
+    class Person(models.Model):
+        ...
+        people = PersonQuerySet.as_manager()
+
+The ``Manager`` instance created by :meth:`QuerySet.as_manager()
+<django.db.models.query.QuerySet.as_manager>` will be virtually
+identical to the ``PersonManager`` from the previous example.
+
+Not every ``QuerySet`` method makes sense at the ``Manager`` level; for
+instance we intentionally prevent the :meth:`QuerySet.delete()
+<django.db.models.query.QuerySet.delete>` method from being copied onto
+the ``Manager`` class.
+
+Methods are copied according to the following rules:
+
+- Public methods are copied by default.
+- Private methods (starting with an underscore) are not copied by default.
+- Methods with a `queryset_only` attribute set to `False` are always copied.
+- Methods with a `queryset_only` attribute set to `True` are never copied.
+
+For example::
+
+    class CustomQuerySet(models.QuerySet):
+        # Available on both Manager and QuerySet.
+        def public_method(self):
+            return
+
+        # Available only on QuerySet.
+        def _private_method(self):
+            return
+
+        # Available only on QuerySet.
+        def opted_out_public_method(self):
+            return
+        opted_out_public_method.queryset_only = True
+
+        # Available on both Manager and QuerySet.
+        def _opted_in_private_method(self):
+            return
+        _opted_in_private_method.queryset_only = False
+
+from_queryset
+~~~~~~~~~~~~~
+
+.. classmethod:: from_queryset(queryset_class)
+
+For advance usage you might want both a custom ``Manager`` and a custom
+``QuerySet``. You can do that by calling ``Manager.from_queryset()`` which
+returns a *subclass* of your base ``Manager`` with a copy of the custom
+``QuerySet`` methods::
+
+    class BaseManager(models.Manager):
+        def __init__(self, *args, **kwargs):
+            ...
+
+        def manager_only_method(self):
+            return
+
+    class CustomQuerySet(models.QuerySet):
+        def manager_and_queryset_method(self):
+            return
+
+    class MyModel(models.Model):
+        objects = BaseManager.from_queryset(CustomQueryset)(*args, **kwargs)
+
+You may also store the generated class into a variable::
+
+    CustomManager = BaseManager.from_queryset(CustomQueryset)
+
+    class MyModel(models.Model):
+        objects = CustomManager(*args, **kwargs)
+
 .. _custom-managers-and-inheritance:
 
 Custom managers and model inheritance

docs/topics/db/queries.txt

@@ -720,7 +720,7 @@ efficient code.
 In a newly created :class:`~django.db.models.query.QuerySet`, the cache is
 empty. The first time a :class:`~django.db.models.query.QuerySet` is evaluated
 -- and, hence, a database query happens -- Django saves the query results in
-the :class:`~django.db.models.query.QuerySet`\'s cache and returns the results
+the :class:`~django.db.models.query.QuerySet`’s cache and returns the results
 that have been explicitly requested (e.g., the next element, if the
 :class:`~django.db.models.query.QuerySet` is being iterated over). Subsequent
 evaluations of the :class:`~django.db.models.query.QuerySet` reuse the cached

docs/topics/db/tablespaces.txt

@@ -30,7 +30,7 @@ Declaring tablespaces for indexes
 ---------------------------------
 
 You can pass the :attr:`~django.db.models.Field.db_tablespace` option to a
-``Field`` constructor to specify an alternate tablespace for the ``Field``'s
+``Field`` constructor to specify an alternate tablespace for the ``Field``’s
 column index. If no index would be created for the column, the option is
 ignored.
 

docs/topics/db/transactions.txt

@@ -619,7 +619,7 @@ context managers breaks atomicity.
 Managing autocommit
 ~~~~~~~~~~~~~~~~~~~
 
-Django 1.6 introduces an explicit :ref:`API for mananging autocommit
+Django 1.6 introduces an explicit :ref:`API for managing autocommit
 <managing-autocommit>`.
 
 To disable autocommit temporarily, instead of::

docs/topics/email.txt

@@ -38,7 +38,7 @@ a secure connection is used.
 send_mail()
 ===========
 
-.. function:: send_mail(subject, message, from_email, recipient_list, fail_silently=False, auth_user=None, auth_password=None, connection=None)
+.. function:: send_mail(subject, message, from_email, recipient_list, fail_silently=False, auth_user=None, auth_password=None, connection=None, html_message=None)
 
 The simplest way to send email is using
 ``django.core.mail.send_mail()``.
@@ -66,6 +66,14 @@ are required.
   If unspecified, an instance of the default backend will be used.
   See the documentation on :ref:`Email backends <topic-email-backends>`
   for more details.
+* ``html_message``: If ``html_message`` is provided, the resulting email will be a
+  :mimetype:`multipart/alternative` email with ``message`` as the
+  :mimetype:`text/plain` content type and ``html_message`` as the
+  :mimetype:`text/html` content type.
+
+.. versionadded:: 1.7
+
+    The ``html_message`` parameter was added.
 
 send_mass_mail()
 ================

docs/topics/forms/formsets.txt

@@ -3,7 +3,10 @@
 Formsets
 ========
 
-.. class:: django.forms.formsets.BaseFormSet
+.. module:: django.forms.formsets
+    :synopsis: An abstraction for working with multiple forms on the same page.
+
+.. class:: BaseFormSet
 
 A formset is a layer of abstraction to work with multiple forms on the same
 page. It can be best compared to a data grid. Let's say you have the following
@@ -164,9 +167,7 @@ As we can see, ``formset.errors`` is a list whose entries correspond to the
 forms in the formset. Validation was performed for each of the two forms, and
 the expected error message appears for the second item.
 
-.. currentmodule:: django.forms.formsets.BaseFormSet
-
-.. method:: total_error_count(self)
+.. method:: BaseFormSet.total_error_count(self)
 
 .. versionadded:: 1.6
 
@@ -353,6 +354,8 @@ formsets and deletion of forms from a formset.
 ``can_order``
 ~~~~~~~~~~~~~
 
+.. attribute:: BaseFormSet.can_order
+
 Default: ``False``
 
 Lets you create a formset with the ability to order::
@@ -411,6 +414,8 @@ happen when the user changes these values::
 ``can_delete``
 ~~~~~~~~~~~~~~
 
+.. attribute:: BaseFormSet.can_delete
+
 Default: ``False``
 
 Lets you create a formset with the ability to select forms for deletion::
@@ -463,10 +468,23 @@ delete fields you can access them with ``deleted_forms``::
 
 If you are using a :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`,
 model instances for deleted forms will be deleted when you call
-``formset.save()``. On the other hand, if you are using a plain ``FormSet``,
-it's up to you to handle ``formset.deleted_forms``, perhaps in your formset's
-``save()`` method, as there's no general notion of what it means to delete a
-form.
+``formset.save()``.
+
+.. versionchanged:: 1.7
+
+    If you call ``formset.save(commit=False)``, objects will not be deleted
+    automatically.  You'll need to call ``delete()`` on each of the
+    :attr:`formset.deleted_objects
+    <django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
+    them::
+
+        >>> instances = formset.save(commit=False)
+        >>> for obj in formset.deleted_objects:
+        ...     obj.delete()
+
+On the other hand, if you are using a plain ``FormSet``, it's up to you to
+handle ``formset.deleted_forms``, perhaps in your formset's ``save()`` method,
+as there's no general notion of what it means to delete a form.
 
 Adding additional fields to a formset
 -------------------------------------

docs/topics/forms/modelforms.txt

@@ -392,7 +392,7 @@ these security concerns do not apply to you:
                model = Author
                fields = '__all__'
 
-2. Set the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta`` class to
+2. Set the ``exclude`` attribute of the ``ModelForm``’s inner ``Meta`` class to
    a list of fields to be excluded from the form.
 
    For example::
@@ -757,7 +757,7 @@ Specifying widgets to use in the form with ``widgets``
 .. versionadded:: 1.6
 
 Using the ``widgets`` parameter, you can specify a dictionary of values to
-customize the ``ModelForm``'s widget class for a particular field. This
+customize the ``ModelForm``’s widget class for a particular field. This
 works the same way as the ``widgets`` dictionary on the inner ``Meta``
 class of a ``ModelForm`` works::
 
@@ -825,6 +825,13 @@ to the database. If your formset contains a ``ManyToManyField``, you'll also
 need to call ``formset.save_m2m()`` to ensure the many-to-many relationships
 are saved properly.
 
+After calling ``save()``, your model formset will have three new attributes
+containing the formset's changes:
+
+.. attribute:: models.BaseModelFormSet.changed_objects
+.. attribute:: models.BaseModelFormSet.deleted_objects
+.. attribute:: models.BaseModelFormSet.new_objects
+
 .. _model-formsets-max-num:
 
 Limiting the number of editable objects

docs/topics/http/middleware.txt

@@ -28,11 +28,12 @@ here's the default value created by :djadmin:`django-admin.py startproject
 <startproject>`::
 
     MIDDLEWARE_CLASSES = (
-        'django.middleware.common.CommonMiddleware',
         'django.contrib.sessions.middleware.SessionMiddleware',
+        'django.middleware.common.CommonMiddleware',
         'django.middleware.csrf.CsrfViewMiddleware',
         'django.contrib.auth.middleware.AuthenticationMiddleware',
         'django.contrib.messages.middleware.MessageMiddleware',
+        'django.middleware.clickjacking.XFrameOptionsMiddleware',
     )
 
 A Django installation doesn't require any middleware —

docs/topics/http/sessions.txt

@@ -293,7 +293,7 @@ You can edit it multiple times.
       expiration (or those set to expire at browser close), this will equal the
       date :setting:`SESSION_COOKIE_AGE` seconds from now.
 
-      This function accepts the same keyword argumets as :meth:`get_expiry_age`.
+      This function accepts the same keyword arguments as :meth:`get_expiry_age`.
 
     .. method:: get_expire_at_browser_close
 

docs/topics/http/urls.txt

@@ -412,7 +412,7 @@ For example::
     )
 
 In this example, for a request to ``/blog/2005/``, Django will call
-``blog.views.year_archive(year='2005', foo='bar')``.
+``blog.views.year_archive(request, year='2005', foo='bar')``.
 
 This technique is used in the
 :doc:`syndication framework </ref/contrib/syndication>` to pass metadata and
@@ -623,7 +623,7 @@ change the entry in the URLconf.
 
 In some scenarios where views are of a generic nature, a many-to-one
 relationship might exist between URLs and views. For these cases the view name
-isn't a good enough identificator for it when it comes the time of reversing
+isn't a good enough identifier for it when comes the time of reversing
 URLs. Read the next section to know about the solution Django provides for this.
 
 .. _naming-url-patterns:

docs/topics/http/views.txt

@@ -140,18 +140,18 @@ The 404 (page not found) view
 
 .. function:: django.views.defaults.page_not_found(request, template_name='404.html')
 
-When you raise an ``Http404`` exception, Django loads a special view devoted
-to handling 404 errors. By default, it's the view
-``django.views.defaults.page_not_found``, which either produces a very simple
-"Not Found" message or loads and renders the template ``404.html`` if you
-created it in your root template directory.
+When you raise :exc:`~django.http.Http404` from within a view, Django loads a
+special view devoted to handling 404 errors. By default, it's the view
+:func:`django.views.defaults.page_not_found`, which either produces a very
+simple "Not Found" message or loads and renders the template ``404.html`` if
+you created it in your root template directory.
 
 The default 404 view will pass one variable to the template: ``request_path``,
 which is the URL that resulted in the error.
 
 The ``page_not_found`` view should suffice for 99% of Web applications, but if
-you want to override it, you can specify ``handler404`` in your URLconf, like
-so::
+you want to override it, you can specify ``handler404`` in your root URLconf
+(setting ``handler404`` anywhere else will have no effect), like so::
 
     handler404 = 'mysite.views.my_custom_404_view'
 

docs/topics/install.txt

@@ -59,11 +59,10 @@ installed.
 
 If you can't use mod_wsgi for some reason, fear not: Django supports many other
 deployment options. One is :doc:`uWSGI </howto/deployment/wsgi/uwsgi>`; it works
-very well with `nginx`_. Another is :doc:`FastCGI </howto/deployment/fastcgi>`,
-perfect for using Django with servers other than Apache. Additionally, Django
-follows the WSGI spec (:pep:`3333`), which allows it to run on a variety of
-server platforms. See the `server-arrangements wiki page`_ for specific
-installation instructions for each platform.
+very well with `nginx`_. Additionally, Django follows the WSGI spec
+(:pep:`3333`), which allows it to run on a variety of server platforms. See the
+`server-arrangements wiki page`_ for specific installation instructions for
+each platform.
 
 .. _Apache: http://httpd.apache.org/
 .. _nginx: http://nginx.org/

docs/topics/localflavor.txt

@@ -7,8 +7,9 @@ assorted pieces of code that are useful for particular countries or cultures.
 This code is now distributed separately from Django, for easier maintenance
 and to trim the size of Django's codebase.
 
-The localflavor packages are named ``django-localflavor-*``, where the asterisk
-is an `ISO 3166 country code`_. For example: ``django-localflavor-us`` is the
+The new localflavor package is named ``django-localflavor``, with a main
+module called ``localflavor`` and many subpackages using an
+`ISO 3166 country code`_. For example: ``localflavor.us`` is the
 localflavor package for the U.S.A.
 
 Most of these ``localflavor`` add-ons are country-specific fields for the
@@ -22,7 +23,7 @@ For example, here's how you can create a form with a field representing a
 French telephone number::
 
     from django import forms
-    from django_localflavor_fr.forms import FRPhoneNumberField
+    from localflavor.fr.forms import FRPhoneNumberField
 
     class MyForm(forms.Form):
         my_french_phone_no = FRPhoneNumberField()
@@ -37,75 +38,30 @@ file.
 Supported countries
 ===================
 
-The following countries have django-localflavor- packages.
+See the official documentation for more information:
 
-* Argentina: https://github.com/django/django-localflavor-ar
-* Australia: https://github.com/django/django-localflavor-au
-* Austria: https://github.com/django/django-localflavor-at
-* Belgium: https://github.com/django/django-localflavor-be
-* Brazil: https://github.com/django/django-localflavor-br
-* Canada: https://github.com/django/django-localflavor-ca
-* Chile: https://github.com/django/django-localflavor-cl
-* China: https://github.com/django/django-localflavor-cn
-* Colombia: https://github.com/django/django-localflavor-co
-* Croatia: https://github.com/django/django-localflavor-hr
-* Czech Republic: https://github.com/django/django-localflavor-cz
-* Ecuador: https://github.com/django/django-localflavor-ec
-* Finland: https://github.com/django/django-localflavor-fi
-* France: https://github.com/django/django-localflavor-fr
-* Germany: https://github.com/django/django-localflavor-de
-* Greece: https://github.com/spapas/django-localflavor-gr
-* Hong Kong: https://github.com/django/django-localflavor-hk
-* Iceland: https://github.com/django/django-localflavor-is
-* India: https://github.com/django/django-localflavor-in
-* Indonesia: https://github.com/django/django-localflavor-id
-* Ireland: https://github.com/django/django-localflavor-ie
-* Israel: https://github.com/django/django-localflavor-il
-* Italy: https://github.com/django/django-localflavor-it
-* Japan: https://github.com/django/django-localflavor-jp
-* Kuwait: https://github.com/django/django-localflavor-kw
-* Lithuania: https://github.com/simukis/django-localflavor-lt
-* Macedonia: https://github.com/django/django-localflavor-mk
-* Mexico: https://github.com/django/django-localflavor-mx
-* The Netherlands: https://github.com/django/django-localflavor-nl
-* Norway: https://github.com/django/django-localflavor-no
-* Peru: https://github.com/django/django-localflavor-pe
-* Poland: https://github.com/django/django-localflavor-pl
-* Portugal: https://github.com/django/django-localflavor-pt
-* Paraguay: https://github.com/django/django-localflavor-py
-* Romania: https://github.com/django/django-localflavor-ro
-* Russia: https://github.com/django/django-localflavor-ru
-* Slovakia: https://github.com/django/django-localflavor-sk
-* Slovenia: https://github.com/django/django-localflavor-si
-* South Africa: https://github.com/django/django-localflavor-za
-* Spain: https://github.com/django/django-localflavor-es
-* Sweden: https://github.com/django/django-localflavor-se
-* Switzerland: https://github.com/django/django-localflavor-ch
-* Turkey: https://github.com/django/django-localflavor-tr
-* United Kingdom: https://github.com/django/django-localflavor-gb
-* United States of America: https://github.com/django/django-localflavor-us
-* Uruguay: https://github.com/django/django-localflavor-uy
+    https://django-localflavor.readthedocs.org/
 
 Internationalization of localflavors
 ====================================
 
-To activate translations for a ``localflavor`` application, you must include
-the application's name (e.g. ``django_localflavor_jp``) in the
-:setting:`INSTALLED_APPS` setting, so the internationalization system can find
-the catalog, as explained in :ref:`how-django-discovers-translations`.
+To activate translations for the ``localflavor`` application, you must include
+the application's name in the :setting:`INSTALLED_APPS` setting, so the
+internationalization system can find the catalog, as explained in
+:ref:`how-django-discovers-translations`.
 
 .. _localflavor-how-to-migrate:
 
 How to migrate
 ==============
 
-If you've used the old ``django.contrib.localflavor`` package, follow these two
-easy steps to update your code:
+If you've used the old ``django.contrib.localflavor`` package or one of the
+temporary ``django-localflavor-*`` releases, follow these two easy steps to
+update your code:
 
-1. Install the appropriate third-party ``django-localflavor-*`` package(s).
-   Go to https://github.com/django/ and find the package for your country.
+1. Install the third-party ``django-localflavor`` package from PyPI.
 
-2. Change your app's import statements to reference the new packages.
+2. Change your app's import statements to reference the new package.
 
    For example, change this::
 
@@ -113,9 +69,9 @@ easy steps to update your code:
 
    ...to this::
 
-       from django_localflavor_fr.forms import FRPhoneNumberField
+       from localflavor.fr.forms import FRPhoneNumberField
 
-The code in the new packages is the same (it was copied directly from Django),
+The code in the new package is the same (it was copied directly from Django),
 so you don't have to worry about backwards compatibility in terms of
 functionality. Only the imports have changed.
 

docs/topics/templates.txt

@@ -45,7 +45,9 @@ A template contains **variables**, which get replaced with values when the
 template is evaluated, and **tags**, which control the logic of the template.
 
 Below is a minimal template that illustrates a few basics. Each element will be
-explained later in this document.::
+explained later in this document.
+
+.. code-block:: html+django
 
     {% extends "base_generic.html" %}
 

docs/topics/testing/advanced.txt

@@ -174,7 +174,7 @@ Advanced features of ``TransactionTestCase``
     .. warning::
 
         This attribute is a private API. It may be changed or removed without
-        a deprecation period in the future, for instance to accomodate changes
+        a deprecation period in the future, for instance to accommodate changes
         in application loading.
 
         It's used to optimize Django's own test suite, which contains hundreds

docs/topics/testing/overview.txt

@@ -1421,7 +1421,7 @@ The decorator can also be applied to test case classes::
 
 
 You can also simulate the absence of a setting by deleting it after settings
-have been overriden, like this::
+have been overridden, like this::
 
     @override_settings()
     def test_something(self):
@@ -1437,7 +1437,7 @@ callbacks to clean up and otherwise reset state when settings are changed.
 Django itself uses this signal to reset various data:
 
 ================================ ========================
-Overriden settings               Data reset
+Overridden settings              Data reset
 ================================ ========================
 USE_TZ, TIME_ZONE                Databases timezone
 TEMPLATE_CONTEXT_PROCESSORS      Context processors cache
@@ -1639,7 +1639,7 @@ your test suite.
     .. versionadded:: 1.5
 
     Asserts that the strings ``xml1`` and ``xml2`` are equal. The
-    comparison is based on XML semantics. Similarily to
+    comparison is based on XML semantics. Similarly to
     :meth:`~SimpleTestCase.assertHTMLEqual`, the comparison is
     made on parsed content, hence only semantic differences are considered, not
     syntax differences. When unvalid XML is passed in any parameter, an