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.

docs/topics/auth/customizing.txt

@@ -82,8 +82,8 @@ backends that follow.
     authenticated user is needed. This effectively means that authentication
     sources are cached on a per-session basis, so if you change
     :setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data if
-    you need to force users to re-authenticate using different methods. A simple
-    way to do that is simply to execute ``Session.objects.all().delete()``.
+    you need to force users to re-authenticate using different methods. A
+    simple way to do that is to execute ``Session.objects.all().delete()``.
 
 Writing an authentication backend
 ---------------------------------
@@ -98,7 +98,7 @@ database ID or whatever, but has to be the primary key of your user object --
 and returns a user object or ``None``.
 
 The ``authenticate`` method takes a ``request`` argument and credentials as
-keyword arguments. Most of the time, it'll just look like this::
+keyword arguments. Most of the time, it'll look like this::
 
     from django.contrib.auth.backends import BaseBackend
 
@@ -197,7 +197,7 @@ exception in :meth:`~django.contrib.auth.models.User.has_perm()` or
 :meth:`~django.contrib.auth.models.User.has_module_perms()`, the authorization
 will immediately fail and Django won't check the backends that follow.
 
-A backend could implement permissions for the magic admin fairly simply::
+A backend could implement permissions for the magic admin like this::
 
     from django.contrib.auth.backends import BaseBackend
 
@@ -729,7 +729,7 @@ Writing a manager for a custom user model
 You should also define a custom manager for your user model. If your user model
 defines ``username``, ``email``, ``is_staff``, ``is_active``, ``is_superuser``,
 ``last_login``, and ``date_joined`` fields the same as Django's default user,
-you can just install Django's :class:`~django.contrib.auth.models.UserManager`;
+you can install Django's :class:`~django.contrib.auth.models.UserManager`;
 however, if your user model defines different fields, you'll need to define a
 custom manager that extends :class:`~django.contrib.auth.models.BaseUserManager`
 providing two additional methods:
@@ -793,10 +793,10 @@ Extending Django's default ``User``
 -----------------------------------
 
 If you're entirely happy with Django's :class:`~django.contrib.auth.models.User`
-model and you just want to add some additional profile information, you could
-simply subclass :class:`django.contrib.auth.models.AbstractUser` and add your
-custom profile fields, although we'd recommend a separate model as described in
-the "Model design considerations" note of :ref:`specifying-custom-user-model`.
+model, but you want to add some additional profile information, you could
+subclass :class:`django.contrib.auth.models.AbstractUser` and add your custom
+profile fields, although we'd recommend a separate model as described in the
+"Model design considerations" note of :ref:`specifying-custom-user-model`.
 ``AbstractUser`` provides the full implementation of the default
 :class:`~django.contrib.auth.models.User` as an :ref:`abstract model
 <abstract-base-classes>`.
@@ -835,8 +835,8 @@ to work with a custom user model:
 * :class:`~django.contrib.auth.forms.UserCreationForm`
 * :class:`~django.contrib.auth.forms.UserChangeForm`
 
-If your custom user model is a simple subclass of ``AbstractUser``, then you
-can extend these forms in this manner::
+If your custom user model is a subclass of ``AbstractUser``, then you can
+extend these forms in this manner::
 
     from django.contrib.auth.forms import UserCreationForm
     from myapp.models import CustomUser
@@ -1009,10 +1009,10 @@ A full example
 
 Here is an example of an admin-compliant custom user app. This user model uses
 an email address as the username, and has a required date of birth; it
-provides no permission checking, beyond a simple ``admin`` flag on the user
-account. This model would be compatible with all the built-in auth forms and
-views, except for the user creation forms. This example illustrates how most of
-the components work together, but is not intended to be copied directly into
+provides no permission checking beyond an ``admin`` flag on the user account.
+This model would be compatible with all the built-in auth forms and views,
+except for the user creation forms. This example illustrates how most of the
+components work together, but is not intended to be copied directly into
 projects for production use.
 
 This code would all live in a ``models.py`` file for a custom

docs/topics/auth/default.txt

@@ -150,7 +150,7 @@ Authenticating users
 Permissions and Authorization
 =============================
 
-Django comes with a simple permissions system. It provides a way to assign
+Django comes with a built-in permissions system. It provides a way to assign
 permissions to specific users and groups of users.
 
 It's used by the Django admin site, but you're welcome to use it in your own
@@ -473,7 +473,7 @@ Limiting access to logged-in users
 The raw way
 ~~~~~~~~~~~
 
