Spellcheck.

13 files changed, 52 insertions, 50 deletions

diff --git a/docs/narr/environment.rst b/docs/narr/environment.rst
index 6a366f783..aec605a84 100644
--- a/docs/narr/environment.rst
+++ b/docs/narr/environment.rst
@@ -100,7 +100,7 @@ with ``debug_``). on in one fell swoop, you can use
 settings that do not start with ``debug_*`` such as
 ``reload_templates``.
 
-If you want to turn all ``reload`` settings (everysetting that starts
+If you want to turn all ``reload`` settings (every setting that starts
 with ``reload_``). on in one fell swoop, you can use
 ``BFG_RELOAD_ALL=1`` as an environment variable setting or you may use
 ``reload_all=true`` in the config file.  Note that this does not
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index c2f6966de..65e21d3f2 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -83,7 +83,7 @@ code that implements a minimal forbidden view:
 .. warning:: the default forbidden view sends a response with a ``401
    Unauthorized`` status code for backwards compatibility reasons.
    You can influence the status code of Forbidden responses by using
-   an alterate forbidden view.  For example, it would make sense to
+   an alternate forbidden view.  For example, it would make sense to
    return a response with a ``403 Forbidden`` status code.
 
 Changing the response factory
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst
index 129d76732..48b2eedfc 100644
--- a/docs/narr/hybrid.rst
+++ b/docs/narr/hybrid.rst
@@ -43,7 +43,7 @@ URL Dispatch Only
 ~~~~~~~~~~~~~~~~~
 
 An application that uses :term:`url dispatch` exclusively to map URLs
-to code will usually exlusively have declarations like this within
+to code will usually exclusively have declarations like this within
 their ``configure.zcml`` file:
 
 .. code-block:: xml
@@ -93,10 +93,11 @@ code just won't have any ``<route>`` declarations.  Instead, its ZCML
      />
 
 "Under the hood", the above view statements register a view using the
-:term:`context` interface ``None``, the IRequest :term:`request type`
-with a :term:`view name` matching the name= argument.  The "foobar"
-view above will match the URL ``/a/b/c/foobar`` or ``/foobar``, etc,
-assuming that no view is named "a", "b", or "c" during traversal.
+:term:`context` interface ``None``, the ``IRequest`` :term:`request
+type` with a :term:`view name` matching the name= argument.  The
+"foobar" view above will match the URL ``/a/b/c/foobar`` or
+``/foobar``, etc, assuming that no view is named "a", "b", or "c"
+during traversal.
 
 Hybrid Applications
 -------------------
@@ -198,7 +199,7 @@ view will be called.
 
 A ``<route>`` declaration *must* precede (in XML order) any ``<view>``
 declaration which names it as a ``route_name``.  If it does not, at
-application startup time a ConfigurationError will be raised.
+application startup time a ``ConfigurationError`` will be raised.
 
 Route Factories
 ---------------
@@ -225,7 +226,7 @@ Using ``*subpath`` in a Route Path
 ----------------------------------
 
 There are certain (extremely rare) cases when you'd like to influence
-the traversal :term:`subpath` when a route matches without atually
+the traversal :term:`subpath` when a route matches without actually
 performing traversal.  For instance, the ``repoze.bfg.wsgi.wsgiapp2``
 decorator and the ``repoze.bfg.view.static`` helper attempt to compute
 ``PATH_INFO`` from the request's subpath, so it's useful to be able to
@@ -467,4 +468,4 @@ A ``<route>`` Statement *Must* Precede Any ``<view>`` Statement Which Mentions I
 
 A ``<route>`` declaration *must* precede (in XML order) any ``<view>``
 declaration which names it as a ``route_name``.  If it does not, at
-application startup time a ConfigurationError will be raised.
+application startup time a ``ConfigurationError`` will be raised.
diff --git a/docs/narr/models.rst b/docs/narr/models.rst
index a3613c77c..18738e8f4 100644
--- a/docs/narr/models.rst
+++ b/docs/narr/models.rst
@@ -128,7 +128,7 @@ that you don't want to disturb, use the
    alsoProvides(IBlogEntry2, entry)
 
 See the :ref:`views_chapter` for more information about why providing
-models with an interface can be an interesing thing to do with regard
+models with an interface can be an interesting thing to do with regard
 to :term:`view` lookup.
 
 Defining a Graph of Model Instances for Traversal
@@ -253,7 +253,7 @@ conveniently locate one object "inside" another.
 
 Some APIs in :ref:`security_module` accept a model object as a
 parameter.  For example, the ``has_permission`` API accepts a
-"context" (a model object) as one of its arguments; the "acl" is
+"context" (a model object) as one of its arguments; the ACL is
 obtained from this model or one of its ancestors.  Other APIs in the
 same module also accept :term:`context` as an argument, and a context
 is always a model.
diff --git a/docs/narr/resources.rst b/docs/narr/resources.rst
index 4a042f140..5df23b2fe 100644
--- a/docs/narr/resources.rst
+++ b/docs/narr/resources.rst
@@ -11,9 +11,9 @@ example, each of the following is a resource:
 
 - a GIF image file contained within a Python package.
 
-- a CSS file contined within a Python package.
+- a CSS file contained within a Python package.
 
-- a Javascript source file contained within a Python package.
+- a JavaScript source file contained within a Python package.
 
 - A directory within a package that does not have an ``__init__.py``
   in it (if it possessed an ``__init__.py`` it would *be* a package).
@@ -94,7 +94,7 @@ following kinds of resources defined in any Python package:
 
 - Individual :term:`Chameleon` templates.
 
-- A directory containing multuple Chameleon templates.
+- A directory containing multiple Chameleon templates.
 
 - Individual static files served up by an instance of the
   ``repoze.bfg.view.static`` helper class.
diff --git a/docs/narr/router.rst b/docs/narr/router.rst
index a7e19f134..a86e5267c 100644
--- a/docs/narr/router.rst
+++ b/docs/narr/router.rst
@@ -60,7 +60,7 @@ processing?
    ``__getitem__`` on the root object and subobjects) to find a
    :term:`context`.  If the root object has no ``__getitem__`` method,
    the root itself is assumed to be the context.  The exact traversal
