Spellcheck.

6 files changed, 21 insertions, 21 deletions

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.