Fixed spelling mistakes in docs.

20 files changed, 27 insertions, 28 deletions

diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt
index 7b60f285cf..4a77b586cf 100644
--- a/docs/internals/committers.txt
+++ b/docs/internals/committers.txt
@@ -408,7 +408,7 @@ Anssi Kääriäinen
     Django as a great match for that use case.
 
     Anssi is interested in developing the object relational mapper (ORM) and
-    all related features. He's also a fan of benckmarking and he tries keep
+    all related features. He's also a fan of benchmarking and he tries keep
     Django as fast as possible.
 
 Florian Apolloner
diff --git a/docs/internals/contributing/localizing.txt b/docs/internals/contributing/localizing.txt
index 1b23a2296c..7705098143 100644
--- a/docs/internals/contributing/localizing.txt
+++ b/docs/internals/contributing/localizing.txt
@@ -22,7 +22,7 @@ translating or add a language that isn't yet translated, here's what to do:
 
 * Make sure you read the notes about :ref:`specialties-of-django-i18n`.
 
-* Signup at `Transifex`_ and visit the `Django project page`_.
+* Sign up at `Transifex`_ and visit the `Django project page`_.
 
 * On the `Django project page`_, choose the language you want to work on,
   **or** -- in case the language doesn't exist yet --
@@ -37,7 +37,7 @@ translating or add a language that isn't yet translated, here's what to do:
 
 * Once you are a member of a team choose the translation resource you
   want to update on the team page. For example the "core" resource refers
-  to the translation catalogue that contains all non-contrib translations.
+  to the translation catalog that contains all non-contrib translations.
   Each of the contrib apps also have a resource (prefixed with "contrib").
 
   .. note::
diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index 90a8dd5748..4fb5d1b9f0 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -435,7 +435,7 @@ this case, we've set the :attr:`~django.db.models.Field.default` value of
 Finally, note a relationship is defined, using
 :class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
 to a single ``Question``. Django supports all the common database relationships:
-many-to-ones, many-to-manys and one-to-ones.
+many-to-one, many-to-many and one-to-one.
 
 .. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path
 
@@ -591,12 +591,12 @@ Now, run :djadmin:`migrate` again to create those model tables in your database:
 The :djadmin:`migrate` command takes all the migrations that haven't been
 applied (Django tracks which ones are applied using a special table in your
 database called ``django_migrations``) and runs them against your database -
-essentially, synchronising the changes you made to your models with the schema
+essentially, synchronizing the changes you made to your models with the schema
 in the database.
 
 Migrations are very powerful and let you change your models over time, as you
 develop your project, without the need to delete your database or tables and
-make new ones - it specialises in upgrading your database live, without
+make new ones - it specializes in upgrading your database live, without
 losing data. We'll cover them in more depth in a later part of the tutorial,
 but for now, remember the three-step guide to making model changes:
 
diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt
index b31f00337c..b29d21ac3b 100644
--- a/docs/ref/applications.txt
+++ b/docs/ref/applications.txt
@@ -157,7 +157,7 @@ Configurable attributes
 
     Short name for the application, e.g. ``'admin'``
 
-    This attribute allows relabelling an application when two applications
+    This attribute allows relabeling an application when two applications
     have conflicting labels. It defaults to the last component of ``name``.
     It should be a valid Python identifier.
 