-   agorithm is described in :ref:`traversal_chapter`. The traverser
+   algorithm is described in :ref:`traversal_chapter`. The traverser
    function returns a dictionary, which contains a :term:`context` and
    a :term:`view name` as well as other ancillary information.
 
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index cd2dc9a50..423e640ed 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -54,7 +54,7 @@ and an instance of the class
 ``repoze.bfg.authorization.ACLAuthorizationPolicy`` to be injected as
 the :term:`authorization policy` used by this application.
 
-:mod:`repoze.bfg` ships with a few prechewed authentication and
+:mod:`repoze.bfg` ships with a few pre-chewed authentication and
 authorization policies that should prove useful.  See
 :ref:`authentication_policies_directives_section` and
 :ref:`authorization_policies_directives_section` for more information.
@@ -278,7 +278,7 @@ module.  These can be imported for use in ACLs.
 
   An object representing, literally, *all* permissions.  Useful in an
   ACL like so: ``(Allow, 'fred', ALL_PERMISSIONS)``.  The
-  ``ALL_PERMISSIONS`` object is actually a standin object that has a
+  ``ALL_PERMISSIONS`` object is actually a stand-in object that has a
   ``__contains__`` method that always returns True, which, for all
   known authorization policies, has the effect of indicating that a
   given principal "has" any permission asked for by the system.
@@ -399,7 +399,7 @@ information in the debugger or via print statements when a
 Built-In Authentication Policy Directives
 -----------------------------------------
 
-:mod:`repoze.who` ships with a few "prechewed" authentication policy
+:mod:`repoze.who` ships with a few "pre-chewed" authentication policy
 implementations that you can make use of within your application.
 
 ``repozewho1authenticationpolicy``
