Fixed typos

docs/api-guide/fields.md

@@ -204,7 +204,7 @@ If you want to override this behavior, you'll need to declare the `DateTimeField
         class Meta:
             model = Comment
 
-Note that by default, datetime representations are deteremined by the renderer in use, although this can be explicitly overridden as detailed below.
+Note that by default, datetime representations are determined by the renderer in use, although this can be explicitly overridden as detailed below.
 
 In the case of JSON this means the default datetime representation uses the [ECMA 262 date time string specification][ecma262].  This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: `2013-01-29T12:34:56.123Z`.
 
@@ -226,7 +226,7 @@ Corresponds to `django.db.models.fields.DateField`
 * `format` - A string representing the output format.  If not specified, this defaults to `None`, which indicates that python `date` objects should be returned by `to_native`.  In this case the date encoding will be determined by the renderer.
 * `input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `DATE_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`. 
 
-Date format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style dates should be used. (eg `'2013-01-29'`)
+Date format strings may either be [python strftime formats][strftime] which explicitly specify the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style dates should be used. (eg `'2013-01-29'`)
 
 ## TimeField
 

docs/api-guide/generic-views.md

@@ -71,7 +71,7 @@ The following attributes control the basic view behavior.
 The following attibutes are used to control pagination when used with list views.
 
 * `paginate_by` - The size of pages to use with paginated data.  If set to `None` then pagination is turned off.  If unset this uses the same value as the `PAGINATE_BY` setting, which defaults to `None`.
-* `paginate_by_param` - The name of a query parameter, which can be used by the client to overide the default page size to use for pagination.  If unset this uses the same value as the `PAGINATE_BY_PARAM` setting, which defaults to `None`.
+* `paginate_by_param` - The name of a query parameter, which can be used by the client to override the default page size to use for pagination.  If unset this uses the same value as the `PAGINATE_BY_PARAM` setting, which defaults to `None`.
 * `pagination_serializer_class` - The pagination serializer class to use when determining the style of paginated responses.  Defaults to the same value as the `DEFAULT_PAGINATION_SERIALIZER_CLASS` setting.
 * `page_kwarg` - The name of a URL kwarg or URL query parameter which can be used by the client to control which page is requested.  Defaults to `'page'`.
 

docs/api-guide/relations.md

@@ -237,7 +237,7 @@ Would serialize to a nested representation like this:
         'album_name': 'The Grey Album',
         'artist': 'Danger Mouse'
         'tracks': [
-            {'order': 1, 'title': 'Public Service Annoucement'},
+            {'order': 1, 'title': 'Public Service Announcement'},
             {'order': 2, 'title': 'What More Can I Say'},
             {'order': 3, 'title': 'Encore'},
             ...

docs/api-guide/renderers.md

@@ -14,7 +14,7 @@ The set of valid renderers for a view is always defined as a list of classes.  W
 
 The basic process of content negotiation involves examining the request's `Accept` header, to determine which media types it expects in the response.  Optionally, format suffixes on the URL may be used to explicitly request a particular representation.  For example the URL `http://example.com/api/users_count.json` might be an endpoint that always returns JSON data.
 
-For more information see the documentation on [content negotation][conneg].
+For more information see the documentation on [content negotiation][conneg].
 
 ## Setting the renderers
 
@@ -69,7 +69,7 @@ If your API includes views that can serve both regular webpages and API response
 
 Renders the request data into `JSON`, using utf-8 encoding.
 
-Note that non-ascii charaters will be rendered using JSON's `\uXXXX` character escape.  For example:
+Note that non-ascii characters will be rendered using JSON's `\uXXXX` character escape.  For example:
 
     {"unicode black star": "\u2605"}
 
@@ -89,7 +89,7 @@ The client may additionally include an `'indent'` media type parameter, in which
 
 Renders the request data into `JSON`, using utf-8 encoding.
 
-Note that non-ascii charaters will not be character escaped.  For example:
+Note that non-ascii characters will not be character escaped.  For example:
 
     {"unicode black star": "★"}
 

docs/api-guide/routers.md

@@ -85,7 +85,7 @@ This router is similar to `SimpleRouter` as above, but additionally includes a d
 
 # Custom Routers
 
-Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specfic requirements about how the your URLs for your API are strutured.  Doing so allows you to encapsulate the URL structure in a reusable way that ensures you don't have to write your URL patterns explicitly for each new view.
+Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specific requirements about how the your URLs for your API are strutured.  Doing so allows you to encapsulate the URL structure in a reusable way that ensures you don't have to write your URL patterns explicitly for each new view.
 
 The simplest way to implement a custom router is to subclass one of the existing router classes.  The `.routes` attribute is used to template the URL patterns that will be mapped to each viewset. 
 

docs/api-guide/serializers.md

@@ -104,7 +104,7 @@ When deserializing a list of items, errors will be returned as a list of diction
 
 #### Field-level validation
 
-You can specify custom field-level validation by adding `.validate_<fieldname>` methods to your `Serializer` subclass. These are analagous to `.clean_<fieldname>` methods on Django forms, but accept slightly different arguments.
+You can specify custom field-level validation by adding `.validate_<fieldname>` methods to your `Serializer` subclass. These are analogous to `.clean_<fieldname>` methods on Django forms, but accept slightly different arguments.
 
 They take a dictionary of deserialized attributes as a first argument, and the field name in that dictionary as a second argument (which will be either the name of the field or the value of the `source` argument to the field, if one was provided).
 

docs/api-guide/settings.md

@@ -125,7 +125,7 @@ Default: `None`
 
 #### PAGINATE_BY_PARAM
 
-The name of a query parameter, which can be used by the client to overide the default page size to use for pagination.  If set to `None`, clients may not override the default page size.
+The name of a query parameter, which can be used by the client to override the default page size to use for pagination.  If set to `None`, clients may not override the default page size.
 
 Default: `None`
 

docs/api-guide/viewsets.md

@@ -34,7 +34,7 @@ Let's define a simple viewset that can be used to list or retrieve all the users
             serializer = UserSerializer(user)
             return Response(serializer.data)
 
-If we need to, we can bind this viewset into two seperate views, like so:
+If we need to, we can bind this viewset into two separate views, like so:
 
     user_list = UserViewSet.as_view({'get': 'list'})
     user_detail = UserViewSet.as_view({'get': 'retrieve'})
@@ -92,7 +92,7 @@ The default routers included with REST framework will provide routes for a stand
         def destroy(self, request, pk=None):
             pass
 
-If you have ad-hoc methods that you need to be routed to, you can mark them as requiring routing using the `@link` or `@action` decorators.  The `@link` decorator will route `GET` requests, and the `@action` decroator will route `POST` requests.
+If you have ad-hoc methods that you need to be routed to, you can mark them as requiring routing using the `@link` or `@action` decorators.  The `@link` decorator will route `GET` requests, and the `@action` decorator will route `POST` requests.
 
 For example:
 

docs/topics/2.2-announcement.md

