Merge pull request #372 from slashme/patch-1

Copy-edit

Author: poswald

docs/tutorial/tutorial_01.rst

@@ -8,7 +8,7 @@ You want to make your own :term:`Authorization Server` to issue access tokens to
 Start Your App
 --------------
 During this tutorial you will make an XHR POST from a Heroku deployed app to your localhost instance.
-Since the domain that will originate the request (the app on Heroku) is different than the destination domain (your local instance),
+Since the domain that will originate the request (the app on Heroku) is different from the destination domain (your local instance),
 you will need to install the `django-cors-headers <https://github.com/ottoyiu/django-cors-headers>`_ app.
 These "cross-domain" requests are by default forbidden by web browsers unless you use `CORS <http://en.wikipedia.org/wiki/Cross-origin_resource_sharing>`_.
 
@@ -67,7 +67,7 @@ for details on using login templates.
 
     <input type="hidden" name="next" value="{{ next }}" />
 
-As a final step, execute migrate command, start the internal server, and login with your credentials.
+As a final step, execute the migrate command, start the internal server, and login with your credentials.
 
 Create an OAuth2 Client Application
 -----------------------------------
@@ -78,11 +78,11 @@ the API, subject to approval by its users.
 Let's register your application.
 
 Point your browser to http://localhost:8000/o/applications/ and add an Application instance.
-`Client id` and `Client Secret` are automatically generated, you have to provide the rest of the informations:
+`Client id` and `Client Secret` are automatically generated; you have to provide the rest of the informations:
 
  * `User`: the owner of the Application (e.g. a developer, or the currently logged in user.)
 
- * `Redirect uris`: Applications must register at least one redirection endpoint prior to utilizing the
+ * `Redirect uris`: Applications must register at least one redirection endpoint before using the
    authorization endpoint. The :term:`Authorization Server` will deliver the access token to the client only if the client
    specifies one of the verified redirection uris. For this tutorial, paste verbatim the value
    `http://django-oauth-toolkit.herokuapp.com/consumer/exchange/`
@@ -117,9 +117,9 @@ Authorize the Application
 +++++++++++++++++++++++++
 When a user clicks the link, she is redirected to your (possibly local) :term:`Authorization Server`.
 If you're not logged in, you will be prompted for username and password. This is because the authorization
-page is login protected by django-oauth-toolkit. Login, then you should see the (not so cute) form users can use to give
+page is login protected by django-oauth-toolkit. Login, then you should see the (not so cute) form a user can use to give
 her authorization to the client application. Flag the *Allow* checkbox and click *Authorize*, you will be redirected
-again on to the consumer service.
+again to the consumer service.
 
 __ loginTemplate_
 
@@ -140,9 +140,9 @@ Refresh the token
 +++++++++++++++++
 The page showing the access token retrieved from the :term:`Authorization Server` also let you make a POST request to
 the server itself to swap the refresh token for another, brand new access token.
-Just fill in the missing form fields and click the Refresh button: if everything goes smooth you will see the access and
+Just fill in the missing form fields and click the Refresh button: if everything goes smoothly you will see the access and
 refresh token change their values, otherwise you will likely see an error message.
-When finished playing with your authorization server, take note of both the access and refresh tokens, we will use them
+When you have finished playing with your authorization server, take note of both the access and refresh tokens, we will use them
 for the next part of the tutorial.
 
 So let's make an API and protect it with your OAuth2 tokens in the :doc:`part 2 of the tutorial <tutorial_02>`.