Improve style, fix some typos (#8405)

* Improve style, fix some typos

* Update docs/api-guide/fields.md

Co-authored-by: Tom Christie <[email protected]>

Co-authored-by: Tom Christie <[email protected]>

Author: franciscouzo

docs/api-guide/authentication.md

@@ -201,7 +201,7 @@ If you've already created some users, you can generate tokens for all existing u
 
 #### By exposing an api endpoint
 
-When using `TokenAuthentication`, you may want to provide a mechanism for clients to obtain a token given the username and password.  REST framework provides a built-in view to provide this behaviour.  To use it, add the `obtain_auth_token` view to your URLconf:
+When using `TokenAuthentication`, you may want to provide a mechanism for clients to obtain a token given the username and password.  REST framework provides a built-in view to provide this behavior.  To use it, add the `obtain_auth_token` view to your URLconf:
 
     from rest_framework.authtoken import views
     urlpatterns += [
@@ -216,7 +216,7 @@ The `obtain_auth_token` view will return a JSON response when valid `username` a
 
 Note that the default `obtain_auth_token` view explicitly uses JSON requests and responses, rather than using default renderer and parser classes in your settings.
 
-By default, there are no permissions or throttling applied to the  `obtain_auth_token` view. If you do wish to apply to throttle you'll need to override the view class,
+By default, there are no permissions or throttling applied to the `obtain_auth_token` view. If you do wish to apply throttling you'll need to override the view class,
 and include them using the `throttle_classes` attribute.
 
 If you need a customized version of the `obtain_auth_token` view, you can do so by subclassing the `ObtainAuthToken` view class, and using that in your url conf instead.
@@ -250,7 +250,7 @@ And in your `urls.py`:
 
 #### With Django admin
 
-It is also possible to create Tokens manually through the admin interface. In case you are using a large user base, we recommend that you monkey patch the `TokenAdmin` class customize it to your needs, more specifically by declaring the `user` field as `raw_field`.
+It is also possible to create Tokens manually through the admin interface. In case you are using a large user base, we recommend that you monkey patch the `TokenAdmin` class to customize it to your needs, more specifically by declaring the `user` field as `raw_field`.
 
 `your_app/admin.py`:
 
@@ -289,7 +289,7 @@ If you're using an AJAX-style API with SessionAuthentication, you'll need to mak
 
 **Warning**: Always use Django's standard login view when creating login pages. This will ensure your login views are properly protected.
 
-CSRF validation in REST framework works slightly differently from standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behaviour is not suitable for login views, which should always have CSRF validation applied.
+CSRF validation in REST framework works slightly differently from standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behavior is not suitable for login views, which should always have CSRF validation applied.
 
 
 ## RemoteUserAuthentication
@@ -299,15 +299,15 @@ environment variable.
 
 To use it, you must have `django.contrib.auth.backends.RemoteUserBackend` (or a subclass) in your
 `AUTHENTICATION_BACKENDS` setting. By default, `RemoteUserBackend` creates `User` objects for usernames that don't
-already exist. To change this and other behaviour, consult the
+already exist. To change this and other behavior, consult the
 [Django documentation](https://docs.djangoproject.com/en/stable/howto/auth-remote-user/).
 
 If successfully authenticated, `RemoteUserAuthentication` provides the following credentials:
 
 * `request.user` will be a Django `User` instance.
 * `request.auth` will be `None`.
 
-Consult your web server's documentation for information about configuring an authentication method, e.g.:
+Consult your web server's documentation for information about configuring an authentication method, for example:
 
 * [Apache Authentication How-To](https://httpd.apache.org/docs/2.4/howto/auth.html)
 * [NGINX (Restricting Access)](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/)
@@ -418,7 +418,7 @@ HTTP Signature (currently a [IETF draft][http-signature-ietf-draft]) provides a
 
 ## Djoser
 
-[Djoser][djoser] library provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation. The package works with a custom user model and uses token-based authentication. This is ready to use REST implementation of the Django authentication system.
+[Djoser][djoser] library provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation. The package works with a custom user model and uses token-based authentication. This is a ready to use REST implementation of the Django authentication system.
 
 ## django-rest-auth / dj-rest-auth
 

docs/api-guide/fields.md

@@ -46,7 +46,7 @@ Defaults to `True`. If you're using [Model Serializer](https://www.django-rest-f
 
 ### `default`
 
-If set, this gives the default value that will be used for the field if no input value is supplied. If not set the default behaviour is to not populate the attribute at all.
+If set, this gives the default value that will be used for the field if no input value is supplied. If not set the default behavior is to not populate the attribute at all.
 
 The `default` is not applied during partial update operations. In the partial update case only fields that are provided in the incoming data will have a validated value returned.
 
@@ -85,7 +85,7 @@ When serializing fields with dotted notation, it may be necessary to provide a `
     class CommentSerializer(serializers.Serializer):
         email = serializers.EmailField(source="user.email")
 
-would require user object to be fetched from database when it is not prefetched. If that is not wanted, be sure to be using `prefetch_related` and `select_related` methods appropriately. For more information about the methods refer to [django documentation][django-docs-select-related].
+This case would require user object to be fetched from database when it is not prefetched. If that is not wanted, be sure to be using `prefetch_related` and `select_related` methods appropriately. For more information about the methods refer to [django documentation][django-docs-select-related].
 
 The value `source='*'` has a special meaning, and is used to indicate that the entire object should be passed through to the field.  This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.
 
@@ -151,7 +151,7 @@ Prior to Django 2.1 `models.BooleanField` fields were always `blank=True`. Thus
 since Django 2.1 default `serializers.BooleanField` instances will be generated
 without the `required` kwarg (i.e. equivalent to `required=True`) whereas with
 previous versions of Django, default `BooleanField` instances will be generated
-with a `required=False` option.  If you want to control this behaviour manually,
+with a `required=False` option.  If you want to control this behavior manually,
 explicitly declare the `BooleanField` on the serializer class, or use the
 `extra_kwargs` option to set the `required` flag.
 
@@ -771,7 +771,7 @@ Here the mapping between the target and source attribute pairs (`x` and
 `x_coordinate`, `y` and `y_coordinate`) is handled in the `IntegerField`
 declarations. It's our `NestedCoordinateSerializer` that takes `source='*'`.
 
-Our new `DataPointSerializer` exhibits the same behaviour as the custom field
+Our new `DataPointSerializer` exhibits the same behavior as the custom field
 approach.
 
 Serializing:
@@ -831,7 +831,7 @@ the [djangorestframework-recursive][djangorestframework-recursive] package provi
 
 ## django-rest-framework-gis
 
-The [django-rest-framework-gis][django-rest-framework-gis] package provides geographic addons for django rest framework like a  `GeometryField` field and a GeoJSON serializer.
+The [django-rest-framework-gis][django-rest-framework-gis] package provides geographic addons for django rest framework like a `GeometryField` field and a GeoJSON serializer.
 
 ## django-rest-framework-hstore
 

docs/api-guide/format-suffixes.md

@@ -23,8 +23,8 @@ Returns a URL pattern list which includes format suffix patterns appended to eac
 Arguments:
 
 * **urlpatterns**: Required.  A URL pattern list.
-* **suffix_required**:  Optional.  A boolean indicating if suffixes in the URLs should be optional or mandatory.  Defaults to `False`, meaning that suffixes are optional by default.
-* **allowed**:  Optional.  A list or tuple of valid format suffixes.  If not provided, a wildcard format suffix pattern will be used.
+* **suffix_required**: Optional.  A boolean indicating if suffixes in the URLs should be optional or mandatory.  Defaults to `False`, meaning that suffixes are optional by default.
+* **allowed**: Optional.  A list or tuple of valid format suffixes.  If not provided, a wildcard format suffix pattern will be used.
 
 Example:
 

docs/api-guide/generic-views.md

@@ -98,7 +98,7 @@ For example:
 
 ---
 
-**Note:** If the serializer_class used in the generic view spans orm relations, leading to an n+1 problem, you could optimize your queryset in this method using `select_related` and `prefetch_related`. To get more information about n+1 problem and use cases of the mentioned methods refer to related section in [django documentation][django-docs-select-related].
+**Note:** If the `serializer_class` used in the generic view spans orm relations, leading to an n+1 problem, you could optimize your queryset in this method using `select_related` and `prefetch_related`. To get more information about n+1 problem and use cases of the mentioned methods refer to related section in [django documentation][django-docs-select-related].
 
 ---
 

docs/api-guide/pagination.md

@@ -227,7 +227,7 @@ Note that the `paginate_queryset` method may set state on the pagination instanc
 
 ## Example
 
-Suppose we want to replace the default pagination output style with a modified format that  includes the next and previous links under in a nested 'links' key. We could specify a custom pagination class like so:
+Suppose we want to replace the default pagination output style with a modified format that includes the next and previous links under in a nested 'links' key. We could specify a custom pagination class like so:
 
     class CustomPagination(pagination.PageNumberPagination):
         def get_paginated_response(self, data):

docs/api-guide/parsers.md

@@ -15,7 +15,7 @@ REST framework includes a number of built in Parser classes, that allow you to a
 
 ## How the parser is determined
 
-The set of valid parsers for a view is always defined as a list of classes.  When  `request.data` is accessed, REST framework will examine the `Content-Type` header on the incoming request, and determine which parser to use to parse the request content.
+The set of valid parsers for a view is always defined as a list of classes.  When `request.data` is accessed, REST framework will examine the `Content-Type` header on the incoming request, and determine which parser to use to parse the request content.
 
 ---
 

docs/api-guide/permissions.md

@@ -177,7 +177,7 @@ This permission class ties into Django's standard `django.contrib.auth` [model p
 * `PUT` and `PATCH` requests require the user to have the `change` permission on the model.
 * `DELETE` requests require the user to have the `delete` permission on the model.
 
-The default behaviour can also be overridden to support custom model permissions.  For example, you might want to include a `view` model permission for `GET` requests.
+The default behavior can also be overridden to support custom model permissions.  For example, you might want to include a `view` model permission for `GET` requests.
 
 To use custom model permissions, override `DjangoModelPermissions` and set the `.perms_map` property.  Refer to the source code for details.
 

docs/api-guide/relations.md

@@ -246,7 +246,7 @@ When using `SlugRelatedField` as a read-write field, you will normally want to e
 
 ## HyperlinkedIdentityField
 
-This field can be applied as an identity relationship, such as the `'url'` field on  a HyperlinkedModelSerializer.  It can also be used for an attribute on the object.  For example, the following serializer:
+This field can be applied as an identity relationship, such as the `'url'` field on a HyperlinkedModelSerializer.  It can also be used for an attribute on the object.  For example, the following serializer:
 
     class AlbumSerializer(serializers.HyperlinkedModelSerializer):
         track_listing = serializers.HyperlinkedIdentityField(view_name='track-list')

docs/api-guide/renderers.md

@@ -105,7 +105,7 @@ The TemplateHTMLRenderer will create a `RequestContext`, using the `response.dat
 
 ---
 
-**Note:** When used with a view that makes use of a serializer the `Response` sent for rendering may not be a dictionary and will need to be wrapped in a dict before returning to allow the TemplateHTMLRenderer to render it. For example:
+**Note:** When used with a view that makes use of a serializer the `Response` sent for rendering may not be a dictionary and will need to be wrapped in a dict before returning to allow the `TemplateHTMLRenderer` to render it. For example:
 
 ```
 response.data = {'results': response.data}
@@ -192,7 +192,7 @@ By default the response content will be rendered with the highest priority rende
         def get_default_renderer(self, view):
             return JSONRenderer()
 
-##  AdminRenderer
+## AdminRenderer
 
 Renders data into HTML for an admin-like display:
 
@@ -332,7 +332,7 @@ You can do some pretty flexible things using REST framework's renderers.  Some e
 * Specify multiple types of HTML representation for API clients to use.
 * Underspecify a renderer's media type, such as using `media_type = 'image/*'`, and use the `Accept` header to vary the encoding of the response.
 
-## Varying behaviour by media type
+## Varying behavior by media type
 
 In some cases you might want your view to use different serialization styles depending on the accepted media type.  If you need to do this you can access `request.accepted_renderer` to determine the negotiated renderer that will be used for the response.
 

docs/api-guide/requests.md

@@ -49,7 +49,7 @@ If a client sends a request with a content-type that cannot be parsed then a `Un
 
 # Content negotiation
 
-The request exposes some properties that allow you to determine the result of the content negotiation stage. This allows you to implement behaviour such as selecting a different serialization schemes for different media types.
+The request exposes some properties that allow you to determine the result of the content negotiation stage. This allows you to implement behavior such as selecting a different serialization schemes for different media types.
 
 ## .accepted_renderer
 

docs/api-guide/reverse.md

@@ -38,7 +38,7 @@ You should **include the request as a keyword argument** to the function, for ex
         def get(self, request):
             year = now().year
             data = {
-                 ...
+                ...
                 'year-summary-url': reverse('year-summary', args=[year], request=request)
             }
             return Response(data)

docs/api-guide/schemas.md

@@ -293,15 +293,15 @@ class CustomView(APIView):
 
 This saves you having to create a custom subclass per-view for a commonly used option.
 
-Not all `AutoSchema` methods expose related  `__init__()` kwargs, but those for
+Not all `AutoSchema` methods expose related `__init__()` kwargs, but those for
 the more commonly needed options do.
 
 ### `AutoSchema` methods
 
 #### `get_components()`
 
 Generates the OpenAPI components that describe request and response bodies,
-deriving  their properties from the serializer.
+deriving their properties from the serializer.
 
 Returns a dictionary mapping the component name to the generated
 representation. By default this has just a single pair but you may override