Fixed #15992 -- Added more references to settings. Thanks, aaugustin.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16290 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jannis Leidel
parent
61da3cc47a
commit
49f57a5d28
|
|
@ -8,8 +8,8 @@ The login cookie isn't being set correctly, because the domain of the cookie
|
|||
sent out by Django doesn't match the domain in your browser. Try these two
|
||||
things:
|
||||
|
||||
* Set the ``SESSION_COOKIE_DOMAIN`` setting in your admin config file
|
||||
to match your domain. For example, if you're going to
|
||||
* Set the :setting:`SESSION_COOKIE_DOMAIN` setting in your admin config
|
||||
file to match your domain. For example, if you're going to
|
||||
"http://www.example.com/admin/" in your browser, in
|
||||
"myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.example.com'``.
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ things:
|
|||
don't have dots in them. If you're running the admin site on "localhost"
|
||||
or another domain that doesn't have a dot in it, try going to
|
||||
"localhost.localdomain" or "127.0.0.1". And set
|
||||
``SESSION_COOKIE_DOMAIN`` accordingly.
|
||||
:setting:`SESSION_COOKIE_DOMAIN` accordingly.
|
||||
|
||||
I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
|
||||
-----------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -6,16 +6,17 @@ FAQ: Databases and models
|
|||
How can I see the raw SQL queries Django is running?
|
||||
----------------------------------------------------
|
||||
|
||||
Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do
|
||||
this::
|
||||
Make sure your Django :setting:`DEBUG` setting is set to ``True``.
|
||||
Then, just do this::
|
||||
|
||||
>>> from django.db import connection
|
||||
>>> connection.queries
|
||||
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
|
||||
'time': '0.002'}]
|
||||
|
||||
``connection.queries`` is only available if ``DEBUG`` is ``True``. It's a list
|
||||
of dictionaries in order of query execution. Each dictionary has the following::
|
||||
``connection.queries`` is only available if :setting:`DEBUG` is ``True``.
|
||||
It's a list of dictionaries in order of query execution. Each dictionary has
|
||||
the following::
|
||||
|
||||
``sql`` -- The raw SQL statement
|
||||
``time`` -- How long the statement took to execute, in seconds.
|
||||
|
|
@ -89,13 +90,13 @@ Why is Django leaking memory?
|
|||
|
||||
Django isn't known to leak memory. If you find your Django processes are
|
||||
allocating more and more memory, with no sign of releasing it, check to make
|
||||
sure your ``DEBUG`` setting is set to ``False``. If ``DEBUG`` is ``True``, then
|
||||
Django saves a copy of every SQL statement it has executed.
|
||||
sure your :setting:`DEBUG` setting is set to ``False``. If :setting:`DEBUG`
|
||||
is ``True``, then Django saves a copy of every SQL statement it has executed.
|
||||
|
||||
(The queries are saved in ``django.db.connection.queries``. See
|
||||
`How can I see the raw SQL queries Django is running?`_.)
|
||||
|
||||
To fix the problem, set ``DEBUG`` to ``False``.
|
||||
To fix the problem, set :setting:`DEBUG` to ``False``.
|
||||
|
||||
If you need to clear the query list manually at any point in your functions,
|
||||
just call ``reset_queries()``, like this::
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ message file specific to the project you are composing. The choice is yours.
|
|||
|
||||
All message file repositories are structured the same way. They are:
|
||||
|
||||
* All paths listed in ``LOCALE_PATHS`` in your settings file are
|
||||
* All paths listed in :setting:`LOCALE_PATHS` in your settings file are
|
||||
searched for ``<language>/LC_MESSAGES/django.(po|mo)``
|
||||
* ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)`` --
|
||||
deprecated, see above.
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ details for each database:
|
|||
|
||||
You will also need to ensure that your database uses UTF-8 as the default
|
||||
character set. If your database server doesn't use UTF-8 as a default charset,
|
||||
you will need to include a value for ``TEST_CHARSET`` in the settings
|
||||
you will need to include a value for :setting:`TEST_CHARSET` in the settings
|
||||
dictionary for the applicable database.
|
||||
|
||||
Running only some of the tests
|
||||
|
|
|
|||
|
|
@ -170,9 +170,9 @@ their deprecation, as per the :ref:`Django deprecation policy
|
|||
and :class:`django.contrib.auth.context_processors.PermLookupDict`,
|
||||
respectively.
|
||||
|
||||
* The ``MEDIA_URL`` or ``STATIC_URL`` settings are required to end
|
||||
with a trailing slash to ensure there is a consistent way to
|
||||
combine paths in templates.
|
||||
* The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings are
|
||||
required to end with a trailing slash to ensure there is a consistent
|
||||
way to combine paths in templates.
|
||||
|
||||
* 1.6
|
||||
* The compatibility modules ``django.utils.copycompat`` and
|
||||
|
|
|
|||
|
|
@ -1765,7 +1765,7 @@ In this example, we register the default ``AdminSite`` instance
|
|||
)
|
||||
|
||||
Above we used ``admin.autodiscover()`` to automatically load the
|
||||
``INSTALLED_APPS`` admin.py modules.
|
||||
:setting:`INSTALLED_APPS` admin.py modules.
|
||||
|
||||
In this example, we register the ``AdminSite`` instance
|
||||
``myproject.admin.admin_site`` at the URL ``/myadmin/`` ::
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ the GeoIP C libary 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 ``GeoIP.dat.gz`` and ``GeoLiteCity.dat.gz``
|
||||
and unzip them in a directory corresponding to what you set
|
||||
``GEOIP_PATH`` with in your settings. See the example and reference below
|
||||
:setting:`GEOIP_PATH` with in your settings. See the example and reference below
|
||||
for more details.
|
||||
|
||||
__ http://www.maxmind.com/app/c
|
||||
|
|
|
|||
|
|
@ -184,9 +184,9 @@ If using a binary package of GEOS (e.g., on Ubuntu), you may need to :ref:`binut
|
|||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If your GEOS library is in a non-standard location, or you don't want to
|
||||
modify the system's library path then the :setting:`GEOS_LIBRARY_PATH` setting
|
||||
may be added to your Django settings file with the full path to the GEOS
|
||||
C library. For example::
|
||||
modify the system's library path then the :setting:`GEOS_LIBRARY_PATH`
|
||||
setting may be added to your Django settings file with the full path to the
|
||||
GEOS C library. For example::
|
||||
|
||||
GEOS_LIBRARY_PATH = '/home/bob/local/lib/libgeos_c.so'
|
||||
|
||||
|
|
@ -592,8 +592,8 @@ Now, the ``spatialite`` command can be used to initialize a spatial database::
|
|||
__ http://www.gaia-gis.it/spatialite/resources.html
|
||||
|
||||
|
||||
Add ``django.contrib.gis`` to ``INSTALLED_APPS``
|
||||
------------------------------------------------
|
||||
Add ``django.contrib.gis`` to :setting:`INSTALLED_APPS`
|
||||
-------------------------------------------------------
|
||||
|
||||
Like other Django contrib applications, you will *only* need to add
|
||||
:mod:`django.contrib.gis` to :setting:`INSTALLED_APPS` in your settings.
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ those packages have.
|
|||
|
||||
For most of these add-ons -- specifically, the add-ons that include either
|
||||
models or template tags -- you'll need to add the package name (e.g.,
|
||||
``'django.contrib.admin'``) to your ``INSTALLED_APPS`` setting and re-run
|
||||
``manage.py syncdb``.
|
||||
``'django.contrib.admin'``) to your :setting:`INSTALLED_APPS` setting and
|
||||
re-run ``manage.py syncdb``.
|
||||
|
||||
.. _"batteries included" philosophy: http://docs.python.org/tutorial/stdlib.html#batteries-included
|
||||
|
||||
|
|
|
|||
|
|
@ -386,7 +386,7 @@ SESSION_COOKIE_DOMAIN
|
|||
Default: ``None``
|
||||
|
||||
The storage backends that use cookies -- ``CookieStorage`` and
|
||||
``FallbackStorage`` -- use the value of ``SESSION_COOKIE_DOMAIN`` in
|
||||
``FallbackStorage`` -- use the value of :setting:`SESSION_COOKIE_DOMAIN` in
|
||||
setting their cookies. See the :doc:`settings documentation </ref/settings>`
|
||||
for more information on how this works and why you might need to set it.
|
||||
|
||||
|
|
|
|||
|
|
@ -262,8 +262,8 @@ Connection settings are used in this order:
|
|||
:setting:`HOST`, :setting:`PORT`
|
||||
3. MySQL option files.
|
||||
|
||||
In other words, if you set the name of the database in ``OPTIONS``,
|
||||
this will take precedence over ``NAME``, which would override
|
||||
In other words, if you set the name of the database in :setting:`OPTIONS`,
|
||||
this will take precedence over :setting:`NAME`, which would override
|
||||
anything in a `MySQL option file`_.
|
||||
|
||||
Here's a sample configuration which uses a MySQL option file::
|
||||
|
|
@ -574,7 +574,7 @@ Your Django settings.py file should look something like this for Oracle::
|
|||
|
||||
If you don't use a ``tnsnames.ora`` file or a similar naming method that
|
||||
recognizes the SID ("xe" in this example), then fill in both
|
||||
``HOST`` and ``PORT`` like so::
|
||||
:setting:`HOST` and :setting:`PORT` like so::
|
||||
|
||||
DATABASES = {
|
||||
'default': {
|
||||
|
|
@ -587,7 +587,7 @@ recognizes the SID ("xe" in this example), then fill in both
|
|||
}
|
||||
}
|
||||
|
||||
You should supply both ``HOST`` and ``PORT``, or leave both
|
||||
You should supply both :setting:`HOST` and :setting:`PORT`, or leave both
|
||||
as empty strings.
|
||||
|
||||
Threaded option
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ App names
|
|||
---------
|
||||
|
||||
Many commands take a list of "app names." An "app name" is the basename of
|
||||
the package containing your models. For example, if your ``INSTALLED_APPS``
|
||||
the package containing your models. For example, if your :setting:`INSTALLED_APPS`
|
||||
contains the string ``'mysite.blog'``, the app name is ``blog``.
|
||||
|
||||
Determining the version
|
||||
|
|
@ -126,7 +126,7 @@ dbshell
|
|||
|
||||
Runs the command-line client for the database engine specified in your
|
||||
``ENGINE`` setting, with the connection parameters specified in your
|
||||
``USER``, ``PASSWORD``, etc., settings.
|
||||
:setting:`USER`, :setting:`PASSWORD`, etc., settings.
|
||||
|
||||
* For PostgreSQL, this runs the ``psql`` command-line client.
|
||||
* For MySQL, this runs the ``mysql`` command-line client.
|
||||
|
|
@ -151,8 +151,9 @@ Displays differences between the current settings file and Django's default
|
|||
settings.
|
||||
|
||||
Settings that don't appear in the defaults are followed by ``"###"``. For
|
||||
example, the default settings don't define ``ROOT_URLCONF``, so
|
||||
``ROOT_URLCONF`` is followed by ``"###"`` in the output of ``diffsettings``.
|
||||
example, the default settings don't define :setting:`ROOT_URLCONF`, so
|
||||
:setting:`ROOT_URLCONF` is followed by ``"###"`` in the output of
|
||||
``diffsettings``.
|
||||
|
||||
Note that Django's default settings live in ``django/conf/global_settings.py``,
|
||||
if you're ever curious to see the full list of defaults.
|
||||
|
|
@ -245,7 +246,7 @@ inspectdb
|
|||
.. django-admin:: inspectdb
|
||||
|
||||
Introspects the database tables in the database pointed-to by the
|
||||
``NAME`` setting and outputs a Django model module (a ``models.py``
|
||||
:setting:`NAME` setting and outputs a Django model module (a ``models.py``
|
||||
file) to standard output.
|
||||
|
||||
Use this if you have a legacy database with which you'd like to use Django.
|
||||
|
|
@ -309,7 +310,7 @@ fixture can be distributed over multiple directories, in multiple applications.
|
|||
Django will search in three locations for fixtures:
|
||||
|
||||
1. In the ``fixtures`` directory of every installed application
|
||||
2. In any directory named in the ``FIXTURE_DIRS`` setting
|
||||
2. In any directory named in the :setting:`FIXTURE_DIRS` setting
|
||||
3. In the literal path named by the fixture
|
||||
|
||||
Django will load any and all fixtures it finds in these locations that match
|
||||
|
|
@ -340,7 +341,7 @@ directories will be included in the search path. For example::
|
|||
|
||||
would search ``<appname>/fixtures/foo/bar/mydata.json`` for each installed
|
||||
application, ``<dirname>/foo/bar/mydata.json`` for each directory in
|
||||
``FIXTURE_DIRS``, and the literal path ``foo/bar/mydata.json``.
|
||||
:setting:`FIXTURE_DIRS`, and the literal path ``foo/bar/mydata.json``.
|
||||
|
||||
When fixture files are processed, the data is saved to the database as is.
|
||||
Model defined ``save`` methods and ``pre_save`` signals are not called.
|
||||
|
|
@ -742,7 +743,7 @@ Serving static files with the development server
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default, the development server doesn't serve any static files for your site
|
||||
(such as CSS files, images, things under ``MEDIA_URL`` and so forth). If
|
||||
(such as CSS files, images, things under :setting:`MEDIA_URL` and so forth). If
|
||||
you want to configure Django to serve static media, read :doc:`/howto/static-files`.
|
||||
|
||||
shell
|
||||
|
|
@ -912,13 +913,13 @@ syncdb
|
|||
|
||||
.. django-admin:: syncdb
|
||||
|
||||
Creates the database tables for all apps in ``INSTALLED_APPS`` whose tables
|
||||
have not already been created.
|
||||
Creates the database tables for all apps in :setting:`INSTALLED_APPS` whose
|
||||
tables have not already been created.
|
||||
|
||||
Use this command when you've added new applications to your project and want to
|
||||
install them in the database. This includes any apps shipped with Django that
|
||||
might be in ``INSTALLED_APPS`` by default. When you start a new project, run
|
||||
this command to install the default apps.
|
||||
might be in :setting:`INSTALLED_APPS` by default. When you start a new project,
|
||||
run this command to install the default apps.
|
||||
|
||||
.. admonition:: Syncdb will not alter existing tables
|
||||
|
||||
|
|
@ -1032,8 +1033,8 @@ validate
|
|||
|
||||
.. django-admin:: validate
|
||||
|
||||
Validates all installed models (according to the ``INSTALLED_APPS`` setting)
|
||||
and prints validation errors to standard output.
|
||||
Validates all installed models (according to the :setting:`INSTALLED_APPS`
|
||||
setting) and prints validation errors to standard output.
|
||||
|
||||
Commands provided by applications
|
||||
=================================
|
||||
|
|
|
|||
|
|
@ -764,7 +764,7 @@ Takes the following optional arguments:
|
|||
.. attribute:: URLField.validator_user_agent
|
||||
|
||||
String used as the user-agent used when checking for a URL's existence.
|
||||
Defaults to the value of the ``URL_VALIDATOR_USER_AGENT`` setting.
|
||||
Defaults to the value of the :setting:`URL_VALIDATOR_USER_AGENT` setting.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The URLField previously did not recognize URLs as valid that contained an IDN
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ which is a dictionary of the parameters captured in the URL.
|
|||
just before rendering the template.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
**Example:**
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ a date in the *future* are not included unless you set ``allow_future`` to
|
|||
the view's template.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
* ``allow_future``: A boolean specifying whether to include "future"
|
||||
objects on this page, where "future" means objects in which the field
|
||||
|
|
@ -290,7 +290,7 @@ to ``True``.
|
|||
this is ``False``.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
* ``allow_future``: A boolean specifying whether to include "future"
|
||||
objects on this page, where "future" means objects in which the field
|
||||
|
|
@ -377,7 +377,7 @@ date in the *future* are not displayed unless you set ``allow_future`` to
|
|||
determining the variable's name.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
* ``allow_future``: A boolean specifying whether to include "future"
|
||||
objects on this page, where "future" means objects in which the field
|
||||
|
|
@ -465,7 +465,7 @@ in the *future* are not displayed unless you set ``allow_future`` to ``True``.
|
|||
determining the variable's name.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
* ``allow_future``: A boolean specifying whether to include "future"
|
||||
objects on this page, where "future" means objects in which the field
|
||||
|
|
@ -550,7 +550,7 @@ you set ``allow_future`` to ``True``.
|
|||
determining the variable's name.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
* ``allow_future``: A boolean specifying whether to include "future"
|
||||
objects on this page, where "future" means objects in which the field
|
||||
|
|
@ -660,7 +660,7 @@ future, the view will throw a 404 error by default, unless you set
|
|||
to use in the template context. By default, this is ``'object'``.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
* ``allow_future``: A boolean specifying whether to include "future"
|
||||
objects on this page, where "future" means objects in which the field
|
||||
|
|
@ -738,7 +738,7 @@ A page representing a list of objects.
|
|||
determining the variable's name.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
**Template name:**
|
||||
|
||||
|
|
@ -852,7 +852,7 @@ A page representing an individual object.
|
|||
to use in the template context. By default, this is ``'object'``.
|
||||
|
||||
* ``mimetype``: The MIME type to use for the resulting document. Defaults
|
||||
to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
|
||||
to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting.
|
||||
|
||||
**Template name:**
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ A tuple of strings representing allowed prefixes for the ``{% ssi %}`` template
|
|||
tag. This is a security measure, so that template authors can't access files
|
||||
that they shouldn't be accessing.
|
||||
|
||||
For example, if ``ALLOWED_INCLUDE_ROOTS`` is ``('/home/html', '/var/www')``,
|
||||
For example, if :setting:`ALLOWED_INCLUDE_ROOTS` is ``('/home/html', '/var/www')``,
|
||||
then ``{% ssi /home/html/foo.txt %}`` would work, but ``{% ssi /etc/passwd %}``
|
||||
wouldn't.
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ in the URLconf and it doesn't end in a slash, an HTTP redirect is issued to the
|
|||
same URL with a slash appended. Note that the redirect may cause any data
|
||||
submitted in a POST request to be lost.
|
||||
|
||||
The ``APPEND_SLASH`` setting is only used if
|
||||
The :setting:`APPEND_SLASH` setting is only used if
|
||||
:class:`~django.middleware.common.CommonMiddleware` is installed
|
||||
(see :doc:`/topics/http/middleware`). See also :setting:`PREPEND_WWW`.
|
||||
|
||||
|
|
@ -634,9 +634,9 @@ locale-dictated format has higher precedence and will be applied instead. See
|
|||
:tfilter:`allowed date format strings <date>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This setting can now be overriden by setting ``USE_L10N`` to ``True``.
|
||||
This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.
|
||||
|
||||
See also ``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``SHORT_DATE_FORMAT``.
|
||||
See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
||||
|
||||
.. setting:: DATE_INPUT_FORMATS
|
||||
|
||||
|
|
@ -657,7 +657,7 @@ Note that these format strings are specified in Python's datetime_ module
|
|||
syntax, that is different from the one used by Django for formatting dates
|
||||
to be displayed.
|
||||
|
||||
See also ``DATETIME_INPUT_FORMATS`` and ``TIME_INPUT_FORMATS``.
|
||||
See also :setting:`DATETIME_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
|
|
@ -674,9 +674,9 @@ locale-dictated format has higher precedence and will be applied instead. See
|
|||
:tfilter:`allowed date format strings <date>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This setting can now be overriden by setting ``USE_L10N`` to ``True``.
|
||||
This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.
|
||||
|
||||
See also ``DATE_FORMAT``, ``TIME_FORMAT`` and ``SHORT_DATETIME_FORMAT``.
|
||||
See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
||||
|
||||
.. setting:: DATETIME_INPUT_FORMATS
|
||||
|
||||
|
|
@ -697,7 +697,7 @@ Note that these format strings are specified in Python's datetime_ module
|
|||
syntax, that is different from the one used by Django for formatting dates
|
||||
to be displayed.
|
||||
|
||||
See also ``DATE_INPUT_FORMATS`` and ``TIME_INPUT_FORMATS``.
|
||||
See also :setting:`DATE_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
|
|
@ -720,11 +720,12 @@ Still, note that there are always going to be sections of your debug output that
|
|||
are inappropriate for public consumption. File paths, configuration options, and
|
||||
the like all give attackers extra information about your server.
|
||||
|
||||
It is also important to remember that when running with ``DEBUG`` turned on, Django
|
||||
will remember every SQL query it executes. This is useful when you are debugging,
|
||||
but on a production server, it will rapidly consume memory.
|
||||
It is also important to remember that when running with :setting:`DEBUG`
|
||||
turned on, Django will remember every SQL query it executes. This is useful
|
||||
when you are debugging, but on a production server, it will rapidly consume
|
||||
memory.
|
||||
|
||||
Never deploy a site into production with ``DEBUG`` turned on.
|
||||
Never deploy a site into production with :setting:`DEBUG` turned on.
|
||||
|
||||
.. _django/views/debug.py: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py
|
||||
|
||||
|
|
@ -757,7 +758,7 @@ DEFAULT_CHARSET
|
|||
Default: ``'utf-8'``
|
||||
|
||||
Default charset to use for all ``HttpResponse`` objects, if a MIME type isn't
|
||||
manually specified. Used with ``DEFAULT_CONTENT_TYPE`` to construct the
|
||||
manually specified. Used with :setting:`DEFAULT_CONTENT_TYPE` to construct the
|
||||
``Content-Type`` header.
|
||||
|
||||
.. setting:: DEFAULT_CONTENT_TYPE
|
||||
|
|
@ -768,8 +769,8 @@ DEFAULT_CONTENT_TYPE
|
|||
Default: ``'text/html'``
|
||||
|
||||
Default content type to use for all ``HttpResponse`` objects, if a MIME type
|
||||
isn't manually specified. Used with ``DEFAULT_CHARSET`` to construct the
|
||||
``Content-Type`` header.
|
||||
isn't manually specified. Used with :setting:`DEFAULT_CHARSET` to construct
|
||||
the ``Content-Type`` header.
|
||||
|
||||
.. setting:: DEFAULT_FILE_STORAGE
|
||||
|
||||
|
|
@ -855,7 +856,7 @@ Default: ``'localhost'``
|
|||
|
||||
The host to use for sending email.
|
||||
|
||||
See also ``EMAIL_PORT``.
|
||||
See also :setting:`EMAIL_PORT`.
|
||||
|
||||
.. setting:: EMAIL_HOST_PASSWORD
|
||||
|
||||
|
|
@ -864,12 +865,12 @@ EMAIL_HOST_PASSWORD
|
|||
|
||||
Default: ``''`` (Empty string)
|
||||
|
||||
Password to use for the SMTP server defined in ``EMAIL_HOST``. This setting is
|
||||
used in conjunction with ``EMAIL_HOST_USER`` when authenticating to the SMTP
|
||||
server. If either of these settings is empty, Django won't attempt
|
||||
authentication.
|
||||
Password to use for the SMTP server defined in :setting:`EMAIL_HOST`. This
|
||||
setting is used in conjunction with :setting:`EMAIL_HOST_USER` when
|
||||
authenticating to the SMTP server. If either of these settings is empty,
|
||||
Django won't attempt authentication.
|
||||
|
||||
See also ``EMAIL_HOST_USER``.
|
||||
See also :setting:`EMAIL_HOST_USER`.
|
||||
|
||||
.. setting:: EMAIL_HOST_USER
|
||||
|
||||
|
|
@ -878,10 +879,10 @@ EMAIL_HOST_USER
|
|||
|
||||
Default: ``''`` (Empty string)
|
||||
|
||||
Username to use for the SMTP server defined in ``EMAIL_HOST``. If empty,
|
||||
Django won't attempt authentication.
|
||||
Username to use for the SMTP server defined in :setting:`EMAIL_HOST`.
|
||||
If empty, Django won't attempt authentication.
|
||||
|
||||
See also ``EMAIL_HOST_PASSWORD``.
|
||||
See also :setting:`EMAIL_HOST_PASSWORD`.
|
||||
|
||||
.. setting:: EMAIL_PORT
|
||||
|
||||
|
|
@ -890,7 +891,7 @@ EMAIL_PORT
|
|||
|
||||
Default: ``25``
|
||||
|
||||
Port to use for the SMTP server defined in ``EMAIL_HOST``.
|
||||
Port to use for the SMTP server defined in :setting:`EMAIL_HOST`.
|
||||
|
||||
.. setting:: EMAIL_SUBJECT_PREFIX
|
||||
|
||||
|
|
@ -1037,8 +1038,8 @@ project locales. If not ``None``, Django will check for a ``formats.py``
|
|||
file, under the directory named as the current locale, and will use the
|
||||
formats defined on this file.
|
||||
|
||||
For example, if ``FORMAT_MODULE_PATH`` is set to ``mysite.formats``, and
|
||||
current language is ``en`` (English), Django will expect a directory tree
|
||||
For example, if :setting:`FORMAT_MODULE_PATH` is set to ``mysite.formats``,
|
||||
and current language is ``en`` (English), Django will expect a directory tree
|
||||
like::
|
||||
|
||||
mysite/
|
||||
|
|
@ -1048,10 +1049,12 @@ like::
|
|||
__init__.py
|
||||
formats.py
|
||||
|
||||
Available formats are ``DATE_FORMAT``, ``TIME_FORMAT``, ``DATETIME_FORMAT``,
|
||||
``YEAR_MONTH_FORMAT``, ``MONTH_DAY_FORMAT``, ``SHORT_DATE_FORMAT``,
|
||||
``SHORT_DATETIME_FORMAT``, ``FIRST_DAY_OF_WEEK``, ``DECIMAL_SEPARATOR``,
|
||||
``THOUSAND_SEPARATOR`` and ``NUMBER_GROUPING``.
|
||||
Available formats are :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`,
|
||||
:setting:`DATETIME_FORMAT`, :setting:`YEAR_MONTH_FORMAT`,
|
||||
:setting:`MONTH_DAY_FORMAT`, :setting:`SHORT_DATE_FORMAT`,
|
||||
:setting:`SHORT_DATETIME_FORMAT`, :setting:`FIRST_DAY_OF_WEEK`,
|
||||
:setting:`DECIMAL_SEPARATOR`, :setting:`THOUSAND_SEPARATOR` and
|
||||
:setting:`NUMBER_GROUPING`.
|
||||
|
||||
.. setting:: IGNORABLE_404_URLS
|
||||
|
||||
|
|
@ -1100,7 +1103,7 @@ Default: ``()`` (Empty tuple)
|
|||
|
||||
A tuple of IP addresses, as strings, that:
|
||||
|
||||
* See debug comments, when ``DEBUG`` is ``True``
|
||||
* See debug comments, when :setting:`DEBUG` is ``True``
|
||||
* Receive X headers if the ``XViewMiddleware`` is installed (see
|
||||
:doc:`/topics/http/middleware`)
|
||||
|
||||
|
|
@ -1122,8 +1125,8 @@ LANGUAGE_COOKIE_NAME
|
|||
|
||||
Default: ``'django_language'``
|
||||
|
||||
The name of the cookie to use for the language cookie. This can be whatever you
|
||||
want (but should be different from ``SESSION_COOKIE_NAME``). See
|
||||
The name of the cookie to use for the language cookie. This can be whatever
|
||||
you want (but should be different from :setting:`SESSION_COOKIE_NAME`). See
|
||||
:doc:`/topics/i18n/index`.
|
||||
|
||||
.. setting:: LANGUAGES
|
||||
|
|
@ -1147,12 +1150,13 @@ This specifies which languages are available for language selection. See
|
|||
Generally, the default value should suffice. Only set this setting if you want
|
||||
to restrict language selection to a subset of the Django-provided languages.
|
||||
|
||||
If you define a custom ``LANGUAGES`` setting, it's OK to mark the languages as
|
||||
translation strings (as in the default value referred to above) -- but use a
|
||||
"dummy" ``gettext()`` function, not the one in ``django.utils.translation``.
|
||||
You should *never* import ``django.utils.translation`` from within your
|
||||
settings file, because that module in itself depends on the settings, and that
|
||||
would cause a circular import.
|
||||
If you define a custom :setting:`LANGUAGES` setting, it's OK to mark the
|
||||
languages as translation strings (as in the default value referred to above)
|
||||
-- but use a "dummy" ``gettext()`` function, not the one in
|
||||
``django.utils.translation``. You should *never* import
|
||||
``django.utils.translation`` from within your settings file, because that
|
||||
module in itself depends on the settings, and that would cause a circular
|
||||
import.
|
||||
|
||||
The solution is to use a "dummy" ``gettext()`` function. Here's a sample
|
||||
settings file::
|
||||
|
|
@ -1167,7 +1171,7 @@ settings file::
|
|||
With this arrangement, ``django-admin.py makemessages`` will still find and
|
||||
mark these strings for translation, but the translation won't happen at
|
||||
runtime -- so you'll have to remember to wrap the languages in the *real*
|
||||
``gettext()`` in any code that uses ``LANGUAGES`` at runtime.
|
||||
``gettext()`` in any code that uses :setting:`LANGUAGES` at runtime.
|
||||
|
||||
.. setting:: LOCALE_PATHS
|
||||
|
||||
|
|
@ -1263,7 +1267,7 @@ MANAGERS
|
|||
|
||||
Default: ``()`` (Empty tuple)
|
||||
|
||||
A tuple in the same format as ``ADMINS`` that specifies who should get
|
||||
A tuple in the same format as :setting:`ADMINS` that specifies who should get
|
||||
broken-link notifications when ``SEND_BROKEN_LINK_EMAILS=True``.
|
||||
|
||||
.. setting:: MEDIA_ROOT
|
||||
|
|
@ -1368,8 +1372,9 @@ drilldown, the header for a given day displays the day and month. Different
|
|||
locales have different formats. For example, U.S. English would say
|
||||
"January 1," whereas Spanish might say "1 Enero."
|
||||
|
||||
See :tfilter:`allowed date format strings <date>`. See also ``DATE_FORMAT``,
|
||||
``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``YEAR_MONTH_FORMAT``.
|
||||
See :tfilter:`allowed date format strings <date>`. See also
|
||||
:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`,
|
||||
:setting:`TIME_FORMAT` and :setting:`YEAR_MONTH_FORMAT`.
|
||||
|
||||
.. setting:: NUMBER_GROUPING
|
||||
|
||||
|
|
@ -1463,10 +1468,10 @@ SEND_BROKEN_LINK_EMAILS
|
|||
|
||||
Default: ``False``
|
||||
|
||||
Whether to send an email to the ``MANAGERS`` each time somebody visits a
|
||||
Django-powered page that is 404ed with a non-empty referer (i.e., a broken
|
||||
Whether to send an email to the :setting:`MANAGERS` each time somebody visits
|
||||
a Django-powered page that is 404ed with a non-empty referer (i.e., a broken
|
||||
link). This is only used if ``CommonMiddleware`` is installed (see
|
||||
:doc:`/topics/http/middleware`). See also ``IGNORABLE_404_URLS`` and
|
||||
:doc:`/topics/http/middleware`). See also :setting:`IGNORABLE_404_URLS` and
|
||||
:doc:`/howto/error-reporting`.
|
||||
|
||||
.. setting:: SERIALIZATION_MODULES
|
||||
|
|
@ -1490,7 +1495,7 @@ SERVER_EMAIL
|
|||
Default: ``'root@localhost'``
|
||||
|
||||
The email address that error messages come from, such as those sent to
|
||||
``ADMINS`` and ``MANAGERS``.
|
||||
:setting:`ADMINS` and :setting:`MANAGERS`.
|
||||
|
||||
.. setting:: SESSION_COOKIE_AGE
|
||||
|
||||
|
|
@ -1539,7 +1544,8 @@ SESSION_COOKIE_NAME
|
|||
Default: ``'sessionid'``
|
||||
|
||||
The name of the cookie to use for sessions. This can be whatever you want (but
|
||||
should be different from ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/sessions`.
|
||||
should be different from :setting:`LANGUAGE_COOKIE_NAME`).
|
||||
See the :doc:`/topics/http/sessions`.
|
||||
|
||||
.. setting:: SESSION_COOKIE_PATH
|
||||
|
||||
|
|
@ -1629,7 +1635,7 @@ templates. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|||
corresponding locale-dictated format has higher precedence and will be applied.
|
||||
See :tfilter:`allowed date format strings <date>`.
|
||||
|
||||
See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``.
|
||||
See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
||||
|
||||
.. setting:: SHORT_DATETIME_FORMAT
|
||||
|
||||
|
|
@ -1645,7 +1651,7 @@ templates. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|||
corresponding locale-dictated format has higher precedence and will be applied.
|
||||
See :tfilter:`allowed date format strings <date>`.
|
||||
|
||||
See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``.
|
||||
See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
||||
|
||||
.. setting:: SIGNING_BACKEND
|
||||
|
||||
|
|
@ -1767,10 +1773,10 @@ error page will display a detailed report for any ``TemplateSyntaxError``. This
|
|||
report contains the relevant snippet of the template, with the appropriate line
|
||||
highlighted.
|
||||
|
||||
Note that Django only displays fancy error pages if ``DEBUG`` is ``True``, so
|
||||
Note that Django only displays fancy error pages if :setting:`DEBUG` is ``True``, so
|
||||
you'll want to set that to take advantage of this setting.
|
||||
|
||||
See also ``DEBUG``.
|
||||
See also :setting:`DEBUG`.
|
||||
|
||||
.. setting:: TEMPLATE_DIRS
|
||||
|
||||
|
|
@ -1802,9 +1808,9 @@ module, subsequent items are passed to the ``Loader`` during initialization. See
|
|||
|
||||
.. versionchanged:: 1.2
|
||||
The class-based API for template loaders was introduced in Django 1.2
|
||||
although the ``TEMPLATE_LOADERS`` setting will accept strings that specify
|
||||
function-based loaders until compatibility with them is completely removed in
|
||||
Django 1.4.
|
||||
although the :setting:`TEMPLATE_LOADERS` setting will accept strings
|
||||
that specify function-based loaders until compatibility with them is
|
||||
completely removed in Django 1.4.
|
||||
|
||||
.. setting:: TEMPLATE_STRING_IF_INVALID
|
||||
|
||||
|
|
@ -1838,10 +1844,11 @@ THOUSAND_SEPARATOR
|
|||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default ``,`` (Comma)
|
||||
Default: ``,`` (Comma)
|
||||
|
||||
Default thousand separator used when formatting numbers. This setting is
|
||||
used only when ``NUMBER_GROUPING`` and ``USE_THOUSAND_SEPARATOR`` are set.
|
||||
used only when :setting:`NUMBER_GROUPING` and :setting:`USE_THOUSAND_SEPARATOR`
|
||||
are set.
|
||||
|
||||
See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and
|
||||
:setting:`USE_THOUSAND_SEPARATOR`.
|
||||
|
|
@ -1859,9 +1866,9 @@ locale-dictated format has higher precedence and will be applied instead. See
|
|||
:tfilter:`allowed date format strings <date>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This setting can now be overriden by setting ``USE_L10N`` to ``True``.
|
||||
This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.
|
||||
|
||||
See also ``DATE_FORMAT`` and ``DATETIME_FORMAT``.
|
||||
See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`.
|
||||
|
||||
.. setting:: TIME_INPUT_FORMATS
|
||||
|
||||
|
|
@ -1878,7 +1885,7 @@ Note that these format strings are specified in Python's datetime_ module
|
|||
syntax, that is different from the one used by Django for formatting dates
|
||||
to be displayed.
|
||||
|
||||
See also ``DATE_INPUT_FORMATS`` and ``DATETIME_INPUT_FORMATS``.
|
||||
See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
|
|
@ -1897,7 +1904,7 @@ A string representing the time zone for this installation, or
|
|||
choices lists more than one on the same line; you'll want to use just
|
||||
one of the choices for a given time zone. For instance, one line says
|
||||
``'Europe/London GB GB-Eire'``, but you should use the first bit of
|
||||
that -- ``'Europe/London'`` -- as your ``TIME_ZONE`` setting.)
|
||||
that -- ``'Europe/London'`` -- as your :setting:`TIME_ZONE` setting.)
|
||||
|
||||
Note that this is the time zone to which Django will convert all
|
||||
dates/times -- not necessarily the timezone of the server. For
|
||||
|
|
@ -1905,7 +1912,7 @@ example, one server may serve multiple Django-powered sites, each with
|
|||
a separate time-zone setting.
|
||||
|
||||
Normally, Django sets the ``os.environ['TZ']`` variable to the time
|
||||
zone you specify in the ``TIME_ZONE`` setting. Thus, all your views
|
||||
zone you specify in the :setting:`TIME_ZONE` setting. Thus, all your views
|
||||
and models will automatically operate in the correct time zone.
|
||||
However, Django won't set the ``TZ`` environment variable under the
|
||||
following conditions:
|
||||
|
|
@ -1962,7 +1969,7 @@ enabled. This provides an easy way to turn it off, for performance. If this is
|
|||
set to ``False``, Django will make some optimizations so as not to load the
|
||||
internationalization machinery.
|
||||
|
||||
See also ``USE_L10N``
|
||||
See also :setting:`USE_L10N`
|
||||
|
||||
.. setting:: USE_L10N
|
||||
|
||||
|
|
@ -1971,13 +1978,13 @@ USE_L10N
|
|||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default ``False``
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies if data will be localized by default or not. If this
|
||||
is set to ``True``, e.g. Django will display numbers and dates using the
|
||||
format of the current locale.
|
||||
|
||||
See also ``USE_I18N`` and ``LANGUAGE_CODE``
|
||||
See also :setting:`USE_I18N` and :setting:`LANGUAGE_CODE`
|
||||
|
||||
.. setting:: USE_THOUSAND_SEPARATOR
|
||||
|
||||
|
|
@ -1986,14 +1993,15 @@ USE_THOUSAND_SEPARATOR
|
|||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default ``False``
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies wheter to display numbers using a thousand separator.
|
||||
If this is set to ``True``, Django will use values from ``THOUSAND_SEPARATOR``
|
||||
and ``NUMBER_GROUPING`` from current locale, to format the number.
|
||||
``USE_L10N`` must be set to ``True``, in order to format numbers.
|
||||
If this is set to ``True``, Django will use values from
|
||||
:setting:`THOUSAND_SEPARATOR` and :setting:`NUMBER_GROUPING` from current
|
||||
locale, to format the number. :setting:`USE_L10N` must be set to ``True``,
|
||||
in order to format numbers.
|
||||
|
||||
See also ``THOUSAND_SEPARATOR`` and ``NUMBER_GROUPING``.
|
||||
See also :setting:`THOUSAND_SEPARATOR` and :setting:`NUMBER_GROUPING`.
|
||||
|
||||
.. setting:: YEAR_MONTH_FORMAT
|
||||
|
||||
|
|
@ -2011,8 +2019,9 @@ drilldown, the header for a given month displays the month and the year.
|
|||
Different locales have different formats. For example, U.S. English would say
|
||||
"January 2006," whereas another locale might say "2006/January."
|
||||
|
||||
See :tfilter:`allowed date format strings <date>`. See also ``DATE_FORMAT``,
|
||||
``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``MONTH_DAY_FORMAT``.
|
||||
See :tfilter:`allowed date format strings <date>`. See also
|
||||
:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT`
|
||||
and :setting:`MONTH_DAY_FORMAT`.
|
||||
|
||||
Deprecated settings
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -1307,10 +1307,11 @@ If ``value`` is a ``datetime`` object (e.g., the result of
|
|||
``datetime.datetime.now()``), the output will be the string
|
||||
``'Wed 09 Jan 2008'``.
|
||||
|
||||
The format passed can be one of the predefined ones ``DATE_FORMAT``,
|
||||
``DATETIME_FORMAT``, ``SHORT_DATE_FORMAT`` or ``SHORT_DATETIME_FORMAT``, or a
|
||||
custom format that uses the format specifiers shown in the table above. Note
|
||||
that predefined formats may vary depending on the current locale.
|
||||
The format passed can be one of the predefined ones :setting:`DATE_FORMAT`,
|
||||
:setting:`DATETIME_FORMAT`, :setting:`SHORT_DATE_FORMAT` or
|
||||
:setting:`SHORT_DATETIME_FORMAT`, or a custom format that uses the format
|
||||
specifiers shown in the table above. Note that predefined formats may vary
|
||||
depending on the current locale.
|
||||
|
||||
Assuming that :setting:`USE_L10N` is ``True`` and :setting:`LANGUAGE_CODE` is,
|
||||
for example, ``"es"``, then for::
|
||||
|
|
@ -1941,9 +1942,9 @@ time
|
|||
|
||||
Formats a time according to the given format.
|
||||
|
||||
Given format can be the predefined one ``TIME_FORMAT``, or a custom format,
|
||||
same as the :tfilter:`date` filter. Note that the predefined format is locale-
|
||||
dependant.
|
||||
Given format can be the predefined one :setting:`TIME_FORMAT`, or a custom
|
||||
format, same as the :tfilter:`date` filter. Note that the predefined format
|
||||
is locale-dependant.
|
||||
|
||||
The time filter will only accept parameters in the format string that relate
|
||||
to the time of day, not the date (for obvious reasons). If you need to
|
||||
|
|
@ -2243,7 +2244,7 @@ Other tags and filter libraries
|
|||
-------------------------------
|
||||
|
||||
Django comes with a couple of other template-tag libraries that you have to
|
||||
enable explicitly in your ``INSTALLED_APPS`` setting and enable in your
|
||||
enable explicitly in your :setting:`INSTALLED_APPS` setting and enable in your
|
||||
template with the ``{% load %}`` tag.
|
||||
|
||||
django.contrib.humanize
|
||||
|
|
@ -2274,15 +2275,18 @@ i18n
|
|||
|
||||
Provides a couple of templatetags that allow specifying translatable text in
|
||||
Django templates. It is slightly different from the libraries described
|
||||
above because you don't need to add any application to the ``INSTALLED_APPS``
|
||||
setting but rather set :setting:`USE_I18N` to True, then loading it with
|
||||
``{% load i18n %}``. See :ref:`specifying-translation-strings-in-template-code`.
|
||||
above because you don't need to add any application to the
|
||||
:setting:`INSTALLED_APPS` setting but rather set :setting:`USE_I18N` to True,
|
||||
then loading it with ``{% load i18n %}``.
|
||||
|
||||
See :ref:`specifying-translation-strings-in-template-code`.
|
||||
|
||||
l10n
|
||||
~~~~
|
||||
|
||||
Provides a couple of templatetags that allow control over the localization of
|
||||
values in Django templates. It is slightly different from the libraries described
|
||||
above because you don't need to add any application to the ``INSTALLED_APPS``;
|
||||
you only need to load the library using ``{% load l10n %}``. See
|
||||
:ref:`topic-l10n-templates`.
|
||||
above because you don't need to add any application to the :setting:`INSTALLED_APPS`;
|
||||
you only need to load the library using ``{% load l10n %}``.
|
||||
|
||||
See :ref:`topic-l10n-templates`.
|
||||
|
|
|
|||
|
|
@ -61,8 +61,8 @@ to distinguish caches by the ``Accept-language`` header.
|
|||
|
||||
Each header is only added if it isn't already set.
|
||||
|
||||
``cache_timeout`` is in seconds. The ``CACHE_MIDDLEWARE_SECONDS`` setting
|
||||
is used by default.
|
||||
``cache_timeout`` is in seconds. The :setting:`CACHE_MIDDLEWARE_SECONDS`
|
||||
setting is used by default.
|
||||
|
||||
.. function:: add_never_cache_headers(response)
|
||||
|
||||
|
|
|
|||
|
|
@ -443,10 +443,10 @@ The old :exc:`EnvironmentError` has split into an :exc:`ImportError` when
|
|||
Django fails to find the settings module and a :exc:`RuntimeError` when you try
|
||||
to reconfigure settings after having already used them
|
||||
|
||||
``LOGIN_URL`` has moved
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
:setting:`LOGIN_URL` has moved
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``LOGIN_URL`` constant moved from ``django.contrib.auth`` into the
|
||||
The :setting:`LOGIN_URL` constant moved from ``django.contrib.auth`` into the
|
||||
``settings`` module. Instead of using ``from django.contrib.auth import
|
||||
LOGIN_URL`` refer to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
|
||||
|
||||
|
|
@ -454,11 +454,11 @@ LOGIN_URL`` refer to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In 0.96, if a URL didn't end in a slash or have a period in the final
|
||||
component of its path, and ``APPEND_SLASH`` was True, Django would redirect
|
||||
to the same URL, but with a slash appended to the end. Now, Django checks to
|
||||
see whether the pattern without the trailing slash would be matched by
|
||||
something in your URL patterns. If so, no redirection takes place, because it
|
||||
is assumed you deliberately wanted to catch that pattern.
|
||||
component of its path, and :setting:`APPEND_SLASH` was True, Django would
|
||||
redirect to the same URL, but with a slash appended to the end. Now, Django
|
||||
checks to see whether the pattern without the trailing slash would be matched
|
||||
by something in your URL patterns. If so, no redirection takes place, because
|
||||
it is assumed you deliberately wanted to catch that pattern.
|
||||
|
||||
For most people, this won't require any changes. Some people, though, have URL
|
||||
patterns that look like this::
|
||||
|
|
@ -548,8 +548,8 @@ need to reload your data. Do this after you have made the change to using
|
|||
**Back up your database first!**
|
||||
|
||||
For SQLite, this means making a copy of the single file that stores the
|
||||
database (the name of that file is the ``DATABASE_NAME`` in your settings.py
|
||||
file).
|
||||
database (the name of that file is the :setting:`DATABASE_NAME` in your
|
||||
settings.py file).
|
||||
|
||||
To upgrade each application to use a ``DecimalField``, you can do the
|
||||
following, replacing ``<app>`` in the code below with each app's name:
|
||||
|
|
|
|||
|
|
@ -1076,8 +1076,8 @@ Up to version 1.1 Django used technical message IDs
|
|||
to provide localizers the possibility to translate date and time formats. They
|
||||
were translatable :term:`translation strings <translation string>` that could
|
||||
be recognized because they were all upper case (for example
|
||||
``DATETIME_FORMAT``, ``DATE_FORMAT``, ``TIME_FORMAT``). They have been
|
||||
deprecated in favor of the new :ref:`Format localization
|
||||
:setting:`DATETIME_FORMAT`, :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`).
|
||||
They have been deprecated in favor of the new :ref:`Format localization
|
||||
<format-localization>` infrastructure that allows localizers to specify that
|
||||
information in a ``formats.py`` file in the corresponding
|
||||
``django/conf/locale/<locale name>/`` directory.
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ framework, we have "fixed" the problem by making the list of
|
|||
prohibited words an empty list.
|
||||
|
||||
If you want to restore the old behavior, simply put a
|
||||
``PROFANITIES_LIST`` setting in your settings file that includes the
|
||||
:setting:`PROFANITIES_LIST` setting in your settings file that includes the
|
||||
words that you want to prohibit (see the `commit that implemented this
|
||||
change`_ if you want to see the list of words that was historically
|
||||
prohibited). However, if avoiding profanities is important to you, you
|
||||
|
|
|
|||
|
|
@ -264,8 +264,8 @@ The GeoDjango test suite is now included when
|
|||
:ref:`running the Django test suite <running-unit-tests>` with ``runtests.py``
|
||||
when using :ref:`spatial database backends <spatial-backends>`.
|
||||
|
||||
``MEDIA_URL`` and ``STATIC_URL`` must end in a slash
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
:setting:`MEDIA_URL` and :setting:`STATIC_URL` must end in a slash
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Previously, the :setting:`MEDIA_URL` setting only required a trailing slash if
|
||||
it contained a suffix beyond the domain name.
|
||||
|
|
@ -581,7 +581,7 @@ gettext domain):
|
|||
|
||||
* Now it is possible to override the translations shipped with applications by
|
||||
using the :setting:`LOCALE_PATHS` setting whose translations have now higher
|
||||
precedence than the translations of ``INSTALLED_APPS`` applications.
|
||||
precedence than the translations of :setting:`INSTALLED_APPS` applications.
|
||||
The relative priority among the values listed in this setting has also been
|
||||
modified so the paths listed first have higher precedence than the
|
||||
ones listed later.
|
||||
|
|
@ -589,7 +589,7 @@ gettext domain):
|
|||
* The ``locale`` subdirectory of the directory containing the settings, that
|
||||
usually coincides with and is know as the *project directory* is being
|
||||
deprecated in this release as a source of translations. (the precedence of
|
||||
these translations is intermediate between applications and ``LOCALE_PATHS``
|
||||
these translations is intermediate between applications and :setting:`LOCALE_PATHS`
|
||||
translations). See the `corresponding deprecated features section`_
|
||||
of this document.
|
||||
|
||||
|
|
|
|||
|
|
@ -420,7 +420,7 @@ Once the cache is set up, the simplest way to use caching is to cache your
|
|||
entire site. You'll need to add
|
||||
``'django.middleware.cache.UpdateCacheMiddleware'`` and
|
||||
``'django.middleware.cache.FetchFromCacheMiddleware'`` to your
|
||||
``MIDDLEWARE_CLASSES`` setting, as in this example::
|
||||
:setting:`MIDDLEWARE_CLASSES` setting, as in this example::
|
||||
|
||||
MIDDLEWARE_CLASSES = (
|
||||
'django.middleware.cache.UpdateCacheMiddleware',
|
||||
|
|
|
|||
|
|
@ -509,8 +509,8 @@ Defining a custom email backend
|
|||
-------------------------------
|
||||
|
||||
If you need to change how emails are sent you can write your own email
|
||||
backend. The ``EMAIL_BACKEND`` setting in your settings file is then the
|
||||
Python import path for your backend class.
|
||||
backend. The :setting:`EMAIL_BACKEND` setting in your settings file is then
|
||||
the Python import path for your backend class.
|
||||
|
||||
Custom email backends should subclass ``BaseEmailBackend`` that is located in
|
||||
the ``django.core.mail.backends.base`` module. A custom email backend must
|
||||
|
|
|
|||
|
|
@ -225,8 +225,8 @@ Upload Handlers
|
|||
|
||||
When a user uploads a file, Django passes off the file data to an *upload
|
||||
handler* -- a small class that handles file data as it gets uploaded. Upload
|
||||
handlers are initially defined in the ``FILE_UPLOAD_HANDLERS`` setting, which
|
||||
defaults to::
|
||||
handlers are initially defined in the :setting:`FILE_UPLOAD_HANDLERS` setting,
|
||||
which defaults to::
|
||||
|
||||
("django.core.files.uploadhandler.MemoryFileUploadHandler",
|
||||
"django.core.files.uploadhandler.TemporaryFileUploadHandler",)
|
||||
|
|
@ -246,8 +246,8 @@ Modifying upload handlers on the fly
|
|||
Sometimes particular views require different upload behavior. In these cases,
|
||||
you can override upload handlers on a per-request basis by modifying
|
||||
``request.upload_handlers``. By default, this list will contain the upload
|
||||
handlers given by ``FILE_UPLOAD_HANDLERS``, but you can modify the list as you
|
||||
would any other list.
|
||||
handlers given by :setting:`FILE_UPLOAD_HANDLERS`, but you can modify the list
|
||||
as you would any other list.
|
||||
|
||||
For instance, suppose you've written a ``ProgressBarUploadHandler`` that
|
||||
provides feedback on upload progress to some sort of AJAX widget. You'd add this
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ To enable session functionality, do the following:
|
|||
has ``SessionMiddleware`` activated.
|
||||
|
||||
If you don't want to use sessions, you might as well remove the
|
||||
``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and
|
||||
``SessionMiddleware`` line from :setting:`MIDDLEWARE_CLASSES` and
|
||||
``'django.contrib.sessions'`` from your :setting:`INSTALLED_APPS`.
|
||||
It'll save you a small bit of overhead.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ Using database-backed sessions
|
|||
------------------------------
|
||||
|
||||
If you want to use a database-backed session, you need to add
|
||||
``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting.
|
||||
``'django.contrib.sessions'`` to your :setting:`INSTALLED_APPS` setting.
|
||||
|
||||
Once you have configured your installation, run ``manage.py syncdb``
|
||||
to install the single database table that stores session data.
|
||||
|
|
@ -359,8 +359,8 @@ setting to ``True``. When set to ``True``, Django will save the session to the
|
|||
database on every single request.
|
||||
|
||||
Note that the session cookie is only sent when a session has been created or
|
||||
modified. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, the session cookie
|
||||
will be sent on every request.
|
||||
modified. If :setting:`SESSION_SAVE_EVERY_REQUEST` is ``True``, the session
|
||||
cookie will be sent on every request.
|
||||
|
||||
Similarly, the ``expires`` part of a session cookie is updated each time the
|
||||
session cookie is sent.
|
||||
|
|
@ -372,15 +372,15 @@ You can control whether the session framework uses browser-length sessions vs.
|
|||
persistent sessions with the :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE`
|
||||
setting.
|
||||
|
||||
By default, ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``False``, which
|
||||
means session cookies will be stored in users' browsers for as long as
|
||||
By default, :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``False``,
|
||||
which means session cookies will be stored in users' browsers for as long as
|
||||
:setting:`SESSION_COOKIE_AGE`. Use this if you don't want people to have to
|
||||
log in every time they open a browser.
|
||||
|
||||
If ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``True``, Django will use
|
||||
browser-length cookies -- cookies that expire as soon as the user closes his or
|
||||
her browser. Use this if you want people to have to log in every time they open
|
||||
a browser.
|
||||
If :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``True``, Django will
|
||||
use browser-length cookies -- cookies that expire as soon as the user closes
|
||||
his or her browser. Use this if you want people to have to log in every time
|
||||
they open a browser.
|
||||
|
||||
This setting is a global default and can be overwritten at a per-session level
|
||||
by explicitly calling the :meth:`~backends.base.SessionBase.set_expiry` method
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Let's step through this code one line at a time:
|
|||
|
||||
.. admonition:: Django's Time Zone
|
||||
|
||||
Django includes a ``TIME_ZONE`` setting that defaults to
|
||||
Django includes a :setting:`TIME_ZONE` setting that defaults to
|
||||
``America/Chicago``. This probably isn't where you live, so you might want
|
||||
to change it in your settings file.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ use internationalization, you should take the two seconds to set
|
|||
optimizations so as not to load the internationalization machinery.
|
||||
|
||||
You'll probably also want to remove ``'django.core.context_processors.i18n'``
|
||||
from your ``TEMPLATE_CONTEXT_PROCESSORS`` setting.
|
||||
from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -47,22 +47,22 @@ Django uses this language as the default translation -- the final attempt if no
|
|||
other translator finds a translation.
|
||||
|
||||
If all you want to do is run Django with your native language, and a language
|
||||
file is available for it, all you need to do is set ``LANGUAGE_CODE``.
|
||||
file is available for it, all you need to do is set :setting:`LANGUAGE_CODE`.
|
||||
|
||||
If you want to let each individual user specify which language he or she
|
||||
prefers, use ``LocaleMiddleware``. ``LocaleMiddleware`` enables language
|
||||
selection based on data from the request. It customizes content for each user.
|
||||
|
||||
To use ``LocaleMiddleware``, add ``'django.middleware.locale.LocaleMiddleware'``
|
||||
to your ``MIDDLEWARE_CLASSES`` setting. Because middleware order matters, you
|
||||
should follow these guidelines:
|
||||
to your :setting:`MIDDLEWARE_CLASSES` setting. Because middleware order
|
||||
matters, you should follow these guidelines:
|
||||
|
||||
* Make sure it's one of the first middlewares installed.
|
||||
* It should come after ``SessionMiddleware``, because ``LocaleMiddleware``
|
||||
makes use of session data.
|
||||
* If you use ``CacheMiddleware``, put ``LocaleMiddleware`` after it.
|
||||
|
||||
For example, your ``MIDDLEWARE_CLASSES`` might look like this::
|
||||
For example, your :setting:`MIDDLEWARE_CLASSES` might look like this::
|
||||
|
||||
MIDDLEWARE_CLASSES = (
|
||||
'django.contrib.sessions.middleware.SessionMiddleware',
|
||||
|
|
@ -81,7 +81,7 @@ following this algorithm:
|
|||
|
||||
* Failing that, it looks for a cookie.
|
||||
|
||||
The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME``
|
||||
The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME`
|
||||
setting. (The default name is ``django_language``.)
|
||||
|
||||
* Failing that, it looks at the ``Accept-Language`` HTTP header. This
|
||||
|
|
@ -89,7 +89,7 @@ following this algorithm:
|
|||
prefer, in order by priority. Django tries each language in the header
|
||||
until it finds one with available translations.
|
||||
|
||||
* Failing that, it uses the global ``LANGUAGE_CODE`` setting.
|
||||
* Failing that, it uses the global :setting:`LANGUAGE_CODE` setting.
|
||||
|
||||
.. _locale-middleware-notes:
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ Notes:
|
|||
* Only languages listed in the :setting:`LANGUAGES` setting can be selected.
|
||||
If you want to restrict the language selection to a subset of provided
|
||||
languages (because your application doesn't provide all those languages),
|
||||
set ``LANGUAGES`` to a list of languages. For example::
|
||||
set :setting:`LANGUAGES` to a list of languages. For example::
|
||||
|
||||
LANGUAGES = (
|
||||
('de', _('German')),
|
||||
|
|
@ -118,7 +118,7 @@ Notes:
|
|||
selection to German and English (and any sublanguage, like de-ch or
|
||||
en-us).
|
||||
|
||||
* If you define a custom ``LANGUAGES`` setting, as explained in the
|
||||
* If you define a custom :setting:`LANGUAGES` setting, as explained in the
|
||||
previous bullet, it's OK to mark the languages as translation strings
|
||||
-- but use a "dummy" ``ugettext()`` function, not the one in
|
||||
``django.utils.translation``. You should *never* import
|
||||
|
|
@ -139,7 +139,8 @@ Notes:
|
|||
With this arrangement, ``django-admin.py makemessages`` will still find
|
||||
and mark these strings for translation, but the translation won't happen
|
||||
at runtime -- so you'll have to remember to wrap the languages in the
|
||||
*real* ``ugettext()`` in any code that uses ``LANGUAGES`` at runtime.
|
||||
*real* ``ugettext()`` in any code that uses :setting:`LANGUAGES` at
|
||||
runtime.
|
||||
|
||||
* The ``LocaleMiddleware`` can only select languages for which there is a
|
||||
Django-provided base translation. If you want to provide translations
|
||||
|
|
|
|||
|
|
@ -674,9 +674,9 @@ You hook it up like this::
|
|||
)
|
||||
|
||||
Each string in ``packages`` should be in Python dotted-package syntax (the
|
||||
same format as the strings in ``INSTALLED_APPS``) and should refer to a package
|
||||
that contains a ``locale`` directory. If you specify multiple packages, all
|
||||
those catalogs are merged into one catalog. This is useful if you have
|
||||
same format as the strings in :setting:`INSTALLED_APPS`) and should refer to a
|
||||
package that contains a ``locale`` directory. If you specify multiple packages,
|
||||
all those catalogs are merged into one catalog. This is useful if you have
|
||||
JavaScript that uses strings from different applications.
|
||||
|
||||
The precedence of translations is such that the packages appearing later in the
|
||||
|
|
@ -707,8 +707,8 @@ the ones appearing first having higher precedence than the ones appearing
|
|||
later.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Directories listed in ``LOCALE_PATHS`` weren't included in the lookup
|
||||
algorithm until version 1.3.
|
||||
Directories listed in :setting:`LOCALE_PATHS` weren't included in the
|
||||
lookup algorithm until version 1.3.
|
||||
|
||||
Using the JavaScript translation catalog
|
||||
----------------------------------------
|
||||
|
|
|
|||
|
|
@ -486,7 +486,7 @@ Python logging module.
|
|||
The ``include_html`` argument of ``AdminEmailHandler`` is used to
|
||||
control whether the traceback email includes an HTML attachment
|
||||
containing the full content of the debug Web page that would have been
|
||||
produced if ``DEBUG`` were ``True``. To set this value in your
|
||||
produced if :setting:`DEBUG` were ``True``. To set this value in your
|
||||
configuration, include it in the handler definition for
|
||||
``django.utils.log.AdminEmailHandler``, like this::
|
||||
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ provides the default settings as the ``default_settings`` argument (or as the
|
|||
first positional argument) in the call to ``configure()``.
|
||||
|
||||
In this example, default settings are taken from ``myapp_defaults``, and the
|
||||
``DEBUG`` setting is set to ``True``, regardless of its value in
|
||||
:setting:`DEBUG` setting is set to ``True``, regardless of its value in
|
||||
``myapp_defaults``::
|
||||
|
||||
from django.conf import settings
|
||||
|
|
|
|||
|
|
@ -101,8 +101,8 @@ In the above example, ``{{ section.title }}`` will be replaced with the
|
|||
``title`` attribute of the ``section`` object.
|
||||
|
||||
If you use a variable that doesn't exist, the template system will insert
|
||||
the value of the ``TEMPLATE_STRING_IF_INVALID`` setting, which is set to ``''``
|
||||
(the empty string) by default.
|
||||
the value of the :setting:`TEMPLATE_STRING_IF_INVALID` setting, which is set
|
||||
to ``''`` (the empty string) by default.
|
||||
|
||||
Filters
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -383,7 +383,7 @@ entirely!). If you want to use a different database name, specify
|
|||
Aside from using a separate database, the test runner will otherwise
|
||||
use all of the same database settings you have in your settings file:
|
||||
:setting:`ENGINE`, :setting:`USER`, :setting:`HOST`, etc. The test
|
||||
database is created by the user specified by ``USER``, so you'll need
|
||||
database is created by the user specified by :setting:`USER`, so you'll need
|
||||
to make sure that the given user account has sufficient privileges to
|
||||
create a new database on the system.
|
||||
|
||||
|
|
@ -1309,8 +1309,8 @@ In order to provide a reliable URL space for your test,
|
|||
``django.test.TestCase`` provides the ability to customize the URLconf
|
||||
configuration for the duration of the execution of a test suite. If your
|
||||
``TestCase`` instance defines an ``urls`` attribute, the ``TestCase`` will use
|
||||
the value of that attribute as the ``ROOT_URLCONF`` for the duration of that
|
||||
test.
|
||||
the value of that attribute as the :setting:`ROOT_URLCONF` for the duration
|
||||
of that test.
|
||||
|
||||
For example::
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue