12 files changed, 44 insertions, 44 deletions

diff --git a/docs/designdefense.rst b/docs/designdefense.rst
index 87fc54341..679d19f48 100644
--- a/docs/designdefense.rst
+++ b/docs/designdefense.rst
@@ -3,7 +3,7 @@ Defending BFG's Design
 
 From time to time, challenges to various aspects of :mod:`repoze.bfg`
 design are lodged.  To give context to the discussions that follow, we
-detail some of the design decisions and tradeoffs here.
+detail some of the design decisions and trade-offs here.
 
 BFG Uses The Zope Component Architecture ("ZCA")
 ------------------------------------------------
@@ -14,8 +14,8 @@ This is a point of some contention.  :mod:`repoze.bfg` is of a
 ZCA at its inception.  However, :mod:`repoze.bfg` allegiance to its
 Zope pedigree is not blind.  We understand that using the ZCA has
 issues and consequences, which we've attempted to address as best we
-can.  Here'a an introspection about BFG's use of the ZCA, and the
-tradeoffs its usage involves.
+can.  Here's an introspection about BFG's use of the ZCA, and the
+trade offs its usage involves.
 
 Problems
 ++++++++
@@ -39,7 +39,7 @@ it's unlikely that any "civilian" would know that just by reading the
 code.  There are a number of comprehension issues with the bit of code
 above that are obvious.
 
-First, what's a "utility"?  Well, for the purposes of this dicussion,
+First, what's a "utility"?  Well, for the purposes of this discussion,
 and for the purpose of the code above, it's just not very important.
 If you really care, you can go read `this
 <http://www.muthukadan.net/docs/zca.html#utility>`_.  However, still,
@@ -70,7 +70,7 @@ require knowledge of internals).  Can there be more than one?  Yes.
 So *which* registry does it find the registration in?  Well, the
 "current" registry of course.  In terms of :mod:`repoze.bfg`, the
 current registry is a thread local variable.  Using an API that
-consults a thread local makes understanding how it works nonlocal.
+consults a thread local makes understanding how it works non-local.
 
 Sixth, fine, you've bought in to the fact that there's a registry that
 is just "hanging around".  But how does the registry get populated?
@@ -164,7 +164,7 @@ the ZCA API, work on it was largely abandoned and it is not used in
    reinventing the wheel.
 
 Making framework developers and extenders understand the ZCA is a
-tradeoff.  We (the :mod:`repoze.bfg` developers) like the features
+trade-off.  We (the :mod:`repoze.bfg` developers) like the features
 that the ZCA gives us, and we have long-ago borne the weight of
 understanding what it does and how it works.  The authors of
 :mod:`repoze.bfg` understand the ZCA deeply and can read code that
@@ -228,7 +228,7 @@ Here are the main rationales for BFG's design decision to use the ZCA:
 - Pedigree.  A nontrivial part of the answer to this question is
   "pedigree".  Much of the design of :mod:`repoze.bfg` is stolen
   directly from :term:`Zope`.  Zope uses the ZCA to do a number of
-  tricks.  :mod:`repoze.bfg` mimics these tricks apeishly, and,
+  tricks.  :mod:`repoze.bfg` mimics these tricks apishly, and,
   because the ZCA works well for that set of tricks, :mod:`repoze.bfg`
   uses it for the same purposes.  For example, the way that BFG maps a
   :term:`request` to a :term:`view callable` is lifted almost entirely
@@ -432,7 +432,7 @@ I Can't Figure Out How "BFG" Is Related to "Repoze"
 
 When the `Repoze project <http://repoze.org>`_ was first started,
 :mod:`repoze.bfg` did not exist.  The `website <http://repoze.org>`_
-for the project had (and still has, of this writing) a tagline of
+for the project had (and still has, of this writing) a tag line of
 "Plumbing Zope into the WSGI Pipeline", and contained descriptions of
 :term:`WSGI` middleware that were inspired by Zope features, and
 applications that help :term:`Zope` to run within a WSGI environment.
@@ -516,7 +516,7 @@ object graph (or at least is a :term:`view` related to a node in the
 object graph), and traversal is required to reach this code.
 
 I'll argue that URL dispatch is ultimately useful, even if you want to
-use traversal as well.  You can actully *combine* URL dispatch and
+use traversal as well.  You can actually *combine* URL dispatch and
 traversal in :mod:`repoze.bfg` (see :ref:`hybrid_chapter`).  One
 example of such a usage: if you want to emulate something like Zope
 2's "Zope Management Interface" UI on top of your model graph (or any
@@ -588,7 +588,7 @@ specification matching done aggressively can be costly, and
 decided to make people obtain information by interrogating the request
 object for it in the view body instead of providing magic to do
 unpacking into the view argument list.  The feature itself also just
-seems a bit like a gimmick.  Getting the arguments you wnt explicitly
+seems a bit like a gimmick.  Getting the arguments you want explicitly
 from the request via getitem is not really very hard; it's certainly
 never a bottleneck for the author when he writes web apps.
 
@@ -606,7 +606,7 @@ looks in ``request.matchdict``.
 It's possible at some point that :mod:`repoze.bfg` will grow some form
 of argument matching feature (it would be simple to make it an
 always-on optional feature that has no cost unless you actually use
-it) for, but curently it has none.
+it) for, but currently it has none.
 
 BFG Provides Too Few "Rails"
 ----------------------------
@@ -618,7 +618,7 @@ not a particularly "opinionated" web framework.  This is by design.
 bindings.  It contains no prebaked REST helper functionality.  It
 contains no form generation framework.  It contains no sessioning
 library.  It does not help with internationalization of content.  It
-has no adminstrative web user interface.  It has no built in text
+has no administrative web user interface.  It has no built in text
 indexing.  And so on.
 
 :mod:`repoze.bfg` developers put opinionated functionality in
@@ -783,7 +783,7 @@ the `Model-View-Controller Wikipedia entry
     restarts the cycle.
 
 To be honest, it seems as if someone edited this Wikipedia definition,
-torturously couching concepts in the most generic terms possible in
+tortuously couching concepts in the most generic terms possible in
 order to account for the use of the term "MVC" by current web
 frameworks.  I doubt such a broad definition would ever be agreed to
 by the original authors of the MVC pattern.  But *even so*, it seems
@@ -792,7 +792,7 @@ definition.
 
 For example, do your templates (views) always query models directly as
 is claimed in "note that the view gets its own data from the model"?
-Probaby not.  My "controllers" tend to do this, massaging the data for
+Probably not.  My "controllers" tend to do this, massaging the data for
 easier use by the "view" (template). What do you do when your
 "controller" returns JSON? Do your controllers use a template to
 generate JSON? If not, what's the "view" then?  Most MVC-style GUI web
@@ -809,8 +809,8 @@ doesn't need a template to return a response.  There's no
 "controller": it just doesn't exist.  This seems to us like a more
 reasonable model, given the current constraints of the web.
 
-BFG Applications are Exensible; I Don't Believe In Extensible Applications
---------------------------------------------------------------------------
+BFG Applications are Extensible; I Don't Believe In Extensible Applications
+---------------------------------------------------------------------------
 
 Any :mod:`repoze.bfg` application written obeying certain constraints
 is *extensible*. "Extensible", in this context, means:
diff --git a/docs/glossary.rst b/docs/glossary.rst
index 1bb4dfab3..e7b33b0c4 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -258,7 +258,7 @@ Glossary
     `chameleon <http://chameleon.repoze.org>`_ is an attribute
     language template compiler which supports both the :term:`ZPT` and
     :term:`Genshi` templating specifications.  It is written and
-    maintained by Malthe Borch.  It has serveral extensions, such as
+    maintained by Malthe Borch.  It has several extensions, such as
     the ability to use bracketed (Genshi-style) ``${name}`` syntax,
     even within ZPT.  It is also much faster than the reference
     implementations of both ZPT and Genshi.  :mod:`repoze.bfg` offers
@@ -452,7 +452,7 @@ Glossary
     given request.
   Route Predicate
     An attribute of a ZCML ``route`` directive which implies a value
