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

Backport of 98839e906632dfe77c6f6906d61d62868a0541dc from master

8 files changed, 10 insertions, 10 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/ref/models/instances.txt b/docs/ref/models/instances.txt
index 70b9883731..7909d9d5c6 100644
--- a/docs/ref/models/instances.txt
+++ b/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::
 
diff --git a/docs/ref/urlresolvers.txt b/docs/ref/urlresolvers.txt
index 5bad660f48..d7e1077d85 100644
--- a/docs/ref/urlresolvers.txt
+++ b/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.
 
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
index 77080266de..08805b9346 100644
--- a/docs/topics/conditional-view-processing.txt
+++ b/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:
 
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
index e49ab3aea8..5ebea94923 100644
--- a/docs/topics/db/models.txt
+++ b/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
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index 978a35e87f..af6754b78b 100644
--- a/docs/topics/db/transactions.txt
+++ b/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.
diff --git a/tests/unmanaged_models/tests.py b/tests/unmanaged_models/tests.py
index 4ed07bf0d2..0a775a3068 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.