diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt index 92f9406c5b4..3f4033f27e0 100644 --- a/docs/internals/contributing/triaging-tickets.txt +++ b/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" diff --git a/docs/internals/security.txt b/docs/internals/security.txt index 409e298dc93..6d53c3dff70 100644 --- a/docs/internals/security.txt +++ b/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. diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index a7746e3deb7..47efa42c16c 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/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. diff --git a/docs/ref/contrib/gis/geoquerysets.txt b/docs/ref/contrib/gis/geoquerysets.txt index 5f1d3521ebf..b27781bdc84 100644 --- a/docs/ref/contrib/gis/geoquerysets.txt +++ b/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. diff --git a/docs/ref/contrib/gis/install/postgis.txt b/docs/ref/contrib/gis/install/postgis.txt index 75597fbb38f..a248d336903 100644 --- a/docs/ref/contrib/gis/install/postgis.txt +++ b/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/ diff --git a/docs/ref/contrib/staticfiles.txt b/docs/ref/contrib/staticfiles.txt index 79ce21ecda1..961abf5c5d6 100644 --- a/docs/ref/contrib/staticfiles.txt +++ b/docs/ref/contrib/staticfiles.txt @@ -321,7 +321,7 @@ CachedStaticFilesStorage but uses Django's :doc:`caching framework` 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 diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index f7c4f0f9fb0..33f47914c2c 100644 --- a/docs/ref/databases.txt +++ b/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 diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index e2b4daec443..724be518375 100644 --- a/docs/ref/django-admin.txt +++ b/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`. diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt index f48f9ff4ad5..c2194cc5122 100644 --- a/docs/ref/forms/fields.txt +++ b/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` diff --git a/docs/ref/migration-operations.txt b/docs/ref/migration-operations.txt index 70406adc22f..cb77d7d93ff 100644 --- a/docs/ref/migration-operations.txt +++ b/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 diff --git a/docs/ref/models/custom-lookups.txt b/docs/ref/models/custom-lookups.txt index b800897712b..8aa2f792e59 100644 --- a/docs/ref/models/custom-lookups.txt +++ b/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) diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index 7c95f0fd709..4e02c66ca08 100644 --- a/docs/ref/models/fields.txt +++ b/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 diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt index 5701b1a9d17..08c86d99fc8 100644 --- a/docs/ref/templates/api.txt +++ b/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 diff --git a/docs/releases/1.2.txt b/docs/releases/1.2.txt index 387f2508ef2..b728e3bfe46 100644 --- a/docs/releases/1.2.txt +++ b/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 `_. -New features include suppport for the :ref:`geography type ` +New features include support for the :ref:`geography type ` and enabling of :ref:`distance queries ` with non-point geometries on geographic coordinate systems. diff --git a/docs/releases/1.4-alpha-1.txt b/docs/releases/1.4-alpha-1.txt index ebd00844699..6dce90bd8cd 100644 --- a/docs/releases/1.4-alpha-1.txt +++ b/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 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. diff --git a/docs/releases/1.4-beta-1.txt b/docs/releases/1.4-beta-1.txt index 674aa0e9445..d6074ba0ef5 100644 --- a/docs/releases/1.4-beta-1.txt +++ b/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 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. diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index c2b26d0aa01..054a89a7784 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -1318,7 +1318,7 @@ names, like ``django.contrib.*``. The expansion was performed by a filesystem-based implementation of ``from 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. diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt index aef8842e360..ab8115e1cdf 100644 --- a/docs/releases/1.7.txt +++ b/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 diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt index 12b11822e12..6ad93a3a843 100644 --- a/docs/topics/auth/passwords.txt +++ b/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 diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index 96e89bc3a55..97c54918cda 100644 --- a/docs/topics/cache.txt +++ b/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 diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt index 57c7a0d02fc..9c5527dac57 100644 --- a/docs/topics/class-based-views/generic-display.txt +++ b/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. diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt index 8e7b4561e9e..f79bf1160e7 100644 --- a/docs/topics/class-based-views/mixins.txt +++ b/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()``. diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt index 66118631e05..9d0663434d7 100644 --- a/docs/topics/db/queries.txt +++ b/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:: diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt index 6222f342b42..bd312562cbe 100644 --- a/docs/topics/forms/modelforms.txt +++ b/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. diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt index 7ab01352592..1d1d278f3f6 100644 --- a/docs/topics/migrations.txt +++ b/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 diff --git a/docs/topics/performance.txt b/docs/topics/performance.txt index 37c61bc3430..65835fb35ff 100644 --- a/docs/topics/performance.txt +++ b/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). diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index 14ba1b2cd2f..d6e60458f31 100644 --- a/docs/topics/testing/tools.txt +++ b/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.