-    that evaluates to true or fale for a given :term:`request`.  All
+    that evaluates to true or false for a given :term:`request`.  All
     predicates attached to a route configuration must evaluate to true
     for the associated route to "match" the current request.  If a
     route does not match the current request, the next route (in
diff --git a/docs/narr/extending.rst b/docs/narr/extending.rst
index ffe0080e7..26520d2d0 100644
--- a/docs/narr/extending.rst
+++ b/docs/narr/extending.rst
@@ -212,7 +212,7 @@ accessible within a Python *package*.  An entire chapter is devoted to
 resources: :ref:`resources_chapter`.  Within this chapter is a section
 named :ref:`overriding_resources_section`.  This section of that
 chapter describes in detail how to override package resources with
-other resouces by using :term:`ZCML` ``<resource>`` declarations.  Add
+other resources by using :term:`ZCML` ``<resource>`` declarations.  Add
 such ``<resource>`` declarations to your override package's
 ``configure.zcml`` to perform overrides.
 
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index c2f546896..c390df375 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -362,7 +362,7 @@ this writing, and neither does the generated sample application.
 
 The ``[app:main]`` section represents configuration for your
 application.  This section name represents the ``main`` application
-(and it's an ``app`` -lication, thus ``app:main``), sigifiying that
+(and it's an ``app`` -lication, thus ``app:main``), signifying that
 this is the default application run by ``paster serve`` when it is
 invoked against this configuration file.  The name ``main`` is a
 convention signifying that it the default application.
@@ -464,7 +464,7 @@ on the command line.
 
 Within the arguments to this function call, information about your
 application is kept.  While it's beyond the scope of this
-documentation to explan everything about setuptools setup files, we'll
+documentation to explain everything about setuptools setup files, we'll
 provide a whirlwind tour of what exists in this file here.
 
 Your application's name (this can be any string) is specified in the
@@ -488,7 +488,7 @@ as a directory, which is more convenient).  ``install_requires`` and
 application, which means all tests found in the package will be
 installed.  We examined ``entry_points`` in our discussion of the
 ``MyProject.ini`` file; this file defines the ``app`` entry point that
-represent's our project's application.
+represents our project's application.
 
 Usually you only need to think about the contents of the ``setup.py``
 file when distributing your application to other people, or when
@@ -577,7 +577,7 @@ registry`. It looks like so:
    "shortcuts" which point at files relative to the :term:`package` in
    which the ``configure.zcml`` file lives.  In this case, since the
    ``configure.zcml`` file lives within the ``myproject`` package, the
-   shorcut ``.models.MyModel`` could also be spelled
+   shortcut ``.models.MyModel`` could also be spelled
    ``myproject.models.MyModel`` (forming a full Python dotted-path
    name to the ``MyModel`` class).  Likewise the shortcut
    ``.views.my_view`` could be replaced with
@@ -585,7 +585,7 @@ registry`. It looks like so:
 
    The view declaration also names a ``renderer``, which in this case
    is a template that will be used to render the result of the view
-   callable.  This particular view delcaration points at
+   callable.  This particular view declaration points at
    ``templates/mytemplate.pt``, which is a *relative* file
    specification (it's relative to the directory in which the
    ``configure.zcml`` file lives).  The template file it points at is
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 773ab3a4f..54c951847 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -469,7 +469,7 @@ lifetime of the ticket contained in the cookie, while this value
 represents the lifetime of the cookie itself.  When this value is set,
 the cookie's ``Max-Age`` and ``Expires`` settings will be set,
 allowing the auth_tkt cookie to last between browser sessions.  It is
-typically nonsenical to set this to a value that is lower than
+typically nonsensical to set this to a value that is lower than
 ``timeout`` or ``reissue_time``, although it is not explicitly
 prevented.  It defaults to ``None``, meaning (on all major browser
 platforms) that auth_tkt cookies will last for the lifetime of the
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index dd20ae7f4..341701844 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -185,7 +185,7 @@ view_permission
   If the ``view`` attribute is not provided, this attribute has no
   effect.
 
-  This atribute can also be spelled as ``permission``.
+  This attribute can also be spelled as ``permission``.
 
 view_renderer
 
@@ -194,7 +194,7 @@ view_renderer
   (e.g. ``templates/views.pt``).  If the renderer value is a single
   term (does not contain a dot ``.``), the specified term will be used
   to look up a renderer implementation, and that renderer
-  inplementation will be used to construct a response from the view
+  implementation will be used to construct a response from the view
   return value.  If the renderer term contains a dot (``.``), the
   specified term will be treated as a path, and the filename extension
   of the last element in the path will be used to look up the renderer
@@ -206,7 +206,7 @@ view_renderer
   If the ``view`` attribute is not provided, this attribute has no
   effect.
 
-  This atribute can also be spelled as ``renderer``.
+  This attribute can also be spelled as ``renderer``.
 
   .. note:: This feature is new as of :mod:`repoze.bfg` 1.1.
 
@@ -239,7 +239,7 @@ view_attr
 
   The view machinery defaults to using the ``__call__`` method of the
   view callable (or the function itself, if the view callable is a
-  funcion) to obtain a response dictionary.  The ``attr`` value allows
+  function) to obtain a response dictionary.  The ``attr`` value allows
   you to vary the method attribute used to obtain the response.  For
   example, if your view was a class, and the class has a method named
   ``index`` and you wanted to use this method instead of the class'
@@ -392,7 +392,7 @@ opposed to using both url dispatch and :term:`traversal`), the
 particularly if you never use a ``factory`` attribute on your route
 definitions.  For this reason, :mod:`repoze.bfg` supports view
 callables defined with only a ``request`` argument in their argument