diff --git a/docs/ref/contrib/gis/geoip.txt b/docs/ref/contrib/gis/geoip.txt
index b6aca6b211..ec83a45aab 100644
--- a/docs/ref/contrib/gis/geoip.txt
+++ b/docs/ref/contrib/gis/geoip.txt
@@ -11,7 +11,7 @@ The :class:`GeoIP` object is a ctypes wrapper for the
 `MaxMind GeoIP C API`__. [#]_
 
 In order to perform IP-based geolocation, the :class:`GeoIP` object requires
-the GeoIP C libary and either the GeoIP `Country`__ or `City`__
+the GeoIP C library and either the GeoIP `Country`__ or `City`__
 datasets in binary format (the CSV files will not work!).  These datasets may be
 `downloaded from MaxMind`__.  Grab the ``GeoLiteCountry/GeoIP.dat.gz`` and
 ``GeoLiteCity.dat.gz`` files and unzip them in a directory corresponding to what
@@ -96,7 +96,7 @@ Defaults to ``'GeoLiteCity.dat'``.
 The ``GeoIP`` object does not require any parameters to use the default
 settings.  However, at the very least the :setting:`GEOIP_PATH` setting
 should be set with the path of the location of your GeoIP data sets.  The
-following intialization keywords may be used to customize any of the
+following initialization keywords may be used to customize any of the
 defaults.
 
 ===================  =======================================================
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 36426af5a8..e9dd1134c2 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -173,7 +173,7 @@ readers sign up to get notifications when news happens. It's pretty basic: A
 reader signs up on a Web form and immediately gets an email saying,
 "Thanks for your subscription."
 
-It'd be inefficient and redundant to implement this signup-processing code
+It'd be inefficient and redundant to implement this sign up processing code
 twice, so the sites use the same code behind the scenes. But the "thank you for
 signing up" notice needs to be different for each site. By using
 :class:`~django.contrib.sites.models.Site`
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index 33f47914c2..7802ee1073 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -554,7 +554,7 @@ are passed into the query. So the :lookup:`iexact` filter will behave exactly
 the same as the :lookup:`exact` filter in these cases.
 
 Some possible workarounds for this are `documented at sqlite.org`_, but they
-aren't utilised by the default SQLite backend in Django, as incorporating them
+aren't utilized by the default SQLite backend in Django, as incorporating them
 would be fairly difficult to do robustly. Thus, Django exposes the default
 SQLite behavior and you should be aware of this when doing case-insensitive or
 substring filtering.
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index 724be51837..853f64b936 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -784,7 +784,7 @@ Write stderr to the *FILE* file.
 
 ``umask=UMASK``
 
-Umask to use when daemonizing. The value is interpeted as an octal number
+Umask to use when daemonizing. The value is interpreted as an octal number
 (default value is ``022``).
 
 Example usage::
diff --git a/docs/ref/migration-operations.txt b/docs/ref/migration-operations.txt
index cb77d7d93f..cad46f2d01 100644
--- a/docs/ref/migration-operations.txt
+++ b/docs/ref/migration-operations.txt
@@ -12,7 +12,7 @@ your migrations; that's why they're declarative, as it means Django can
 easily load them all into memory and run through them without touching
 the database to work out what your project should look like.
 
-There are also more specialised Operation objects which are for things like
+There are also more specialized Operation objects which are for things like
 :ref:`data migrations <data-migrations>` and for advanced manual database
 manipulation. You can also write your own Operation classes if you want
 to encapsulate a custom change you commonly make.
@@ -221,7 +221,7 @@ SeparateDatabaseAndState
 
     SeparateDatabaseAndState(database_operations=None, state_operations=None)
 
-A highly specalist operation that let you mix and match the database
+A highly specialist operation that let you mix and match the database
 (schema-changing) and state (autodetector-powering) aspects of operations.
 
 It accepts two list of operations, and when asked to apply state will use the
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index 2371fd3c8a..21bcba4636 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -610,7 +610,7 @@ in ``get_absolute_url()`` and have all your other code call that one place.
 
 .. note::
     The string you return from ``get_absolute_url()`` **must** contain only
-    ASCII characters (required by the URI specfication, :rfc:`2396`) and be
+    ASCII characters (required by the URI specification, :rfc:`2396`) and be
     URL-encoded, if necessary.
 
     Code and templates calling ``get_absolute_url()`` should be able to use the
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index 339b5e18fe..a160587953 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -2045,7 +2045,7 @@ Case-insensitive exact match.
 
 .. versionchanged:: 1.7
 
-    If the value provided for comparision is ``None``, it will be interpreted
+    If the value provided for comparison is ``None``, it will be interpreted
     as an SQL ``NULL`` (see :lookup:`isnull` for more details).
 
 Example::
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index ebac2a8898..508ad4b56f 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -1800,7 +1800,7 @@ SILENCED_SYSTEM_CHECKS
 
 Default: ``[]``
 
-A list of identifers of messages generated by the system check framework
+A list of identifiers of messages generated by the system check framework
 (i.e. ``["models.W001"]``) that you wish to permanently acknowledge and ignore.
 Silenced warnings will no longer be output to the console; silenced errors
 will still be printed, but will not prevent management commands from running.
diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt
index 15242f030f..9e5bd41b67 100644
--- a/docs/ref/utils.txt
+++ b/docs/ref/utils.txt
@@ -900,7 +900,7 @@ For a complete discussion on the usage of the following see the
     :func:`django.utils.translation.activate` to fetch the translation object
     for a given language, installing it as the translation object for the
     current thread and reinstall the previous active language on exit.
-    Optionally it can simply deinstall the temporary translation on exit with
+    Optionally it can simply uninstall the temporary translation on exit with
     :func:`django.utils.translation.deactivate` if the deactivate argument is
     True. If you pass None as the language argument, a NullTranslations()
     instance is installed while the context is active.
diff --git a/docs/releases/0.95.txt b/docs/releases/0.95.txt
index 5730fd6a98..a2e9cd63ec 100644
--- a/docs/releases/0.95.txt
+++ b/docs/releases/0.95.txt
@@ -16,8 +16,8 @@ wanting to work on production-level applications that use Django.
 
 However, it's not the 1.0 release, and we'll be introducing further changes
 before 1.0. For a clear look at which areas of the framework will change (and
-which ones will *not* change) before 1.0, see the api-stability.txt file, which
-lives in the docs/ directory of the distribution.
+which ones will *not* change) before 1.0, see the ``api-stability.txt`` file,
+which lives in the docs/ directory of the distribution.
 
 You may have a need to use some of the features that are marked as
 "subject to API change" in that document, but that's OK with us as long as it's
