- Minor edits to tutorials for accuracy based on feedback.

- Back to dev.

1 files changed, 7 insertions, 7 deletions

diff --git a/docs/tutorials/bfgwiki2/definingviews.rst b/docs/tutorials/bfgwiki2/definingviews.rst
index a75f4b74b..c7f9ba945 100644
--- a/docs/tutorials/bfgwiki2/definingviews.rst
+++ b/docs/tutorials/bfgwiki2/definingviews.rst
@@ -8,7 +8,7 @@ single parameter named :term:`request`.  A view is assumed to return a
 :term:`response` object.
 
 .. note:: A :mod:`repoze.bfg` view can also be defined as callable
-   which accepts *two* arguments: a :term:`context` and `
+   which accepts *two* arguments: a :term:`context` and a
    :term:`request`.  You'll see this two-argument pattern used in
    other :mod:`repoze.bfg` tutorials and applications.  Either calling
    convention will work in any :mod:`repoze.bfg` application.  In
@@ -25,14 +25,14 @@ elements placed into the URL by the ``path`` of a ``route`` statement.
 For instance, if a route statement in ``configure.zcml`` had the path
 ``:one/:two``, and the URL at ``http://example.com/foo/bar`` was
 invoked, matching this path, the matchdict dictionary attached to the
-request passed to the view would have a ``one`` key withe the value
+request passed to the view would have a ``one`` key with the value
 ``foo`` and a ``two`` key with the value ``bar``.
 
 Declaring Dependencies in Our ``setup.py`` File
 ===============================================
 
-The view code in our application will depend a package which is not a
-dependency of the original "tutorial" application.  The original
+The view code in our application will depend on a package which is not
+a dependency of the original "tutorial" application.  The original
 "tutorial" application was generated by the ``paster create`` command;
 it doesn't know about our custom application requirements.  We need to
 add a dependency on the ``docutils`` package to our ``tutorial``
@@ -74,7 +74,7 @@ The ``view_wiki`` function will respond as the default view of a
 ``Wiki`` model object.  It always redirects to a URL which represents
 the path to our "FrontPage".  It returns an instance of the
 ``webob.exc.HTTPFound`` class (instances of which implement the WebOb
-:term:`response` interface), It will use the the
+:term:`response` interface), It will use the
 ``repoze.bfg.url.route_url`` API to construct a URL to the
 ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and
 will use it as the "location" of the HTTPFound response, forming an
@@ -325,8 +325,8 @@ our application in a browser.  The views we'll try are as follows:
   browser invokes the ``view_wiki`` view.  This always redirects to
   the ``view_page`` view of the FrontPage page object.
 
-- Visiting `http://localhost:6543/FrontPage/
-  <http://localhost:6543/FrontPage/>`_ in a browser invokes the
+- Visiting `http://localhost:6543/FrontPage
+  <http://localhost:6543/FrontPage>`_ in a browser invokes the
   ``view_page`` view of the front page page object.
 
 - Visiting `http://localhost:6543/FrontPage/edit_page