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, 28 insertions, 29 deletions

diff --git a/docs/ref/forms/validation.txt b/docs/ref/forms/validation.txt
index 72af31d907..188ccca736 100644
--- a/docs/ref/forms/validation.txt
+++ b/docs/ref/forms/validation.txt
@@ -19,10 +19,10 @@ for the best practice in raising ``ValidationError``. If no ``ValidationError``
 is raised, the method should return the cleaned (normalized) data as a Python
 object.
 
-Most validation can be done using `validators`_ - simple helpers that can be
-reused easily. Validators are simple functions (or callables) that take a single
-argument and raise ``ValidationError`` on invalid input. Validators are run
-after the field's ``to_python`` and ``validate`` methods have been called.
+Most validation can be done using `validators`_ - helpers that can be reused.
+Validators are functions (or callables) that take a single argument and raise
+``ValidationError`` on invalid input. Validators are run after the field's
+``to_python`` and ``validate`` methods have been called.
 
 Validation of a form is split into several steps, which can be customized or
 overridden:
@@ -65,9 +65,9 @@ overridden:
   For example, if you wanted to validate that the contents of a
   ``CharField`` called ``serialnumber`` was unique,
   ``clean_serialnumber()`` would be the right place to do this. You don't
-  need a specific field (it's just a ``CharField``), but you want a
-  formfield-specific piece of validation and, possibly,
-  cleaning/normalizing the data.
+  need a specific field (it's a ``CharField``), but you want a
+  formfield-specific piece of validation and, possibly, cleaning/normalizing
+  the data.
 
   The return value of this method replaces the existing value in
   ``cleaned_data``, so it must be the field's value from ``cleaned_data`` (even
@@ -218,16 +218,16 @@ previous features.
 Using validators
 ----------------
 
-Django's form (and model) fields support use of simple utility functions and
-classes known as validators. A validator is merely a callable object or
-function that takes a value and simply returns nothing if the value is valid or
-raises a :exc:`~django.core.exceptions.ValidationError` if not. These can be
-passed to a field's constructor, via the field's ``validators`` argument, or
-defined on the :class:`~django.forms.Field` class itself with the
-``default_validators`` attribute.
+Django's form (and model) fields support use of utility functions and classes
+known as validators. A validator is a callable object or function that takes a
+value and returns nothing if the value is valid or raises a
+:exc:`~django.core.exceptions.ValidationError` if not. These can be passed to a
+field's constructor, via the field's ``validators`` argument, or defined on the
+:class:`~django.forms.Field` class itself with the ``default_validators``
+attribute.
 
-Simple validators can be used to validate values inside the field, let's have
-a look at Django's ``SlugField``::
+Validators can be used to validate values inside the field, let's have a look
+at Django's ``SlugField``::
 
     from django.core import validators
     from django.forms import CharField
@@ -235,9 +235,9 @@ a look at Django's ``SlugField``::
     class SlugField(CharField):
         default_validators = [validators.validate_slug]
 
-As you can see, ``SlugField`` is just a ``CharField`` with a customized
-validator that validates that submitted text obeys to some character rules.
-This can also be done on field definition so::
+As you can see, ``SlugField`` is a ``CharField`` with a customized validator
+that validates that submitted text obeys to some character rules. This can also
+be done on field definition so::
 
     slug = forms.SlugField()
 
@@ -281,8 +281,7 @@ Every form that uses this field will have these methods run before anything
 else can be done with the field's data. This is cleaning that is specific to
 this type of field, regardless of how it is subsequently used.
 
-Let's create a simple ``ContactForm`` to demonstrate how you'd use this
-field::
+Let's create a ``ContactForm`` to demonstrate how you'd use this field::
 
     class ContactForm(forms.Form):
         subject = forms.CharField(max_length=100)
@@ -291,10 +290,10 @@ field::
         recipients = MultiEmailField()
         cc_myself = forms.BooleanField(required=False)
 
-Simply use ``MultiEmailField`` like any other form field. When the
-``is_valid()`` method is called on the form, the ``MultiEmailField.clean()``
-method will be run as part of the cleaning process and it will, in turn, call
-the custom ``to_python()`` and ``validate()`` methods.
+Use ``MultiEmailField`` like any other form field. When the ``is_valid()``
+method is called on the form, the ``MultiEmailField.clean()`` method will be
+run as part of the cleaning process and it will, in turn, call the custom
+``to_python()`` and ``validate()`` methods.
 
 Cleaning a specific field attribute
 -----------------------------------
@@ -403,7 +402,7 @@ work out what works effectively in your particular situation. Our new code
                 self.add_error('cc_myself', msg)
                 self.add_error('subject', msg)
 
-The second argument of ``add_error()`` can be a simple string, or preferably
-an instance of ``ValidationError``. See :ref:`raising-validation-error` for
-more details. Note that ``add_error()`` automatically removes the field
-from ``cleaned_data``.
+The second argument of ``add_error()`` can be a string, or preferably an
+instance of ``ValidationError``. See :ref:`raising-validation-error` for more
+details. Note that ``add_error()`` automatically removes the field from
+``cleaned_data``.