Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixed doc typos.

  • Loading branch information...
commit 7f2505ad9e27962ecbd61d2ce26ad691727404a4 1 parent 55fb162
@timgraham timgraham authored
Showing with 38 additions and 38 deletions.
  1. +1 −1  docs/internals/contributing/triaging-tickets.txt
  2. +1 −1  docs/internals/security.txt
  3. +1 −1  docs/ref/contrib/admin/index.txt
  4. +1 −1  docs/ref/contrib/gis/geoquerysets.txt
  5. +1 −1  docs/ref/contrib/gis/install/postgis.txt
  6. +1 −1  docs/ref/contrib/staticfiles.txt
  7. +2 −2 docs/ref/databases.txt
  8. +2 −2 docs/ref/django-admin.txt
  9. +1 −1  docs/ref/forms/fields.txt
  10. +3 −3 docs/ref/migration-operations.txt
  11. +2 −2 docs/ref/models/custom-lookups.txt
  12. +1 −1  docs/ref/models/fields.txt
  13. +1 −1  docs/ref/templates/api.txt
  14. +1 −1  docs/releases/1.2.txt
  15. +1 −1  docs/releases/1.4-alpha-1.txt
  16. +1 −1  docs/releases/1.4-beta-1.txt
  17. +1 −1  docs/releases/1.4.txt
  18. +1 −1  docs/releases/1.7.txt
  19. +2 −2 docs/topics/auth/passwords.txt
  20. +1 −1  docs/topics/cache.txt
  21. +1 −1  docs/topics/class-based-views/generic-display.txt
  22. +1 −1  docs/topics/class-based-views/mixins.txt
  23. +2 −2 docs/topics/db/queries.txt
  24. +1 −1  docs/topics/forms/modelforms.txt
  25. +4 −4 docs/topics/migrations.txt
  26. +2 −2 docs/topics/performance.txt
  27. +1 −1  docs/topics/testing/tools.txt
View
2  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"
View
2  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.
View
2  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.
View
2  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.
View
2  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/
View
2  docs/ref/contrib/staticfiles.txt
@@ -321,7 +321,7 @@ CachedStaticFilesStorage
but uses Django's :doc:`caching framework</topics/cache>` 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
View
4 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
View
4 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`.
View
2  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`
View
6 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
View
4 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)
View
2  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
View
2  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
View
2  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 <http://postgis.refractions.net/documentation/manual-1.5/>`_.
-New features include suppport for the :ref:`geography type <geography-type>`
+New features include support for the :ref:`geography type <geography-type>`
and enabling of :ref:`distance queries <distance-queries>`
with non-point geometries on geographic coordinate systems.
View
2  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 <package> 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.
View
2  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 <package> 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.
View
2  docs/releases/1.4.txt
@@ -1318,7 +1318,7 @@ names, like ``django.contrib.*``. The expansion was performed by a
filesystem-based implementation of ``from <package> 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.
View
2  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
View
4 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
View
2  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
View
2  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.
View
2  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()``.
View
4 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::
View
2  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.
View
8 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
View
4 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).
View
2  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.
Please sign in to comment.
Something went wrong with that request. Please try again.