Fixed doc typos.

docs/internals/contributing/triaging-tickets.txt

@@ -357,7 +357,7 @@ Then, you can help out by:
 * Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate."
 
 * Closing "Unreviewed" tickets as "needsinfo" when the description is too
-  sparse to be actionnable, or when they're feature requests requiring a
+  sparse to be actionable, or when they're feature requests requiring a
   discussion on |django-developers|.
 
 * Correcting the "Needs tests", "Needs documentation", or "Has patch"

docs/internals/security.txt

@@ -92,7 +92,7 @@ email message, signed with the Django release key, containing:
 * The patch(es), if any, that will be applied to Django.
 
 * The date on which the Django team will apply these patches, issue
-  new releases and publicy disclose the issue.
+  new releases and publicly disclose the issue.
 
 Simultaneously, the reporter of the issue will receive notification of
 the date on which we plan to take the issue public.

docs/ref/contrib/admin/index.txt

@@ -1803,7 +1803,7 @@ in your own admin JavaScript without including a second copy, you can use the
 
 The :class:`ModelAdmin` class requires jQuery by default, so there is no need
 to add jQuery to your ``ModelAdmin``’s list of media resources unless you have
-a specifc need. For example, if you require the jQuery library to be in the
+a specific need. For example, if you require the jQuery library to be in the
 global namespace (for example when using third-party jQuery plugins) or if you
 need a newer version of jQuery, you will have to include your own copy.
 

docs/ref/contrib/gis/geoquerysets.txt

@@ -1102,7 +1102,7 @@ Aggregate Methods
 *Availability*: PostGIS
 
 Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry
-column.  This is analagous to a simplified version of the :meth:`GeoQuerySet.unionagg` method,
+column.  This is analogous to a simplified version of the :meth:`GeoQuerySet.unionagg` method,
 except it can be several orders of magnitude faster than performing a union because
 it simply rolls up geometries into a collection or multi object, not caring about
 dissolving boundaries.

docs/ref/contrib/gis/install/postgis.txt

@@ -11,7 +11,7 @@ might also need additional libraries, see `PostGIS requirements`_.
 
 .. note::
 
-    The `psycopg2`_ module is required for use as the database adaptor
+    The `psycopg2`_ module is required for use as the database adapter
     when using GeoDjango with PostGIS.
 
 .. _psycopg2: http://initd.org/psycopg/

docs/ref/contrib/staticfiles.txt

@@ -321,7 +321,7 @@ CachedStaticFilesStorage
 but uses Django's :doc:`caching framework</topics/cache>` for storing the
 hashed names of processed files instead of a static manifest file called
 ``staticfiles.json``. This is mostly useful for situations in which you don't
-have accesss to the file system.
+have access to the file system.
 
 If you want to override certain options of the cache backend the storage uses,
 simply specify a custom entry in the :setting:`CACHES` setting named

docs/ref/databases.txt

@@ -259,8 +259,8 @@ drivers that implement this API:
 Both drivers are thread-safe and both provide connection pooling. The major
 difference is that MySQL Connector/Python supports Python 3.
 
-In addition to a DB API driver, Django needs an adaptor to access the database
-drivers from its ORM. Django provides an adaptor for MySQLdb while MySQL
+In addition to a DB API driver, Django needs an adapter to access the database
+drivers from its ORM. Django provides an adapter for MySQLdb while MySQL
 Connector/Python includes `its own`_.
 
 .. _its own: http://dev.mysql.com/doc/refman/5.6/en/connector-python-django-backend.html

docs/ref/django-admin.txt

@@ -1239,8 +1239,8 @@ syncdb
 
 .. deprecated:: 1.7
 
-    This command has been deprecated in favour of the :djadmin:`migrate`
-    command, which performs both the old behaviour as well as executing
+    This command has been deprecated in favor of the :djadmin:`migrate`
+    command, which performs both the old behavior as well as executing
     migrations. It is now just an alias to that command.
 
 Alias for :djadmin:`migrate`.