-specification.  For example, the below view statement is competely
+specification.  For example, the below view statement is completely
 equivalent to the above view statement:
 
 .. code-block:: python
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 88ae12764..4f67d9663 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -381,7 +381,7 @@ renderer
   (e.g. ``templates/views.pt``).  If the renderer value is a single
   term (does not contain a dot ``.``), the specified term will be used
   to look up a renderer implementation, and that renderer
-  inplementation will be used to construct a response from the view
+  implementation will be used to construct a response from the view
   return value.  If the renderer term contains a dot (``.``), the
   specified term will be treated as a path, and the filename extension
   of the last element in the path will be used to look up the renderer
@@ -506,7 +506,7 @@ containment
 
 xhr
 
-  Thie value should be either ``True`` or ``False``.  If this value is
+  This value should be either ``True`` or ``False``.  If this value is
   specified and is ``True``, the :term:`request` must possess an
   ``HTTP_X_REQUESTED_WITH`` (aka ``X-Requested-With``) header that has
   the value ``XMLHttpRequest`` for this view to be found and called.
@@ -865,7 +865,7 @@ invoking user.  No further view narrowing or view lookup is done.
    changing the default forbidden view.
 
 The value of the ``name`` attribute represents a direct match of the
-view name returned via traversal.  It is part of intial view lookup
+view name returned via traversal.  It is part of initial view lookup
 rather than a predicate/narrower.
 
 The value of the ``renderer`` attribute represents the renderer used
@@ -1087,14 +1087,14 @@ rendered template in a response to the user.  If the view returns
 anything but a dictionary, an error will be raised.
 
 Before passing keywords to the template, the keywords derived from the
-dictionary returned by the view are augumented.  The callable object
+dictionary returned by the view are augmented.  The callable object
 (whatever object was used to define the ``view``) will be
 automatically inserted into the set of keyword arguments passed to the
 template as the ``view`` keyword.  If the view callable was a class,
 the ``view`` keyword will be an instance of that class.  Also inserted
 into the keywords passed to the template are ``renderer_name`` (the
 name of the renderer, which may be a full path or a package-relative
-name, typically the full string used in the ``renderer`` atttribute of
+name, typically the full string used in the ``renderer`` attribute of
 the directive), ``context`` (the context of the view used to render
 the template), and ``request`` (the request passed to the view used to
 render the template).
@@ -1390,7 +1390,7 @@ In this case, ``.models.Root`` refers to the class of which your
    ``static`` to be accessible as the static view against any model.
    This will also allow ``/static/foo.js`` to work, but it will allow
    for ``/anything/static/foo.js`` too, as long as ``anything`` itself
