[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

django/contrib/gis/db/models/sql/conversion.py

@@ -22,6 +22,6 @@ class DistanceField(BaseField):
 class GeomField(BaseField):
     """
     Wrapper for Geometry values.  It is a lightweight alternative to 
-    using GeometryField (which requires a SQL query upon instantiation).
+    using GeometryField (which requires an SQL query upon instantiation).
     """
     pass

django/db/backends/__init__.py

@@ -698,7 +698,7 @@ class BaseDatabaseOperations(object):
 
     def cache_key_culling_sql(self):
         """
-        Returns a SQL query that retrieves the first cache key greater than the
+        Returns an SQL query that retrieves the first cache key greater than the
         n smallest.
 
         This is used by the 'db' cache backend to determine where to start
@@ -930,7 +930,7 @@ class BaseDatabaseOperations(object):
 
     def random_function_sql(self):
         """
-        Returns a SQL expression that returns a random value.
+        Returns an SQL expression that returns a random value.
         """
         return 'RANDOM()'
 

docs/internals/contributing/writing-documentation.txt

@@ -78,6 +78,10 @@ documentation:
 
 * **MySQL**, **PostgreSQL**, **SQLite**
 
+* **SQL** -- when referring to SQL, the expected pronunciation should be
+  "Ess Queue Ell" and not "sequel". Thus in a phrase like "Returns an
+  SQL expression", "SQL" should be preceded by "an" and not "a".
+
 * **Python** -- when referring to the language, capitalize Python.
 
 * **realize**, **customize**, **initialize**, etc. -- use the American

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,

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:
 

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.

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:

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.
 

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

docs/releases/1.4.4.txt

@@ -83,6 +83,6 @@ Other bugfixes and changes
 ==========================
 
 * Prevented transaction state from leaking from one request to the next (#19707).
-* Changed a SQL command syntax to be MySQL 4 compatible (#19702).
+* Changed an SQL command syntax to be MySQL 4 compatible (#19702).
 * Added backwards-compatibility with old unsalted MD5 passwords (#18144).
 * Numerous documentation improvements and fixes.

docs/topics/db/multi-db.txt

@@ -433,7 +433,7 @@ Consider the following example::
 
 In statement 1, a new ``Person`` object is saved to the ``first``
 database. At this time, ``p`` doesn't have a primary key, so Django
-issues a SQL ``INSERT`` statement. This creates a primary key, and
+issues an SQL ``INSERT`` statement. This creates a primary key, and
 Django assigns that primary key to ``p``.
 
 When the save occurs in statement 2, ``p`` already has a primary key
@@ -457,7 +457,7 @@ database::
     >>> p.save(using='second') # Write a completely new object.
 
 The second option is to use the ``force_insert`` option to ``save()``
-to ensure that Django does a SQL ``INSERT``::
+to ensure that Django does an SQL ``INSERT``::
 
     >>> p = Person(name='Fred')
     >>> p.save(using='first')

tests/backends/tests.py

@@ -402,7 +402,7 @@ class EscapingChecks(TestCase):
         self.assertEqual(cursor.fetchall()[0], ('%', '%d'))
 
     @unittest.skipUnless(connection.vendor == 'sqlite',
-                         "This is a sqlite-specific issue")
+                         "This is an sqlite-specific issue")
     def test_sqlite_parameter_escaping(self):
         #13648: '%s' escaping support for sqlite3
         cursor = connection.cursor()

tests/test_runner/tests.py

@@ -245,7 +245,7 @@ class Sqlite3InMemoryTestDbs(TestCase):
     available_apps = []
 
     @unittest.skipUnless(all(db.connections[conn].vendor == 'sqlite' for conn in db.connections),
-                         "This is a sqlite-specific issue")
+                         "This is an sqlite-specific issue")
     def test_transaction_support(self):
         """Ticket #16329: sqlite3 in-memory test databases"""
         old_db_connections = db.connections