Fixed grammar and tweaked notes about MySQL database/table collation interaction with text fields. Refs #14417.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14779 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/ref/databases.txt

@@ -227,18 +227,19 @@ non-unique) with the default collation.
 In many cases, this default will not be a problem. However, if you really want
 case-sensitive comparisons on a particular column or table, you would change
 the column or table to use the ``utf8_bin`` collation. The main thing to be
-aware of in this case is that if you are using MySQLdb 1.2.2, the database backend in Django will then return
+aware of in this case is that if you are using MySQLdb 1.2.2, the database
-bytestrings (instead of unicode strings) for any character fields it returns
+backend in Django will then return bytestrings (instead of unicode strings) for
-receive from the database. This is a strong variation from Django's normal
+any character fields it receive from the database. This is a strong variation
-practice of *always* returning unicode strings. It is up to you, the
+from Django's normal practice of *always* returning unicode strings. It is up
-developer, to handle the fact that you will receive bytestrings if you
+to you, the developer, to handle the fact that you will receive bytestrings if
-configure your table(s) to use ``utf8_bin`` collation. Django itself should work
+you configure your table(s) to use ``utf8_bin`` collation. Django itself should
-smoothly with such columns, but if your code must be prepared to call
+mostly work smoothly with such columns (except for the ``contrib.sessions``
-``django.utils.encoding.smart_unicode()`` at times if it really wants to work
+``Session`` and ``contrib.admin`` ``LogEntry`` tables described below), but
-with consistent data -- Django will not do this for you (the database backend
+your code must be prepared to call ``django.utils.encoding.smart_unicode()`` at
-layer and the model population layer are separated internally so the database
+times if it really wants to work with consistent data -- Django will not do
-layer doesn't know it needs to make this conversion in this one particular
+this for you (the database backend layer and the model population layer are
-case).
+separated internally so the database layer doesn't know it needs to make this
+conversion in this one particular case).
 
 If you're using MySQLdb 1.2.1p2, Django's standard
 :class:`~django.db.models.CharField` class will return unicode strings even
@@ -249,11 +250,12 @@ the information needed to make the necessary conversions isn't available when
 the data is read in from the database. This problem was `fixed in MySQLdb
 1.2.2`_, so if you want to use :class:`~django.db.models.TextField` with
 ``utf8_bin`` collation, upgrading to version 1.2.2 and then dealing with the
-bytestrings (which shouldn't be too difficult) is the recommended solution.
+bytestrings (which shouldn't be too difficult) as described above is the
+recommended solution.
 
 Should you decide to use ``utf8_bin`` collation for some of your tables with
-MySQLdb 1.2.1p2, you should still use ``utf8_collation_ci_swedish`` (the
+MySQLdb 1.2.1p2 or 1.2.2, you should still use ``utf8_collation_ci_swedish``
-default) collation for the :class:`django.contrib.sessions.models.Session`
+(the default) collation for the :class:`django.contrib.sessions.models.Session`
 table (usually called ``django_session``) and the
 :class:`django.contrib.admin.models.LogEntry` table (usually called
 ``django_admin_log``). Those are the two standard tables that use