Index: docs/intro/tutorial01.txt
===================================================================
--- docs/intro/tutorial01.txt	(revision 17756)
+++ docs/intro/tutorial01.txt	(working copy)
@@ -340,9 +340,9 @@
    the :ref:`DRY Principle <dry>`. The goal is to define your data model in one
    place and automatically derive things from it.
 
-In our simple poll app, we'll create two models: polls and choices. A poll has
-a question and a publication date. A choice has two fields: the text of the
-choice and a vote tally. Each choice is associated with a poll.
+In our simple poll app, we'll create two models: ``Poll`` and ``Choice``. A ``Poll`` has
+a question and a publication date. A ``Choice`` has two fields: the text of the
+choice and a vote tally. Each ``Choice`` is associated with a ``Poll``.
 
 These concepts are represented by simple Python classes. Edit the
 :file:`polls/models.py` file so it looks like this::
@@ -385,8 +385,8 @@
 schema, but in validation, as we'll soon see.
 
 Finally, note a relationship is defined, using
-:class:`~django.db.models.ForeignKey`. That tells Django each Choice is related
-to a single Poll. Django supports all the common database relationships:
+:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
+to a single ``Poll``. Django supports all the common database relationships:
 many-to-ones, many-to-manys and one-to-ones.
 
 .. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path
@@ -398,7 +398,7 @@
 is able to:
 
 * Create a database schema (``CREATE TABLE`` statements) for this app.
-* Create a Python database-access API for accessing Poll and Choice objects.
+* Create a Python database-access API for accessing ``Poll`` and ``Choice`` objects.
 
 But first we need to tell our project that the ``polls`` app is installed.
 
@@ -679,7 +679,7 @@
     True
 
     # Give the Poll a couple of Choices. The create call constructs a new
-    # choice object, does the INSERT statement, adds the choice to the set
+    # Choice object, does the INSERT statement, adds the choice to the set
     # of available choices and returns the new Choice object. Django creates
     # a set to hold the "other side" of a ForeignKey relation
     # (e.g. a poll's choices) which can be accessed via the API.
Index: docs/intro/tutorial02.txt
===================================================================
--- docs/intro/tutorial02.txt	(revision 17756)
+++ docs/intro/tutorial02.txt	(working copy)
@@ -276,11 +276,11 @@
 dynamically add it as the selected choice on the "Add choice" form you're
 looking at.
 
-But, really, this is an inefficient way of adding Choice objects to the system.
+But, really, this is an inefficient way of adding ``Choice`` objects to the system.
 It'd be better if you could add a bunch of Choices directly when you create the
-Poll object. Let's make that happen.
+``Poll`` object. Let's make that happen.
 
-Remove the ``register()`` call for the Choice model. Then, edit the ``Poll``
+Remove the ``register()`` call for the ``Choice`` model. Then, edit the ``Poll``
 registration code to read::
 
     class ChoiceInline(admin.StackedInline):
@@ -296,7 +296,7 @@
 
     admin.site.register(Poll, PollAdmin)
 
-This tells Django: "Choice objects are edited on the Poll admin page. By
+This tells Django: "``Choice`` objects are edited on the Poll admin page. By
 default, provide enough fields for 3 choices."
 
 Load the "Add poll" page to see how that looks, you may need to restart your development server:
@@ -309,7 +309,7 @@
 already-created object, you get another three extra slots.
 
 One small problem, though. It takes a lot of screen space to display all the
-fields for entering related Choice objects. For that reason, Django offers a
+fields for entering related ``Choice`` objects. For that reason, Django offers a
 tabular way of displaying inline related objects; you just need to change
 the ``ChoiceInline`` declaration to read::
 
@@ -397,7 +397,7 @@
 fields as you'd like -- although because it uses a ``LIKE`` query behind the
 scenes, keep it reasonable, to keep your database happy.
 
-Finally, because Poll objects have dates, it'd be convenient to be able to
+Finally, because ``Poll`` objects have dates, it'd be convenient to be able to
 drill down by date. Add this line::
 
     date_hierarchy = 'pub_date'
Index: docs/intro/tutorial03.txt
===================================================================
--- docs/intro/tutorial03.txt	(revision 17756)
+++ docs/intro/tutorial03.txt	(working copy)
@@ -411,7 +411,7 @@
 
 Method-calling happens in the :ttag:`{% for %}<for>` loop:
 ``poll.choice_set.all`` is interpreted as the Python code
-``poll.choice_set.all()``, which returns an iterable of Choice objects and is
+``poll.choice_set.all()``, which returns an iterable of ``Choice`` objects and is
 suitable for use in the :ttag:`{% for %}<for>` tag.
 
 See the :doc:`template guide </topics/templates>` for more about templates.
