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

Backport of 98839e906632dfe77c6f6906d61d62868a0541dc from master

5 files changed, 7 insertions, 7 deletions

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.