Standardize spelling to American English in documentation

.pre-commit-config.yaml

@@ -29,6 +29,11 @@ repos:
   rev: v2.4.1
   hooks:
   - id: codespell
+    args: [
+            "--builtin", "clear,rare,code,names,en-GB_to_en-US",
+            "--ignore-words", "codespell-ignore-words.txt",
+            "--skip", "*.css",
+          ]
     exclude: locale|kickstarter-announcement.md|coreapi-0.1.1.js
     additional_dependencies:
       # python doesn't come with a toml parser prior to 3.11

codespell-ignore-words.txt

@@ -0,0 +1,6 @@
+Tim
+assertIn
+IAM
+endcode
+deque
+thead

docs/api-guide/authentication.md

@@ -416,7 +416,7 @@ JSON Web Token is a fairly new standard which can be used for token-based authen
 
 ## Hawk HTTP Authentication
 
-The [HawkREST][hawkrest] library builds on the [Mohawk][mohawk] library to let you work with [Hawk][hawk] signed requests and responses in your API. [Hawk][hawk] lets two parties securely communicate with each other using messages signed by a shared key. It is based on [HTTP MAC access authentication][mac] (which was based on parts of [OAuth 1.0][oauth-1.0a]).
+The [HawkREST][hawkrest] library builds on the [Mohawk][mohawk] library to let you work with [Hawk][hawk] signed requests and responses in your API. [Hawk][hawk] let's two parties securely communicate with each other using messages signed by a shared key. It is based on [HTTP MAC access authentication][mac] (which was based on parts of [OAuth 1.0][oauth-1.0a]).
 
 ## HTTP Signature Authentication
 

docs/api-guide/fields.md

@@ -180,7 +180,7 @@ The `allow_null` option is also available for string fields, although its usage
 
 ## EmailField
 
-A text representation, validates the text to be a valid e-mail address.
+A text representation, validates the text to be a valid email address.
 
 Corresponds to `django.db.models.fields.EmailField`
 
@@ -762,7 +762,7 @@ suitable for updating our target object. With `source='*'`, the return from
                      ('y_coordinate', 4),
                      ('x_coordinate', 3)])
 
-For completeness lets do the same thing again but with the nested serializer
+For completeness let's do the same thing again but with the nested serializer
 approach suggested above:
 
     class NestedCoordinateSerializer(serializers.Serializer):

docs/api-guide/relations.md

@@ -300,7 +300,7 @@ For example, the following serializer:
 
 Would serialize to a nested representation like this:
 
-    >>> album = Album.objects.create(album_name="The Grey Album", artist='Danger Mouse')
+    >>> album = Album.objects.create(album_name="The Gray Album", artist='Danger Mouse')
     >>> Track.objects.create(album=album, order=1, title='Public Service Announcement', duration=245)
     <Track: Track object>
     >>> Track.objects.create(album=album, order=2, title='What More Can I Say', duration=264)
