From 928c6196b0058dbeae97347eb60801d5949da440 Mon Sep 17 00:00:00 2001 From: M Lewis Date: Tue, 18 Sep 2018 14:26:23 -0700 Subject: [PATCH] Fix typos --- docs/api-guide/schemas.md | 4 ++-- docs/topics/documenting-your-api.md | 6 +++--- docs/topics/html-and-forms.md | 2 +- docs/topics/internationalization.md | 2 +- docs/topics/writable-nested-serializers.md | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/api-guide/schemas.md b/docs/api-guide/schemas.md index 6ad259588..8144f3eee 100644 --- a/docs/api-guide/schemas.md +++ b/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. diff --git a/docs/topics/documenting-your-api.md b/docs/topics/documenting-your-api.md index d57f9d6e4..71db39930 100644 --- a/docs/topics/documenting-your-api.md +++ b/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`: diff --git a/docs/topics/html-and-forms.md b/docs/topics/html-and-forms.md index 0b4afca12..18774926b 100644 --- a/docs/topics/html-and-forms.md +++ b/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. diff --git a/docs/topics/internationalization.md b/docs/topics/internationalization.md index ed8b85836..7cfc6e247 100644 --- a/docs/topics/internationalization.md +++ b/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]. diff --git a/docs/topics/writable-nested-serializers.md b/docs/topics/writable-nested-serializers.md index a39feb18c..9ba719f4e 100644 --- a/docs/topics/writable-nested-serializers.md +++ b/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},