mirror of
https://github.com/django/django.git
synced 2025-12-04 00:55:36 +00:00
Fixed #30573 -- Rephrased documentation to avoid words that minimise the involved difficulty.
This patch does not remove all occurrences of the words in question. Rather, I went through all of the occurrences of the words listed below, and judged if they a) suggested the reader had some kind of knowledge/experience, and b) if they added anything of value (including tone of voice, etc). I left most of the words alone. I looked at the following words: - simply/simple - easy/easier/easiest - obvious - just - merely - straightforward - ridiculous Thanks to Carlton Gibson for guidance on how to approach this issue, and to Tim Bell for providing the idea. But the enormous lion's share of thanks go to Adam Johnson for his patient and helpful review.
This commit is contained in:
parent
addabc492b
commit
4a954cfd11
149 changed files with 1101 additions and 1157 deletions
|
|
@ -5,7 +5,7 @@ The Django template language: for Python programmers
|
|||
.. currentmodule:: django.template
|
||||
|
||||
This document explains the Django template system from a technical
|
||||
perspective -- how it works and how to extend it. If you're just looking for
|
||||
perspective -- how it works and how to extend it. If you're looking for
|
||||
reference on the language syntax, see :doc:`/ref/templates/language`.
|
||||
|
||||
It assumes an understanding of templates, contexts, variables, tags, and
|
||||
|
|
@ -41,12 +41,12 @@ lower level APIs:
|
|||
Configuring an engine
|
||||
=====================
|
||||
|
||||
If you are simply using the
|
||||
:class:`~django.template.backends.django.DjangoTemplates` backend, this
|
||||
probably isn't the documentation you're looking for. An instance of the
|
||||
``Engine`` class described below is accessible using the ``engine`` attribute
|
||||
of that backend and any attribute defaults mentioned below are overridden by
|
||||
what's passed by :class:`~django.template.backends.django.DjangoTemplates`.
|
||||
If you are using the :class:`~django.template.backends.django.DjangoTemplates`
|
||||
backend, this probably isn't the documentation you're looking for. An instance
|
||||
of the ``Engine`` class described below is accessible using the ``engine``
|
||||
attribute of that backend and any attribute defaults mentioned below are
|
||||
overridden by what's passed by
|
||||
:class:`~django.template.backends.django.DjangoTemplates`.
|
||||
|
||||
.. class:: Engine(dirs=None, app_dirs=False, context_processors=None, debug=False, loaders=None, string_if_invalid='', file_charset='utf-8', libraries=None, builtins=None, autoescape=True)
|
||||
|
||||
|
|
@ -315,9 +315,8 @@ straight lookups. Here are some things to keep in mind:
|
|||
|
||||
.. _alters-data-description:
|
||||
|
||||
* Obviously, there can be side effects when calling some variables, and
|
||||
it'd be either foolish or a security hole to allow the template system
|
||||
to access them.
|
||||
* There can be side effects when calling some variables, and it'd be either
|
||||
foolish or a security hole to allow the template system to access them.
|
||||
|
||||
A good example is the :meth:`~django.db.models.Model.delete` method on
|
||||
each Django model object. The template system shouldn't be allowed to do
|
||||
|
|
@ -754,10 +753,10 @@ variables:
|
|||
Writing your own context processors
|
||||
-----------------------------------
|
||||
|
||||
A context processor has a very simple interface: It's a Python function
|
||||
that takes one argument, an :class:`~django.http.HttpRequest` object, and
|
||||
returns a dictionary that gets added to the template context. Each context
|
||||
processor *must* return a dictionary.
|
||||
A context processor has a simple interface: It's a Python function that takes
|
||||
one argument, an :class:`~django.http.HttpRequest` object, and returns a
|
||||
dictionary that gets added to the template context. Each context processor
|
||||
*must* return a dictionary.
|
||||
|
||||
Custom context processors can live anywhere in your code base. All Django
|
||||
cares about is that your custom context processors are pointed to by the
|
||||
|
|
@ -859,7 +858,7 @@ loaders that come with Django:
|
|||
subdirectory. If the directory exists, Django looks for templates in there.
|
||||
|
||||
This means you can store templates with your individual apps. This also
|
||||
makes it easy to distribute Django apps with default templates.
|
||||
helps to distribute Django apps with default templates.
|
||||
|
||||
For example, for this setting::
|
||||
|
||||
|
|
@ -885,8 +884,8 @@ loaders that come with Django:
|
|||
it caches a list of which :setting:`INSTALLED_APPS` packages have a
|
||||
``templates`` subdirectory.
|
||||
|
||||
You can enable this loader simply by setting
|
||||
:setting:`APP_DIRS <TEMPLATES-APP_DIRS>` to ``True``::
|
||||
You can enable this loader by setting :setting:`APP_DIRS
|
||||
<TEMPLATES-APP_DIRS>` to ``True``::
|
||||
|
||||
TEMPLATES = [{
|
||||
'BACKEND': 'django.template.backends.django.DjangoTemplates',
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ You can mix variables and strings::
|
|||
|
||||
In some cases you might want to refer to the current value of a cycle
|
||||
without advancing to the next value. To do this,
|
||||
just give the ``{% cycle %}`` tag a name, using "as", like this::
|
||||
give the ``{% cycle %}`` tag a name, using "as", like this::
|
||||
|
||||
{% cycle 'row1' 'row2' as rowcolors %}
|
||||
|
||||
|
|
@ -2182,9 +2182,9 @@ the output will be the string ``"01:23"`` (The ``"TIME_FORMAT"`` format
|
|||
specifier for the ``de`` locale as shipped with Django is ``"H:i"``).
|
||||
|
||||
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
|
||||
format a ``date`` value, use the :tfilter:`date` filter instead (or along
|
||||
``time`` if you need to render a full :py:class:`~datetime.datetime` value).
|
||||
relate to the time of day, not the date. If you need to format a ``date``
|
||||
value, use the :tfilter:`date` filter instead (or along with :tfilter:`time` if
|
||||
you need to render a full :py:class:`~datetime.datetime` value).
|
||||
|
||||
There is one exception the above rule: When passed a ``datetime`` value with
|
||||
attached timezone information (a :ref:`time-zone-aware
|
||||
|
|
|
|||
|
|
@ -36,8 +36,8 @@ Templates
|
|||
|
||||
.. highlightlang:: html+django
|
||||
|
||||
A template is simply a text file. It can generate any text-based format (HTML,
|
||||
XML, CSV, etc.).
|
||||
A template is a text file. It can generate any text-based format (HTML, XML,
|
||||
CSV, etc.).
|
||||
|
||||
A template contains **variables**, which get replaced with values when the
|
||||
template is evaluated, and **tags**, which control the logic of the template.
|
||||
|
|
@ -289,7 +289,7 @@ engine is template inheritance. Template inheritance allows you to build a base
|
|||
"skeleton" template that contains all the common elements of your site and
|
||||
defines **blocks** that child templates can override.
|
||||
|
||||
It's easiest to understand template inheritance by starting with an example::
|
||||
Let's look at template inheritance by starting with an example::
|
||||
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
|
|
@ -314,9 +314,9 @@ It's easiest to understand template inheritance by starting with an example::
|
|||
</body>
|
||||
</html>
|
||||
|
||||
This template, which we'll call ``base.html``, defines a simple HTML skeleton
|
||||
document that you might use for a simple two-column page. It's the job of
|
||||
"child" templates to fill the empty blocks with content.
|
||||
This template, which we'll call ``base.html``, defines an HTML skeleton
|
||||
document that you might use for a two-column page. It's the job of "child"
|
||||
templates to fill the empty blocks with content.
|
||||
|
||||
In this example, the :ttag:`block` tag defines three blocks that child
|
||||
templates can fill in. All the :ttag:`block` tag does is to tell the template
|
||||
|
|
@ -386,8 +386,8 @@ inheritance is the following three-level approach:
|
|||
article or blog entry. These templates extend the appropriate section
|
||||
template.
|
||||
|
||||
This approach maximizes code reuse and makes it easy to add items to shared
|
||||
content areas, such as section-wide navigation.
|
||||
This approach maximizes code reuse and helps to add items to shared content
|
||||
areas, such as section-wide navigation.
|
||||
|
||||
Here are some tips for working with inheritance:
|
||||
|
||||
|
|
@ -533,8 +533,8 @@ the output will be::
|
|||
For template blocks
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To control auto-escaping for a template, wrap the template (or just a
|
||||
particular section of the template) in the :ttag:`autoescape` tag, like so::
|
||||
To control auto-escaping for a template, wrap the template (or a particular
|
||||
section of the template) in the :ttag:`autoescape` tag, like so::
|
||||
|
||||
{% autoescape off %}
|
||||
Hello {{ name }}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue