From 4b57e203fe8c1550e5235a064a875bbeca293953 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Tue, 27 May 2014 19:46:48 -0400 Subject: [PATCH] Fixed spelling in docs. --- docs/ref/contrib/postgres/fields.txt | 4 ++-- docs/ref/contrib/postgres/index.txt | 4 ++-- docs/ref/settings.txt | 2 +- docs/spelling_wordlist | 1 + 4 files changed, 6 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`, diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index e112dc9000..39f6fb2030 100644 --- a/docs/spelling_wordlist +++ b/docs/spelling_wordlist @@ -244,6 +244,7 @@ gunicorn Gunicorn gz GZip +gzipped hackish handheld hardcode