-The simple, raw way to limit access to pages is to check
+The raw way to limit access to pages is to check
 :attr:`request.user.is_authenticated
 <django.contrib.auth.models.User.is_authenticated>` and either redirect to a
 login page::
@@ -615,10 +615,9 @@ Limiting access to logged-in users that pass a test
 To limit access based on certain permissions or some other test, you'd do
 essentially the same thing as described in the previous section.
 
-The simple way is to run your test on :attr:`request.user
-<django.http.HttpRequest.user>` in the view directly. For example, this view
-checks to make sure the user has an email in the desired domain and if not,
-redirects to the login page::
+You can run your test on :attr:`request.user <django.http.HttpRequest.user>` in
+the view directly. For example, this view checks to make sure the user has an
+email in the desired domain and if not, redirects to the login page::
 
     from django.shortcuts import redirect
 
@@ -1015,8 +1014,8 @@ implementation details see :ref:`using-the-views`.
     * ``redirect_field_name``: The name of a ``GET`` field containing the
       URL to redirect to after login. Defaults to ``next``.
 
-    * ``authentication_form``: A callable (typically just a form class) to
-      use for authentication. Defaults to
+    * ``authentication_form``: A callable (typically a form class) to use for
+      authentication. Defaults to
       :class:`~django.contrib.auth.forms.AuthenticationForm`.
 
     * ``extra_context``: A dictionary of context data that will be added to the

docs/topics/auth/passwords.txt

@@ -423,8 +423,8 @@ Password validation
 
 Users often choose poor passwords. To help mitigate this problem, Django
 offers pluggable password validation. You can configure multiple password
-validators at the same time. A few validators are included in Django, but it's
-simple to write your own as well.
+validators at the same time. A few validators are included in Django, but you
+can write your own as well.
 
 Each password validator must provide a help text to explain the requirements to
 the user, validate a given password and return an error message if it does not
@@ -434,7 +434,7 @@ Validators can also have optional settings to fine tune their behavior.
 Validation is controlled by the :setting:`AUTH_PASSWORD_VALIDATORS` setting.
 The default for the setting is an empty list, which means no validators are
 applied. In new projects created with the default :djadmin:`startproject`
-template, a simple set of validators is enabled.
+template, a set of validators is enabled by default.
 
 By default, validators are used in the forms to reset or change passwords and
 in the :djadmin:`createsuperuser` and :djadmin:`changepassword` management
@@ -479,10 +479,9 @@ This example enables all four included validators:
 
 * ``UserAttributeSimilarityValidator``, which checks the similarity between
   the password and a set of attributes of the user.
-* ``MinimumLengthValidator``, which simply checks whether the password meets a
-  minimum length. This validator is configured with a custom option: it now
-  requires the minimum length to be nine characters, instead of the default
-  eight.
+* ``MinimumLengthValidator``, which checks whether the password meets a minimum
+  length. This validator is configured with a custom option: it now requires
+  the minimum length to be nine characters, instead of the default eight.
 * ``CommonPasswordValidator``, which checks whether the password occurs in a
   list of common passwords. By default, it compares to an included list of
   20,000 common passwords.
@@ -490,8 +489,8 @@ This example enables all four included validators:
   entirely numeric.
 
 For ``UserAttributeSimilarityValidator`` and ``CommonPasswordValidator``,
-we're simply using the default settings in this example.
-``NumericPasswordValidator`` has no settings.
+we're using the default settings in this example. ``NumericPasswordValidator``
+has no settings.
 
 The help texts and any errors from password validators are always returned in
 the order they are listed in :setting:`AUTH_PASSWORD_VALIDATORS`.
@@ -601,15 +600,15 @@ Writing your own validator
 --------------------------
 
 If Django's built-in validators are not sufficient, you can write your own
-password validators. Validators are fairly simple classes. They must implement
-two methods:
+password validators. Validators have a fairly small interface. They must
+implement two methods:
 
 * ``validate(self, password, user=None)``: validate a password. Return
   ``None`` if the password is valid, or raise a
   :exc:`~django.core.exceptions.ValidationError` with an error message if the
   password is not valid. You must be able to deal with ``user`` being
-  ``None`` - if that means your validator can't run, simply return ``None``
-  for no error.
+  ``None`` - if that means your validator can't run, return ``None`` for no
+  error.
 * ``get_help_text()``: provide a help text to explain the requirements to
   the user.