docs/ref/forms/fields.txt

@@ -666,7 +666,7 @@ For each field, we describe the default widget used if you don't specify
 .. class:: IPAddressField(**kwargs)
 
     .. deprecated:: 1.7
-        This field has been deprecated in favour of
+        This field has been deprecated in favor of
         :class:`~django.forms.GenericIPAddressField`.
 
     * Default widget: :class:`TextInput`

docs/ref/migration-operations.txt

@@ -47,7 +47,7 @@ rather than a field takes from another model).
 
 ``options`` is an optional dictionary of values from the model's ``Meta`` class.
 
-``bases`` is an optional list of other classes to have this model inheirit from;
+``bases`` is an optional list of other classes to have this model inherit from;
 it can contain both class objects as well as strings in the format
 ``"appname.ModelName"`` if you want to depend on another model (so you inherit
 from the historical version). If it's not supplied, it defaults to just
@@ -122,7 +122,7 @@ The ``preserve_default`` argument indicates whether the field's default
 value is permanent and should be baked into the project state (``True``),
 or if it is temporary and just for this migration (``False``) - usually
 because the migration is adding a non-nullable field to a table and needs
-a default value to put into existing rows. It does not effect the behaviour
+a default value to put into existing rows. It does not effect the behavior
 of setting defaults in the database directly - Django never sets database
 defaults, and always applies them in the Django ORM code.
 
@@ -188,7 +188,7 @@ correctly, in which case you should manually split the SQL into multiple calls
 to ``RunSQL``.
 
 The ``state_operations`` argument is so you can supply operations that are
