Fixed spelling in docs.

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

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