mirror of https://github.com/django/django.git
Changed some words to use inline markup.
This commit is contained in:
parent
b1005c0e40
commit
67b5f506a6
|
@ -493,8 +493,8 @@ following arguments:
|
|||
|
||||
* ``None`` (if the field allows ``null=True``)
|
||||
|
||||
In our ``HandField`` class, we're storing the data as a VARCHAR field in the
|
||||
database, so we need to be able to process strings and ``None`` in the
|
||||
In our ``HandField`` class, we're storing the data as a ``VARCHAR`` field in
|
||||
the database, so we need to be able to process strings and ``None`` in the
|
||||
``from_db_value()``. In ``to_python()``, we need to also handle ``Hand``
|
||||
instances::
|
||||
|
||||
|
|
|
@ -89,7 +89,7 @@ This is not suitable for production use! For some common deployment
|
|||
strategies, see :doc:`/howto/static-files/deployment`.
|
||||
|
||||
For example, if your :setting:`STATIC_URL` is defined as ``static/``, you can
|
||||
do this by adding the following snippet to your urls.py::
|
||||
do this by adding the following snippet to your ``urls.py``::
|
||||
|
||||
from django.conf import settings
|
||||
from django.conf.urls.static import static
|
||||
|
|
|
@ -78,7 +78,7 @@ Django's JavaScript tests use `QUnit`_. Here is an example test module:
|
|||
});
|
||||
|
||||
|
||||
Please consult the QUnit documentation for information on the types of
|
||||
Please consult the ``QUnit`` documentation for information on the types of
|
||||
`assertions supported by QUnit <https://api.qunitjs.com/assert/>`_.
|
||||
|
||||
Running tests
|
||||
|
|
|
@ -107,8 +107,9 @@ The remainder of this documentation shows commands for running tests without
|
|||
``tox``, however, any option passed to ``runtests.py`` can also be passed to
|
||||
``tox`` by prefixing the argument list with ``--``, as above.
|
||||
|
||||
Tox also respects the :envvar:`DJANGO_SETTINGS_MODULE` environment variable, if
|
||||
set. For example, the following is equivalent to the command above:
|
||||
``Tox`` also respects the :envvar:`DJANGO_SETTINGS_MODULE` environment
|
||||
variable, if set. For example, the following is equivalent to the command
|
||||
above:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
|
@ -121,9 +121,9 @@ any time leading up to the actual release:
|
|||
|
||||
$ python scripts/manage_translations.py fetch
|
||||
|
||||
and then commit the changed/added files (both .po and .mo). Sometimes there
|
||||
are validation errors which need to be debugged, so avoid doing this task
|
||||
immediately before a release is needed.
|
||||
and then commit the changed/added files (both ``.po`` and ``.mo``).
|
||||
Sometimes there are validation errors which need to be debugged, so avoid
|
||||
doing this task immediately before a release is needed.
|
||||
|
||||
#. :ref:`Update the django-admin manual page <django-admin-manpage>`::
|
||||
|
||||
|
@ -345,9 +345,9 @@ Now you're ready to actually put the release out there. To do this:
|
|||
$ twine upload -s dist/*
|
||||
|
||||
#. Go to the `Add release page in the admin`__, enter the new release number
|
||||
exactly as it appears in the name of the tarball (Django-<version>.tar.gz).
|
||||
So for example enter "1.5.1" or "1.4c2", etc. If the release is part of
|
||||
an LTS branch, mark it so.
|
||||
exactly as it appears in the name of the tarball
|
||||
(``Django-<version>.tar.gz``). So for example enter "1.5.1" or "1.4c2", etc.
|
||||
If the release is part of an LTS branch, mark it so.
|
||||
|
||||
__ https://www.djangoproject.com/admin/releases/release/add/
|
||||
|
||||
|
|
|
@ -1610,7 +1610,7 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
|
|||
Set the :class:`ForeignKey` to the value passed to
|
||||
:func:`~django.db.models.SET()`, or if a callable is passed in,
|
||||
the result of calling it. In most cases, passing a callable will be
|
||||
necessary to avoid executing queries at the time your models.py is
|
||||
necessary to avoid executing queries at the time your ``models.py`` is
|
||||
imported::
|
||||
|
||||
from django.conf import settings
|
||||
|
|
|
@ -422,7 +422,7 @@ Arguments sent with this signal:
|
|||
Same as ``sender``.
|
||||
|
||||
``verbosity``
|
||||
Indicates how much information manage.py is printing on screen. See
|
||||
Indicates how much information ``manage.py`` is printing on screen. See
|
||||
the :option:`--verbosity` flag for details.
|
||||
|
||||
Functions which listen for :data:`pre_migrate` should adjust what they
|
||||
|
@ -481,7 +481,7 @@ Arguments sent with this signal:
|
|||
Same as ``sender``.
|
||||
|
||||
``verbosity``
|
||||
Indicates how much information manage.py is printing on screen. See
|
||||
Indicates how much information ``manage.py`` is printing on screen. See
|
||||
the :option:`--verbosity` flag for details.
|
||||
|
||||
Functions which listen for :data:`post_migrate` should adjust what they
|
||||
|
|
|
@ -2397,7 +2397,7 @@ Newlines in the HTML content will be preserved.
|
|||
------------------
|
||||
|
||||
Recursively takes a self-nested list and returns an HTML unordered list --
|
||||
WITHOUT opening and closing <ul> tags.
|
||||
WITHOUT opening and closing ``<ul>`` tags.
|
||||
|
||||
The list is assumed to be in the proper format. For example, if ``var``
|
||||
contains ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then
|
||||
|
|
|
@ -551,7 +551,7 @@ need to reload your data. Do this after you have made the change to using
|
|||
|
||||
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).
|
||||
``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:
|
||||
|
|
|
@ -634,7 +634,7 @@ Django 1.4 also includes several smaller improvements worth noting:
|
|||
:meth:`~django.db.models.query.QuerySet.distinct`.
|
||||
|
||||
* The admin login page will add a password reset link if you include a URL with
|
||||
the name ``'admin_password_reset'`` in your urls.py, so plugging in the
|
||||
the name ``'admin_password_reset'`` in your ``urls.py``, so plugging in the
|
||||
built-in password reset mechanism and making it available is now much easier.
|
||||
For details, see :ref:`auth_password_reset`.
|
||||
|
||||
|
|
|
@ -263,7 +263,7 @@ Django 1.5 also includes several smaller improvements worth noting:
|
|||
* The :djadmin:`dumpdata` management command outputs one row at a time,
|
||||
preventing out-of-memory errors when dumping large datasets.
|
||||
|
||||
* In the localflavor for Canada, "pq" was added to the acceptable codes for
|
||||
* In the localflavor for Canada, ``pq`` was added to the acceptable codes for
|
||||
Quebec. It's an old abbreviation.
|
||||
|
||||
* The :ref:`receiver <connecting-receiver-functions>` decorator is now able to
|
||||
|
|
|
@ -11,7 +11,8 @@ included.
|
|||
Bug fixes
|
||||
=========
|
||||
|
||||
* Fixed ``BCryptSHA256PasswordHasher`` with py-bcrypt and Python 3 (#21398).
|
||||
* Fixed ``BCryptSHA256PasswordHasher`` with ``py-bcrypt`` and Python 3
|
||||
(#21398).
|
||||
* Fixed a regression that prevented a ``ForeignKey`` with a hidden reverse
|
||||
manager (``related_name`` ending with '+') from being used as a lookup for
|
||||
``prefetch_related`` (#21410).
|
||||
|
|
|
@ -946,7 +946,7 @@ Miscellaneous
|
|||
with ``localhost`` as the domain.
|
||||
|
||||
* The new :option:`makemessages --keep-pot` option prevents deleting the
|
||||
temporary .pot file generated before creating the .po file.
|
||||
temporary ``.pot`` file generated before creating the ``.po`` file.
|
||||
|
||||
* The undocumented ``django.core.servers.basehttp.WSGIServerException`` has
|
||||
been removed. Use ``socket.error`` provided by the standard library instead.
|
||||
|
|
|
@ -675,7 +675,7 @@ Internationalization
|
|||
beginning and end of a line and merge all lines into one using a space
|
||||
character to separate them. This is quite useful for indenting the content of
|
||||
a ``{% blocktrans %}`` tag without having the indentation characters end up
|
||||
in the corresponding entry in the PO file, which makes the translation
|
||||
in the corresponding entry in the ``.po`` file, which makes the translation
|
||||
process easier.
|
||||
|
||||
* When you run :djadmin:`makemessages` from the root directory of your project,
|
||||
|
@ -685,7 +685,7 @@ Internationalization
|
|||
|
||||
* The :djadmin:`makemessages` command now always adds the ``--previous``
|
||||
command line flag to the ``msgmerge`` command, keeping previously translated
|
||||
strings in po files for fuzzy strings.
|
||||
strings in ``.po`` files for fuzzy strings.
|
||||
|
||||
* The following settings to adjust the language cookie options were introduced:
|
||||
:setting:`LANGUAGE_COOKIE_AGE`, :setting:`LANGUAGE_COOKIE_DOMAIN`
|
||||
|
|
|
@ -77,7 +77,7 @@ Bugfixes
|
|||
* Made ``loaddata`` skip disabling and enabling database constraints when it
|
||||
doesn't load any fixtures (:ticket:`23372`).
|
||||
|
||||
* Restored ``contrib.auth`` hashers compatibility with py-bcrypt
|
||||
* Restored ``contrib.auth`` hashers compatibility with ``py-bcrypt``
|
||||
(:ticket:`26016`).
|
||||
|
||||
* Fixed a crash in ``QuerySet.values()/values_list()`` after an ``annotate()``
|
||||
|
|
|
@ -406,8 +406,8 @@ Internationalization
|
|||
project and it will find all the app message files that were created by
|
||||
:djadmin:`makemessages`.
|
||||
|
||||
* :djadmin:`makemessages` now calls xgettext once per locale directory rather
|
||||
than once per translatable file. This speeds up localization builds.
|
||||
* :djadmin:`makemessages` now calls ``xgettext`` once per locale directory
|
||||
rather than once per translatable file. This speeds up localization builds.
|
||||
|
||||
* :ttag:`blocktrans` supports assigning its output to a variable using
|
||||
``asvar``.
|
||||
|
|
|
@ -212,7 +212,7 @@ Management Commands
|
|||
``PositiveIntegerField`` or ``PositiveSmallIntegerField``.
|
||||
|
||||
* The new :option:`makemessages --add-location` option controls the comment
|
||||
format in PO files.
|
||||
format in ``.po`` files.
|
||||
|
||||
* :djadmin:`loaddata` can now :ref:`read from stdin <loading-fixtures-stdin>`.
|
||||
|
||||
|
|
|
@ -195,7 +195,6 @@ GiST
|
|||
Googol
|
||||
Greenhill
|
||||
gunicorn
|
||||
gz
|
||||
GZip
|
||||
gzipped
|
||||
hardcode
|
||||
|
@ -356,13 +355,11 @@ Pinterest
|
|||
plaintext
|
||||
pluggable
|
||||
pluralizations
|
||||
po
|
||||
pooler
|
||||
postfix
|
||||
postgis
|
||||
postgres
|
||||
postgresql
|
||||
pq
|
||||
pre
|
||||
precisions
|
||||
precomputation
|
||||
|
@ -390,7 +387,6 @@ pseudocode
|
|||
psycopg
|
||||
Punycode
|
||||
Puthraya
|
||||
py
|
||||
pyformat
|
||||
pysqlite
|
||||
pythonic
|
||||
|
@ -400,7 +396,6 @@ querysets
|
|||
querystring
|
||||
queueing
|
||||
Quickstart
|
||||
QUnit
|
||||
quoteless
|
||||
Radziej
|
||||
rasters
|
||||
|
@ -535,7 +530,6 @@ titlecase
|
|||
tokenized
|
||||
toolkits
|
||||
toolset
|
||||
Tox
|
||||
trac
|
||||
tracebacks
|
||||
transactional
|
||||
|
@ -548,7 +542,6 @@ trigram
|
|||
trigrams
|
||||
Turkmen
|
||||
tv
|
||||
ul
|
||||
umask
|
||||
unannotated
|
||||
unapplied
|
||||
|
@ -600,7 +593,6 @@ uWSGI
|
|||
validator
|
||||
validators
|
||||
validsite
|
||||
VARCHAR
|
||||
variadic
|
||||
vendored
|
||||
virtualized
|
||||
|
@ -614,6 +606,5 @@ wrappable
|
|||
wsgi
|
||||
www
|
||||
xe
|
||||
xgettext
|
||||
xxxxx
|
||||
Zope
|
||||
|
|
|
@ -234,8 +234,8 @@ them. Note that if you *do* use them, the ORM will have to go and get them in
|
|||
a separate query, making this a pessimization if you use it inappropriately.
|
||||
|
||||
Don't be too aggressive in deferring fields without profiling as the database
|
||||
has to read most of the non-text, non-VARCHAR data from the disk for a single
|
||||
row in the results, even if it ends up only using a few columns. The
|
||||
has to read most of the non-text, non-``VARCHAR`` data from the disk for a
|
||||
single row in the results, even if it ends up only using a few columns. The
|
||||
``defer()`` and ``only()`` methods are most useful when you can avoid loading a
|
||||
lot of text data or for fields that might take a lot of processing to convert
|
||||
back to Python. As always, profile first, then optimize.
|
||||
|
|
|
@ -720,8 +720,8 @@ the content of the ``{% blocktranslate %}`` tag, replace any whitespace at the
|
|||
beginning and end of a line and merge all lines into one using a space
|
||||
character to separate them. This is quite useful for indenting the content of a
|
||||
``{% blocktranslate %}`` tag without having the indentation characters end up
|
||||
in the corresponding entry in the PO file, which makes the translation process
|
||||
easier.
|
||||
in the corresponding entry in the ``.po`` file, which makes the translation
|
||||
process easier.
|
||||
|
||||
For instance, the following ``{% blocktranslate %}`` tag::
|
||||
|
||||
|
@ -730,8 +730,8 @@ For instance, the following ``{% blocktranslate %}`` tag::
|
|||
Second paragraph.
|
||||
{% endblocktranslate %}
|
||||
|
||||
will result in the entry ``"First sentence. Second paragraph."`` in the PO file,
|
||||
compared to ``"\n First sentence.\n Second paragraph.\n"``, if the
|
||||
will result in the entry ``"First sentence. Second paragraph."`` in the ``.po``
|
||||
file, compared to ``"\n First sentence.\n Second paragraph.\n"``, if the
|
||||
``trimmed`` option had not been specified.
|
||||
|
||||
String literals passed to tags and filters
|
||||
|
@ -1607,9 +1607,9 @@ otherwise, they'll be tacked together without whitespace!
|
|||
|
||||
Due to the way the ``gettext`` tools work internally and because we want to
|
||||
allow non-ASCII source strings in Django's core and your applications, you
|
||||
**must** use UTF-8 as the encoding for your PO files (the default when PO
|
||||
files are created). This means that everybody will be using the same
|
||||
encoding, which is important when Django processes the PO files.
|
||||
**must** use UTF-8 as the encoding for your ``.po`` files (the default when
|
||||
``.po`` files are created). This means that everybody will be using the
|
||||
same encoding, which is important when Django processes the ``.po`` files.
|
||||
|
||||
.. admonition:: Fuzzy entries
|
||||
|
||||
|
@ -1646,7 +1646,7 @@ That's it. Your translations are ready for use.
|
|||
:djadmin:`django-admin compilemessages <compilemessages>` works see
|
||||
:ref:`gettext_on_windows` for more information.
|
||||
|
||||
.. admonition:: .po files: Encoding and BOM usage.
|
||||
.. admonition:: ``.po`` files: Encoding and BOM usage.
|
||||
|
||||
Django only supports ``.po`` files encoded in UTF-8 and without any BOM
|
||||
(Byte Order Mark) so if your text editor adds such marks to the beginning of
|
||||
|
@ -1709,7 +1709,7 @@ You may also use ``gettext`` binaries you have obtained elsewhere, so long as
|
|||
the ``xgettext --version`` command works properly. Do not attempt to use Django
|
||||
translation utilities with a ``gettext`` package if the command ``xgettext
|
||||
--version`` entered at a Windows command prompt causes a popup window saying
|
||||
"xgettext.exe has generated errors and will be closed by Windows".
|
||||
"``xgettext.exe`` has generated errors and will be closed by Windows".
|
||||
|
||||
.. _customizing-makemessages:
|
||||
|
||||
|
|
|
@ -81,7 +81,7 @@ your project's ``manage.py`` utility::
|
|||
|
||||
Test discovery is based on the unittest module's :py:ref:`built-in test
|
||||
discovery <unittest-test-discovery>`. By default, this will discover tests in
|
||||
any file named "test*.py" under the current working directory.
|
||||
any file named ``test*.py`` under the current working directory.
|
||||
|
||||
You can specify particular tests to run by supplying any number of "test
|
||||
labels" to ``./manage.py test``. Each test label can be a full Python dotted
|
||||
|
@ -283,8 +283,8 @@ file, all Django tests run with :setting:`DEBUG`\=False. This is to ensure that
|
|||
the observed output of your code matches what will be seen in a production
|
||||
setting.
|
||||
|
||||
Caches are not cleared after each test, and running "manage.py test fooapp" can
|
||||
insert data from the tests into the cache of a live system if you run your
|
||||
Caches are not cleared after each test, and running ``manage.py test fooapp``
|
||||
can insert data from the tests into the cache of a live system if you run your
|
||||
tests in production because, unlike databases, a separate "test cache" is not
|
||||
used. This behavior :ticket:`may change <11505>` in the future.
|
||||
|
||||
|
|
Loading…
Reference in New Issue