Doc edits for refs #22487.

docs/ref/migration-operations.txt

@@ -239,7 +239,7 @@ set ``atomic=False``.
 
 .. warning::
 
-    RunPython does not magically alter the connection of the models for you;
+    ``RunPython`` does not magically alter the connection of the models for you;
     any model methods you call will go to the default database unless you
     give them the current database alias (available from
     ``schema_editor.connection.alias``, where ``schema_editor`` is the second

docs/ref/settings.txt

@@ -2083,17 +2083,19 @@ The name of the class to use for starting the test suite. See
 TEST_NON_SERIALIZED_APPS
 ------------------------
 
+.. versionadded:: 1.7
+
 Default: ``[]``
 
-In order to restore the database state between tests for TransactionTestCases
+In order to restore the database state between tests for
-and database backends without transactions, Django will :ref:`serialize the
+``TransactionTestCase``\s and database backends without transactions, Django
-contents of all apps with migrations <test-case-serialized-rollback>` when it
+will :ref:`serialize the contents of all apps with migrations
-starts the test run so it can then reload from that copy before tests that
+<test-case-serialized-rollback>` when it starts the test run so it can then
-need it.
+reload from that copy before tests that need it.
 
 This slows down the startup time of the test runner; if you have apps that
 you know don't need this feature, you can add their full names in here (e.g.
-``django.contrib.contenttypes``) to exclude them from this serialization
+``'django.contrib.contenttypes'``) to exclude them from this serialization
 process.
 
 .. setting:: THOUSAND_SEPARATOR
@@ -3001,6 +3003,7 @@ Templates
 Testing
 -------
 * Database: :setting:`TEST <DATABASE-TEST>`
+* :setting:`TEST_NON_SERIALIZED_APPS`
 * :setting:`TEST_RUNNER`
 
 URLs

docs/releases/1.7.txt

@@ -63,9 +63,10 @@ but a few of the key features are:
 * ``initial_data`` fixtures are no longer loaded for apps with migrations; if
   you want to load initial data for an app, we suggest you do it in a migration.
 
-* Test rollback behaviour is different for apps with migrations; in particular,
+* Test rollback behavior is different for apps with migrations; in particular,
   Django will no longer emulate rollbacks on non-transactional databases or
-  inside ``TransactionTestCase`` :ref:`unless specifically asked <test-case-serialized-rollback>`.
+  inside ``TransactionTestCase`` :ref:`unless specifically requested
+  <test-case-serialized-rollback>`.
 
 App-loading refactor
 ~~~~~~~~~~~~~~~~~~~~

docs/spelling_wordlist

@@ -637,6 +637,8 @@ ubuntu
 Ubuntuusers
 ul
 umask
+unassigning
+unapplied
 unapply
 unapplying
 uncheck

docs/topics/testing/advanced.txt

@@ -505,7 +505,7 @@ can be useful during testing.
     in-memory JSON string before running tests (used to restore the database
     state between tests if you don't have transactions). You can set this to
     False to significantly speed up creation time if you know you don't need
-    data persistance outside of test fixtures.
+    data persistence outside of test fixtures.
 
     ``keepdb`` determines if the test run should use an existing
     database, or create a new one. If ``True``, the existing

docs/topics/testing/overview.txt

@@ -244,7 +244,7 @@ tests and not in ``TransactionTestCase`` tests, and additionally only on
 backends where transactions are supported (the most important exception being
 MyISAM).
 
-Django can re-load that data for you on a per-testcase basis by
+Django can reload that data for you on a per-testcase basis by
 setting the ``serialized_rollback`` option to ``True`` in the body of the
 ``TestCase`` or ``TransactionTestCase``, but note that this will slow down
 that test suite by approximately 3x.
@@ -276,7 +276,6 @@ used. This behavior `may change`_ in the future.
 
 .. _may change: https://code.djangoproject.com/ticket/11505
 
-
 Understanding the test output
 -----------------------------