-equivalent to the SQL in terms of project state; for example, if you are 
+equivalent to the SQL in terms of project state; for example, if you are
 manually creating a column, you should pass in a list containing an ``AddField``
 operation here so that the autodetector still has an up-to-date state of the
 model (otherwise, when you next run ``makemigrations``, it won't see any

docs/ref/models/custom-lookups.txt

@@ -198,7 +198,7 @@ MySQL for the NotEqual operator. Instead of ``<>`` we will be using ``!=``
 operator. (Note that in reality almost all databases support both, including
 all the official databases supported by Django).
 
-We can change the behaviour on a specific backend by creating a subclass of
+We can change the behavior on a specific backend by creating a subclass of
 ``NotEqual`` with a ``as_mysql`` method::
 
   class MySQLNotEqual(NotEqual):
@@ -241,7 +241,7 @@ to this API.
     The ``get_lookup()`` method is used to fetch lookups. By default the
     lookup is fetched from the expression's output type in the same way
     described in registering and fetching lookup documentation below.
-    It is possible to override this method to alter that behaviour.
+    It is possible to override this method to alter that behavior.
 
 .. method:: as_vendorname(qn, connection)
 

docs/ref/models/fields.txt

@@ -867,7 +867,7 @@ databases supported by Django. The default form widget for this field is a
 .. class:: IPAddressField([**options])
 
 .. deprecated:: 1.7
-    This field has been deprecated in favour of
+    This field has been deprecated in favor of
     :class:`~django.db.models.GenericIPAddressField`.
 
 An IP address, in string format (e.g. "192.0.2.30"). The default form widget

docs/ref/templates/api.txt

@@ -225,7 +225,7 @@ straight lookups. Here are some things to keep in mind:
     sensitive_function.alters_data = True
 
 * Occasionally you may want to turn off this feature for other reasons,
-  and tell the template system to leave a variable un-called no matter
+  and tell the template system to leave a variable uncalled no matter
   what.  To do so, set a ``do_not_call_in_templates`` attribute on the
   callable with the value ``True``.  The template system then will act as
   if your variable is not callable (allowing you to access attributes of

docs/releases/1.2.txt

@@ -352,7 +352,7 @@ are now included:
 
 GeoDjango now supports the rich capabilities added
 in the `PostGIS 1.5 release <http://postgis.refractions.net/documentation/manual-1.5/>`_.
-New features include suppport for the :ref:`geography type <geography-type>`
+New features include support for the :ref:`geography type <geography-type>`
 and enabling of :ref:`distance queries <distance-queries>`
 with non-point geometries on geographic coordinate systems.
 

docs/releases/1.4-alpha-1.txt

@@ -1056,7 +1056,7 @@ names, like ``django.contrib.*``. The expansion was performed by a
 filesystem-based implementation of ``from <package> import *``. Unfortunately,
 `this can't be done reliably`_.
 
-This behavior was never documented. Since it is un-pythonic and not obviously
+This behavior was never documented. Since it is unpythonic and not obviously
 useful, it was removed in Django 1.4. If you relied on it, you must edit your
 settings file to list all your applications explicitly.
 

docs/releases/1.4-beta-1.txt

@@ -1127,7 +1127,7 @@ names, like ``django.contrib.*``. The expansion was performed by a
 filesystem-based implementation of ``from <package> import *``. Unfortunately,
 `this can't be done reliably`_.
 
-This behavior was never documented. Since it is un-pythonic and not obviously
+This behavior was never documented. Since it is unpythonic and not obviously
 useful, it was removed in Django 1.4. If you relied on it, you must edit your
 settings file to list all your applications explicitly.
 

docs/releases/1.4.txt

@@ -1318,7 +1318,7 @@ names, like ``django.contrib.*``. The expansion was performed by a
 filesystem-based implementation of ``from <package> import *``. Unfortunately,
 `this can't be done reliably`_.
 
-This behavior was never documented. Since it is un-pythonic and not obviously
+This behavior was never documented. Since it is unpythonic and not obviously
 useful, it was removed in Django 1.4. If you relied on it, you must edit your
 settings file to list all your applications explicitly.
 

docs/releases/1.7.txt

@@ -793,7 +793,7 @@ initial_data
 
 Apps with migrations will not load ``initial_data`` fixtures when they have
 finished migrating. Apps without migrations will continue to load these fixtures
-during the phase of ``migrate`` which emulates the old ``syncdb`` behaviour,
+during the phase of ``migrate`` which emulates the old ``syncdb`` behavior,
 but any new apps will not have this support.
 
 Instead, you are encouraged to load initial data in migrations if you need it

docs/topics/auth/passwords.txt

@@ -182,8 +182,8 @@ can switch to new (and better) storage algorithms as they get invented.
 
 However, Django can only upgrade passwords that use algorithms mentioned in
 :setting:`PASSWORD_HASHERS`, so as you upgrade to new systems you should make
-sure never to *remove* entries from this list. If you do, users using un-
-mentioned algorithms won't be able to upgrade.
+sure never to *remove* entries from this list. If you do, users using
+unmentioned algorithms won't be able to upgrade.
 
 .. versionadded:: 1.6
 

docs/topics/cache.txt

@@ -740,7 +740,7 @@ Accessing the cache
 .. function:: django.core.cache.get_cache(backend, **kwargs)
 
     .. deprecated:: 1.7
-        This function has been deprecated in favour of
+        This function has been deprecated in favor of
         :data:`~django.core.cache.caches`.
 
     Before Django 1.7 this function was the canonical way to obtain a cache

docs/topics/class-based-views/generic-display.txt

@@ -189,7 +189,7 @@ specifies the context variable to use::
 
     class PublisherList(ListView):
         model = Publisher
-        context_object_name = 'my_favourite_publishers'
+        context_object_name = 'my_favorite_publishers'
 
 Providing a useful ``context_object_name`` is always a good idea. Your
 coworkers who design templates will thank you.

docs/topics/class-based-views/mixins.txt

@@ -303,7 +303,7 @@ object. In order to do this, we need to have two different querysets:
     Since both :class:`~django.views.generic.detail.SingleObjectMixin` and
     :class:`ListView` will
     put things in the context data under the value of
-    ``context_object_name`` if it's set, we'll instead explictly
+    ``context_object_name`` if it's set, we'll instead explicitly
     ensure the ``Publisher`` is in the context data. :class:`ListView`
     will add in the suitable ``page_obj`` and ``paginator`` for us
     providing we remember to call ``super()``.

docs/topics/db/queries.txt

@@ -447,8 +447,8 @@ probably use:
 
         >>> Blog.objects.get(name__iexact="beatles blog")
 
-    Would match a ``Blog`` titled "Beatles Blog", "beatles blog", or even
-    "BeAtlES blOG".
+    Would match a ``Blog`` titled ``"Beatles Blog"``, ``"beatles blog"``, or
+    even ``"BeAtlES blOG"``.
 
 :lookup:`contains`
     Case-sensitive containment test. For example::

docs/topics/forms/modelforms.txt

@@ -662,7 +662,7 @@ There are a couple of things to note, however.
 
 .. versionchanged:: 1.7
 
-* It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneuosly,
+* It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneously,
   however, you must ensure that ``ModelForm`` appears first in the MRO. This is
   because these classes rely on different metaclasses and a class can only have
   one metaclass.

docs/topics/migrations.txt

@@ -38,11 +38,11 @@ and Django's handling of database schema:
 It's worth noting that migrations are created and run on a per-app basis.
 In particular, it's possible to have apps that *do not use migrations* (these
 are referred to as "unmigrated" apps) - these apps will instead mimic the
-legacy behaviour of just adding new models.
+legacy behavior of just adding new models.
 
 You should think of migrations as a version control system for your database
 schema. ``makemigrations`` is responsible for packaging up your model changes
-into individual migration files - analagous to commits - and ``migrate`` is
+into individual migration files - analogous to commits - and ``migrate`` is
 responsible for applying those to your database.
 
 The migration files for each app live in a "migrations" directory inside
@@ -194,7 +194,7 @@ If this didn't happen, the migration would try to create the ForeignKey column
 without the table it's referencing existing and your database would
 throw an error.
 
-This dependency behaviour affects most migration operations where you
+This dependency behavior affects most migration operations where you
 restrict to a single app. Restricting to a single app (either in
 ``makemigrations`` or ``migrate``) is a best-efforts promise, and not
 a guarantee; any other apps that need to be used to get dependencies correct
@@ -361,7 +361,7 @@ doing this can confuse the migration autodetector!)
 
 Let's write a simple migration that populates our new ``name`` field with the
 combined values of ``first_name`` and ``last_name`` (we've come to our senses
-and realised that not everyone has first and last names). All we
+and realized that not everyone has first and last names). All we
 need to do is use the historical model and iterate over the rows::
 
     # encoding: utf8

docs/topics/performance.txt

@@ -286,7 +286,7 @@ memory.
 Static files
 ------------
 
-Static files, which by defintion are not dynamic, make an excellent target for
+Static files, which by definition are not dynamic, make an excellent target for
 optimization gains.
 
 :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage`
@@ -425,5 +425,5 @@ C implementations of Python libraries
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Some Python libraries are also implemented in C, and can be much faster. They
-aim to offer the same APIs. Note that compatibility issues and behaviour
+aim to offer the same APIs. Note that compatibility issues and behavior
 differences are not unknown (and not always immediately evident).

docs/topics/testing/tools.txt

@@ -770,7 +770,7 @@ out the `full reference`_ for more details.
     expected locations during the execution of these tests.
 
     In Django 1.7 this dependency of core functionality on a ``contrib``
-    appplication has been removed, because of which ``LiveServerTestCase``
+    application has been removed, because of which ``LiveServerTestCase``
     ability in this respect has been retrofitted to simply publish the contents
     of the file system under :setting:`STATIC_ROOT` at the :setting:`STATIC_URL`
     URL.