Preferred usage of among/while to amongst/whilst.

Author: smithdc1

django/core/checks/model_checks.py

@@ -64,7 +64,7 @@ def check_all_models(app_configs=None, **kwargs):
                 Error(
                     "index name '%s' is not unique %s %s." % (
                         index_name,
-                        'for model' if len(model_labels) == 1 else 'amongst models:',
+                        'for model' if len(model_labels) == 1 else 'among models:',
                         ', '.join(sorted(model_labels)),
                     ),
                     id='models.E029' if len(model_labels) == 1 else 'models.E030',
@@ -77,7 +77,7 @@ def check_all_models(app_configs=None, **kwargs):
                 Error(
                     "constraint name '%s' is not unique %s %s." % (
                         constraint_name,
-                        'for model' if len(model_labels) == 1 else 'amongst models:',
+                        'for model' if len(model_labels) == 1 else 'among models:',
                         ', '.join(sorted(model_labels)),
                     ),
                     id='models.E031' if len(model_labels) == 1 else 'models.E032',

docs/howto/writing-migrations.txt

@@ -327,7 +327,7 @@ If you change a :class:`~django.db.models.ManyToManyField` to use a ``through``
 model, the default migration will delete the existing table and create a new
 one, losing the existing relations. To avoid this, you can use
 :class:`.SeparateDatabaseAndState` to rename the existing table to the new
-table name whilst telling the migration autodetector that the new model has
+table name while telling the migration autodetector that the new model has
 been created. You can check the existing table name through
 :djadmin:`sqlmigrate` or :djadmin:`dbshell`. You can check the new table name
 with the through model's ``_meta.db_table`` property. Your new ``through``

docs/ref/checks.txt

@@ -343,11 +343,11 @@ Models
 * **models.E028**: ``db_table`` ``<db_table>`` is used by multiple models:
   ``<model list>``.
 * **models.E029**: index name ``<index>`` is not unique for model ``<model>``.
-* **models.E030**: index name ``<index>`` is not unique amongst models:
+* **models.E030**: index name ``<index>`` is not unique among models:
   ``<model list>``.
 * **models.E031**: constraint name ``<constraint>`` is not unique for model
   ``<model>``.
-* **models.E032**: constraint name ``<constraint>`` is not unique amongst
+* **models.E032**: constraint name ``<constraint>`` is not unique among
   models: ``<model list>``.
 * **models.E033**: The index name ``<index>`` cannot start with an underscore
   or a number.

docs/ref/forms/fields.txt

@@ -711,7 +711,7 @@ For each field, we describe the default widget used if you don't specify
     After the field has been cleaned and validated, the ``UploadedFile``
     object will have an additional ``image`` attribute containing the Pillow
     `Image`_ instance used to check if the file was a valid image. Pillow
-    closes the underlying file descriptor after verifying an image, so whilst
+    closes the underlying file descriptor after verifying an image, so while
     non-image data attributes, such as ``format``, ``height``, and ``width``,
     are available, methods that access the underlying image data, such as
     ``getdata()`` or ``getpixel()``, cannot be used without reopening the file.
@@ -1354,7 +1354,7 @@ By default, :class:`ModelChoiceField` and :class:`ModelMultipleChoiceField` use
 
 When iterated, ``ModelChoiceIterator`` yields 2-tuple choices containing
 :class:`ModelChoiceIteratorValue` instances as the first ``value`` element in
-each choice. ``ModelChoiceIteratorValue`` wraps the choice value whilst
+each choice. ``ModelChoiceIteratorValue`` wraps the choice value while
 maintaining a reference to the source model instance that can be used in custom
 widget implementations, for example, to add `data-* attributes`_ to
 ``<option>`` elements.

docs/ref/models/querysets.txt

@@ -1710,7 +1710,7 @@ to refer to the queryset's model.
 
 On PostgreSQL only, you can pass ``no_key=True`` in order to acquire a weaker
 lock, that still allows creating rows that merely reference locked rows
-(through a foreign key, for example) whilst the lock is in place. The
+(through a foreign key, for example) while the lock is in place. The
 PostgreSQL documentation has more details about `row-level lock modes
 <https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS>`_.
 

docs/releases/1.9.txt

@@ -246,7 +246,7 @@ Minor features
 
 * The new :meth:`GDALRaster.warp() <django.contrib.gis.gdal.GDALRaster.warp>`
   method allows warping a raster by specifying target raster properties such as
-  origin, width, height, or pixel size (amongst others).
+  origin, width, height, or pixel size (among others).
 
 * The new :meth:`GDALRaster.transform()
   <django.contrib.gis.gdal.GDALRaster.transform>` method allows transforming a

docs/releases/2.1.15.txt

@@ -32,7 +32,7 @@ inlines in the admin form of an otherwise view-only parent model.
 Given the complexity of the Django admin, and in-particular the permissions
 related checks, it is the view of the Django security team that this change was
 necessary: that it is not currently feasible to maintain the existing behavior
-whilst escaping the potential privilege escalation in a way that would avoid a
+while escaping the potential privilege escalation in a way that would avoid a
 recurrence of similar issues in the future, and that would be compatible with
 Django's *safe by default* philosophy.
 

docs/releases/2.2.8.txt

@@ -33,7 +33,7 @@ inlines in the admin form of an otherwise view-only parent model.
 Given the complexity of the Django admin, and in-particular the permissions
 related checks, it is the view of the Django security team that this change was
 necessary: that it is not currently feasible to maintain the existing behavior
-whilst escaping the potential privilege escalation in a way that would avoid a
+while escaping the potential privilege escalation in a way that would avoid a
 recurrence of similar issues in the future, and that would be compatible with
 Django's *safe by default* philosophy.
 

docs/spelling_wordlist

@@ -12,7 +12,6 @@ Ai
 Alchin
 alphanumerics
 amet
-amongst
 analytics
 apnumber
 app

docs/topics/db/queries.txt

@@ -495,7 +495,7 @@ is ``'Beatles Blog'``::
 
 This spanning can be as deep as you'd like.
 
-It works backwards, too. Whilst it :attr:`can be customized
+It works backwards, too. While it :attr:`can be customized
 <.ForeignKey.related_query_name>`, by default you refer to a "reverse"
 relationship in a lookup using the lowercase name of the model.