Fix some typos in the docs

docs/extensiondev.rst

@@ -67,7 +67,7 @@ First we create the following folder structure::
         setup.py
         LICENSE
 
-Here the contents of the most important files:
+Here's the contents of the most important files:
 
 flaskext/__init__.py
 ````````````````````
@@ -171,7 +171,7 @@ controller object that can be used to connect to the database.
 The Extension Code
 ------------------
 
-Here the contents of the `flaskext/sqlite3.py` for copy/paste::
+Here's the contents of the `flaskext/sqlite3.py` for copy/paste::
 
     from __future__ import absolute_import
     import sqlite3
@@ -196,7 +196,7 @@ Here the contents of the `flaskext/sqlite3.py` for copy/paste::
             g.sqlite3_db.close()
             return response
 
-So here what the lines of code do:
+So here's what the lines of code do:
 
 1.  the ``__future__`` import is necessary to activate absolute imports.
     This is needed because otherwise we could not call our module
@@ -237,7 +237,7 @@ If you don't need that, you can go with initialization functions.
 Initialization Functions
 ------------------------
 
-Here how the module would look like with initialization functions::
+Here's what the module would look like with initialization functions::
 
     from __future__ import absolute_import
     import sqlite3

docs/patterns/errorpages.rst

@@ -5,7 +5,7 @@ Flask comes with a handy :func:`~flask.abort` function that aborts a
 request with an HTTP error code early.  It will also provide a plain black
 and white error page for you with a basic description, but nothing fancy.
 
-Depening on the error code it is less or more likely for the user to
+Depending on the error code it is less or more likely for the user to
 actually see such an error.
 
 Common Error Codes

docs/patterns/jquery.rst

@@ -53,8 +53,8 @@ is quite simple: it's on localhost port something and directly on the root
 of that server.  But what if you later decide to move your application to
 a different location?  For example to ``http://example.com/myapp``?  On
 the server side this never was a problem because we were using the handy
-:func:`~flask.url_for` function that did could answer that question for
-us, but if we are using jQuery we should better not hardcode the path to
+:func:`~flask.url_for` function that could answer that question for
+us, but if we are using jQuery we should not hardcode the path to
 the application but make that dynamic, so how can we do that?
 
 A simple method would be to add a script tag to our page that sets a
@@ -118,9 +118,9 @@ special error reporting in that case.
 The HTML
 --------
 
-You index.html template either has to extend a `layout.html` template with
+Your index.html template either has to extend a `layout.html` template with
 jQuery loaded and the `$SCRIPT_ROOT` variable set, or do that on the top.
-Here the HTML code needed for our little application (`index.html`).
+Here's the HTML code needed for our little application (`index.html`).
 Notice that we also drop the script directly into the HTML here.  It is
 usually a better idea to have that in a separate script file:
 

docs/patterns/lazyloading.rst

@@ -74,7 +74,7 @@ function but internally imports the real function on first use::
             return self.view(*args, **kwargs)
 
 What's important here is is that `__module__` and `__name__` are properly
-set.  This is used by Flask internally to figure out how to do name the
+set.  This is used by Flask internally to figure out how to name the
 URL rules in case you don't provide a name for the rule yourself.
 
 Then you can define your central place to combine the views like this::

docs/patterns/wtforms.rst

@@ -77,7 +77,7 @@ how easy this is.  WTForms does half the form generation for us already.
 To make it even nicer, we can write a macro that renders a field with
 label and a list of errors if there are any.
 
-Here an example `_formhelpers.html` template with such a macro:
+Here's an example `_formhelpers.html` template with such a macro:
 
 .. sourcecode:: html+jinja
 
@@ -93,7 +93,7 @@ Here an example `_formhelpers.html` template with such a macro:
     {% endmacro %}
 
 This macro accepts a couple of keyword arguments that are forwarded to
-WTForm's field function that renders the field for us.  They keyword
+WTForm's field function that renders the field for us.  The keyword
 arguments will be inserted as HTML attributes.  So for example you can
 call ``render_field(form.username, class='username')`` to add a class to
 the input element.  Note that WTForms returns standard Python unicode

docs/quickstart.rst

@@ -231,7 +231,7 @@ parameter.  Here are some examples:
 /user/John%20Doe
 
 (This also uses the :meth:`~flask.Flask.test_request_context` method
-explained below.  It basically tells flask to think we are handling a
+explained below.  It basically tells Flask to think we are handling a
 request even though we are not, we are in an interactive Python shell.
 Have a look at the explanation below. :ref:`context-locals`).
 

docs/security.rst

@@ -72,7 +72,7 @@ do stupid things without them knowing.
 
 Say you have a specific URL that, when you sent `POST` requests to will
 delete a user's profile (say `http://example.com/user/delete`).  If an
-attacker now creates a page that sents a post request to that page with
+attacker now creates a page that sends a post request to that page with
 some JavaScript he just has to trick some users to that page and their
 profiles will end up being deleted.
 
@@ -163,6 +163,6 @@ page loaded the data from the JSON response is in the `captured` array.
 Because it is a syntax error in JavaScript to have an object literal
 (``{...}``) toplevel an attacker could not just do a request to an
 external URL with the script tag to load up the data.  So what Flask does
-is only allowing objects as toplevel elements when using
+is to only allow objects as toplevel elements when using
 :func:`~flask.jsonify`.  Make sure to do the same when using an ordinary
 JSON generate function.

docs/upgrading.rst

@@ -2,7 +2,7 @@ Upgrading to Newer Releases
 ===========================
 
 Flask itself is changing like any software is changing over time.  Most of
-the changes are the nice kind, the kind where you don't have th change
+the changes are the nice kind, the kind where you don't have to change
 anything in your code to profit from a new release.
 
 However every once in a while there are changes that do require some