Added backticks to code literals in various docs.

docs/faq/usage.txt

@@ -8,7 +8,7 @@ Why do I get an error about importing :envvar:`DJANGO_SETTINGS_MODULE`?
 Make sure that:
 
 * The environment variable :envvar:`DJANGO_SETTINGS_MODULE` is set to a
-  fully-qualified Python module (i.e. "mysite.settings").
+  fully-qualified Python module (i.e. ``mysite.settings``).
 
 * Said module is on ``sys.path`` (``import mysite.settings`` should work).
 

docs/howto/custom-management-commands.txt

@@ -287,7 +287,7 @@ the :meth:`~BaseCommand.handle` method must be implemented.
 
     Tries to execute this command, performing system checks if needed (as
     controlled by the :attr:`requires_system_checks` attribute). If the command
-    raises a :exc:`CommandError`, it's intercepted and printed to stderr.
+    raises a :exc:`CommandError`, it's intercepted and printed to ``stderr``.
 
 .. admonition:: Calling a management command in your code
 
@@ -305,7 +305,8 @@ the :meth:`~BaseCommand.handle` method must be implemented.
 
     Uses the system check framework to inspect the entire Django project for
     potential problems. Serious problems are raised as a :exc:`CommandError`;
-    warnings are output to stderr; minor notifications are output to stdout.
+    warnings are output to ``stderr``; minor notifications are output to
+    ``stdout``.
 
     If ``app_configs`` and ``tags`` are both ``None``, all system checks are
     performed. ``tags`` can be a list of check tags, like ``compatibility`` or
@@ -359,11 +360,11 @@ Exception class indicating a problem while executing a management command.
 
 If this exception is raised during the execution of a management command from a
 command line console, it will be caught and turned into a nicely-printed error
-message to the appropriate output stream (i.e., stderr); as a result, raising
-this exception (with a sensible description of the error) is the preferred way
-to indicate that something has gone wrong in the execution of a command. It
-accepts the optional ``returncode`` argument to customize the exit status for
-the management command to exit with, using :func:`sys.exit`.
+message to the appropriate output stream (i.e., ``stderr``); as a result,
+raising this exception (with a sensible description of the error) is the
+preferred way to indicate that something has gone wrong in the execution of a
+command. It accepts the optional ``returncode`` argument to customize the exit
+status for the management command to exit with, using :func:`sys.exit`.
 
 If a management command is called from code through
 :func:`~django.core.management.call_command`, it's up to you to catch the

docs/ref/contrib/gis/install/postgis.txt

@@ -11,10 +11,10 @@ The `psycopg2`_ module is required for use as the database adapter when using
 GeoDjango with PostGIS.
 
 On Debian/Ubuntu, you are advised to install the following packages:
-postgresql-x.x, postgresql-x.x-postgis, postgresql-server-dev-x.x,
-python-psycopg2 (x.x matching the PostgreSQL version you want to install).
-Alternately, you can `build from source`_. Consult the platform-specific
-instructions if you are on :ref:`macos` or :ref:`windows`.
+``postgresql-x.x``, ``postgresql-x.x-postgis``, ``postgresql-server-dev-x.x``,
+and ``python-psycopg2`` (x.x matching the PostgreSQL version you want to
+install). Alternately, you can `build from source`_. Consult the
+platform-specific instructions if you are on :ref:`macos` or :ref:`windows`.
 
 .. _PostGIS: https://postgis.net/
 .. _psycopg2: https://www.psycopg.org/

docs/releases/1.3.4.txt

@@ -20,7 +20,7 @@ as was reported to us recently. The Host header parsing in Django 1.3.3 and
 Django 1.4.1 -- specifically, ``django.http.HttpRequest.get_host()`` -- was
 incorrectly handling username/password information in the header. Thus, for
 example, the following Host header would be accepted by Django when running on
-"validsite.com"::
+``validsite.com``::
 
     Host: validsite.com:random@evilsite.com
 

docs/releases/1.4.2.txt

@@ -20,7 +20,7 @@ as was reported to us recently. The Host header parsing in Django 1.3.3 and
 Django 1.4.1 -- specifically, ``django.http.HttpRequest.get_host()`` -- was
 incorrectly handling username/password information in the header. Thus, for
 example, the following Host header would be accepted by Django when running on
-"validsite.com"::
+``validsite.com``::
 
     Host: validsite.com:random@evilsite.com
 

docs/releases/1.4.txt

@@ -167,7 +167,7 @@ You could import ``mysite.settings``, ``mysite.urls``, and ``mysite.myapp``,
 but not ``settings``, ``urls``, or ``myapp`` as top-level modules.
 
 Anything imported as a top-level module can be placed adjacent to the new
-``manage.py``. For instance, to decouple "myapp" from the project module and
+``manage.py``. For instance, to decouple ``myapp`` from the project module and
 import it as just ``myapp``, place it outside the ``mysite/`` directory::
 
     manage.py
@@ -1060,7 +1060,7 @@ Session cookies now have the ``httponly`` flag by default
 
 Session cookies now include the ``httponly`` attribute by default to
 help reduce the impact of potential XSS attacks. As a consequence of
-this change, session cookie data, including sessionid, is no longer
+this change, session cookie data, including ``sessionid``, is no longer
 accessible from JavaScript in many browsers. For strict backwards
 compatibility, use ``SESSION_COOKIE_HTTPONLY = False`` in your
 settings file.

docs/spelling_wordlist

@@ -20,7 +20,6 @@ args
 async
 atomicity
 auth
-autoclobber
 autocommit
 autocomplete
 autocompletion
@@ -305,8 +304,6 @@ multitenancy
 multithreaded
 multithreading
 multivalued
-myapp
-mysite
 mysql
 mysqlclient
 naïve
@@ -452,7 +449,6 @@ serializability
 serializable
 serializer
 serializers
-sessionid
 shapefile
 shapefiles
 sharding
@@ -469,9 +465,7 @@ stacktrace
 stateful
 staticfile
 staticfiles
-stderr
 stdlib
-stdout
 storages
 stylesheet
 stylesheets
@@ -590,7 +584,6 @@ Uvicorn
 uWSGI
 validator
 validators
-validsite
 variadic
 vendored
 virtualized

docs/topics/email.txt

@@ -664,7 +664,7 @@ and that those emails will contain the correct content.
 
 The easiest way to configure email for local development is to use the
 :ref:`console <topic-email-console-backend>` email backend. This backend
-redirects all email to stdout, allowing you to inspect the content of mail.
+redirects all email to ``stdout``, allowing you to inspect the content of mail.
 
 The :ref:`file <topic-email-file-backend>` email backend can also be useful
 during development -- this backend dumps the contents of every SMTP connection

docs/topics/testing/advanced.txt

@@ -812,7 +812,7 @@ can be useful during testing.
       approve destroying the existing database. ``sys.exit`` is
       called if the user does not approve.
 
-    * If autoclobber is ``True``, the database will be destroyed
+    * If ``autoclobber`` is ``True``, the database will be destroyed
       without consulting the user.
 
     ``serialize`` determines if Django serializes the database into an