1
0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00

Fixed #16014 -- numerous documentation typos -- thanks psmith.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16220 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Simon Meers
2011-05-13 04:33:42 +00:00
parent df6e031408
commit 5ecb88c146
27 changed files with 40 additions and 40 deletions

View File

@@ -396,7 +396,7 @@ developers of other reusable apps that want the same guarantees also use the
Settings
========
A number of settings can be used to control Django's CSRF behaviour.
A number of settings can be used to control Django's CSRF behavior.
CSRF_COOKIE_DOMAIN
------------------

View File

@@ -86,7 +86,7 @@ does all of the work.
.. versionchanged:: 1.4
Redirects by the middlware are permanent (301 status code) instead of
temporary (302) to match behaviour of the
temporary (302) to match behavior of the
:class:`~django.middleware.common.CommonMiddleware`.
If it doesn't find a match, the request continues to be processed as usual.

View File

@@ -361,6 +361,6 @@ considering aren't valid, we must remember to remove them from the
``cleaned_data``.
In fact, Django will currently completely wipe out the ``cleaned_data``
dictionary if there are any errors in the form. However, this behaviour may
dictionary if there are any errors in the form. However, this behavior may
change in the future, so it's not a bad idea to clean up after yourself in the
first place.

View File

@@ -986,7 +986,7 @@ locks on them.
Usually, if another transaction has already acquired a lock on one of the
selected rows, the query will block until the lock is released. If this is
not the behaviour you want, call ``select_for_update(nowait=True)``. This will
not the behavior you want, call ``select_for_update(nowait=True)``. This will
make the call non-blocking. If a conflicting lock is already acquired by
another transaction, ``django.db.utils.DatabaseError`` will be raised when
the queryset is evaluated.
@@ -1124,7 +1124,7 @@ If you have a field named ``defaults`` and want to use it as an exact lookup in
Foo.objects.get_or_create(defaults__exact='bar', defaults={'defaults': 'baz'})
The ``get_or_create()`` method has similar error behaviour to ``create()``
The ``get_or_create()`` method has similar error behavior to ``create()``
when you are using manually specified primary keys. If an object needs to be
created and the key already exists in the database, an ``IntegrityError`` will
be raised.