mirror of https://github.com/django/django.git
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.
|
||||
|
||||
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.
|
||||
|
||||
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`.
|
||||
|
||||
* 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,
|
||||
**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
|
||||
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").
|
||||
|
||||
.. 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
|
||||
:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
|
||||
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
|
||||
|
||||
|
@ -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
|
||||
applied (Django tracks which ones are applied using a special table in your
|
||||
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.
|
||||
|
||||
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
|
||||
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,
|
||||
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'``
|
||||
|
||||
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``.
|
||||
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`__. [#]_
|
||||
|
||||
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
|
||||
`downloaded from MaxMind`__. Grab the ``GeoLiteCountry/GeoIP.dat.gz`` and
|
||||
``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
|
||||
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
|
||||
following intialization keywords may be used to customize any of the
|
||||
following initialization keywords may be used to customize any of the
|
||||
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,
|
||||
"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
|
||||
signing up" notice needs to be different for each site. By using
|
||||
: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.
|
||||
|
||||
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
|
||||
SQLite behavior and you should be aware of this when doing case-insensitive or
|
||||
substring filtering.
|
||||
|
|
|
@ -784,7 +784,7 @@ Write stderr to the *FILE* file.
|
|||
|
||||
``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``).
|
||||
|
||||
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
|
||||
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
|
||||
manipulation. You can also write your own Operation classes if you want
|
||||
to encapsulate a custom change you commonly make.
|
||||
|
@ -221,7 +221,7 @@ SeparateDatabaseAndState
|
|||
|
||||
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.
|
||||
|
||||
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::
|
||||
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.
|
||||
|
||||
Code and templates calling ``get_absolute_url()`` should be able to use the
|
||||
|
|
|
@ -2045,7 +2045,7 @@ Case-insensitive exact match.
|
|||
|
||||
.. 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).
|
||||
|
||||
Example::
|
||||
|
|
|
@ -1800,7 +1800,7 @@ SILENCED_SYSTEM_CHECKS
|
|||
|
||||
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.
|
||||
Silenced warnings will no longer be output to the console; silenced errors
|
||||
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
|
||||
for a given language, installing it as the translation object for the
|
||||
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
|
||||
True. If you pass None as the language argument, a NullTranslations()
|
||||
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
|
||||
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
|
||||
lives in the docs/ directory of the distribution.
|
||||
which ones will *not* change) before 1.0, see the ``api-stability.txt`` file,
|
||||
which lives in the docs/ directory of the distribution.
|
||||
|
||||
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
|
||||
|
@ -120,4 +120,3 @@ Thanks for using Django!
|
|||
|
||||
The Django Team
|
||||
July 2006
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ wherever you would have historically used::
|
|||
|
||||
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.
|
||||
|
||||
.. _unittest2: http://pypi.python.org/pypi/unittest2
|
||||
|
|
|
@ -433,7 +433,7 @@ Cache
|
|||
instance per thread. It supersedes :func:`django.core.cache.get_cache` which
|
||||
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
|
||||
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
|
||||
: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>`.
|
||||
|
||||
.. code-block:: python
|
||||
|
|
|
@ -588,8 +588,8 @@ The ``manage_articles.html`` template might look like this:
|
|||
</table>
|
||||
</form>
|
||||
|
||||
However the above can be slightly shortcutted and let the formset itself deal
|
||||
with the management form:
|
||||
However there's a slight shortcut for the above by letting the formset itself
|
||||
deal with the management form:
|
||||
|
||||
.. 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'
|
||||
``__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.
|
||||
|
||||
|
||||
|
|
|
@ -354,7 +354,7 @@ Attributes
|
|||
the individual tests and format the results. By default it is set to
|
||||
``unittest.TextTestRunner``. Despite the unfortunate similarity in
|
||||
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.
|
||||
|
||||
.. attribute:: DiscoverRunner.test_loader
|
||||
|
|
Loading…
Reference in New Issue