[1.5.x] Fixed typos in docs and comments

Backport of ee26797cff from master

7 files changed, 11 insertions, 8 deletions

diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 67dda02f8b..bc2f97a485 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -116,7 +116,7 @@ Practicality beats purity, so it is up to each committer to decide how much
 history mangling to do for a pull request. The main points are engaging the
 community, getting work done, and having a usable commit history.
 
-.. _committing-guidlines:
+.. _committing-guidelines:
 
 Committing guidelines
 ---------------------
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index d4a95ae45a..dcfdd9e85b 100644
--- a/docs/internals/contributing/writing-code/working-with-git.txt
+++ b/docs/internals/contributing/writing-code/working-with-git.txt
@@ -81,7 +81,7 @@ commit them::
     git commit
 
 When writing the commit message, follow the :ref:`commit message
-guidelines <committing-guidlines>` to ease the work of the committer. If
+guidelines <committing-guidelines>` to ease the work of the committer. If
 you're uncomfortable with English, try at least to describe precisely what the
 commit does.
 
@@ -121,7 +121,7 @@ a pull request at GitHub. A good pull request means:
 
 * well-formed messages for each commit: a summary line and then paragraphs
   wrapped at 72 characters thereafter -- see the :ref:`committing guidelines
-  <committing-guidlines>` for more details,
+  <committing-guidelines>` for more details,
 
 * documentation and tests, if needed -- actually tests are always needed,
   except for documentation changes.
diff --git a/docs/intro/overview.txt b/docs/intro/overview.txt
index 7cca8bf51b..4f3cd47310 100644
--- a/docs/intro/overview.txt
+++ b/docs/intro/overview.txt
@@ -56,7 +56,9 @@ Enjoy the free API
 ==================
 
 With that, you've got a free, and rich, :doc:`Python API </topics/db/queries>` to
-access your data. The API is created on the fly, no code generation necessary::
+access your data. The API is created on the fly, no code generation necessary:
+
+.. code-block:: python
 
     # Import the models we created from our "news" app
     >>> from news.models import Reporter, Article
diff --git a/docs/misc/api-stability.txt b/docs/misc/api-stability.txt
index 70e6006575..9bd2258a73 100644
--- a/docs/misc/api-stability.txt
+++ b/docs/misc/api-stability.txt
@@ -118,7 +118,8 @@ Security fixes
 
 If we become aware of a security problem -- hopefully by someone following our
 :ref:`security reporting policy <reporting-security-issues>` -- we'll do
-everything necessary to fix it. This might mean breaking backwards compatibility; security trumps the compatibility guarantee.
+everything necessary to fix it. This might mean breaking backwards
+compatibility; security trumps the compatibility guarantee.
 
 Contributed applications (``django.contrib``)
 ---------------------------------------------
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index 757b387d78..1414f19e48 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -840,7 +840,7 @@ subclass::
     added last after all editable fields.
 
     A read-only field can not only display data from a model's field, it can
-    also display the output of a a model's method or a method of the
+    also display the output of a model's method or a method of the
     ``ModelAdmin`` class itself. This is very similar to the way
     :attr:`ModelAdmin.list_display` behaves. This provides an easy way to use
     the admin interface to provide feedback on the status of the objects being
diff --git a/docs/ref/contrib/gis/install/index.txt b/docs/ref/contrib/gis/install/index.txt
index 35c01c9b7e..2987539f33 100644
--- a/docs/ref/contrib/gis/install/index.txt
+++ b/docs/ref/contrib/gis/install/index.txt
@@ -330,7 +330,7 @@ described above, ``psycopg2`` may be installed using the following command::
 
 .. note::
 
-    If you don't have ``pip``, follow the the :ref:`installation instructions
+    If you don't have ``pip``, follow the :ref:`installation instructions
     <installing-official-release>` to install it.
 
 .. _fink:
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index 12e8fc7d76..6847080c1c 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -82,7 +82,7 @@ Changing passwords
 Django does not store raw (clear text) passwords on the user model, but only
 a hash (see :doc:`documentation of how passwords are managed
 </topics/auth/passwords>` for full details). Because of this, do not attempt to
-manipulate the password attribute of the user directly. This is why a a helper
+manipulate the password attribute of the user directly. This is why a helper
 function is used when creating a user.
 
 To change a user's password, you have several options: