[1.6.x] Fixed #21035 -- Changed docs to treat the acronym SQL phonetically.

The documentation and comments now all use 'an' to
refer to the word SQL and not 'a'.

Backport of 4d13cc56de from master

6 files changed, 7 insertions, 7 deletions

diff --git a/docs/ref/contrib/gis/testing.txt b/docs/ref/contrib/gis/testing.txt
index fca6675345..0e1a98d64d 100644
--- a/docs/ref/contrib/gis/testing.txt
+++ b/docs/ref/contrib/gis/testing.txt
@@ -33,7 +33,7 @@ database to use. It automatically defaults to ``'template_postgis'``
 ^^^^^^^^^^^^^^^^^^^
 
 When GeoDjango's spatial backend initializes on PostGIS, it has to perform
-a SQL query to determine the version in order to figure out what
+an SQL query to determine the version in order to figure out what
 features are available. Advanced users wishing to prevent this additional
 query may set the version manually using a 3-tuple of integers specifying
 the major, minor, and subminor version numbers for PostGIS. For example,
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index 29f2f3972d..ff88c24386 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -639,7 +639,7 @@ Parameters not quoted in ``connection.queries``
 ``sqlite3`` does not provide a way to retrieve the SQL after quoting and
 substituting the parameters. Instead, the SQL in ``connection.queries`` is
 rebuilt with a simple string interpolation. It may be incorrect. Make sure
-you add quotes where necessary before copying a query into a SQLite shell.
+you add quotes where necessary before copying a query into an SQLite shell.
 
 .. _oracle-notes:
 
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index 9e3d6bc438..bd17adfa99 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -1515,7 +1515,7 @@ number of roles in which color is used:
 * ``notice`` - A minor error.
 * ``sql_field`` - The name of a model field in SQL.
 * ``sql_coltype`` - The type of a model field in SQL.
-* ``sql_keyword`` - A SQL keyword.
+* ``sql_keyword`` - An SQL keyword.
 * ``sql_table`` - The name of a model in SQL.
 * ``http_info`` - A 1XX HTTP Informational server response.
 * ``http_success`` - A 2XX HTTP Success server response.
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index fe83b54e1c..ad812f6504 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -1177,7 +1177,7 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
 
     Take no action. If your database backend enforces referential
     integrity, this will cause an :exc:`~django.db.IntegrityError` unless
-    you manually add a SQL ``ON DELETE`` constraint to the database field
+    you manually add an SQL ``ON DELETE`` constraint to the database field
     (perhaps using :ref:`initial sql<initial-sql>`).
 
 .. _ref-manytomany:
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index ce943f141d..d5863ec529 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -419,7 +419,7 @@ Deleting objects
 
 .. method:: Model.delete([using=DEFAULT_DB_ALIAS])
 
-Issues a SQL ``DELETE`` for the object. This only deletes the object in the
+Issues an SQL ``DELETE`` for the object. This only deletes the object in the
 database; the Python instance will still exist and will still have data in
 its fields.
 
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index fec059a1be..c5b835f55f 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -820,7 +820,7 @@ This has a similar purpose to ``select_related``, in that both are designed to
 stop the deluge of database queries that is caused by accessing related objects,
 but the strategy is quite different.
 
-``select_related`` works by creating a SQL join and including the fields of the
+``select_related`` works by creating an SQL join and including the fields of the
 related object in the ``SELECT`` statement. For this reason, ``select_related``
 gets the related objects in the same database query. However, to avoid the much
 larger result set that would result from joining across a 'many' relationship,
@@ -950,7 +950,7 @@ referenced is needed, rather than one query for all the items. There could be
 additional queries on the ``ContentType`` table if the relevant rows have not
 already been fetched.
 
-``prefetch_related`` in most cases will be implemented using a SQL query that
+``prefetch_related`` in most cases will be implemented using an SQL query that
 uses the 'IN' operator. This means that for a large ``QuerySet`` a large 'IN' clause
 could be generated, which, depending on the database, might have performance
 problems of its own when it comes to parsing or executing the SQL query. Always