Removed British/Austrialian word: whilist.

6 files changed, 7 insertions, 7 deletions

diff --git a/django/contrib/sessions/backends/base.py b/django/contrib/sessions/backends/base.py
index a4480afabf..718cc54215 100644
--- a/django/contrib/sessions/backends/base.py
+++ b/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
diff --git a/django/views/decorators/http.py b/django/views/decorators/http.py
index 15e89176fd..bef9ea61a9 100644
--- a/django/views/decorators/http.py
+++ b/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
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
index ed319474fa..1af587c225 100644
--- a/docs/topics/conditional-view-processing.txt
+++ b/docs/topics/conditional-view-processing.txt
@@ -184,7 +184,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:
 
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
index bb41dc6f6f..08ea426690 100644
--- a/docs/topics/db/models.txt
+++ b/docs/topics/db/models.txt
@@ -928,7 +928,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
@@ -1011,7 +1011,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
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index 8c2474d527..05a1771d74 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -601,7 +601,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.
diff --git a/tests/unmanaged_models/tests.py b/tests/unmanaged_models/tests.py
index 50b123eef6..e98cee8ae1 100644
--- a/tests/unmanaged_models/tests.py
+++ b/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.