Fixed #24358 -- Corrected code-block directives for console sessions.

docs/howto/deployment/wsgi/uwsgi.txt

@@ -24,7 +24,7 @@ The uWSGI wiki describes several `installation procedures`_. Using pip, the
 Python package manager, you can install any uWSGI version with a single
 command. For example:
 
-.. code-block:: bash
+.. code-block:: console
 
     # Install current stable version.
     $ pip install uwsgi

docs/howto/outputting-pdf.txt

@@ -24,7 +24,7 @@ The ReportLab library is `available on PyPI`_. A `user guide`_ (not
 coincidentally, a PDF file) is also available for download.
 You can install ReportLab with ``pip``:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ pip install reportlab
 

docs/howto/upgrade-version.txt

@@ -52,7 +52,7 @@ might want to set up a new environment with all the dependencies first.
 Exactly which steps you will need to take depends on your installation process.
 The most convenient way is to use pip_ with the ``--upgrade`` or ``-U`` flag:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ pip install -U Django
 
@@ -74,7 +74,7 @@ warnings are silenced by default. It is useful to turn the warnings on so they
 are shown in the test output (you can also use the flag if you test your app
 manually using ``manage.py runserver``):
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python -Wall manage.py test
 

docs/internals/contributing/writing-code/coding-style.txt

@@ -48,7 +48,7 @@ Imports
 
   Quick start:
 
-  .. code-block:: bash
+  .. code-block:: console
 
       $ pip install isort
       $ isort -rc .

docs/internals/contributing/writing-code/unit-tests.txt

@@ -2,6 +2,8 @@
 Unit tests
 ==========
 
+.. highlight:: console
+
 Django comes with a test suite of its own, in the ``tests`` directory of the
 code base. It's our policy to make sure all tests pass at all times.
 
@@ -26,9 +28,7 @@ the other optional test dependencies.
 
 Running the tests requires a Django settings module that defines the
 databases to use. To make it easy to get started, Django provides and uses a
-sample settings module that uses the SQLite database. To run the tests:
-
-.. code-block:: bash
+sample settings module that uses the SQLite database. To run the tests::
 
    $ git clone https://github.com/django/django.git django-repo
    $ cd django-repo/tests
@@ -96,9 +96,7 @@ tests by appending the names of the test modules to ``runtests.py`` on the
 command line.
 
 For example, if you'd like to run tests only for generic relations and
-internationalization, type:
-
-.. code-block:: bash
+internationalization, type::
 
    $ ./runtests.py --settings=path.to.settings generic_relations i18n
 
@@ -107,15 +105,11 @@ directory name there is the name of a test.
 
 If you just want to run a particular class of tests, you can specify a list of
 paths to individual test classes. For example, to run the ``TranslationTests``
-of the ``i18n`` module, type:
-
-.. code-block:: bash
+of the ``i18n`` module, type::
 
    $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
 
-Going beyond that, you can specify an individual test method like this:
-
-.. code-block:: bash
+Going beyond that, you can specify an individual test method like this::
 
    $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
 
@@ -125,9 +119,7 @@ Running the Selenium tests
 Some tests require Selenium and a Web browser (Firefox, Google Chrome, or
 Internet Explorer). To allow those tests to be run rather than skipped, you must
 install the selenium_ package into your Python path and run the tests with the
-``--selenium`` option:
-
-.. code-block:: bash
+``--selenium`` option::
 
    $ ./runtests.py --settings=test_sqlite --selenium admin_inlines
 
@@ -154,9 +146,7 @@ dependencies:
 
 You can find these dependencies in `pip requirements files`_ inside the
 ``tests/requirements`` directory of the Django source tree and install them
-like so:
-
-.. code-block:: bash
+like so::
 
    $ pip install -r tests/requirements/py3.txt  # Python 2: py2.txt
 
@@ -193,15 +183,11 @@ Contributors are encouraged to run coverage on the test suite to identify areas
 that need additional tests. The coverage tool installation and use is described
 in :ref:`testing code coverage<topics-testing-code-coverage>`.
 
-To run coverage on the Django test suite using the standard test settings:
-
-.. code-block:: bash
+To run coverage on the Django test suite using the standard test settings::
 
    $ coverage run ./runtests.py --settings=test_sqlite
 
-After running coverage, generate the html report by running:
-
-.. code-block:: bash
+After running coverage, generate the html report by running::
 
    $ coverage html
 
@@ -230,9 +216,7 @@ Many test failures with ``UnicodeEncodeError``
 If the ``locales`` package is not installed, some tests will fail with a
 ``UnicodeEncodeError``.
 
-You can resolve this on Debian-based systems, for example, by running:
-
-.. code-block:: bash
+You can resolve this on Debian-based systems, for example, by running::
 
     $ apt-get install locales
     $ dpkg-reconfigure locales
@@ -249,9 +233,7 @@ it possible to identify a small number of tests that may be related to the
 failure.
 
 For example, suppose that the failing test that works on its own is
-``ModelTest.test_eq``, then using:
-
-.. code-block:: bash
+``ModelTest.test_eq``, then using::
 
     $ ./runtests.py --bisect basic.tests.ModelTest.test_eq
 
@@ -265,9 +247,7 @@ failing tests is minimized.
 
 The ``--pair`` option runs the given test alongside every other test from the
 suite, letting you check if another test has side-effects that cause the
-failure. So:
-
-.. code-block:: bash
+failure. So::
 
     $ ./runtests.py --pair basic.tests.ModelTest.test_eq
 
@@ -276,25 +256,19 @@ will pair ``test_eq`` with every test label.
 With both ``--bisect`` and ``--pair``, if you already suspect which cases
 might be responsible for the failure, you may limit tests to be cross-analyzed
 by :ref:`specifying further test labels <runtests-specifying-labels>` after