@@ -310,7 +310,7 @@ Would serialize to a nested representation like this:
     >>> serializer = AlbumSerializer(instance=album)
     >>> serializer.data
     {
-        'album_name': 'The Grey Album',
+        'album_name': 'The Gray Album',
         'artist': 'Danger Mouse',
         'tracks': [
             {'order': 1, 'title': 'Public Service Announcement', 'duration': 245},
@@ -344,7 +344,7 @@ By default nested serializers are read-only. If you want to support write-operat
             return album
 
     >>> data = {
-        'album_name': 'The Grey Album',
+        'album_name': 'The Gray Album',
         'artist': 'Danger Mouse',
         'tracks': [
             {'order': 1, 'title': 'Public Service Announcement', 'duration': 245},

docs/api-guide/renderers.md

@@ -134,7 +134,7 @@ An example of a view that uses `TemplateHTMLRenderer`:
 
 You can use `TemplateHTMLRenderer` either to return regular HTML pages using REST framework, or to return both HTML and API responses from a single endpoint.
 
-If you're building websites that use `TemplateHTMLRenderer` along with other renderer classes, you should consider listing `TemplateHTMLRenderer` as the first class in the `renderer_classes` list, so that it will be prioritised first even for browsers that send poorly formed `ACCEPT:` headers.
+If you're building websites that use `TemplateHTMLRenderer` along with other renderer classes, you should consider listing `TemplateHTMLRenderer` as the first class in the `renderer_classes` list, so that it will be prioritized first even for browsers that send poorly formed `ACCEPT:` headers.
 
 See the [_HTML & Forms_ Topic Page][html-and-forms] for further examples of `TemplateHTMLRenderer` usage.
 

docs/api-guide/responses.md

@@ -11,7 +11,7 @@ source:
 
 REST framework supports HTTP content negotiation by providing a `Response` class which allows you to return content that can be rendered into multiple content types, depending on the client request.
 
-The `Response` class subclasses Django's `SimpleTemplateResponse`.  `Response` objects are initialised with data, which should consist of native Python primitives.  REST framework then uses standard HTTP content negotiation to determine how it should render the final response content.
+The `Response` class subclasses Django's `SimpleTemplateResponse`.  `Response` objects are initialized with data, which should consist of native Python primitives.  REST framework then uses standard HTTP content negotiation to determine how it should render the final response content.
 
 There's no requirement for you to use the `Response` class, you can also return regular `HttpResponse` or `StreamingHttpResponse` objects from your views if required.  Using the `Response` class simply provides a nicer interface for returning content-negotiated Web API responses, that can be rendered to multiple formats.
 

docs/api-guide/schemas.md

@@ -20,7 +20,7 @@ package and then subsequently retired over the next releases.
 
 As a full-fledged replacement, we recommend the [drf-spectacular] package.
 It has extensive support for generating OpenAPI 3 schemas from
-REST framework APIs, with both automatic and customisable options available.
+REST framework APIs, with both automatic and customizable options available.
 For further information please refer to
 [Documenting your API](../topics/documenting-your-api.md#drf-spectacular).
 

docs/api-guide/serializers.md

@@ -48,7 +48,7 @@ We can now use `CommentSerializer` to serialize a comment, or list of comments.
     serializer.data
     # {'email': '[email protected]', 'content': 'foo bar', 'created': '2016-01-27T15:17:10.375877'}
 
-At this point we've translated the model instance into Python native datatypes.  To finalise the serialization process we render the data into `json`.
+At this point we've translated the model instance into Python native datatypes.  To finalize the serialization process we render the data into `json`.
 
     from rest_framework.renderers import JSONRenderer
 
@@ -155,7 +155,7 @@ When deserializing data, you always need to call `is_valid()` before attempting
     serializer.is_valid()
     # False
     serializer.errors
-    # {'email': ['Enter a valid e-mail address.'], 'created': ['This field is required.']}
+    # {'email': ['Enter a valid email address.'], 'created': ['This field is required.']}
 
 Each key in the dictionary will be the field name, and the values will be lists of strings of any error messages corresponding to that field.  The `non_field_errors` key may also be present, and will list any general validation errors. The name of the `non_field_errors` key may be customized using the `NON_FIELD_ERRORS_KEY` REST framework setting.
 
@@ -298,7 +298,7 @@ When dealing with nested representations that support deserializing the data, an
     serializer.is_valid()
     # False
     serializer.errors
-    # {'user': {'email': ['Enter a valid e-mail address.']}, 'created': ['This field is required.']}
+    # {'user': {'email': ['Enter a valid email address.']}, 'created': ['This field is required.']}
 
 Similarly, the `.validated_data` property will include nested data structures.
 
@@ -430,7 +430,7 @@ The context dictionary can be used within any serializer field logic, such as a
 
 Often you'll want serializer classes that map closely to Django model definitions.
 
-The `ModelSerializer` class provides a shortcut that lets you automatically create a `Serializer` class with fields that correspond to the Model fields.
+The `ModelSerializer` class provides a shortcut that let's you automatically create a `Serializer` class with fields that correspond to the Model fields.
 
 **The `ModelSerializer` class is the same as a regular `Serializer` class, except that**:
 

docs/api-guide/testing.md

@@ -264,7 +264,7 @@ For example...
     csrftoken = response.cookies['csrftoken']
 
     # Interact with the API.
-    response = client.post('http://testserver/organisations/', json={
+    response = client.post('http://testserver/organizations/', json={
         'name': 'MegaCorp',
         'status': 'active'
     }, headers={'X-CSRFToken': csrftoken})
@@ -292,12 +292,12 @@ The CoreAPIClient allows you to interact with your API using the Python
     client = CoreAPIClient()
     schema = client.get('http://testserver/schema/')
 
-    # Create a new organisation
+    # Create a new organization
     params = {'name': 'MegaCorp', 'status': 'active'}
-    client.action(schema, ['organisations', 'create'], params)
+    client.action(schema, ['organizations', 'create'], params)
 
-    # Ensure that the organisation exists in the listing
-    data = client.action(schema, ['organisations', 'list'])
+    # Ensure that the organization exists in the listing
+    data = client.action(schema, ['organizations', 'list'])
     assert(len(data) == 1)
     assert(data == [{'name': 'MegaCorp', 'status': 'active'}])
 

docs/api-guide/validators.md

@@ -175,7 +175,7 @@ If you want the date field to be entirely hidden from the user, then use `Hidden
 Validators that are applied across multiple fields in the serializer can sometimes require a field input that should not be provided by the API client, but that *is* available as input to the validator.
 For this purposes use `HiddenField`. This field will be present in `validated_data` but *will not* be used in the serializer output representation.
 
-**Note:** Using a `read_only=True` field is excluded from writable fields so it won't use a `default=…` argument. Look [3.8 announcement](https://www.django-rest-framework.org/community/3.8-announcement/#altered-the-behaviour-of-read_only-plus-default-on-field).
+**Note:** Using a `read_only=True` field is excluded from writable fields so it won't use a `default=…` argument. Look [3.8 announcement](https://www.django-rest-framework.org/community/3.8-announcement/#altered-the-behavior-of-read_only-plus-default-on-field).
 
 REST framework includes a couple of defaults that may be useful in this context.
 

docs/community/3.0-announcement.md

@@ -632,7 +632,7 @@ The `MultipleChoiceField` class has been added. This field acts like `ChoiceFiel
 
 The `from_native(self, value)` and `to_native(self, data)` method names have been replaced with the more obviously named `to_internal_value(self, data)` and `to_representation(self, value)`.
 
-The `field_from_native()` and `field_to_native()` methods are removed. Previously you could use these methods if you wanted to customise the behavior in a way that did not simply lookup the field value from the object. For example...
+The `field_from_native()` and `field_to_native()` methods are removed. Previously you could use these methods if you wanted to customize the behavior in a way that did not simply lookup the field value from the object. For example...
 
     def field_to_native(self, obj, field_name):
         """A custom read-only field that returns the class name."""

docs/community/3.12-announcement.md

@@ -50,7 +50,7 @@ See [the schema documentation](https://www.django-rest-framework.org/api-guide/s
 ## Customizing the operation ID.
 
 REST framework automatically determines operation IDs to use in OpenAPI
-schemas. The latest version provides more control for overriding the behaviour
+schemas. The latest version provides more control for overriding the behavior
 used to generate the operation IDs.
 
 See [the schema documentation](https://www.django-rest-framework.org/api-guide/schemas/#operationid) for more information.
@@ -96,7 +96,7 @@ for details on using custom `AutoSchema` subclasses.
 ## Support for JSONField.
 
 Django 3.1 deprecated the existing `django.contrib.postgres.fields.JSONField`
-in favour of a new database-agnositic `JSONField`.
+in favor of a new database-agnositic `JSONField`.
 
 REST framework 3.12 now supports this new model field, and `ModelSerializer`
 classes will correctly map the model field.

docs/community/3.13-announcement.md

@@ -50,6 +50,6 @@ They must now use the more explicit keyword argument style...
 aliases = serializers.ListField(child=serializers.CharField())
 ```
 
-This change has been made because using positional arguments here *does not* result in the expected behaviour.
+This change has been made because using positional arguments here *does not* result in the expected behavior.
 
 See Pull Request [#7632](https://github.com/encode/django-rest-framework/pull/7632) for more details.

docs/community/3.15-announcement.md

@@ -39,12 +39,12 @@ By default the URLs created by `SimpleRouter` use regular expressions. This beha
 
 Dependency on pytz has been removed and deprecation warnings have been added, Django will provide ZoneInfo instances as long as USE_DEPRECATED_PYTZ is not enabled. More info on the migration can be found [in this guide](https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html).
 
-##  Align `SearchFilter` behaviour to `django.contrib.admin` search
+##  Align `SearchFilter` behavior to `django.contrib.admin` search
 
 Searches now may contain _quoted phrases_ with spaces, each phrase is considered as a single search term, and it will raise a validation error if any null-character is provided in search. See the [Filtering API guide](../api-guide/filtering.md) for more information.
 
 ## Other fixes and improvements
 
-There are a number of fixes and minor improvements in this release, ranging from documentation, internal infrastructure (typing, testing, requirements, deprecation, etc.), security and overall behaviour.
+There are a number of fixes and minor improvements in this release, ranging from documentation, internal infrastructure (typing, testing, requirements, deprecation, etc.), security and overall behavior.
 
 See the [release notes](release-notes.md) page for a complete listing.

docs/community/3.16-announcement.md

@@ -29,14 +29,14 @@ The current minimum versions of Django is now 4.2 and Python 3.9.
 
 ## Django LoginRequiredMiddleware
 
-The new `LoginRequiredMiddleware` introduced by Django 5.1 can now be used alongside Django REST Framework, however it is not honored for API views as an equivalent behaviour can be configured via `DEFAULT_AUTHENTICATION_CLASSES`. See [our dedicated section](../api-guide/authentication.md#django-51-loginrequiredmiddleware) in the docs for more information.
+The new `LoginRequiredMiddleware` introduced by Django 5.1 can now be used alongside Django REST Framework, however it is not honored for API views as an equivalent behavior can be configured via `DEFAULT_AUTHENTICATION_CLASSES`. See [our dedicated section](../api-guide/authentication.md#django-51-loginrequiredmiddleware) in the docs for more information.
 
 ## Improved support for UniqueConstraint
 
 The generation of validators for [UniqueConstraint](https://docs.djangoproject.com/en/stable/ref/models/constraints/#uniqueconstraint) has been improved to support better nullable fields and constraints with conditions.
 
 ## Other fixes and improvements
 
-There are a number of fixes and minor improvements in this release, ranging from documentation, internal infrastructure (typing, testing, requirements, deprecation, etc.), security and overall behaviour.
+There are a number of fixes and minor improvements in this release, ranging from documentation, internal infrastructure (typing, testing, requirements, deprecation, etc.), security and overall behavior.
 
 See the [release notes](release-notes.md) page for a complete listing.

docs/community/3.4-announcement.md

@@ -157,7 +157,7 @@ will result in a list of the available choices being returned in the response.
 In cases where there is a relational field, the previous behavior would be
 to return a list of available instances to choose from for that relational field.
 
-In order to minimise exposed information the behavior now is to *not* return
+In order to minimize exposed information the behavior now is to *not* return
 choices information for relational fields.
 
 If you want to override this new behavior you'll need to [implement a custom

docs/community/3.5-announcement.md

@@ -81,7 +81,7 @@ a dynamic client library to interact with your API.
 
 Finally, we're also now exposing the schema generation as a
 [publicly documented API][schema-generation-api], allowing you to more easily
-override the behaviour.
+override the behavior.
 
 ## Requests test client
 
@@ -106,12 +106,12 @@ client library.
     client = CoreAPIClient()
     schema = client.get('http://testserver/schema/')
 
-    # Create a new organisation
+    # Create a new organization
     params = {'name': 'MegaCorp', 'status': 'active'}
-    client.action(schema, ['organisations', 'create'], params)
+    client.action(schema, ['organizations', 'create'], params)
 
-    # Ensure that the organisation exists in the listing
-    data = client.action(schema, ['organisations', 'list'])
+    # Ensure that the organization exists in the listing
+    data = client.action(schema, ['organizations', 'list'])
     assert(len(data) == 1)
     assert(data == [{'name': 'MegaCorp', 'status': 'active'}])
 
@@ -204,18 +204,18 @@ The `'pk'` identifier in schema paths is now mapped onto the actually model fiel
 name by default. This will typically be `'id'`.
 
 This gives a better external representation for schemas, with less implementation
-detail being exposed. It also reflects the behaviour of using a ModelSerializer
+detail being exposed. It also reflects the behavior of using a ModelSerializer
 class with `fields = '__all__'`.
 
-You can revert to the previous behaviour by setting `'SCHEMA_COERCE_PATH_PK': False`
+You can revert to the previous behavior by setting `'SCHEMA_COERCE_PATH_PK': False`
 in the REST framework settings.
 
 ### Schema action name representations
 
 The internal `retrieve()` and `destroy()` method names are now coerced to an
 external representation of `read` and `delete`.
 
-You can revert to the previous behaviour by setting `'SCHEMA_COERCE_METHOD_NAMES': {}`
+You can revert to the previous behavior by setting `'SCHEMA_COERCE_METHOD_NAMES': {}`
 in the REST framework settings.
 
 ### DjangoFilterBackend

docs/community/3.7-announcement.md

@@ -53,7 +53,7 @@ In order to try to address this we're now adding the ability for per-view custom
 
 Let's take a quick look at using the new functionality...
 
-The `APIView` class has a `schema` attribute, that is used to control how the Schema for that particular view is generated. The default behaviour is to use the `AutoSchema` class.
+The `APIView` class has a `schema` attribute, that is used to control how the Schema for that particular view is generated. The default behavior is to use the `AutoSchema` class.
 
     from rest_framework.views import APIView
     from rest_framework.schemas import AutoSchema

docs/community/3.8-announcement.md

@@ -36,15 +36,15 @@ If you use REST framework commercially and would like to see this work continue,
 
 ## Breaking Changes
 
-### Altered the behaviour of `read_only` plus `default` on Field.
+### Altered the behavior of `read_only` plus `default` on Field.
 
 [#5886][gh5886] `read_only` fields will now **always** be excluded from writable fields.
 
 Previously `read_only` fields when combined with a `default` value would use the `default` for create and update
 operations. This was counter-intuitive in some circumstances and led to difficulties supporting dotted `source`
 attributes on nullable relations.
 
-In order to maintain the old behaviour you may need to pass the value of `read_only` fields when calling `save()` in
+In order to maintain the old behavior you may need to pass the value of `read_only` fields when calling `save()` in
 the view:
 
     def perform_create(self, serializer):

docs/community/3.9-announcement.md

@@ -152,7 +152,7 @@ See [#5990][gh5990].
 
 ### `action` decorator replaces `list_route` and `detail_route`
 
-Both `list_route` and `detail_route` are now deprecated in favour of the single `action` decorator.
+Both `list_route` and `detail_route` are now deprecated in favor of the single `action` decorator.
 They will be removed entirely in 3.10.
 
 The `action` decorator takes a boolean `detail` argument.