[1.9.x] Removed British/Austrialian word: whilist.

Backport of 98839e906632dfe77c6f6906d61d62868a0541dc from master

django/contrib/sessions/backends/base.py

@@ -295,7 +295,7 @@ class SessionBase(object):
 
     def cycle_key(self):
         """
-        Creates a new session key, whilst retaining the current session data.
+        Creates a new session key, while retaining the current session data.
         """
         data = self._session_cache
         key = self.session_key

django/views/decorators/http.py

@@ -61,7 +61,7 @@ def condition(etag_func=None, last_modified_func=None):
     The parameters are callables to compute the ETag and last modified time for
     the requested resource, respectively. The callables are passed the same
     parameters as the view itself. The Etag function should return a string (or
-    None if the resource doesn't exist), whilst the last_modified function
+    None if the resource doesn't exist), while the last_modified function
     should return a datetime object (or None if the resource doesn't exist).
 
     If both parameters are provided, all the preconditions must be met before

docs/ref/models/instances.txt

@@ -680,9 +680,9 @@ For example::
     def get_absolute_url(self):
         return "/people/%i/" % self.id
 
-(Whilst this code is correct and simple, it may not be the most portable way to
+While this code is correct and simple, it may not be the most portable way to
 write this kind of method. The :func:`~django.core.urlresolvers.reverse`
-function is usually the best approach.)
+function is usually the best approach.
 
 For example::
 

docs/ref/urlresolvers.txt

@@ -73,7 +73,7 @@ use for reversing. By default, the root URLconf for the current thread is used.
     As part of working out which URL names map to which patterns, the
     ``reverse()`` function has to import all of your URLconf files and examine
     the name of each view. This involves importing each view function. If
-    there are *any* errors whilst importing any of your view functions, it
+    there are *any* errors while importing any of your view functions, it
     will cause ``reverse()`` to raise an error, even if that view function is
     not the one you are trying to reverse.
 

docs/topics/conditional-view-processing.txt

@@ -189,7 +189,7 @@ Comparison with middleware conditional processing
 You may notice that Django already provides simple and straightforward
 conditional ``GET`` handling via the
 :class:`django.middleware.http.ConditionalGetMiddleware` and
-:class:`~django.middleware.common.CommonMiddleware`. Whilst certainly being
+:class:`~django.middleware.common.CommonMiddleware`. While certainly being
 easy to use and suitable for many situations, those pieces of middleware
 functionality have limitations for advanced usage:
 

docs/topics/db/models.txt

@@ -917,7 +917,7 @@ model, since it is an abstract base class. It does not generate a database
 table or have a manager, and cannot be instantiated or saved directly.
 
 For many uses, this type of model inheritance will be exactly what you want.
-It provides a way to factor out common information at the Python level, whilst
+It provides a way to factor out common information at the Python level, while
 still only creating one database table per child model at the database level.
 
 ``Meta`` inheritance
@@ -1000,7 +1000,7 @@ Along with another app ``rare/models.py``::
         pass
 
 The reverse name of the ``common.ChildA.m2m`` field will be
-``common_childa_related``, whilst the reverse name of the
+``common_childa_related``, while the reverse name of the
 ``common.ChildB.m2m`` field will be ``common_childb_related``, and finally the
 reverse name of the ``rare.ChildB.m2m`` field will be ``rare_childb_related``.
 It is up to you how you use the ``'%(class)s'`` and ``'%(app_label)s`` portion

docs/topics/db/transactions.txt

@@ -606,7 +606,7 @@ Handling exceptions within PostgreSQL transactions
 Inside a transaction, when a call to a PostgreSQL cursor raises an exception
 (typically ``IntegrityError``), all subsequent SQL in the same transaction
 will fail with the error "current transaction is aborted, queries ignored
-until end of transaction block". Whilst simple use of ``save()`` is unlikely
+until end of transaction block". While simple use of ``save()`` is unlikely
 to raise an exception in PostgreSQL, there are more advanced usage patterns
 which might, such as saving objects with unique fields, saving using the
 force_insert/force_update flag, or invoking custom SQL.

tests/unmanaged_models/tests.py

@@ -12,7 +12,7 @@ class SimpleTests(TestCase):
         """
         The main test here is that the all the models can be created without
         any database errors. We can also do some more simple insertion and
-        lookup tests whilst we're here to show that the second of models do
+        lookup tests while we're here to show that the second of models do
         refer to the tables from the first set.
         """
         # Insert some data into one set of models.