@@ -120,4 +120,3 @@ Thanks for using Django!
 
 The Django Team
 July 2006
-
diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt
index cb629a2cf8..8898fe67b3 100644
--- a/docs/releases/1.3-alpha-1.txt
+++ b/docs/releases/1.3-alpha-1.txt
@@ -97,7 +97,7 @@ wherever you would have historically used::
 
     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
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 07d8a00928..c0cacb2ec7 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -433,7 +433,7 @@ Cache
   instance per thread. It supersedes :func:`django.core.cache.get_cache` which
   is now deprecated.
 
-* If you instanciate cache backends directly, be aware that they aren't
+* If you instantiate cache backends directly, be aware that they aren't
   thread-safe any more, as :data:`django.core.cache.caches` now yields
   different instances per thread.
 
diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index f79bf1160e..05644fc787 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -219,7 +219,7 @@ processing to work on a particular object, identified from the URL,
 we'll want the functionality provided by
 :class:`~django.views.generic.detail.SingleObjectMixin`.
 
-We'll demonstrate this with the publisher modelling we used in the
+We'll demonstrate this with the publisher modeling we used in the
 :doc:`generic class-based views introduction<generic-display>`.
 
 .. code-block:: python
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 5b2478244d..a1e30b341b 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -588,8 +588,8 @@ The ``manage_articles.html`` template might look like this:
         </table>
     </form>
 
-However the above can be slightly shortcutted and let the formset itself deal
-with the management form:
+However there's a slight shortcut for the above by letting the formset itself
+deal with the management form:
 
 .. code-block:: html+django
 
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 1d1d278f3f..5d7f9ac5e1 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -442,7 +442,7 @@ available at the top level of a module it is not serializable.
 ``kwargs`` should be a dict of keyword arguments to pass to your class'
 ``__init__`` method. Every value should itself be serializable.
 
-Django will write out the value as an instatiation of your class with the
+Django will write out the value as an instantiation of your class with the
 given arguments, similar to the way it writes out references to Django fields.
 
 
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index cbf574a29c..1bd15bd1a6 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -354,7 +354,7 @@ Attributes
     the individual tests and format the results. By default it is set to
     ``unittest.TextTestRunner``. Despite the unfortunate similarity in
     naming conventions, this is not the same type of class as
-    ``DiscoverRunner``, which covers a broader set of responsibilites. You
+    ``DiscoverRunner``, which covers a broader set of responsibilities. You
     can override this attribute to modify the way tests are run and reported.
 
 .. attribute:: DiscoverRunner.test_loader