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

3 files changed, 35 insertions, 69 deletions

diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index 7275393888..2aa967c88d 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/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 .
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index e205092177..4934b40a81 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/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
 
diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt
index 624489503e..885b8b34d5 100644
--- a/docs/internals/howto-release-django.txt
+++ b/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.