Fixed spelling mistakes in docs.
This commit is contained in:
parent
8137215973
commit
1f5f015c32
|
@ -408,7 +408,7 @@ Anssi Kääriäinen
|
||||||
Django as a great match for that use case.
|
Django as a great match for that use case.
|
||||||
|
|
||||||
Anssi is interested in developing the object relational mapper (ORM) and
|
Anssi is interested in developing the object relational mapper (ORM) and
|
||||||
all related features. He's also a fan of benckmarking and he tries keep
|
all related features. He's also a fan of benchmarking and he tries keep
|
||||||
Django as fast as possible.
|
Django as fast as possible.
|
||||||
|
|
||||||
Florian Apolloner
|
Florian Apolloner
|
||||||
|
|
|
@ -22,7 +22,7 @@ translating or add a language that isn't yet translated, here's what to do:
|
||||||
|
|
||||||
* Make sure you read the notes about :ref:`specialties-of-django-i18n`.
|
* Make sure you read the notes about :ref:`specialties-of-django-i18n`.
|
||||||
|
|
||||||
* Signup at `Transifex`_ and visit the `Django project page`_.
|
* Sign up at `Transifex`_ and visit the `Django project page`_.
|
||||||
|
|
||||||
* On the `Django project page`_, choose the language you want to work on,
|
* On the `Django project page`_, choose the language you want to work on,
|
||||||
**or** -- in case the language doesn't exist yet --
|
**or** -- in case the language doesn't exist yet --
|
||||||
|
@ -37,7 +37,7 @@ translating or add a language that isn't yet translated, here's what to do:
|
||||||
|
|
||||||
* Once you are a member of a team choose the translation resource you
|
* Once you are a member of a team choose the translation resource you
|
||||||
want to update on the team page. For example the "core" resource refers
|
want to update on the team page. For example the "core" resource refers
|
||||||
to the translation catalogue that contains all non-contrib translations.
|
to the translation catalog that contains all non-contrib translations.
|
||||||
Each of the contrib apps also have a resource (prefixed with "contrib").
|
Each of the contrib apps also have a resource (prefixed with "contrib").
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
|
@ -435,7 +435,7 @@ this case, we've set the :attr:`~django.db.models.Field.default` value of
|
||||||
Finally, note a relationship is defined, using
|
Finally, note a relationship is defined, using
|
||||||
:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
|
:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
|
||||||
to a single ``Question``. Django supports all the common database relationships:
|
to a single ``Question``. Django supports all the common database relationships:
|
||||||
many-to-ones, many-to-manys and one-to-ones.
|
many-to-one, many-to-many and one-to-one.
|
||||||
|
|
||||||
.. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path
|
.. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path
|
||||||
|
|
||||||
|
@ -591,12 +591,12 @@ Now, run :djadmin:`migrate` again to create those model tables in your database:
|
||||||
The :djadmin:`migrate` command takes all the migrations that haven't been
|
The :djadmin:`migrate` command takes all the migrations that haven't been
|
||||||
applied (Django tracks which ones are applied using a special table in your
|
applied (Django tracks which ones are applied using a special table in your
|
||||||
database called ``django_migrations``) and runs them against your database -
|
database called ``django_migrations``) and runs them against your database -
|
||||||
essentially, synchronising the changes you made to your models with the schema
|
essentially, synchronizing the changes you made to your models with the schema
|
||||||
in the database.
|
in the database.
|
||||||
|
|
||||||
Migrations are very powerful and let you change your models over time, as you
|
Migrations are very powerful and let you change your models over time, as you
|
||||||
develop your project, without the need to delete your database or tables and
|
develop your project, without the need to delete your database or tables and
|
||||||
make new ones - it specialises in upgrading your database live, without
|
make new ones - it specializes in upgrading your database live, without
|
||||||
losing data. We'll cover them in more depth in a later part of the tutorial,
|
losing data. We'll cover them in more depth in a later part of the tutorial,
|
||||||
but for now, remember the three-step guide to making model changes:
|
but for now, remember the three-step guide to making model changes:
|
||||||
|
|
||||||
|
|
|
@ -157,7 +157,7 @@ Configurable attributes
|
||||||
|
|
||||||
Short name for the application, e.g. ``'admin'``
|
Short name for the application, e.g. ``'admin'``
|
||||||
|
|
||||||
This attribute allows relabelling an application when two applications
|
This attribute allows relabeling an application when two applications
|
||||||
have conflicting labels. It defaults to the last component of ``name``.
|
have conflicting labels. It defaults to the last component of ``name``.
|
||||||
It should be a valid Python identifier.
|
It should be a valid Python identifier.
|
||||||
|
|
||||||
|
|
|
@ -11,7 +11,7 @@ The :class:`GeoIP` object is a ctypes wrapper for the
|
||||||
`MaxMind GeoIP C API`__. [#]_
|
`MaxMind GeoIP C API`__. [#]_
|
||||||
|
|
||||||
In order to perform IP-based geolocation, the :class:`GeoIP` object requires
|
In order to perform IP-based geolocation, the :class:`GeoIP` object requires
|
||||||
the GeoIP C libary and either the GeoIP `Country`__ or `City`__
|
the GeoIP C library and either the GeoIP `Country`__ or `City`__
|
||||||
datasets in binary format (the CSV files will not work!). These datasets may be
|
datasets in binary format (the CSV files will not work!). These datasets may be
|
||||||
`downloaded from MaxMind`__. Grab the ``GeoLiteCountry/GeoIP.dat.gz`` and
|
`downloaded from MaxMind`__. Grab the ``GeoLiteCountry/GeoIP.dat.gz`` and
|
||||||
``GeoLiteCity.dat.gz`` files and unzip them in a directory corresponding to what
|
``GeoLiteCity.dat.gz`` files and unzip them in a directory corresponding to what
|
||||||
|
@ -96,7 +96,7 @@ Defaults to ``'GeoLiteCity.dat'``.
|
||||||
The ``GeoIP`` object does not require any parameters to use the default
|
The ``GeoIP`` object does not require any parameters to use the default
|
||||||
settings. However, at the very least the :setting:`GEOIP_PATH` setting
|
settings. However, at the very least the :setting:`GEOIP_PATH` setting
|
||||||
should be set with the path of the location of your GeoIP data sets. The
|
should be set with the path of the location of your GeoIP data sets. The
|
||||||
following intialization keywords may be used to customize any of the
|
following initialization keywords may be used to customize any of the
|
||||||
defaults.
|
defaults.
|
||||||
|
|
||||||
=================== =======================================================
|
=================== =======================================================
|
||||||
|
|
|
@ -173,7 +173,7 @@ readers sign up to get notifications when news happens. It's pretty basic: A
|
||||||
reader signs up on a Web form and immediately gets an email saying,
|
reader signs up on a Web form and immediately gets an email saying,
|
||||||
"Thanks for your subscription."
|
"Thanks for your subscription."
|
||||||
|
|
||||||
It'd be inefficient and redundant to implement this signup-processing code
|
It'd be inefficient and redundant to implement this sign up processing code
|
||||||
twice, so the sites use the same code behind the scenes. But the "thank you for
|
twice, so the sites use the same code behind the scenes. But the "thank you for
|
||||||
signing up" notice needs to be different for each site. By using
|
signing up" notice needs to be different for each site. By using
|
||||||
:class:`~django.contrib.sites.models.Site`
|
:class:`~django.contrib.sites.models.Site`
|
||||||
|
|
|
@ -554,7 +554,7 @@ are passed into the query. So the :lookup:`iexact` filter will behave exactly
|
||||||
the same as the :lookup:`exact` filter in these cases.
|
the same as the :lookup:`exact` filter in these cases.
|
||||||
|
|
||||||
Some possible workarounds for this are `documented at sqlite.org`_, but they
|
Some possible workarounds for this are `documented at sqlite.org`_, but they
|
||||||
aren't utilised by the default SQLite backend in Django, as incorporating them
|
aren't utilized by the default SQLite backend in Django, as incorporating them
|
||||||
would be fairly difficult to do robustly. Thus, Django exposes the default
|
would be fairly difficult to do robustly. Thus, Django exposes the default
|
||||||
SQLite behavior and you should be aware of this when doing case-insensitive or
|
SQLite behavior and you should be aware of this when doing case-insensitive or
|
||||||
substring filtering.
|
substring filtering.
|
||||||
|
|
|
@ -784,7 +784,7 @@ Write stderr to the *FILE* file.
|
||||||
|
|
||||||
``umask=UMASK``
|
``umask=UMASK``
|
||||||
|
|
||||||
Umask to use when daemonizing. The value is interpeted as an octal number
|
Umask to use when daemonizing. The value is interpreted as an octal number
|
||||||
(default value is ``022``).
|
(default value is ``022``).
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
|
|
|
@ -12,7 +12,7 @@ your migrations; that's why they're declarative, as it means Django can
|
||||||
easily load them all into memory and run through them without touching
|
easily load them all into memory and run through them without touching
|
||||||
the database to work out what your project should look like.
|
the database to work out what your project should look like.
|
||||||
|
|
||||||
There are also more specialised Operation objects which are for things like
|
There are also more specialized Operation objects which are for things like
|
||||||
:ref:`data migrations <data-migrations>` and for advanced manual database
|
:ref:`data migrations <data-migrations>` and for advanced manual database
|
||||||
manipulation. You can also write your own Operation classes if you want
|
manipulation. You can also write your own Operation classes if you want
|
||||||
to encapsulate a custom change you commonly make.
|
to encapsulate a custom change you commonly make.
|
||||||
|
@ -221,7 +221,7 @@ SeparateDatabaseAndState
|
||||||
|
|
||||||
SeparateDatabaseAndState(database_operations=None, state_operations=None)
|
SeparateDatabaseAndState(database_operations=None, state_operations=None)
|
||||||
|
|
||||||
A highly specalist operation that let you mix and match the database
|
A highly specialist operation that let you mix and match the database
|
||||||
(schema-changing) and state (autodetector-powering) aspects of operations.
|
(schema-changing) and state (autodetector-powering) aspects of operations.
|
||||||
|
|
||||||
It accepts two list of operations, and when asked to apply state will use the
|
It accepts two list of operations, and when asked to apply state will use the
|
||||||
|
|
|
@ -610,7 +610,7 @@ in ``get_absolute_url()`` and have all your other code call that one place.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
The string you return from ``get_absolute_url()`` **must** contain only
|
The string you return from ``get_absolute_url()`` **must** contain only
|
||||||
ASCII characters (required by the URI specfication, :rfc:`2396`) and be
|
ASCII characters (required by the URI specification, :rfc:`2396`) and be
|
||||||
URL-encoded, if necessary.
|
URL-encoded, if necessary.
|
||||||
|
|
||||||
Code and templates calling ``get_absolute_url()`` should be able to use the
|
Code and templates calling ``get_absolute_url()`` should be able to use the
|
||||||
|
|
|
@ -2045,7 +2045,7 @@ Case-insensitive exact match.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
If the value provided for comparision is ``None``, it will be interpreted
|
If the value provided for comparison is ``None``, it will be interpreted
|
||||||
as an SQL ``NULL`` (see :lookup:`isnull` for more details).
|
as an SQL ``NULL`` (see :lookup:`isnull` for more details).
|
||||||
|
|
||||||
Example::
|
Example::
|
||||||
|
|
|
@ -1800,7 +1800,7 @@ SILENCED_SYSTEM_CHECKS
|
||||||
|
|
||||||
Default: ``[]``
|
Default: ``[]``
|
||||||
|
|
||||||
A list of identifers of messages generated by the system check framework
|
A list of identifiers of messages generated by the system check framework
|
||||||
(i.e. ``["models.W001"]``) that you wish to permanently acknowledge and ignore.
|
(i.e. ``["models.W001"]``) that you wish to permanently acknowledge and ignore.
|
||||||
Silenced warnings will no longer be output to the console; silenced errors
|
Silenced warnings will no longer be output to the console; silenced errors
|
||||||
will still be printed, but will not prevent management commands from running.
|
will still be printed, but will not prevent management commands from running.
|
||||||
|
|
|
@ -900,7 +900,7 @@ For a complete discussion on the usage of the following see the
|
||||||
:func:`django.utils.translation.activate` to fetch the translation object
|
:func:`django.utils.translation.activate` to fetch the translation object
|
||||||
for a given language, installing it as the translation object for the
|
for a given language, installing it as the translation object for the
|
||||||
current thread and reinstall the previous active language on exit.
|
current thread and reinstall the previous active language on exit.
|
||||||
Optionally it can simply deinstall the temporary translation on exit with
|
Optionally it can simply uninstall the temporary translation on exit with
|
||||||
:func:`django.utils.translation.deactivate` if the deactivate argument is
|
:func:`django.utils.translation.deactivate` if the deactivate argument is
|
||||||
True. If you pass None as the language argument, a NullTranslations()
|
True. If you pass None as the language argument, a NullTranslations()
|
||||||
instance is installed while the context is active.
|
instance is installed while the context is active.
|
||||||
|
|
|
@ -16,8 +16,8 @@ wanting to work on production-level applications that use Django.
|
||||||
|
|
||||||
However, it's not the 1.0 release, and we'll be introducing further changes
|
However, it's not the 1.0 release, and we'll be introducing further changes
|
||||||
before 1.0. For a clear look at which areas of the framework will change (and
|
before 1.0. For a clear look at which areas of the framework will change (and
|
||||||
which ones will *not* change) before 1.0, see the api-stability.txt file, which
|
which ones will *not* change) before 1.0, see the ``api-stability.txt`` file,
|
||||||
lives in the docs/ directory of the distribution.
|
which lives in the docs/ directory of the distribution.
|
||||||
|
|
||||||
You may have a need to use some of the features that are marked as
|
You may have a need to use some of the features that are marked as
|
||||||
"subject to API change" in that document, but that's OK with us as long as it's
|
"subject to API change" in that document, but that's OK with us as long as it's
|
||||||
|
@ -120,4 +120,3 @@ Thanks for using Django!
|
||||||
|
|
||||||
The Django Team
|
The Django Team
|
||||||
July 2006
|
July 2006
|
||||||
|
|
||||||
|
|
|
@ -97,7 +97,7 @@ wherever you would have historically used::
|
||||||
|
|
||||||
import unittest
|
import unittest
|
||||||
|
|
||||||
If you want to continue to use the base unittest libary, you can --
|
If you want to continue to use the base unittest library, you can --
|
||||||
you just won't get any of the nice new unittest2 features.
|
you just won't get any of the nice new unittest2 features.
|
||||||
|
|
||||||
.. _unittest2: http://pypi.python.org/pypi/unittest2
|
.. _unittest2: http://pypi.python.org/pypi/unittest2
|
||||||
|
|
|
@ -433,7 +433,7 @@ Cache
|
||||||
instance per thread. It supersedes :func:`django.core.cache.get_cache` which
|
instance per thread. It supersedes :func:`django.core.cache.get_cache` which
|
||||||
is now deprecated.
|
is now deprecated.
|
||||||
|
|
||||||
* If you instanciate cache backends directly, be aware that they aren't
|
* If you instantiate cache backends directly, be aware that they aren't
|
||||||
thread-safe any more, as :data:`django.core.cache.caches` now yields
|
thread-safe any more, as :data:`django.core.cache.caches` now yields
|
||||||
different instances per thread.
|
different instances per thread.
|
||||||
|
|
||||||
|
|
|
@ -219,7 +219,7 @@ processing to work on a particular object, identified from the URL,
|
||||||
we'll want the functionality provided by
|
we'll want the functionality provided by
|
||||||
:class:`~django.views.generic.detail.SingleObjectMixin`.
|
:class:`~django.views.generic.detail.SingleObjectMixin`.
|
||||||
|
|
||||||
We'll demonstrate this with the publisher modelling we used in the
|
We'll demonstrate this with the publisher modeling we used in the
|
||||||
:doc:`generic class-based views introduction<generic-display>`.
|
:doc:`generic class-based views introduction<generic-display>`.
|
||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
|
@ -588,8 +588,8 @@ The ``manage_articles.html`` template might look like this:
|
||||||
</table>
|
</table>
|
||||||
</form>
|
</form>
|
||||||
|
|
||||||
However the above can be slightly shortcutted and let the formset itself deal
|
However there's a slight shortcut for the above by letting the formset itself
|
||||||
with the management form:
|
deal with the management form:
|
||||||
|
|
||||||
.. code-block:: html+django
|
.. code-block:: html+django
|
||||||
|
|
||||||
|
|
|
@ -442,7 +442,7 @@ available at the top level of a module it is not serializable.
|
||||||
``kwargs`` should be a dict of keyword arguments to pass to your class'
|
``kwargs`` should be a dict of keyword arguments to pass to your class'
|
||||||
``__init__`` method. Every value should itself be serializable.
|
``__init__`` method. Every value should itself be serializable.
|
||||||
|
|
||||||
Django will write out the value as an instatiation of your class with the
|
Django will write out the value as an instantiation of your class with the
|
||||||
given arguments, similar to the way it writes out references to Django fields.
|
given arguments, similar to the way it writes out references to Django fields.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -354,7 +354,7 @@ Attributes
|
||||||
the individual tests and format the results. By default it is set to
|
the individual tests and format the results. By default it is set to
|
||||||
``unittest.TextTestRunner``. Despite the unfortunate similarity in
|
``unittest.TextTestRunner``. Despite the unfortunate similarity in
|
||||||
naming conventions, this is not the same type of class as
|
naming conventions, this is not the same type of class as
|
||||||
``DiscoverRunner``, which covers a broader set of responsibilites. You
|
``DiscoverRunner``, which covers a broader set of responsibilities. You
|
||||||
can override this attribute to modify the way tests are run and reported.
|
can override this attribute to modify the way tests are run and reported.
|
||||||
|
|
||||||
.. attribute:: DiscoverRunner.test_loader
|
.. attribute:: DiscoverRunner.test_loader
|
||||||
|
|
Loading…
Reference in New Issue