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.

3 files changed, 30 insertions, 31 deletions

diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
index dbd8324ba2..becd34c545 100644
--- a/docs/ref/templates/api.txt
+++ b/docs/ref/templates/api.txt
@@ -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',
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index 5577131167..b5ebff2b73 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -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
diff --git a/docs/ref/templates/language.txt b/docs/ref/templates/language.txt
index 33687fc49d..62f866bbc0 100644
--- a/docs/ref/templates/language.txt
+++ b/docs/ref/templates/language.txt
@@ -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 }}