@@ -75,7 +75,7 @@ This more explicit behavior on serializing and deserializing data [makes integra
 
 The implicit to-many behavior on serializers, and the `ManyRelatedField` style classes will continue to function, but will raise a `PendingDeprecationWarning`, which can be made visible using the `-Wd` flag.
 
-**Note**: If you need to forcibly turn off the implict "`many=True` for `__iter__` objects" behavior, you can now do so by specifying `many=False`.  This will become the default (instead of the current default of `None`) once the deprecation of the implicit behavior is finalised in version 2.4.
+**Note**: If you need to forcibly turn off the implicit "`many=True` for `__iter__` objects" behavior, you can now do so by specifying `many=False`.  This will become the default (instead of the current default of `None`) once the deprecation of the implicit behavior is finalised in version 2.4.
 
 ### Cleaner optional relationships
 
@@ -103,9 +103,9 @@ The `blank` keyword argument will continue to function, but will raise a `Pendin
 
 ### Simpler object-level permissions
 
-Custom permissions classes previously used the signatute `.has_permission(self, request, view, obj=None)`.  This method would be called twice, firstly for the global permissions check, with the `obj` parameter set to `None`, and again for the object-level permissions check when appropriate, with the `obj` parameter set to the relevant model instance.
+Custom permissions classes previously used the signature `.has_permission(self, request, view, obj=None)`.  This method would be called twice, firstly for the global permissions check, with the `obj` parameter set to `None`, and again for the object-level permissions check when appropriate, with the `obj` parameter set to the relevant model instance.
 
-The global permissions check and object-level permissions check are now seperated into two seperate methods, which gives a cleaner, more obvious API.
+The global permissions check and object-level permissions check are now separated into two separate methods, which gives a cleaner, more obvious API.
 
 * Global permission checks now use the `.has_permission(self, request, view)` signature.
 * Object-level permission checks use a new method `.has_object_permission(self, request, view, obj)`.

docs/topics/2.3-announcement.md

@@ -51,7 +51,7 @@ This improvement is reflected in improved documentation for the `GenericAPIView`
 
 ## Easier Serializers
 
-REST framework lets you be totally explict regarding how you want to represent relationships, allowing you to choose between styles such as hyperlinking or primary key relationships.
+REST framework lets you be totally explicit regarding how you want to represent relationships, allowing you to choose between styles such as hyperlinking or primary key relationships.
 
 The ability to specify exactly how you want to represent relationships is powerful, but it also introduces complexity.  In order to keep things more simple, REST framework now allows you to include reverse relationships simply by including the field name in the `fields` metadata of the serializer class.
 

docs/topics/browser-enhancements.md

@@ -60,7 +60,7 @@ have any control over what is sent in the `Accept` header.
 ## URL based format suffixes
 
 REST framework can take `?format=json` style URL parameters, which can be a
-useful shortcut for determing which content type should be returned from
+useful shortcut for determining which content type should be returned from
 the view.
 
 This is a more concise than using the `accept` override, but it also gives

docs/topics/contributing.md

@@ -22,9 +22,9 @@ It's really helpful if you make sure you address issues to the correct channel.
 
 Some tips on good issue reporting:
 
-* When decribing issues try to phrase your ticket in terms of the *behavior* you think needs changing rather than the *code* you think need changing.
+* When describing issues try to phrase your ticket in terms of the *behavior* you think needs changing rather than the *code* you think need changing.
 * Search the issue list first for related items, and make sure you're running the latest version of REST framework before reporting an issue.
-* If reporting a bug, then try to include a pull request with a failing test case.  This'll help us quickly identify if there is a valid issue, and make sure that it gets fixed more quickly if there is one. 
+* If reporting a bug, then try to include a pull request with a failing test case. This will help us quickly identify if there is a valid issue, and make sure that it gets fixed more quickly if there is one.
 
 
 

docs/topics/release-notes.md

@@ -106,14 +106,14 @@ You can determine your currently installed version using `pip freeze`:
 **Date**: 17th April 2013
 
 * Loud failure when view does not return a `Response` or `HttpResponse`.
-* Bugfix: Fix for Django 1.3 compatiblity.
+* Bugfix: Fix for Django 1.3 compatibility.
 * Bugfix: Allow overridden `get_object()` to work correctly.
 
 ### 2.2.6
 
 **Date**: 4th April 2013
 
-* OAuth2 authentication no longer requires unneccessary URL parameters in addition to the token.
+* OAuth2 authentication no longer requires unnecessary URL parameters in addition to the token.
 * URL hyperlinking in browsable API now handles more cases correctly.
 * Long HTTP headers in browsable API are broken in multiple lines when possible.
 * Bugfix: Fix regression with DjangoFilterBackend not worthing correctly with single object views.

docs/topics/rest-framework-2-announcement.md

@@ -60,7 +60,7 @@ REST framework 2 also allows you to work with both function-based and class-base
 
 ## API Design
 
-Pretty much every aspect of REST framework has been reworked, with the aim of ironing out some of the design flaws of the previous versions.  Each of the components of REST framework are cleanly decoupled, and can be used independantly of each-other, and there are no monolithic resource classes, overcomplicated mixin combinations, or opinionated serialization or URL routing decisions.
+Pretty much every aspect of REST framework has been reworked, with the aim of ironing out some of the design flaws of the previous versions.  Each of the components of REST framework are cleanly decoupled, and can be used independently of each-other, and there are no monolithic resource classes, overcomplicated mixin combinations, or opinionated serialization or URL routing decisions.
 
 ## The Browsable API
 
@@ -70,7 +70,7 @@ Browsable Web APIs are easier to work with, visualize and debug, and generally m
 
 With REST framework 2, the browsable API gets a snazzy new bootstrap-based theme that looks great and is even nicer to work with.
 
-There are also some functionality improvments - actions such as as `POST` and `DELETE` will only display if the user has the appropriate permissions.
+There are also some functionality improvements - actions such as as `POST` and `DELETE` will only display if the user has the appropriate permissions.
 
 ![Browsable API][image]
 

docs/tutorial/4-authentication-and-permissions.md

@@ -17,7 +17,7 @@ Add the following two fields to the model.
     owner = models.ForeignKey('auth.User', related_name='snippets')
     highlighted = models.TextField()
 
-We'd also need to make sure that when the model is saved, that we populate the highlighted field, using the `pygments` code higlighting library.
+We'd also need to make sure that when the model is saved, that we populate the highlighted field, using the `pygments` code highlighting library.
 
 We'll need some extra imports:
 
@@ -137,7 +137,7 @@ And, at the end of the file, add a pattern to include the login and logout views
 
 The `r'^api-auth/'` part of pattern can actually be whatever URL you want to use.  The only restriction is that the included urls must use the `'rest_framework'` namespace.
 
-Now if you open up the browser again and refresh the page you'll see a 'Login' link in the top right of the page.  If you log in as one of the users you created earier, you'll be able to create code snippets again.
+Now if you open up the browser again and refresh the page you'll see a 'Login' link in the top right of the page.  If you log in as one of the users you created earlier, you'll be able to create code snippets again.
 
 Once you've created a few code snippets, navigate to the '/users/' endpoint, and notice that the representation includes a list of the snippet pks that are associated with each user, in each user's 'snippets' field.
 

docs/tutorial/quickstart.md

@@ -10,7 +10,7 @@ Create a new Django project named `tutorial`, then start a new app called `quick
     django-admin.py startproject tutorial
     cd tutorial
 
-    # Create a virtualenv to isolate our package dependancies locally
+    # Create a virtualenv to isolate our package dependencies locally
     virtualenv env
     source env/bin/activate
 
@@ -36,7 +36,7 @@ Next you'll need to get a database set up and synced.  If you just want to use S
 
 The run `syncdb` like so:
 
-    python manange.py syncdb
+    python manage.py syncdb
 
 Once you've set up a database and got everything synced and ready to go, open up the app's directory and we'll get coding...
 

rest_framework/decorators.py

@@ -1,5 +1,5 @@
 """
-The most imporant decorator in this module is `@api_view`, which is used
+The most important decorator in this module is `@api_view`, which is used
 for writing function-based views with REST framework.
 
 There are also various decorators for setting the API policies on function
@@ -40,7 +40,7 @@ def api_view(http_method_names):
 
         # api_view applied with eg. string instead of list of strings
         assert isinstance(http_method_names, (list, tuple)), \
-            '@api_view expected a list of strings, recieved %s' % type(http_method_names).__name__
+            '@api_view expected a list of strings, received %s' % type(http_method_names).__name__
 
         allowed_methods = set(http_method_names) | set(('options',))
         WrappedAPIView.http_method_names = [method.lower() for method in allowed_methods]

rest_framework/response.py

@@ -1,5 +1,5 @@
 """
-The Response class in REST framework is similiar to HTTPResponse, except that
+The Response class in REST framework is similar to HTTPResponse, except that
 it is initialized with unrendered data, instead of a pre-rendered string.
 
 The appropriate renderer is called during Django's template response rendering.

rest_framework/serializers.py

@@ -25,7 +25,7 @@ from rest_framework.compat import get_concrete_model, six
 #
 #     example_field = serializers.CharField(...)
 #
-# This helps keep the seperation between model fields, form fields, and
+# This helps keep the separation between model fields, form fields, and
 # serializer fields more explicit.
 
 from rest_framework.relations import *
@@ -58,7 +58,7 @@ class DictWithMetadata(dict):
     def __getstate__(self):
         """
         Used by pickle (e.g., caching).
-        Overriden to remove the metadata from the dict, since it shouldn't be
+        Overridden to remove the metadata from the dict, since it shouldn't be
         pickled and may in some instances be unpickleable.
         """
         return dict(self)

rest_framework/templatetags/rest_framework.py

@@ -15,7 +15,7 @@ register = template.Library()
 
 # When 1.3 becomes unsupported by REST framework, we can instead start to
 # use the {% load staticfiles %} tag, remove the following code,
-# and add a dependancy that `django.contrib.staticfiles` must be installed.
+# and add a dependency that `django.contrib.staticfiles` must be installed.
 
 # Note: We can't put this into the `compat` module because the compat import
 # from rest_framework.compat import ...