@@ -497,7 +497,7 @@ user information.  It defaults to ``repoze.bfg.auth_tkt``.
 
 ``secure`` is a boolean value.  If it's set to "true", the cookie will
 only be sent back by the browser over a secure (HTTPS) connection.
-It defauls to "false".
+It defaults to "false".
 
 ``include_ip`` is a boolean value.  If it's set to true, the
 requesting IP address is made part of the authentication data in the
@@ -587,11 +587,11 @@ detection.
 Creating Your Own Authorization Policy
 --------------------------------------
 
-An authentiction policy the policy that allows or denies access after
+An authentication policy the policy that allows or denies access after
 a user has been authenticated.  By default, :mod:`repoze.bfg` will use
 the ``repoze.bfg.authorization.ACLAuthorizationPolicy`` if an
 authentication policy is activated and an authorization policy isn't
-otherwise specificed.  In some cases, it's useful to be able to use a
+otherwise specified.  In some cases, it's useful to be able to use a
 different authentication policy than the
 ``repoze.bfg.authorization.ACLAuthorizationPolicy``.  For example, it
 might be desirable to construct an alternate authorization policy
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index a2117622f..a19778f04 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -322,7 +322,7 @@ Jinja2 template bindings are available for :mod:`repoze.bfg` in the
 repository at `http://svn.repoze.org/repoze.bfg.jinja2
 <http://svn.repoze.org/repoze.bfg.jinja2>`_.
 
-Courtesty of Carlos de la Guardia, bindings for the Zope
+Courtesy of Carlos de la Guardia, bindings for the Zope
 ``zope.pagetemplate`` package ("old TAL") are available from
 `http://svn.repoze.org/repoze.bfg.zopepagetemplate/
 <http://svn.repoze.org/repoze.bfg.zopepagetemplate/>`_.
diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst
index 8e21150c1..3ae963e1a 100644
--- a/docs/narr/traversal.rst
+++ b/docs/narr/traversal.rst
@@ -127,7 +127,7 @@ code to execute:
     terminated, the first remaining path element is treated as the
     view name.
 
-    Any subseqent path elements after the view name are deemed the
+    Any subsequent path elements after the view name are deemed the
     :term:`subpath`.  The subpath is always a sequence of path
     segments that come from ``PATH_INFO`` that are "left over" after
     traversal has completed. For instance, if ``PATH_INFO`` was
@@ -144,13 +144,13 @@ code to execute:
     performs a permission lookup.  If a permission declaration is
     found for the view name and context implied by the current
     request, an :term:`authorization policy` is consulted to see if
