Spell-check the entire documentation.

docs/source/pluginwriter/api.rst

@@ -83,7 +83,7 @@ can use a shortcut to get your plugin's config section::
   >>> floobie_dir = floobie_config['floobie_dir']
   
 A tip: you have access to the `%(here)s` variable in your config,
-which is the directory that the user's mediagoblin config is running
+which is the directory that the user's MediaGoblin config is running
 out of.  So for example, your plugin may need a "floobie" directory to
 store floobs in.  You could give them a reasonable default that makes
 use of the default `user_dev` location, but allow users to override
@@ -92,7 +92,7 @@ it, like so::
   [plugin_spec]
   floobie_dir = string(default="%(here)s/user_dev/floobs/")
 
-Note, this is relative to the user's mediagoblin config directory,
+Note, this is relative to the user's MediaGoblin config directory,
 *not* your plugin directory!
 
 
@@ -178,7 +178,7 @@ Adding static resources
 -----------------------
 
 It's possible to add static resources for your plugin.  Say your
-plugin needs some special javascript and images... how to provide
+plugin needs some special JavaScript and images... how to provide
 them?  Then how to access them?  MediaGoblin has a way!
 
 
@@ -230,7 +230,7 @@ the MediaGoblin repository.
 WTForms hooks
 +++++++++++++
 
-We haven't totally settled on a way to tranform wtforms form objects,
+We haven't totally settled on a way to transform wtforms form objects,
 but here's one way.  In your view::
 
   from mediagoblin.foo.forms import SomeForm

docs/source/pluginwriter/authhooks.rst

@@ -44,7 +44,7 @@ This hook is called in ``mediagoblin.auth.views`` in both the ``login`` and
 if :ref:`basic_auth-chapter` is not enabled, the user will be redirected to the
 correct login and registration views for your plugin.
 
-The code assumes that it can generate a valid url given
+The code assumes that it can generate a valid URL given
 ``mediagoblin.plugins.{{ your_plugin_here }}.login`` and
 ``mediagoblin.plugins.{{ your_plugin_here }}.register``. This is only needed if
 you will not be using the ``login`` and ``register`` views in 
@@ -82,5 +82,5 @@ the ``stored_hash`` and return either ``True`` or ``False``.
 
 This hook is called in ``mediagoblin.auth.tools.check_login_simple``. It is
 called if a user is not found and should do something that takes the same amount
-of time as your ``check_password`` function. This is to help prevent timining
+of time as your ``check_password`` function. This is to help prevent timing
 attacks.

docs/source/pluginwriter/database.rst

@@ -24,7 +24,7 @@ Accessing Existing Data
 =======================
 
 If your plugin wants to access existing data, this is quite
-straight forward. Just import the appropiate models and use
+straight forward. Just import the appropriate models and use
 the full power of SQLAlchemy. Take a look at the (upcoming)
 database section in the Developer's Chapter.
 
@@ -134,13 +134,13 @@ plugin's models.py and then run::
   ./bin/gmg alembic --with-plugins revision \
        --head REVISION_HERE \
        --autogenerate \
-       -m "YOUR_PLUGIN_NAME: Change explaination here."
+       -m "YOUR_PLUGIN_NAME: Change explanation here."
 
 Once again, this will dump the migration into the wrong place, so move
 to your plugin's migrations directory.  Open the file, adjust
 accordingly, and read carefully!  Now you should also test your
-migration with some real data.  Be sure to test it both on sqlite
-*AND* on postgresql!
+migration with some real data.  Be sure to test it both on SQLite
+*AND* on PostgreSQL!
 
 One last *very critical* note: you must never, never modify core
 tables with your plugin.  To do that is to put you and all your users

docs/source/pluginwriter/hooks.rst

@@ -28,7 +28,7 @@ What hooks are available?
 This hook is used by ``add_media_to_collection``
 in ``mediagoblin.user_pages.lib``.
 It gets a ``CollectionItem`` as its argument.
-It's the newly created item just before getting commited.
+It's the newly created item just before getting committed.
 So the item can be modified by the hook, if needed.
 Changing the session regarding this item is currently
 undefined behaviour, as the SQL Session might contain other

docs/source/pluginwriter/tests.rst

@@ -19,7 +19,7 @@ Here's a brief guide to writing unit tests for plugins.  However, it
 isn't really ideal.  It also hasn't been well tested... yes, there's
 some irony there :)
 
-Some notes: we're using py.test and webtest for unit testing stuff.
+Some notes: we're using py.test and WebTest for unit testing stuff.
 Keep that in mind.
 
 My suggestion is to mime the behavior of `mediagoblin/tests/` and put
@@ -44,7 +44,7 @@ In any test module in your tests directory you can then do::
       # real code goes here
       pass
 
-And you'll get a mediagoblin application wrapped in webtest passed in
+And you'll get a MediaGoblin application wrapped in WebTest passed in
 to your environment.
 
 If your plugin needs to define multiple configuration setups, you can
@@ -52,8 +52,8 @@ actually set up multiple fixtures very easily for this.  You can just
 set up multiple fixtures with different names that point to different
 configs and pass them in as that named argument.
 
-To run the tests, from mediagoblin's directory (make sure that your
-plugin has been added to your mediagoblin checkout's virtualenv!) do::
+To run the tests, from MediaGoblin's directory (make sure that your
+plugin has been added to your MediaGoblin checkout's virtualenv!) do::
 
   ./runtests.sh /path/to/myplugin/tests/