-   is resolveable.
+   is resolvable.
 
 .. note:: To ensure that model objects contained in the root don't
    "shadow" your static view (model objects take precedence during
@@ -1588,7 +1588,7 @@ callable to influence automatically constructed response attributes.
 Adding and Overriding Renderers
 -------------------------------
 
-Additonal ZCML declarations can be made which override an existing
+Additional ZCML declarations can be made which override an existing
 :term:`renderer` or which add a new renderer.  Adding or overriding a
 renderer is accomplished via one or more separate ZCML directives.
 
diff --git a/docs/narr/webob.rst b/docs/narr/webob.rst
index a9adf8233..c343ee1e0 100644
--- a/docs/narr/webob.rst
+++ b/docs/narr/webob.rst
@@ -212,13 +212,13 @@ Here's the highlights:
     the cookie value to ``''``.
 
 ``response.cache_expires(seconds=0)``:
-    This makes this response cachable for the given number of seconds,
+    This makes this response cacheable for the given number of seconds,
     or if ``seconds`` is 0 then the response is uncacheable (this also
     sets the ``Expires`` header).
 
 ``response(environ, start_response)``: The response object is a WSGI
     application.  As an application, it acts according to how you
-    creat it.  It *can* do conditional responses if you pass
+    create it.  It *can* do conditional responses if you pass
     ``conditional_response=True`` when instantiating (or set that
     attribute later).  It can also do HEAD and Range requests.
 
diff --git a/docs/tutorials/cmf/workflow.rst b/docs/tutorials/cmf/workflow.rst
index a66d8d78e..ff9527591 100644
--- a/docs/tutorials/cmf/workflow.rst
+++ b/docs/tutorials/cmf/workflow.rst
@@ -8,7 +8,7 @@ In CMF, the "workflow tool" allows developers to design state machines
 which imply transition between content states.
 
 :mod:`repoze.bfg` itself has no such concept, but the
-:term:`repoze.workflow` packge provides a simple state machine
+:term:`repoze.workflow` package provides a simple state machine
 implementation that can act as a barebones workflow tool.  See its
 documentation for more information.
 
diff --git a/docs/tutorials/zeo/index.rst b/docs/tutorials/zeo/index.rst
index f96167402..6519145db 100644
--- a/docs/tutorials/zeo/index.rst
+++ b/docs/tutorials/zeo/index.rst
@@ -18,7 +18,7 @@ exposed by :term:`mod_wsgi`.
 The easiest way to get started with ZODB in a :mod:`repoze.bfg`
 application is to use the ZODB ``bfg_zodb`` paster template.  See
 :ref:`additional_paster_templates` for more information about using
-theis template.  However, the Paster template does not set up a
+this template.  However, the Paster template does not set up a
 ZEO-capable application.  This chapter shows you how to do that "from
 scratch".
 
diff --git a/docs/tutorials/zodbsessions/index.rst b/docs/tutorials/zodbsessions/index.rst
index 69dc67d2b..43a8cf5db 100644
--- a/docs/tutorials/zodbsessions/index.rst
+++ b/docs/tutorials/zodbsessions/index.rst
@@ -140,7 +140,7 @@ Configuration
    See :ref:`MyProject_ini` for more information about project Paste
    ``.ini`` files.
 
-#.  Add a ``get_session`` API to your application.  I've chosed to add
+#.  Add a ``get_session`` API to your application.  I've chosen to add
     it directly to my ``views.py`` file, although it can live anywhere.
 
     .. code-block:: python
diff --git a/docs/whatsnew-1.1.rst b/docs/whatsnew-1.1.rst
index 5808d05fd..a6491fed3 100644
--- a/docs/whatsnew-1.1.rst
+++ b/docs/whatsnew-1.1.rst
@@ -4,7 +4,7 @@ What's New In :mod:`repoze.bfg` 1.1
 This article explains the new features in :mod:`repoze.bfg` version
 1.1 as compared to the previous 1.0 release.  It also documents
 backwards incompatibilities between the two versions and deprecations
-added to 1.1, as well as sotware dependency changes and notable
+added to 1.1, as well as software dependency changes and notable
 documentation additions.
 
 Major Feature Additions
@@ -675,7 +675,7 @@ Backwards Incompatibilities
 
 - The ``registry_manager`` backwards compatibility alias importable
   from "repoze.bfg.registry", deprecated since repoze.bfg 0.9 has been
-  removed.  If you are tring to use the registry manager within a
+  removed.  If you are tyring to use the registry manager within a
   debug script of your own, use a combination of the
   "repoze.bfg.paster.get_app" and "repoze.bfg.scripting.get_root" APIs
   instead.