diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt
a
|
b
|
|
31 | 31 | How can I prevent the cache middleware from caching the admin site? |
32 | 32 | ------------------------------------------------------------------- |
33 | 33 | |
34 | | Set the :setting:``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting to ``True``. See the |
| 34 | Set the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting to ``True``. See the |
35 | 35 | :ref:`cache documentation <topics-cache>` for more information. |
36 | 36 | |
37 | 37 | How do I automatically set a field's value to the user who last edited the object in the admin? |
diff --git a/docs/ref/contrib/databrowse.txt b/docs/ref/contrib/databrowse.txt
a
|
b
|
|
35 | 35 | more. |
36 | 36 | |
37 | 37 | * Otherwise, determine the full filesystem path to the |
38 | | `:file:`django/contrib/databrowse/templates` directory, and add that |
| 38 | :file:`django/contrib/databrowse/templates` directory, and add that |
39 | 39 | directory to your :setting:`TEMPLATE_DIRS` setting. |
40 | 40 | |
41 | 41 | 2. Register a number of models with the Databrowse site:: |
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
a
|
b
|
|
207 | 207 | files for both the LJWorld.com and Lawrence.com template directories. That |
208 | 208 | gives you more flexibility, but it's also more complex. |
209 | 209 | |
210 | | It's a good idea to exploit the :class:`~django.contrib.sites.models.Site`` |
| 210 | It's a good idea to exploit the :class:`~django.contrib.sites.models.Site` |
211 | 211 | objects as much as possible, to remove unneeded complexity and redundancy. |
212 | 212 | |
213 | 213 | Getting the current domain for full URLs |
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
a
|
b
|
|
271 | 271 | version of ``pysqlite2`` (``pysqlite-2.x.x.win32-py2.5.exe``) that includes and |
272 | 272 | uses a newer version of SQLite. Python 2.6 ships with a newer version of |
273 | 273 | SQLite and is not affected by this issue. |
274 | | |
275 | | If you are in such platform and find yourself in the need to update |
276 | | ``pysqlite``/SQLite, you will also need to manually modify the |
277 | | ``django/db/backends/sqlite3/base.py`` file in the Django source tree so it |
278 | | attempts to import ``pysqlite2`` before that ``sqlite3`` and so it can take |
| 274 | |
| 275 | If you are in such platform and find yourself in the need to update |
| 276 | ``pysqlite``/SQLite, you will also need to manually modify the |
| 277 | ``django/db/backends/sqlite3/base.py`` file in the Django source tree so it |
| 278 | attempts to import ``pysqlite2`` before than ``sqlite3`` and so it can take |
279 | 279 | advantage of the new ``pysqlite2``/SQLite versions. |
280 | 280 | |
281 | 281 | .. _oracle-notes: |
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
a
|
b
|
|
35 | 35 | |
36 | 36 | * **Slicing.** As explained in :ref:`limiting-querysets`, a ``QuerySet`` can |
37 | 37 | be sliced, using Python's array-slicing syntax. Usually slicing a |
38 | | ``QuerySet`` returns another (unevaluated )``QuerySet``, but Django will |
| 38 | ``QuerySet`` returns another (unevaluated ) ``QuerySet``, but Django will |
39 | 39 | execute the database query if you use the "step" parameter of slice |
40 | 40 | syntax. |
41 | 41 | |
… |
… |
|
627 | 627 | .. versionadded:: 1.0 |
628 | 628 | |
629 | 629 | In some rare cases, you might wish to pass parameters to the SQL fragments |
630 | | in ``extra(select=...)```. For this purpose, use the ``select_params`` |
| 630 | in ``extra(select=...)``. For this purpose, use the ``select_params`` |
631 | 631 | parameter. Since ``select_params`` is a sequence and the ``select`` |
632 | 632 | attribute is a dictionary, some care is required so that the parameters |
633 | 633 | are matched up correctly with the extra select pieces. In this situation, |
diff --git a/docs/ref/models/relations.txt b/docs/ref/models/relations.txt
a
|
b
|
|
19 | 19 | >>> e = Entry.objects.get(id=234) |
20 | 20 | >>> b.entry_set.add(e) # Associates Entry e with Blog b. |
21 | 21 | |
22 | | .. method:: QuerySet.create(**kwargs)` |
| 22 | .. method:: QuerySet.create(**kwargs) |
23 | 23 | |
24 | 24 | Creates a new object, saves it and puts it in the related object set. |
25 | 25 | Returns the newly created object:: |
… |
… |
|
73 | 73 | |
74 | 74 | Note this doesn't delete the related objects -- it just disassociates them. |
75 | 75 | |
76 | | Just like ``remove()``, ``clear()`` is only available on ``ForeignKey``s |
| 76 | Just like ``remove()``, ``clear()`` is only available on ``ForeignKey``\s |
77 | 77 | where ``null=True``. |
diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
a
|
b
|
|
294 | 294 | }) |
295 | 295 | |
296 | 296 | The second difference is that it automatically populates the context with a few |
297 | | variables, according to your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting`. |
| 297 | variables, according to your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting. |
298 | 298 | |
299 | 299 | The :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting is a tuple of callables -- |
300 | 300 | called **context processors** -- that take a request object as their argument |
… |
… |
|
384 | 384 | |
385 | 385 | * ``LANGUAGES`` -- The value of the :setting:`LANGUAGES` setting. |
386 | 386 | * ``LANGUAGE_CODE`` -- ``request.LANGUAGE_CODE``, if it exists. Otherwise, |
387 | | the value of the :setting:`LANGUAGE_CODE` setting`. |
| 387 | the value of the :setting:`LANGUAGE_CODE` setting. |
388 | 388 | |
389 | 389 | See :ref:`topics-i18n` for more. |
390 | 390 | |
diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
a
|
b
|
|
687 | 687 | a query string, too. |
688 | 688 | |
689 | 689 | * ``site_name``: The name of the current |
690 | | :class:`~django.contrib.sites.models.Site``, according to the |
| 690 | :class:`~django.contrib.sites.models.Site`, according to the |
691 | 691 | :setting:`SITE_ID` setting. If you're using the Django development version |
692 | 692 | and you don't have the site framework installed, this will be set to the |
693 | 693 | value of ``request.META['SERVER_NAME']``. For more on sites, see |
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
a
|
b
|
|
153 | 153 | ``0`` is very important: it indicates an octal number, which is the |
154 | 154 | way that modes must be specified. If you try to use ``644``, you'll |
155 | 155 | get totally incorrect behavior. |
156 | | |
157 | | **Always prefix the mode with a ``0``.** |
| 156 | |
| 157 | **Always prefix the mode with a 0.** |
158 | 158 | |
159 | 159 | :setting:`FILE_UPLOAD_HANDLERS` |
160 | 160 | The actual handlers for uploaded files. Changing this setting allows |
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
a
|
b
|
|
50 | 50 | |
51 | 51 | 4. Once one of the regexes matches, Django imports and calls the given |
52 | 52 | view, which is a simple Python function. The view gets passed an |
53 | | :class:`~django.http.HttpRequest`` as its first argument and any values |
| 53 | :class:`~django.http.HttpRequest` as its first argument and any values |
54 | 54 | captured in the regex as remaining arguments. |
55 | 55 | |
56 | 56 | Example |
diff --git a/docs/topics/i18n.txt b/docs/topics/i18n.txt
a
|
b
|
|
298 | 298 | currently active locale). |
299 | 299 | |
300 | 300 | * ``LANGUAGE_CODE`` is the current user's preferred language, as a string. |
301 | | Example: ``en-us``. (See "How language preference is discovered", below.) |
| 301 | Example: ``en-us``. (See :ref:`how-django-discovers-language-preference`, |
| 302 | below.) |
302 | 303 | |
303 | 304 | * ``LANGUAGE_BIDI`` is the current locale's direction. If True, it's a |
304 | 305 | right-to-left language, e.g.: Hebrew, Arabic. If False it's a |
… |
… |
|
514 | 515 | out empty, so it's your responsibility to change it. Make sure you keep |
515 | 516 | the quotes around your translation. |
516 | 517 | * As a convenience, each message includes, in the form of a comment line |
517 | | prefixed with ``#`` and locted above the ``msgid`` line, the filename and |
| 518 | prefixed with ``#`` and located above the ``msgid`` line, the filename and |
518 | 519 | line number from which the translation string was gleaned. |
519 | 520 | |
520 | 521 | Long messages are a special case. There, the first string directly after the |
… |
… |
|
565 | 566 | If you're using Windows and need to install the GNU gettext utilities so |
566 | 567 | ``django-admin compilemessages`` works see `gettext on Windows`_ for more |
567 | 568 | information. |
| 569 | |
| 570 | .. _how-django-discovers-language-preference: |
568 | 571 | |
569 | 572 | 3. How Django discovers language preference |
570 | 573 | =========================================== |
… |
… |
|
783 | 786 | |
784 | 787 | The easiest way out is to store applications that are not part of the project |
785 | 788 | (and so carry their own translations) outside the project tree. That way, |
786 | | |
787 | 789 | ``django-admin.py makemessages`` on the project level will only translate |
788 | 790 | strings that are connected to your explicit project and not strings that are |
789 | 791 | distributed independently. |