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.

1 files changed, 9 insertions, 10 deletions

diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt
index e735fce951..89ba64e691 100644
--- a/docs/ref/applications.txt
+++ b/docs/ref/applications.txt
@@ -8,7 +8,7 @@ Django contains a registry of installed applications that stores configuration
 and provides introspection. It also maintains a list of available :doc:`models
 </topics/db/models>`.
 
-This registry is simply called :attr:`~django.apps.apps` and it's available in
+This registry is called :attr:`~django.apps.apps` and it's available in
 :mod:`django.apps`::
 
     >>> from django.apps import apps
@@ -40,7 +40,7 @@ projects with the :setting:`INSTALLED_APPS` setting and optionally with other
 mechanisms such as URLconfs, the :setting:`MIDDLEWARE` setting, or template
 inheritance.
 
-It is important to understand that a Django application is just a set of code
+It is important to understand that a Django application is a set of code
 that interacts with various parts of the framework. There's no such thing as
 an ``Application`` object. However, there's a few places where Django needs to
 interact with installed applications, mainly for configuration and also for
@@ -59,9 +59,8 @@ Configuring applications
 To configure an application, subclass :class:`~django.apps.AppConfig` and put
 the dotted path to that subclass in :setting:`INSTALLED_APPS`.
 
-When :setting:`INSTALLED_APPS` simply contains the dotted path to an
-application module, Django checks for a ``default_app_config`` variable in
-that module.
+When :setting:`INSTALLED_APPS` contains the dotted path to an application
+module, Django checks for a ``default_app_config`` variable in that module.
 
 If it's defined, it's the dotted path to the :class:`~django.apps.AppConfig`
 subclass for that application.
@@ -99,11 +98,11 @@ subclass by default as follows::
     default_app_config = 'rock_n_roll.apps.RockNRollConfig'
 
 That will cause ``RockNRollConfig`` to be used when :setting:`INSTALLED_APPS`
-just contains ``'rock_n_roll'``. This allows you to make use of
-:class:`~django.apps.AppConfig` features without requiring your users to
-update their :setting:`INSTALLED_APPS` setting. Besides this use case, it's
-best to avoid using ``default_app_config`` and instead specify the app config
-class in :setting:`INSTALLED_APPS` as described next.
+contains ``'rock_n_roll'``. This allows you to make use of
+:class:`~django.apps.AppConfig` features without requiring your users to update
+their :setting:`INSTALLED_APPS` setting. Besides this use case, it's best to
+avoid using ``default_app_config`` and instead specify the app config class in
+:setting:`INSTALLED_APPS` as described next.
 
 Of course, you can also tell your users to put
 ``'rock_n_roll.apps.RockNRollConfig'`` in their :setting:`INSTALLED_APPS`