More typo fixes.

docs/api.rst

@@ -69,7 +69,7 @@ Incoming Request Data
       the data is stored unmodified in this stream for consumption.  Most
       of the time it is a better idea to use :attr:`data` which will give
       you that data as a string.  The stream only returns the data once.
-      
+
    .. attribute:: data
 
       Contains the incoming request data as string in case it came with

docs/deploying/mod_wsgi.rst

@@ -19,10 +19,10 @@ Installing `mod_wsgi`
 If you don't have `mod_wsgi` installed yet you have to either install it using
 a package manager or compile it yourself.
 
-The mod_wsgi `installation instructions`_ cover source installations on UNIX 
+The mod_wsgi `installation instructions`_ cover source installations on UNIX
 systems.
 
-If you are using ubuntu / debian you can apt-get it and activate it as follows:
+If you are using Ubuntu/Debian you can apt-get it and activate it as follows:
 
 .. sourcecode:: text
 
@@ -96,7 +96,7 @@ Toubleshooting
 
 If your application does not run, follow this guide to troubleshoot:
 
-**Problem:** Application does not run, errorlog shows SystemExit ignored
+**Problem:** application does not run, errorlog shows SystemExit ignored
     You have a ``app.run()`` call in your application file that is not
     guarded by an ``if __name__ == '__main__':`` condition.  Either remove
     that :meth:`~flask.Flask.run` call from the file and move it into a
@@ -130,6 +130,6 @@ If your application does not run, follow this guide to troubleshoot:
     instead you either have to put the folder into the pythonpath the file
     is stored in, or convert your application into a package.
 
-    The reason for this is that for non-installed Packages, the module
+    The reason for this is that for non-installed packages, the module
     filename is used to locate the resources and for symlinks the wrong
     filename is picked up.

docs/design.rst

@@ -90,15 +90,15 @@ of variables and take the return value as string.
 But that's about where similarities end.  Jinja2 for example has an
 extensive filter system, a certain way to do template inheritance, support
 for reusable blocks (macros) that can be used from inside templates and
-also from Python code, uses unicode for all operations, supports
+also from Python code, uses Unicode for all operations, supports
 iterative template rendering, configurable syntax and more.  On the other
 hand an engine like Genshi is based on XML stream evaluation, template
 inheritance by taking the availability of XPath into account and more.
 Mako on the other hand treats templates similar to Python modules.
 
-When it comes to connecting a template engine with an application or 
+When it comes to connecting a template engine with an application or
 framework there is more than just rendering templates.  For instance,
-Flask uses Jinja2's extensive autoescaping support.  Also it provides 
+Flask uses Jinja2's extensive autoescaping support.  Also it provides
 ways to access macros from Jinja2 templates.
 
 A template abstraction layer that would not take the unique features of

docs/installation.rst

@@ -29,7 +29,7 @@ you have shell access.  So first: what does virtualenv do?  If you are
 like me and you like Python, chances are you want to use it for another
 project as well.  Now the more projects you have, the more likely it is
 that you will be working with different versions of Python itself or at
-least an individual library.  Because let's face it: quite often libraries 
+least an individual library.  Because let's face it: quite often libraries
 break backwards compatibility and it's unlikely that your application will
 not have any dependencies, that just won't happen.  So virtualenv to the
 rescue!

docs/quickstart.rst

@@ -209,19 +209,19 @@ parameter.  Here some examples:
 >>> app = Flask(__name__)
 >>> @app.route('/')
 ... def index(): pass
-... 
+...
 >>> @app.route('/login')
 ... def login(): pass
-... 
+...
 >>> @app.route('/user/<username>')
 ... def profile(username): pass
-... 
+...
 >>> with app.test_request_context():
 ...  print url_for('index')
 ...  print url_for('login')
 ...  print url_for('login', next='/')
 ...  print url_for('profile', username='John Doe')
-... 
+...
 /
 /login
 /login?next=/
@@ -238,7 +238,7 @@ templates?  There are three good reasons for this:
 1. reversing is often more descriptive than hardcoding the URLs.  Also and
    more importantly you can change URLs in one go without having to change
    the URLs all over the place.
-2. URL building will handle escaping of special characters and unicode
+2. URL building will handle escaping of special characters and Unicode
    data transparently for you, you don't have to deal with that.
 3. If your application is placed outside the URL root (so say in
    ``/myapplication`` instead of ``/``), :func:`~flask.url_for` will
@@ -355,7 +355,7 @@ application is a module, that folder is next to that module, if it's a
 package it's actually inside your package:
 
 **Case 1**: a module::
-    
+
     /application.py
     /templates
         /hello.html
@@ -663,7 +663,7 @@ not using the template engine (like in this example).
 
    The problem with random is that it's hard to judge what random is.  And
    a secret key should be as random as possible.  Your operating system
-   has ways to generate pretty random stuff based on a cryptographical
+   has ways to generate pretty random stuff based on a cryptographic
    random generator which can be used to get such a key:
 
    >>> import os
@@ -707,8 +707,8 @@ come in handy.  As of Flask 0.3 a logger is preconfigured for you to use.
 Here are some example log calls::
 
     app.logger.debug('A value for debugging')
-    app.logger.warning('A warning ocurred (%d apples)', 42)
+    app.logger.warning('A warning occurred (%d apples)', 42)
-    app.logger.error('An error occoured')
+    app.logger.error('An error occurred')
 
 The attached :attr:`~flask.Flask.logger` is a standard logging
 :class:`~logging.Logger`, so head over to the official stdlib

docs/testing.rst

@@ -70,7 +70,7 @@ low-level file handle and a random file name, the latter we use as
 database name.  We just have to keep the `db_fd` around so that we can use
 the :func:`os.close` function to close the file.
 
-If we now run that testsuite, we should see the following output::
+If we now run that test suite, we should see the following output::
 
     $ python flaskr_tests.py
 
@@ -181,11 +181,11 @@ which is the intended behavior.
 
 Running that should now give us three passing tests::
 
-    $ python flaskr_tests.py 
+    $ python flaskr_tests.py
     ...
     ----------------------------------------------------------------------
     Ran 3 tests in 0.332s
-    
+
     OK
 
 For more complex tests with headers and status codes, check out the

docs/tutorial/css.rst

@@ -14,7 +14,7 @@ folder we created before:
     h1, h2          { font-family: 'Georgia', serif; margin: 0; }
     h1              { border-bottom: 2px solid #eee; }
     h2              { font-size: 1.2em; }
-    
+
     .page           { margin: 2em auto; width: 35em; border: 5px solid #ccc;
                       padding: 0.8em; background: white; }
     .entries        { list-style: none; margin: 0; padding: 0; }

docs/tutorial/dbinit.rst

@@ -31,7 +31,7 @@ first (`__future__` imports must be the very first import)::
 Next we can create a function called `init_db` that initializes the
 database.  For this we can use the `connect_db` function we defined
 earlier.  Just add that function below the `connect_db` function::
-    
+
     def init_db():
         with closing(connect_db()) as db:
             with app.open_resource('schema.sql') as f:

docs/tutorial/testing.rst

@@ -1,7 +1,7 @@
 .. _tutorial-testing:
 
 Bonus: Testing the Application
-===============================
+==============================
 
 Now that you have finished the application and everything works as
 expected, it's probably not a good idea to add automated tests to simplify