diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt index 309e5c12ed..a844e32817 100644 --- a/docs/howto/custom-management-commands.txt +++ b/docs/howto/custom-management-commands.txt @@ -71,7 +71,7 @@ The new custom command can be called using ``python manage.py closepoll ``. The ``handle()`` method takes zero or more ``poll_ids`` and sets ``poll.opened`` -to ``False`` for each one. If the user referenced any nonexistant polls, a +to ``False`` for each one. If the user referenced any nonexistent polls, a :class:`CommandError` is raised. The ``poll.opened`` attribute does not exist in the :doc:`tutorial` and was added to ``polls.models.Poll`` for this example. diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt index 0f8676e89c..c9dacb590f 100644 --- a/docs/howto/custom-template-tags.txt +++ b/docs/howto/custom-template-tags.txt @@ -894,7 +894,7 @@ Here's how you'd use this new version of the tag: .. admonition:: Variable scope in context Any variable set in the context will only be available in the same ``block`` - of the template in which it was assigned. This behaviour is intentional; + of the template in which it was assigned. This behavior is intentional; it provides a scope for variables so that they don't conflict with context in other blocks. diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt index ddef93873e..4642c39a92 100644 --- a/docs/howto/error-reporting.txt +++ b/docs/howto/error-reporting.txt @@ -44,7 +44,7 @@ setting. .. versionadded:: 1.3 Server error emails are sent using the logging framework, so you can - customize this behaviour by :doc:`customizing your logging configuration + customize this behavior by :doc:`customizing your logging configuration `. 404 errors diff --git a/docs/howto/jython.txt b/docs/howto/jython.txt index 1bf8d6c1f4..9adacdf87f 100644 --- a/docs/howto/jython.txt +++ b/docs/howto/jython.txt @@ -65,7 +65,7 @@ At this point, Django on Jython should behave nearly identically to Django running on standard Python. However, are a few differences to keep in mind: * Remember to use the ``jython`` command instead of ``python``. The - documentation uses ``python`` for consistancy, but if you're using Jython + documentation uses ``python`` for consistency, but if you're using Jython you'll want to mentally replace ``python`` with ``jython`` every time it occurs. diff --git a/docs/howto/static-files.txt b/docs/howto/static-files.txt index e41060583e..633a663786 100644 --- a/docs/howto/static-files.txt +++ b/docs/howto/static-files.txt @@ -137,7 +137,7 @@ A far better way is to use the value of the :setting:`STATIC_URL` setting directly in your templates. This means that a switch of static files servers only requires changing that single value. Much better! -``staticfiles`` inludes two built-in ways of getting at this setting in your +``staticfiles`` includes two built-in ways of getting at this setting in your templates: a context processor and a template tag. With a context processor @@ -170,7 +170,7 @@ As a brief refresher, context processors add variables into the contexts of every template. However, context processors require that you use :class:`~django.template.RequestContext` when rendering templates. This happens automatically if you're using a :doc:`generic view `, -but in views written by hand you'll need to explicitally use ``RequestContext`` +but in views written by hand you'll need to explicitly use ``RequestContext`` To see how that works, and to read more details, check out :ref:`subclassing-context-requestcontext`. @@ -439,7 +439,7 @@ For example, if you've written an S3 storage backend in Once that's done, all you have to do is run :djadmin:`collectstatic` and your static files would be pushed through your storage package up to S3. If you -later needed to swich to a different storage provider, it could be as simple +later needed to switch to a different storage provider, it could be as simple as changing your :setting:`STATICFILES_STORAGE` setting. For details on how you'd write one of these backends, diff --git a/docs/internals/contributing.txt b/docs/internals/contributing.txt index c3be198add..4e2bad91ad 100644 --- a/docs/internals/contributing.txt +++ b/docs/internals/contributing.txt @@ -472,7 +472,7 @@ to do: * Then, click the "Join this Team" button to become a member of this team. Every team has at least one coordinator who is responsible to review your membership request. You can of course also contact the team - coordinator to clarify procedual problems and handle the actual + coordinator to clarify procedural problems and handle the actual translation process. * Once you are a member of a team choose the translation resource you diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 157103cebc..95114fb78b 100644 --- a/docs/internals/deprecation.txt +++ b/docs/internals/deprecation.txt @@ -20,7 +20,7 @@ their deprecation, as per the :ref:`Django deprecation policy * 1.4 * ``CsrfResponseMiddleware``. This has been deprecated since the 1.2 - release, in favour of the template tag method for inserting the CSRF + release, in favor of the template tag method for inserting the CSRF token. ``CsrfMiddleware``, which combines ``CsrfResponseMiddleware`` and ``CsrfViewMiddleware``, is also deprecated. @@ -129,7 +129,7 @@ their deprecation, as per the :ref:`Django deprecation policy * The undocumented function :func:`django.contrib.formtools.utils.security_hash` - is deprecated, in favour of :func:`django.contrib.formtools.utils.form_hmac` + is deprecated, in favor of :func:`django.contrib.formtools.utils.form_hmac` * The function-based generic views have been deprecated in favor of their class-based cousins. The following modules @@ -161,7 +161,7 @@ their deprecation, as per the :ref:`Django deprecation policy a :class:`~django.contrib.gis.geos.GEOSException` when called on a geometry with no SRID value. - * :class:`~django.http.CompatCookie` will be removed in favour of + * :class:`~django.http.CompatCookie` will be removed in favor of :class:`~django.http.SimpleCookie`. * :class:`django.core.context_processors.PermWrapper` and diff --git a/docs/internals/svn.txt b/docs/internals/svn.txt index 9efbe28913..58cabd1ba0 100644 --- a/docs/internals/svn.txt +++ b/docs/internals/svn.txt @@ -199,7 +199,7 @@ branch ``django/branches/releases/1.0.X`` was created to receive bug fixes, and shortly after the release of Django 1.1 the branch ``django/branches/releases/1.1.X`` was created. -Prior to the Django 1.0 release, these branches were maintaind within +Prior to the Django 1.0 release, these branches were maintained within the top-level ``django/branches`` directory, and so the following branches exist there and provided support for older Django releases: diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt index 29a2cb73fc..bf9044e474 100644 --- a/docs/intro/tutorial01.txt +++ b/docs/intro/tutorial01.txt @@ -593,7 +593,7 @@ automatically-generated admin. Unicode string, and ``str(p)`` will return a normal string, with characters encoded as UTF-8. - If all of this is jibberish to you, just remember to add + If all of this is gibberish to you, just remember to add :meth:`~django.db.models.Model.__unicode__` methods to your models. With any luck, things should Just Work for you. 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. diff --git a/docs/releases/1.3-beta-1.txt b/docs/releases/1.3-beta-1.txt index 5d924f8d92..0210ada689 100644 --- a/docs/releases/1.3-beta-1.txt +++ b/docs/releases/1.3-beta-1.txt @@ -27,7 +27,7 @@ The :mod:`~django.contrib.staticfiles` app ships with the ability to automatically serve static files during development (if the :setting:`DEBUG` setting is ``True``) when using the :djadmin:`runserver` management command. Based on feedback from the community this release adds two new options to the -:djadmin:`runserver` command to modify this behaviour: +:djadmin:`runserver` command to modify this behavior: * ``--nostatic``: prevents the :djadmin:`runserver` command from serving files completely. diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 1982de3403..562cd1f2d4 100644 --- a/docs/releases/1.3.txt +++ b/docs/releases/1.3.txt @@ -521,7 +521,7 @@ Callables in templates Previously, a callable in a template would only be called automatically as part of the variable resolution process if it was retrieved via attribute lookup. This was an inconsistency that could result in confusing and unhelpful -behaviour:: +behavior:: >>> Template("{{ user.get_full_name }}").render(Context({'user': user})) u'Joe Bloggs' @@ -529,7 +529,7 @@ behaviour:: u'<bound method User.get_full_name of <... This has been resolved in Django 1.3 - the result in both cases will be ``u'Joe -Bloggs'``. Although the previous behaviour was not useful for a template language +Bloggs'``. Although the previous behavior was not useful for a template language designed for web designers, and was never deliberately supported, it is possible that some templates may be broken by this change. diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index be95d2f02b..6a126ed087 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -132,7 +132,7 @@ flatpage. For example, requesting ``/notaflatpageoravalidurl`` in a previous version would redirect to ``/notaflatpageoravalidurl/``, which would subsequently raise a 404. Requesting ``/notaflatpageoravalidurl`` now will immediately raise a 404. Additionally redirects returned by flatpages are now -permanent (301 status code) to match the behaviour of the +permanent (301 status code) to match the behavior of the :class:`~django.middleware.common.CommonMiddleware`. `COMMENTS_BANNED_USERS_GROUP` setting @@ -144,7 +144,7 @@ the feature properly and didn't enforce the exclusion in other parts of the app, e.g. the template tags. To fix this problem the code was removed from the feed class. -If you rely on the feature and want to restore the old behaviour, simply use +If you rely on the feature and want to restore the old behavior, simply use a custom comment model manager to exclude the user group, e.g.:: from django.conf import settings diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt index 5ecb7e5ee5..12d538fd61 100644 --- a/docs/topics/auth.txt +++ b/docs/topics/auth.txt @@ -283,7 +283,7 @@ Manager functions The :attr:`~django.contrib.auth.models.User.username` and :attr:`~django.contrib.auth.models.User.password` are set as given. The domain portion of :attr:`~django.contrib.auth.models.User.email` is - automatically convered to lowercase, and the returned + automatically converted to lowercase, and the returned :class:`~django.contrib.auth.models.User` object will have :attr:`~models.User.is_active` set to ``True``. @@ -1244,7 +1244,7 @@ To create custom permissions for a given model object, use the ``permissions`` :ref:`model Meta attribute `. This example Task model creates three custom permissions, i.e., actions users -can or cannot do with Task instances, specific to your appication:: +can or cannot do with Task instances, specific to your application:: class Task(models.Model): ... diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index ce2eb592eb..45f295fe6c 100644 --- a/docs/topics/cache.txt +++ b/docs/topics/cache.txt @@ -615,7 +615,7 @@ If :setting:`USE_I18N` is set to ``True`` the per-site middleware cache will :ref:`respect the active language`. For the ``cache`` template tag you could use one of the :ref:`translation-specific variables` available in -templates to archieve the same result: +templates to achieve the same result: .. code-block:: html+django @@ -843,7 +843,7 @@ keys unaffected. Continuing our previous example:: # Version 2 isn't available, either >>> cache.get('my_key', version=2) None - # But version 3 *is* availble + # But version 3 *is* available >>> cache.get('my_key', version=3) 'hello world!' diff --git a/docs/topics/class-based-views.txt b/docs/topics/class-based-views.txt index 01d5f2fa65..c59151a91a 100644 --- a/docs/topics/class-based-views.txt +++ b/docs/topics/class-based-views.txt @@ -72,7 +72,7 @@ so we can just subclass it, and override the template name:: Then, we just need to add this new view into our URLconf. As the class-based views themselves are classes, we point the URL to the as_view class method -instead, which is the entrypoint for class-based views:: +instead, which is the entry point for class-based views:: # urls.py from django.conf.urls.defaults import * diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt index d6fb148988..8267c27778 100644 --- a/docs/topics/db/aggregation.txt +++ b/docs/topics/db/aggregation.txt @@ -233,7 +233,7 @@ the first query will provide the total number of all books published by the publisher; the second query will only include good books in the annotated count. In the first query, the annotation precedes the filter, so the filter has no effect on the annotation. In the second query, the filter -preceeds the annotation, and as a result, the filter constrains the objects +precedes the annotation, and as a result, the filter constrains the objects considered when calculating the annotation. ``order_by()`` diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt index 58f51e3110..0e18205e5d 100644 --- a/docs/topics/db/models.txt +++ b/docs/topics/db/models.txt @@ -188,7 +188,7 @@ ones: :: - >>> p = Person(name="Fred Flinstone", gender="M") + >>> p = Person(name="Fred Flintstone", gender="M") >>> p.save() >>> p.gender u'M' @@ -791,7 +791,7 @@ There are three styles of inheritance that are possible in Django. 2. If you're subclassing an existing model (perhaps something from another application entirely) and want each model to have its own database table, :ref:`multi-table-inheritance` is the way to go. - 3. Finally, if you only want to modify the Python-level behaviour of a model, + 3. Finally, if you only want to modify the Python-level behavior of a model, without changing the models fields in any way, you can use :ref:`proxy-models`. @@ -1218,7 +1218,7 @@ cannot create another model field called ``author`` in any class that inherits from that base class. Overriding fields in a parent model leads to difficulties in areas such as -initialising new instances (specifying which field is being initialized in +initializing new instances (specifying which field is being initialized in ``Model.__init__``) and serialization. These are features which normal Python class inheritance doesn't have to deal with in quite the same way, so the difference between Django model inheritance and Python class inheritance isn't diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt index 4c5a3894a4..265ef55fae 100644 --- a/docs/topics/db/optimization.txt +++ b/docs/topics/db/optimization.txt @@ -93,13 +93,13 @@ caching. Use the ``with`` template tag ----------------------------- -To make use of the caching behaviour of ``QuerySet``, you may need to use the +To make use of the caching behavior of ``QuerySet``, you may need to use the :ttag:`with` template tag. Use ``iterator()`` ------------------ -When you have a lot of objects, the caching behaviour of the ``QuerySet`` can +When you have a lot of objects, the caching behavior of the ``QuerySet`` can cause a large amount of memory to be used. In this case, :meth:`~django.db.models.QuerySet.iterator()` may help. @@ -252,7 +252,7 @@ individual, use a bulk SQL UPDATE statement, via :ref:`QuerySet.update() Note, however, that these bulk update methods cannot call the ``save()`` or ``delete()`` methods of individual instances, which means that any custom -behaviour you have added for these methods will not be executed, including +behavior you have added for these methods will not be executed, including anything driven from the normal database object :doc:`signals `. Use foreign key values directly diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt index 70b11570e1..b2539d8f06 100644 --- a/docs/topics/db/transactions.txt +++ b/docs/topics/db/transactions.txt @@ -234,7 +234,7 @@ provide the savepoint functions, but they are empty operations - they won't actually do anything. Savepoints aren't especially useful if you are using the default -``autocommit`` behaviour of Django. However, if you are using +``autocommit`` behavior of Django. However, if you are using ``commit_on_success`` or ``commit_manually``, each open transaction will build up a series of database operations, awaiting a commit or rollback. If you issue a rollback, the entire transaction is rolled back. Savepoints provide diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt index 4a0fa58c41..37ec98e165 100644 --- a/docs/topics/http/shortcuts.txt +++ b/docs/topics/http/shortcuts.txt @@ -4,7 +4,7 @@ Django shortcut functions .. module:: django.shortcuts :synopsis: - Convience shortcuts that spam multiple levels of Django's MVC stack. + Convenience shortcuts that spam multiple levels of Django's MVC stack. .. index:: shortcuts diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt index 4a9d6ad512..3507793765 100644 --- a/docs/topics/logging.txt +++ b/docs/topics/logging.txt @@ -156,7 +156,7 @@ and handle logging calls on a per-module basis. However, if you have some other way of organizing your logging messages, you can provide any dot-separated name to identify your logger:: - # Get an instance of a specfic named logger + # Get an instance of a specific named logger logger = logging.getLogger('project.interesting.stuff') The dotted paths of logger names define a hierarchy. The diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt index 64ce202939..df4b58b7be 100644 --- a/docs/topics/signals.txt +++ b/docs/topics/signals.txt @@ -106,7 +106,7 @@ must be able to handle those new arguments. Connecting receiver functions ----------------------------- -There are two ways you can connect a receiever to a signal. You can take the +There are two ways you can connect a receiver to a signal. You can take the manual connect route: .. code-block:: python diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt index 8e5cb9f954..61e860c632 100644 --- a/docs/topics/testing.txt +++ b/docs/topics/testing.txt @@ -95,7 +95,7 @@ module defines tests in class-based approach. import unittest - If you want to continue to use the base unittest libary, you can -- + If you want to continue to use the base unittest library, you can -- you just won't get any of the nice new unittest2 features. .. _unittest2: http://pypi.python.org/pypi/unittest2