rendering fixes

1 files changed, 11 insertions, 11 deletions

diff --git a/docs/narr/muchadoabouttraversal.rst b/docs/narr/muchadoabouttraversal.rst
index 375f6e927..c57e58cd0 100644
--- a/docs/narr/muchadoabouttraversal.rst
+++ b/docs/narr/muchadoabouttraversal.rst
@@ -208,10 +208,10 @@ example, for instance, you might want to view the photo in a page, but you
 might also want to provide a way for the user to edit the photo and any
 associated metadata.  We'll call the former the ``view`` view, and the latter
 will be the ``edit`` view.  (Original, I know.)  :app:`Pyramid` has a
-centralized view :term:`registry` where named views can be associated with
-specific resource types.  So in our example, we'll assume that we've
-registered ``view`` and ``edit`` views for photo objects, and that we've
-specified the ``view`` view as the default, so that
+centralized view :term:`application registry` where named views can be
+associated with specific resource types.  So in our example, we'll assume
+that we've registered ``view`` and ``edit`` views for photo objects, and that
+we've specified the ``view`` view as the default, so that
 ``/joeschmoe/photos/photo1/view`` and ``/joeschmoe/photos/photo1`` are
 equivalent.  The edit view would sensibly be provided by a request for
 ``/joeschmoe/photos/photo1/edit``.
@@ -270,13 +270,13 @@ patterns are going to become complex quickly as you try to handle all
 of the edge cases.
 
 With traversal, however, it's straightforward.  20 layers of nesting would be
- no problem.  :app:`Pyramid` will happily call ``__getitem__``
-as many times as it needs to, until it runs out of path segments or until a
-resource raises a :exc:`KeyError`.  Each resource only needs to know how to
-fetch its immediate children, the traversal algorithm takes care of the rest.
-Also, since the structure of the resource tree can live in the database and
-not in the code, it's simple to let users modify the tree at runtime to set
-up their own personalized "directory" structures.
+no problem.  :app:`Pyramid` will happily call ``__getitem__`` as many times
+as it needs to, until it runs out of path segments or until a resource raises
+a :exc:`KeyError`.  Each resource only needs to know how to fetch its
+immediate children, the traversal algorithm takes care of the rest.  Also,
+since the structure of the resource tree can live in the database and not in
+the code, it's simple to let users modify the tree at runtime to set up their
+own personalized "directory" structures.
 
 Another use case in which traversal shines is when there is a need to support
 a context-dependent security policy.  One example might be a document