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:
Tobias Kunze 2019-06-17 16:54:55 +02:00 committed by Mariusz Felisiak
parent addabc492b
commit 4a954cfd11
149 changed files with 1101 additions and 1157 deletions

View file

@ -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',

View file

@ -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

View file

@ -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 }}