Fixed #9497 - Doc typos. Many thanks ramiro.

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

docs/faq/admin.txt

@@ -31,7 +31,7 @@ allows access to users with those two fields both set to True.
 How can I prevent the cache middleware from caching the admin site?
 -------------------------------------------------------------------
 
-Set the :setting:``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting to ``True``. See the
+Set the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting to ``True``. See the
 :ref:`cache documentation <topics-cache>` for more information.
 
 How do I automatically set a field's value to the user who last edited the object in the admin?

docs/ref/contrib/databrowse.txt

@@ -35,7 +35,7 @@ How to use Databrowse
          more.
 
        * Otherwise, determine the full filesystem path to the
-         `:file:`django/contrib/databrowse/templates` directory, and add that
+         :file:`django/contrib/databrowse/templates` directory, and add that
          directory to your :setting:`TEMPLATE_DIRS` setting.
 
     2. Register a number of models with the Databrowse site::

docs/ref/contrib/sites.txt

@@ -207,7 +207,7 @@ In this case, you'd have to create :file:`subject.txt` and :file:`message.txt` t
 files for both the LJWorld.com and Lawrence.com template directories. That
 gives you more flexibility, but it's also more complex.
 
-It's a good idea to exploit the :class:`~django.contrib.sites.models.Site``
+It's a good idea to exploit the :class:`~django.contrib.sites.models.Site`
 objects as much as possible, to remove unneeded complexity and redundancy.
 
 Getting the current domain for full URLs

docs/ref/databases.txt

@@ -271,11 +271,11 @@ described above, this can be solved by downloading and installing a newer
 version of ``pysqlite2`` (``pysqlite-2.x.x.win32-py2.5.exe``) that includes and 
 uses a newer version of SQLite. Python 2.6 ships with a newer version of 
 SQLite and is not affected by this issue.
- 
-If you are in such platform and find yourself in the need to update 
-``pysqlite``/SQLite, you will also need to manually modify the 
-``django/db/backends/sqlite3/base.py`` file in the Django source tree so it 
-attempts to import ``pysqlite2`` before that ``sqlite3`` and so it can take 
+
+If you are in such platform and find yourself in the need to update
+``pysqlite``/SQLite, you will also need to manually modify the
+``django/db/backends/sqlite3/base.py`` file in the Django source tree so it
+attempts to import ``pysqlite2`` before than ``sqlite3`` and so it can take
 advantage of the new ``pysqlite2``/SQLite versions.
 
 .. _oracle-notes:

docs/ref/models/querysets.txt

@@ -35,7 +35,7 @@ You can evaluate a ``QuerySet`` in the following ways:
 
     * **Slicing.** As explained in :ref:`limiting-querysets`, a ``QuerySet`` can
       be sliced, using Python's array-slicing syntax. Usually slicing a
-      ``QuerySet`` returns another (unevaluated )``QuerySet``, but Django will
+      ``QuerySet`` returns another (unevaluated ) ``QuerySet``, but Django will
       execute the database query if you use the "step" parameter of slice
       syntax.
 
@@ -627,7 +627,7 @@ of the arguments is required, but you should use at least one of them.
     .. versionadded:: 1.0
 
     In some rare cases, you might wish to pass parameters to the SQL fragments
-    in ``extra(select=...)```. For this purpose, use the ``select_params``
+    in ``extra(select=...)``. For this purpose, use the ``select_params``
     parameter. Since ``select_params`` is a sequence and the ``select``
     attribute is a dictionary, some care is required so that the parameters
     are matched up correctly with the extra select pieces.  In this situation,

docs/ref/models/relations.txt

@@ -19,7 +19,7 @@ Extra methods on managers when used in a ForeignKey context
         >>> e = Entry.objects.get(id=234)
         >>> b.entry_set.add(e) # Associates Entry e with Blog b.
 
-.. method:: QuerySet.create(**kwargs)`
+.. method:: QuerySet.create(**kwargs)
 
     Creates a new object, saves it and puts it in the related object set.
     Returns the newly created object::
@@ -73,5 +73,5 @@ Extra methods on managers when used in a ForeignKey context
 
     Note this doesn't delete the related objects -- it just disassociates them.
 