-the first one:
-
-.. code-block:: bash
+the first one::
 
     $ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions
 
 You can also try running any set of tests in reverse using the ``--reverse``
 option in order to verify that executing tests in a different order does not
-cause any trouble:
-
-.. code-block:: bash
+cause any trouble::
 
     $ ./runtests.py basic --reverse
 
 If you wish to examine the SQL being run in failing tests, you can turn on
 :ref:`SQL logging <django-db-logger>` using the ``--debug-sql`` option. If you
-combine this with ``--verbosity=2``, all SQL queries will be output.
-
-.. code-block:: bash
+combine this with ``--verbosity=2``, all SQL queries will be output::
 
     $ ./runtests.py basic --debug-sql
 

docs/internals/howto-release-django.txt

@@ -2,6 +2,8 @@
 How is Django Formed?
 =====================
 
+.. highlight:: console
+
 This document explains how to release Django.
 
 **Please, keep these instructions up-to-date if you make changes!** The point
@@ -54,9 +56,7 @@ You'll need a few things before getting started:
   ``you@example.com`` is the email address associated with the key you want to
   use.
 
-* An install of some required Python packages:
-
-  .. code-block:: bash
+* An install of some required Python packages::
 
       $ pip install wheel twine
 
@@ -117,7 +117,7 @@ any time leading up to the actual release:
    rather than the releaser, but here are the steps. Provided you have an
    account on Transifex::
 
-        python scripts/manage_translations.py fetch
+        $ python scripts/manage_translations.py fetch
 
    and then commit the changed/added files (both .po and .mo). Sometimes there
    are validation errors which need to be debugged, so avoid doing this task
@@ -148,16 +148,16 @@ OK, this is the fun part, where we actually push out a release!
 #. A release always begins from a release branch, so you should make sure
    you're on a stable branch and up-to-date. For example::
 
-        git checkout stable/1.5.x
-        git pull
+        $ git checkout stable/1.5.x
+        $ git pull
 
 #. If this is a security release, merge the appropriate patches from
    ``django-private``. Rebase these patches as necessary to make each one a
    simple commit on the release branch rather than a merge commit. To ensure
    this, merge them with the ``--ff-only`` flag; for example::
 
-        git checkout stable/1.5.x
-        git merge --ff-only security/1.5.x
+        $ git checkout stable/1.5.x
+        $ git merge --ff-only security/1.5.x
 
    (This assumes ``security/1.5.x`` is a branch in the ``django-private`` repo
    containing the necessary security patches for the next release in the 1.5
@@ -193,7 +193,7 @@ OK, this is the fun part, where we actually push out a release!
 
 #. Tag the release using ``git tag``. For example::
 
-        git tag --sign --message="Tag 1.5.1" 1.5.1
+        $ git tag --sign --message="Tag 1.5.1" 1.5.1
 
    You can check your work by running ``git tag --verify <tag>``.
 
@@ -205,9 +205,7 @@ OK, this is the fun part, where we actually push out a release!
    create the release packages in a ``dist/`` directory. Note that we don't
    publish wheel files for 1.4.
 
-#. Generate the hashes of the release packages:
-
-   .. code-block:: bash
+#. Generate the hashes of the release packages::
 
         $ cd dist
         $ md5sum *
@@ -217,7 +215,9 @@ OK, this is the fun part, where we actually push out a release!
 #. Create a "checksums" file, ``Django-<<VERSION>>.checksum.txt`` containing
    the hashes and release information. Start with this template and insert the
    correct version, date, GPG key ID (from
-   ``gpg --list-keys --keyid-format LONG``), release URL, and checksums::
+   ``gpg --list-keys --keyid-format LONG``), release URL, and checksums:
+
+   .. code-block:: text
 
     This file contains MD5, SHA1, and SHA256 checksums for the source-code
     tarball of Django <<VERSION>>, released <<DATE>>.
@@ -276,22 +276,16 @@ Making the release(s) available to the public
 Now you're ready to actually put the release out there. To do this:
 
 #. Upload the release package(s) to the djangoproject server, replacing
-   A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release:
-
-   .. code-block:: bash
+   A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release::
 
         $ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
 
-#. Upload the checksum file(s):
-
-   .. code-block:: bash
+#. Upload the checksum file(s)::
 
         $ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt
 
 #. Test that the release packages install correctly using ``easy_install``
-   and ``pip``. Here's one method (which requires `virtualenvwrapper`__):
-
-   .. code-block:: bash
+   and ``pip``. Here's one method (which requires `virtualenvwrapper`__)::
 
         $ RELEASE_VERSION='1.7.2'
         $ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3`
@@ -318,9 +312,7 @@ Now you're ready to actually put the release out there. To do this:
    correct (proper version numbers, no stray ``.pyc`` or other undesirable
    files).
 
-#. Upload the release packages to PyPI:
-
-   .. code-block:: bash
+#. Upload the release packages to PyPI::
 
        $ twine upload -s dist/*
 
@@ -334,7 +326,7 @@ Now you're ready to actually put the release out there. To do this:
 #. Make the blog post announcing the release live.
 
 #. For a new version release (e.g. 1.5, 1.6), update the default stable version
-   of the docs by flipping the ``is_default`` flag to ``True`` on the
+   of the docs by flipping the ``is_default`` flag to `deployment/wsgi/uwsgi.html`True`` on the
    appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com``
    database (this will automatically flip it to ``False`` for all
    others); you can do this using the site's admin.

docs/intro/overview.txt

@@ -51,7 +51,7 @@ Install it
 Next, run the Django command-line utility to create the database tables
 automatically:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py migrate