Fixed #5955 -- Made a bunch of ReST fixes. Thanks, SmileyChris.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@6743 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/authentication.txt

@@ -170,7 +170,7 @@ The ``User`` model has a custom manager that has the following helper functions:
 
       If no password is provided, ``set_unusable_password()`` will be called.
 
-      See _`Creating users` for example usage.
+      See `Creating users`_ for example usage.
 
     * ``make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')``
       Returns a random password with the given length and given string of

docs/django-admin.txt

@@ -651,7 +651,7 @@ To run the test server on port 7000 with ``fixture1`` and ``fixture2``::
 that it doesn't matter whether the options come before or after the fixture
 arguments.)
 
-To run on 1.2.3.4:7000 with a `test` fixture::
+To run on 1.2.3.4:7000 with a ``test`` fixture::
 
     django-admin.py testserver --addrport 1.2.3.4:7000 test
 

docs/model-api.txt

@@ -50,7 +50,7 @@ The above ``Person`` model would create a database table like this::
 Some technical notes:
 
     * The name of the table, ``myapp_person``, is automatically derived from
-      some model metadata but can be overridden. See _`Table names` below.
+      some model metadata but can be overridden. See `Table names`_ below.
     * An ``id`` field is added automatically, but this behavior can be
       overriden. See `Automatic primary key fields`_ below.
     * The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
@@ -1664,7 +1664,7 @@ Adding extra Manager methods
 
 Adding extra ``Manager`` methods is the preferred way to add "table-level"
 functionality to your models. (For "row-level" functionality -- i.e., functions
-that act on a single instance of a model object -- use _`Model methods`, not
+that act on a single instance of a model object -- use `Model methods`_, not
 custom ``Manager`` methods.)
 
 A custom ``Manager`` method can return anything you want. It doesn't have to

docs/release_notes_0.96.txt

@@ -44,7 +44,7 @@ to this::
     DATABASE_ENGINE = "mysql_old"
 
 However, we strongly encourage MySQL users to upgrade to a more recent
-version of `MySQLdb` as soon as possible, The "mysql_old" backend is
+version of ``MySQLdb`` as soon as possible, The "mysql_old" backend is
 provided only to ease this transition, and is considered deprecated;
 aside from any necessary security fixes, it will not be actively
 maintained, and it will be removed in a future release of Django.

docs/templates_python.txt

@@ -1183,7 +1183,7 @@ on the object being edited -- so they're a perfect case for using a small
 template that is filled with details from the current object. (In the admin's
 case, this is the ``submit_row`` tag.)
 
-These sorts of tags are called `inclusion tags`.
+These sorts of tags are called "inclusion tags".
 
 Writing inclusion tags is probably best demonstrated by example. Let's write a
 tag that outputs a list of choices for a given ``Poll`` object, such as was

docs/tutorial01.txt

@@ -47,7 +47,7 @@ will create a ``mysite`` directory in your current directory.
    denied" when you try to run ``django-admin.py startproject``. This
    is because, on Unix-based systems like OS X, a file must be marked
    as "executable" before it can be run as a program. To do this, open
-   Terminal.app and navigate (using the `cd` command) to the directory
+   Terminal.app and navigate (using the ``cd`` command) to the directory
    where ``django-admin.py`` is installed, then run the command
    ``chmod +x django-admin.py``.
 

docs/url_dispatch.txt

@@ -237,7 +237,7 @@ include
 -------
 
 A function that takes a full Python import path to another URLconf that should
-be "included" in this place. See _`Including other URLconfs` below.
+be "included" in this place. See `Including other URLconfs`_ below.
 
 Notes on capturing text in URLs
 ===============================