-    the "current user" (al determined by the the authentication
+    the "current user" (all determined by the the authentication
     policy) can perform the action.  If he can, processing continues.
     If he cannot, the ``forbidden`` view is called (see
     :ref:`changing_the_forbidden_view`).
 
 #.  Armed with the context, the view name, and the subpath, the router
-    performs a view lookup.  It attemtps to look up a view from the
+    performs a view lookup.  It attempts to look up a view from the
     :mod:`repoze.bfg` :term:`application registry` using the view name
     and the context.  If a view function is found, it is called with
     the context and the request.  It returns a response, which is fed
@@ -162,8 +162,8 @@ protocol.
 
 .. _debug_notfound_section:
 
-NotFound Errors
----------------
+``NotFound`` Errors
+-------------------
 
 It's useful to be able to debug ``NotFound`` errors when they occur
 unexpectedly due to an application registry misconfiguration.  To
@@ -181,7 +181,7 @@ Let's pretend the user asks for
 ``http://example.com/foo/bar/baz/biz/buz.txt``. Let's pretend that the
 request's ``PATH_INFO`` in that case is ``/foo/bar/baz/biz/buz.txt``.
 Let's further pretend that when this request comes in that we're
-traversing the follwing graph::
+traversing the following graph::
 
   /--
      |
@@ -210,7 +210,7 @@ error condition.  It signifies that:
 
 - the :term:`subpath` is ``('biz', 'buz.txt')``
 
-Because it's the "context", :mod:`repoze.bfg` examimes "bar" to find
+Because it's the "context", :mod:`repoze.bfg` examines "bar" to find
 out what "type" it is. Let's say it finds that the context is an
 ``IBar`` type (because "bar" happens to have an attribute attached to
 it that indicates it's an ``IBar``).
@@ -248,7 +248,7 @@ The user asks for ``http://example.com/foo/bar/baz/biz/buz.txt``
 - :mod:`repoze.bfg` traverses baz, and attempts to find biz, which it
   finds.
 
-- :mod:`repoze.bfg` traverses biz, and attemtps to find "buz.txt"
+- :mod:`repoze.bfg` traverses biz, and attempts to find "buz.txt"
   which it does not find.
 
 The fact that it does not find "buz.txt" at this point does not
@@ -261,7 +261,7 @@ signify an error condition.  It signifies that:
 
 - the :term:`subpath` is an empty sequence ( ``()`` ).
 
-Because it's the "context", :mod:`repoze.bfg` examimes "biz" to find
+Because it's the "context", :mod:`repoze.bfg` examines "biz" to find
 out what "type" it is. Let's say it finds that the context an ``IBiz``
 type (because "biz" happens to have an attribute attached to it that
 happens indicates it's an ``IBiz``).
@@ -272,7 +272,7 @@ Using the "view name" ("buz.txt") and the type, it asks the
 - Please find me a :term:`view` with the name "buz.txt" that can be
   used for type ``IBiz``.
 
-Let's say that question is answered "here you go, here'a a bit of code
+Let's say that question is answered "here you go, here's a bit of code
 that is willing to deal with that case", and returns a :term:`view`.
 It is passed the "biz" object as the "context" and the current
 :term:`WebOb` :term:`request` as the "request".  It returns a
@@ -337,10 +337,11 @@ Unicode and Traversal
 The traversal machinery by default attempts to first URL-unquote and
 then Unicode-decode each path element in ``PATH_INFO`` from its
 natural byte string (``str`` type) representation.  URL unquoting is
-performed using the Python stdlib ``urllib.unquote`` function.
-Conversion from a URL-decoded string into Unicode is attempted using
-the UTF-8 encoding.  If any URL-unquoted path segment in ``PATH_INFO``
-is not decodeable using the UTF-8 decoding, a TypeError is raised.  A
-segment will be fully URL-unquoted and UTF8-decoded before it is
-passed it to the ``__getitem__`` of any model object during traversal.
+performed using the Python standard library ``urllib.unquote``
+function.  Conversion from a URL-decoded string into Unicode is
+attempted using the UTF-8 encoding.  If any URL-unquoted path segment
+in ``PATH_INFO`` is not decodeable using the UTF-8 decoding, a
+TypeError is raised.  A segment will be fully URL-unquoted and
+UTF8-decoded before it is passed it to the ``__getitem__`` of any
+model object during traversal.
 
diff --git a/docs/narr/unittesting.rst b/docs/narr/unittesting.rst
index a0d2b551b..22a36318a 100644
--- a/docs/narr/unittesting.rst
+++ b/docs/narr/unittesting.rst
@@ -39,7 +39,7 @@ The testing API provided by ``repoze.bfg`` allows you to simulate
 various application registry registrations for use under a unit
 testing framework without needing to invoke the actual application
 ZCML configuration.  For example, if you wanted to test the above
-``view_fn`` (assming it lived in ``my.package``), you could write a
+``view_fn`` (assuming it lived in ``my.package``), you could write a
 unittest TestCase that used the testing API.
 
 .. code-block:: python
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 90ddd6672..7e3454a2a 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -17,7 +17,7 @@ For instance, if all the data in your application lives in a
 relational database, and that relational database has no
 self-referencing tables that form a natural hierarchy, URL dispatch is
 easier to use than traversal, and is often a more natural fit for
-creating an application that maniplates "flat" data.
+creating an application that manipulates "flat" data.
 
 Concept and Usage
 -----------------
@@ -46,7 +46,7 @@ function (usually a traversal function).
 
 A root factory is not required for purely URL-dispatch-based apps: if
 the root factory callable is passed as ``None`` to the ``make_app``
-function, :mod:`repoze.bfg` will return a NotFound error to the user's
+function, :mod:`repoze.bfg` will return a ``NotFound`` error to the user's
 browser when no routes match.
 
 .. note:: See :ref:`modelspy_project_section` for an example of a
@@ -139,7 +139,7 @@ segment ("foo") and two dynamic segments ("baz", and "bar")::
 
     foo/:baz/:bar
 
-The above pattern will match these URLs, generating the followng
+The above pattern will match these URLs, generating the following
 matchdicts::
 
    foo/1/2        -> {'baz':u'1', 'bar':u'2'}
@@ -173,7 +173,7 @@ not need to be preceded by a slash.  For example::
 
     foo/:baz/:bar*traverse
 
-The above pattern will match these URLs, generating the followng
+The above pattern will match these URLs, generating the following
 matchdicts::
 
    foo/1/2/               -> {'baz':1, 'bar':2, 'traverse':()}
@@ -204,7 +204,7 @@ commonly declared.
 Example 1
 ~~~~~~~~~
 
-The simplest route delcaration:
+The simplest route declaration:
 
 .. code-block:: xml
    :linenos:
@@ -232,7 +232,7 @@ The ``mypackage.views`` module referred to above might look like so:
 
 In this case the context object passed to the view will be an instance
 of the ``repoze.bfg.urldispatch.DefaultRoutesContext``.  This is the
-type of obejct created for a context when there is no "factory"
+type of object created for a context when there is no "factory"
 specified in the ``route`` declaration.  It is a mapping object, a lot
 like a dictionary.
 
diff --git a/docs/narr/urlmapping.rst b/docs/narr/urlmapping.rst
index 1c9cde888..87f8c9862 100644
--- a/docs/narr/urlmapping.rst
+++ b/docs/narr/urlmapping.rst
@@ -15,7 +15,7 @@ dispatcher
 :term:`Routes` URL mapping system.
 
 :mod:`repoze.bfg` supports :term:`URL dispatch` via a subsystem that
-was inpsired by :term:`Routes`.  :term:`URL dispatch` is convenient
+was inspired by :term:`Routes`.  :term:`URL dispatch` is convenient
 and straightforward.  When you limit your application to using URL
 dispatch, you know every URL that your application might generate or
 respond to, and all the URL matching elements are listed in a single
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 69be6b046..bdd4518e9 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -143,7 +143,7 @@ app_iter
 
   An iterable representing the body of the response.  This can be a
   list, e.g. ``['<html><head></head><body>Hello
-  world!</body></html>']`` or it can be a filelike object, or any
+  world!</body></html>']`` or it can be a file-like object, or any
   other sort of iterable.
 
 If a view happens to return something to the :mod:`repoze.bfg`
@@ -262,7 +262,7 @@ route_name
   unless you want to perform traversal *after* a route has matched.*
   This value must match the ``name`` of a ``<route>`` declaration (see
   :ref:`urldispatch_chapter`) that must match before this view will be
-  called.  The ``<route>`` declaration specifed by ``route_name`` must
+  called.  The ``<route>`` declaration specified by ``route_name`` must
   exist in ZCML before the view that names the route
   (XML-ordering-wise) .  Note that the ``<route>`` declaration
   referred to by ``route_name`` usually has a ``*traverse`` token in
@@ -300,7 +300,7 @@ decorator to do this work.
    to scan for view declarations.  Additionally, if you use
    decorators, it means that other people will not be able to override
    your view declarations externally using ZCML: this is a common
-   requirement if you're developing an exensible application (e.g. a
+   requirement if you're developing an extensible application (e.g. a
    framework).  See :ref:`extending_chapter` for more information
    about building extensible applications.