Fix docs typos (#6195)

docs/api-guide/schemas.md

@@ -146,7 +146,7 @@ example above.
 
 Automatic schema generation is provided by the `SchemaGenerator` class.
 
-`SchemaGenerator` processes a list of routed URL pattterns and compiles the
+`SchemaGenerator` processes a list of routed URL patterns and compiles the
 appropriately structured Core API Document.
 
 Basic usage is just to provide the title for your schema and call
@@ -818,7 +818,7 @@ A short description of the meaning and intended usage of the input field.
 
 ## drf-yasg - Yet Another Swagger Generator
 
-[drf-yasg][drf-yasg] generates [OpenAPI][open-api] documents suitable for code generation - nested schemas, 
+[drf-yasg][drf-yasg] generates [OpenAPI][open-api] documents suitable for code generation - nested schemas,
 named models, response bodies, enum/pattern/min/max validators, form parameters, etc.
 
 

docs/topics/documenting-your-api.md

@@ -16,11 +16,11 @@ The built-in API documentation includes:
 
 ### Installation
 
-The `coreapi` library is required as a dependancy for the API docs. Make sure
+The `coreapi` library is required as a dependency for the API docs. Make sure
 to install the latest version. The `pygments` and `markdown` libraries
 are optional but recommended.
 
-To install the API documentation, you'll need to include it in your projects URLconf:
+To install the API documentation, you'll need to include it in your project's URLconf:
 
     from rest_framework.documentation import include_docs_urls
 
@@ -39,7 +39,7 @@ This will include two different views:
 **Note**: By default `include_docs_urls` configures the underlying `SchemaView` to generate _public_ schemas.
 This means that views will not be instantiated with a `request` instance. i.e. Inside the view `self.request` will be `None`.
 
-To be compatible with this behaviour methods (such as `get_serializer` or `get_serializer_class` etc.) which inspect `self.request` or, particularly, `self.request.user` may need to be adjusted to handle this case.
+To be compatible with this behaviour, methods (such as `get_serializer` or `get_serializer_class` etc.) which inspect `self.request` or, particularly, `self.request.user` may need to be adjusted to handle this case.
 
 You may ensure views are given a `request` instance by calling `include_docs_urls` with `public=False`:
 

docs/topics/html-and-forms.md

@@ -4,7 +4,7 @@ REST framework is suitable for returning both API style responses, and regular H
 
 ## Rendering HTML
 
-In order to return HTML responses you'll need to either `TemplateHTMLRenderer`, or `StaticHTMLRenderer`.
+In order to return HTML responses you'll need to use either `TemplateHTMLRenderer`, or `StaticHTMLRenderer`.
 
 The `TemplateHTMLRenderer` class expects the response to contain a dictionary of context data, and renders an HTML page based on a template that must be specified either in the view or on the response.
 

docs/topics/internationalization.md

@@ -43,7 +43,7 @@ REST framework includes these built-in translations both for standard exception
 
 Note that the translations only apply to the error strings themselves. The format of error messages, and the keys of field names will remain the same. An example `400 Bad Request` response body might look like this:
 
-    {"detail": {"username": ["Esse campo deve ser unico."]}}
+    {"detail": {"username": ["Esse campo deve ser único."]}}
 
 If you want to use different string for parts of the response such as `detail` and `non_field_errors` then you can modify this behavior by using a [custom exception handler][custom-exception-handler].
 

docs/topics/writable-nested-serializers.md

@@ -27,7 +27,7 @@ Nested data structures are easy enough to work with if they're read-only - simpl
 Some example output from our serializer.
 
     {
-        'title': 'Leaving party preperations',
+        'title': 'Leaving party preparations',
         'items': [
             {'text': 'Compile playlist', 'is_completed': True},
             {'text': 'Send invites', 'is_completed': False},