Added more internal links in the management command documentation.

docs/ref/django-admin.txt

@@ -107,7 +107,7 @@ compilemessages
 
 .. django-admin:: compilemessages
 
-Compiles .po files created with ``makemessages`` to .mo files for use with
+Compiles .po files created :djadmin:`makemessages` to .mo files for use with
 the builtin gettext support. See :doc:`/topics/i18n/index`.
 
 Use the :djadminopt:`--locale` option (or its shorter version ``-l``) to
@@ -195,7 +195,7 @@ application(s).
 
 If no application name is provided, all installed applications will be dumped.
 
-The output of ``dumpdata`` can be used as input for ``loaddata``.
+The output of ``dumpdata`` can be used as input for :djadmin:`loaddata`.
 
 Note that ``dumpdata`` uses the default manager on the model for selecting the
 records to dump. If you're using a :ref:`custom manager <custom-managers>` as
@@ -452,7 +452,7 @@ one fixture can reference data in another fixture. If the database backend
 supports row-level constraints, these constraints will be checked at the
 end of the transaction.
 
-The ``dumpdata`` command can be used to generate input for ``loaddata``.
+The :djadmin:`dumpdata` command can be used to generate input for ``loaddata``.
 
 Compressed fixtures
 ~~~~~~~~~~~~~~~~~~~
@@ -498,8 +498,8 @@ Runs over the entire source tree of the current directory and pulls out all
 strings marked for translation. It creates (or updates) a message file in the
 conf/locale (in the Django tree) or locale (for project and application)
 directory. After making changes to the messages files you need to compile them
-with ``compilemessages`` for use with the builtin gettext support. See the
-:ref:`i18n documentation <how-to-create-language-files>` for details.
+with :djadmin:`compilemessages` for use with the builtin gettext support. See
+the :ref:`i18n documentation <how-to-create-language-files>` for details.
 
 .. django-admin-option:: --all
 
@@ -812,8 +812,8 @@ reduction.
 
 When you start the server, and each time you change Python code while the
 server is running, the server will validate all of your installed models. (See
-the ``validate`` command below.) If the validator finds errors, it will print
-them to standard output, but it won't stop the server.
+the :djadmin:`validate` command below.) If the validator finds errors, it will
+print them to standard output, but it won't stop the server.
 
 You can run as many servers as you want, as long as they're on separate ports.
 Just execute ``django-admin.py runserver`` more than once.
@@ -966,7 +966,7 @@ sqlall <appname appname ...>
 
 Prints the CREATE TABLE and initial-data SQL statements for the given app name(s).
 
-Refer to the description of ``sqlcustom`` for an explanation of how to
+Refer to the description of :djadmin:`sqlcustom` for an explanation of how to
 specify initial data.
 
 The :djadminopt:`--database` option can be used to specify the database for
@@ -1248,8 +1248,8 @@ testserver <fixture fixture ...>
 
 .. django-admin:: testserver
 
-Runs a Django development server (as in ``runserver``) using data from the
-given fixture(s).
+Runs a Django development server (as in :djadmin:`runserver`) using data from
+the given fixture(s).
 
 For example, this command::
 
@@ -1259,8 +1259,8 @@ For example, this command::
 
 1. Create a test database, as described in :ref:`the-test-database`.
 2. Populate the test database with fixture data from the given fixtures.
-   (For more on fixtures, see the documentation for ``loaddata`` above.)
-3. Runs the Django development server (as in ``runserver``), pointed at
+   (For more on fixtures, see the documentation for :djadmin:`loaddata` above.)
+3. Runs the Django development server (as in :djadmin:`runserver`), pointed at
    this newly created test database instead of your production database.
 
 This is useful in a number of ways:
@@ -1271,21 +1271,22 @@ This is useful in a number of ways:
 
 * Let's say you're developing your Django application and have a "pristine"
   copy of a database that you'd like to interact with. You can dump your
-  database to a fixture (using the ``dumpdata`` command, explained above),
-  then use ``testserver`` to run your Web application with that data. With
-  this arrangement, you have the flexibility of messing up your data
+  database to a fixture (using the :djadmin:`dumpdata` command, explained
+  above), then use ``testserver`` to run your Web application with that data.
+  With this arrangement, you have the flexibility of messing up your data
   in any way, knowing that whatever data changes you're making are only
   being made to a test database.
 
 Note that this server does *not* automatically detect changes to your Python
-source code (as ``runserver`` does). It does, however, detect changes to
+source code (as :djadmin:`runserver` does). It does, however, detect changes to
 templates.
 
 .. django-admin-option:: --addrport [port number or ipaddr:port]
 
 Use ``--addrport`` to specify a different port, or IP address and port, from
 the default of ``127.0.0.1:8000``. This value follows exactly the same format and
-serves exactly the same function as the argument to the ``runserver`` command.
+serves exactly the same function as the argument to the :djadmin:`runserver`
+command.
 
 Examples:
 
@@ -1354,8 +1355,8 @@ This command is only available if Django's :doc:`authentication system
 
 Creates a superuser account (a user who has all permissions). This is
 useful if you need to create an initial superuser account but did not
-do so during the first ``migrate``, or if you need to programmatically generate
-superuser accounts for your site(s).
+do so during the first :djadmin:`migrate`, or if you need to programmatically
+generate superuser accounts for your site(s).
 
 When run interactively, this command will prompt for a password for
 the new superuser account. When run non-interactively, no password