diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt index 92f9406c5b..3f4033f27e 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 409e298dc9..6d53c3dff7 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 a7746e3deb..47efa42c16 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 5f1d3521eb..b27781bdc8 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 75597fbb38..a248d33690 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 79ce21ecda..961abf5c5d 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 f7c4f0f9fb..33f47914c2 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 e2b4daec44..724be51837 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 f48f9ff4ad..c2194cc512 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 70406adc22..cb77d7d93f 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 b800897712..8aa2f792e5 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 7c95f0fd70..4e02c66ca0 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 5701b1a9d1..08c86d99fc 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 387f2508ef..b728e3bfe4 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 ebd0084469..6dce90bd8c 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 674aa0e944..d6074ba0ef 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 c2b26d0aa0..054a89a778 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 aef8842e36..ab8115e1cd 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 12b11822e1..6ad93a3a84 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 96e89bc3a5..97c54918cd 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 57c7a0d02f..9c5527dac5 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 8e7b4561e9..f79bf1160e 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 66118631e0..9d0663434d 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 6222f342b4..bd312562cb 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 7ab0135259..1d1d278f3f 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 37c61bc343..65835fb35f 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 14ba1b2cd2..d6e60458f3 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.