-    Just like ``remove()``, ``clear()`` is only available on ``ForeignKey``s
+    Just like ``remove()``, ``clear()`` is only available on ``ForeignKey``\s
     where ``null=True``.

docs/ref/templates/api.txt

@@ -294,7 +294,7 @@ normal ``django.template.Context``. The first difference is that it takes an
     })
 
 The second difference is that it automatically populates the context with a few
-variables, according to your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting`.
+variables, according to your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting.
 
 The :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting is a tuple of callables --
 called **context processors** -- that take a request object as their argument
@@ -384,7 +384,7 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
 
     * ``LANGUAGES`` -- The value of the :setting:`LANGUAGES` setting.
     * ``LANGUAGE_CODE`` -- ``request.LANGUAGE_CODE``, if it exists. Otherwise,
-      the value of the :setting:`LANGUAGE_CODE` setting`.
+      the value of the :setting:`LANGUAGE_CODE` setting.
 
 See :ref:`topics-i18n` for more.
 

docs/topics/auth.txt

@@ -687,7 +687,7 @@ the following line to your URLconf::
           a query string, too.
 
         * ``site_name``: The name of the current
-          :class:`~django.contrib.sites.models.Site``, according to the
+          :class:`~django.contrib.sites.models.Site`, according to the
           :setting:`SITE_ID` setting. If you're using the Django development version
           and you don't have the site framework installed, this will be set to the
           value of ``request.META['SERVER_NAME']``. For more on sites, see 

docs/topics/http/file-uploads.txt

@@ -153,8 +153,8 @@ Three settings control Django's file upload behavior:
             ``0`` is very important: it indicates an octal number, which is the
             way that modes must be specified. If you try to use ``644``, you'll
             get totally incorrect behavior.
-            
-            **Always prefix the mode with a ``0``.**
+
+            **Always prefix the mode with a 0.**
 
     :setting:`FILE_UPLOAD_HANDLERS`
         The actual handlers for uploaded files. Changing this setting allows

docs/topics/http/urls.txt

@@ -50,7 +50,7 @@ algorithm the system follows to determine which Python code to execute:
     
     4. Once one of the regexes matches, Django imports and calls the given
        view, which is a simple Python function. The view gets passed an
-       :class:`~django.http.HttpRequest`` as its first argument and any values
+       :class:`~django.http.HttpRequest` as its first argument and any values
        captured in the regex as remaining arguments.
 
 Example

docs/topics/i18n.txt

@@ -298,7 +298,8 @@ Each ``RequestContext`` has access to three translation-specific variables:
       currently active locale).
 
     * ``LANGUAGE_CODE`` is the current user's preferred language, as a string.
-      Example: ``en-us``. (See "How language preference is discovered", below.)
+      Example: ``en-us``. (See :ref:`how-django-discovers-language-preference`,
+      below.)
 
     * ``LANGUAGE_BIDI`` is the current locale's direction. If True, it's a
       right-to-left language, e.g.: Hebrew, Arabic. If False it's a
@@ -514,7 +515,7 @@ A quick explanation:
       out empty, so it's your responsibility to change it. Make sure you keep
       the quotes around your translation.
     * As a convenience, each message includes, in the form of a comment line
-      prefixed with ``#`` and locted above the ``msgid`` line, the filename and
+      prefixed with ``#`` and located above the ``msgid`` line, the filename and
       line number from which the translation string was gleaned.
 
 Long messages are a special case. There, the first string directly after the
@@ -566,6 +567,8 @@ That's it. Your translations are ready for use.
    ``django-admin compilemessages`` works see `gettext on Windows`_ for more
    information.
 
+.. _how-django-discovers-language-preference:
+
 3. How Django discovers language preference
 ===========================================
 
@@ -783,7 +786,6 @@ project message file that are already in application message files.
 
 The easiest way out is to store applications that are not part of the project
 (and so carry their own translations) outside the project tree. That way,
-
 ``django-admin.py makemessages`` on the project level will only translate
 strings that are connected to your explicit project and not strings that are
 distributed independently.