diff options
| author | Simon Meers <simon@simonmeers.com> | 2011-05-13 04:33:42 +0000 |
|---|---|---|
| committer | Simon Meers <simon@simonmeers.com> | 2011-05-13 04:33:42 +0000 |
| commit | 5ecb88c146c7b4d1adb046d65c43a0b75283c03d (patch) | |
| tree | 255fc1861880cdfaf28912041e645747c7de99a4 /docs/ref | |
| parent | df6e0314080afcd6a96c3769807991d52072b2a1 (diff) | |
Fixed #16014 -- numerous documentation typos -- thanks psmith.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16220 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs/ref')
| -rw-r--r-- | docs/ref/contrib/csrf.txt | 2 | ||||
| -rw-r--r-- | docs/ref/contrib/flatpages.txt | 2 | ||||
| -rw-r--r-- | docs/ref/forms/validation.txt | 2 | ||||
| -rw-r--r-- | docs/ref/models/querysets.txt | 4 |
4 files changed, 5 insertions, 5 deletions
diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt index a3cf2ca963..556013ebca 100644 --- a/docs/ref/contrib/csrf.txt +++ b/docs/ref/contrib/csrf.txt @@ -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 ------------------ diff --git a/docs/ref/contrib/flatpages.txt b/docs/ref/contrib/flatpages.txt index c01130067b..bce9a2f289 100644 --- a/docs/ref/contrib/flatpages.txt +++ b/docs/ref/contrib/flatpages.txt @@ -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. diff --git a/docs/ref/forms/validation.txt b/docs/ref/forms/validation.txt index 23aa27d985..5264279e8e 100644 --- a/docs/ref/forms/validation.txt +++ b/docs/ref/forms/validation.txt @@ -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. diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index f05368bc0c..2bd813d977 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -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. |