Fixed spelling in docs.

3 files changed, 5 insertions, 5 deletions

diff --git a/docs/ref/contrib/postgres/fields.txt b/docs/ref/contrib/postgres/fields.txt
index 563a8bd97e..49ce5368c8 100644
--- a/docs/ref/contrib/postgres/fields.txt
+++ b/docs/ref/contrib/postgres/fields.txt
@@ -21,7 +21,7 @@ ArrayField
 
         This is a required argument.
 
-        Specifies the underlying data type and behaviour for the array. It
+        Specifies the underlying data type and behavior for the array. It
         should be an instance of a subclass of
         :class:`~django.db.models.Field`. For example, it could be an
         :class:`~django.db.models.IntegerField` or a
@@ -227,7 +227,7 @@ lookups available after the transform do not change. For example::
 
 .. admonition:: Multidimensional arrays with indexes and slices
 
-    PostgreSQL has some rather esoteric behaviour when using indexes and slices
+    PostgreSQL has some rather esoteric behavior when using indexes and slices
     on multidimensional arrays. It will always work to use indexes to reach
     down to the final underlying data, but most other slices behave strangely
     at the database level and cannot be supported in a logical, consistent
diff --git a/docs/ref/contrib/postgres/index.txt b/docs/ref/contrib/postgres/index.txt
index 5db4ab80ed..31969222ca 100644
--- a/docs/ref/contrib/postgres/index.txt
+++ b/docs/ref/contrib/postgres/index.txt
@@ -9,12 +9,12 @@ a number of PostgreSQL specific data types.
     Django is, and will continue to be, a database-agnostic web framework. We
     would encourage those writing reusable applications for the Django
     community to write database-agnostic code where practical. However, we
-    recognise that real world projects written using Django need not be
+    recognize that real world projects written using Django need not be
     database-agnostic. In fact, once a project reaches a given size changing
     the underlying data store is already a significant challenge and is likely
     to require changing the code base in some ways to handle differences
     between the data stores.
-    
+
     Django provides support for a number of data types which will
     only work with PostgreSQL. There is no fundamental reason why (for example)
     a ``contrib.mysql`` module does not exist, except that PostgreSQL has the
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 6e94c1ac0d..6f3c0533b9 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -1391,7 +1391,7 @@ like::
     When Django searches for a certain format, it will go through all given
     Python paths until it finds a module that actually defines the given
     format. This means that formats defined in packages farther up in the list
-    will take precendence over the same formats in packages farther down.
+    will take precedence over the same formats in packages farther down.
 
 Available formats are :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`,
 :setting:`DATETIME_FORMAT`, :setting:`YEAR_MONTH_FORMAT`,