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/db/aggregation.txt

@@ -135,9 +135,9 @@ by providing that name when you specify the aggregate clause::
     >>> Book.objects.aggregate(average_price=Avg('price'))
     {'average_price': 34.35}
 
-If you want to generate more than one aggregate, you just add another
-argument to the ``aggregate()`` clause. So, if we also wanted to know
-the maximum and minimum price of all books, we would issue the query::
+If you want to generate more than one aggregate, you add another argument to
+the ``aggregate()`` clause. So, if we also wanted to know the maximum and
+minimum price of all books, we would issue the query::
 
     >>> from django.db.models import Avg, Max, Min
     >>> Book.objects.aggregate(Avg('price'), Max('price'), Min('price'))

docs/topics/db/examples/one_to_one.txt

@@ -102,9 +102,9 @@ raises ``ValueError``::
     ...
     ValueError: save() prohibited to prevent data loss due to unsaved related object 'place'.
 
-Restaurant.objects.all() just returns the Restaurants, not the Places.  Note
-that there are two restaurants - Ace Hardware the Restaurant was created in the
-call to r.place = p2::
+Restaurant.objects.all() returns the Restaurants, not the Places. Note that
+there are two restaurants - Ace Hardware the Restaurant was created in the call
+to r.place = p2::
 
     >>> Restaurant.objects.all()
     <QuerySet [<Restaurant: Demon Dogs the restaurant>, <Restaurant: Ace Hardware the restaurant>]>

docs/topics/db/managers.txt

@@ -145,8 +145,8 @@ So these statements are all legal::
 
 This example also pointed out another interesting technique: using multiple
 managers on the same model. You can attach as many ``Manager()`` instances to
-a model as you'd like. This is an easy way to define common "filters" for your
-models.
+a model as you'd like. This is a non-repetitive way to define common "filters"
+for your models.
 
 For example::
 
@@ -396,7 +396,7 @@ manager, you can provide the default manager on the child class::
         default_manager = OtherManager()
 
 Here, ``default_manager`` is the default. The ``objects`` manager is
-still available, since it's inherited. It just isn't used as the default.
+still available, since it's inherited, but isn't used as the default.
 
 Finally for this example, suppose you want to add extra managers to the child
 class, but still use the default from ``AbstractBase``. You can't add the new

docs/topics/db/models.txt

@@ -265,7 +265,7 @@ By default, Django gives each model the following field::
 
 This is an auto-incrementing primary key.
 
-If you'd like to specify a custom primary key, just specify
+If you'd like to specify a custom primary key, specify
 :attr:`primary_key=True <Field.primary_key>` on one of your fields. If Django
 sees you've explicitly set :attr:`Field.primary_key`, it won't add the automatic
 ``id`` column.
@@ -436,8 +436,8 @@ should work; all are optional.
 Extra fields on many-to-many relationships
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-When you're only dealing with simple many-to-many relationships such as
-mixing and matching pizzas and toppings, a standard
+When you're only dealing with many-to-many relationships such as mixing and
+matching pizzas and toppings, a standard
 :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes
 you may need to associate data with the relationship between two models.
 
@@ -640,7 +640,7 @@ Models across files
 
 It's perfectly OK to relate a model to one from another app. To do this, import
 the related model at the top of the file where your model is defined. Then,
-just refer to the other model class wherever needed. For example::
+refer to the other model class wherever needed. For example::
 
     from django.db import models
     from geography.models import ZipCode
@@ -1218,7 +1218,7 @@ accessible through ``MyPerson``, and vice-versa::
 
 You could also use a proxy model to define a different default ordering on
 a model. You might not always want to order the ``Person`` model, but regularly
-order by the ``last_name`` attribute when you use the proxy. This is easy::
+order by the ``last_name`` attribute when you use the proxy::
 
     class OrderedPerson(Person):
         class Meta:

docs/topics/db/multi-db.txt

@@ -438,8 +438,8 @@ Manually selecting a database for a ``QuerySet``
 ------------------------------------------------
 
 You can select the database for a ``QuerySet`` at any point in the
-``QuerySet`` "chain." Just call ``using()`` on the ``QuerySet`` to get
-another ``QuerySet`` that uses the specified database.
+``QuerySet`` "chain." Call ``using()`` on the ``QuerySet`` to get another
+``QuerySet`` that uses the specified database.
 
 ``using()`` takes a single argument: the alias of the database on
 which you want to run the query. For example::

docs/topics/db/optimization.txt

@@ -53,7 +53,7 @@ Use standard DB optimization techniques
 
 * Appropriate use of field types.
 
-We will assume you have done the obvious things above. The rest of this document
+We will assume you have done the things listed above. The rest of this document
 focuses on how to use Django in such a way that you are not doing unnecessary
 work. This document also does not address other optimization techniques that
 apply to all expensive operations, such as :doc:`general purpose caching
@@ -217,7 +217,7 @@ Don't retrieve things you don't need
 Use ``QuerySet.values()`` and ``values_list()``
 -----------------------------------------------
 
-When you just want a ``dict`` or ``list`` of values, and don't need ORM model
+When you only want a ``dict`` or ``list`` of values, and don't need ORM model
 objects, make appropriate usage of
 :meth:`~django.db.models.query.QuerySet.values()`.
 These can be useful for replacing model objects in template code - as long as
@@ -260,7 +260,7 @@ But:
 Don't overuse ``count()`` and ``exists()``
 ------------------------------------------
 
-If you are going to need other data from the QuerySet, just evaluate it.
+If you are going to need other data from the QuerySet, evaluate it immediately.
 
 For example, assuming an Email model that has a ``body`` attribute and a
 many-to-many relation to User, the following template code is optimal:

docs/topics/db/queries.txt

@@ -96,10 +96,10 @@ Saving ``ForeignKey`` and ``ManyToManyField`` fields
 ----------------------------------------------------
 
 Updating a :class:`~django.db.models.ForeignKey` field works exactly the same
-way as saving a normal field -- simply assign an object of the right type to
-the field in question. This example updates the ``blog`` attribute of an
-``Entry`` instance ``entry``, assuming appropriate instances of ``Entry`` and
-``Blog`` are already saved to the database (so we can retrieve them below)::
+way as saving a normal field -- assign an object of the right type to the field
+in question. This example updates the ``blog`` attribute of an ``Entry``
+instance ``entry``, assuming appropriate instances of ``Entry`` and ``Blog``
+are already saved to the database (so we can retrieve them below)::
 
     >>> from blog.models import Blog, Entry
     >>> entry = Entry.objects.get(pk=1)
@@ -365,9 +365,9 @@ Further filtering or ordering of a sliced queryset is prohibited due to the
 ambiguous nature of how that might work.
 
 To retrieve a *single* object rather than a list
-(e.g. ``SELECT foo FROM bar LIMIT 1``), use a simple index instead of a
-slice. For example, this returns the first ``Entry`` in the database, after
-ordering entries alphabetically by headline::
+(e.g. ``SELECT foo FROM bar LIMIT 1``), use an index instead of a slice. For
+example, this returns the first ``Entry`` in the database, after ordering
+entries alphabetically by headline::
 
     >>> Entry.objects.order_by('headline')[0]
 
@@ -484,7 +484,7 @@ Lookups that span relationships
 
 Django offers a powerful and intuitive way to "follow" relationships in
 lookups, taking care of the SQL ``JOIN``\s for you automatically, behind the
-scenes. To span a relationship, just use the field name of related fields
+scenes. To span a relationship, use the field name of related fields
 across models, separated by double underscores, until you get to the field you
 want.
 
@@ -495,7 +495,7 @@ is ``'Beatles Blog'``::
 
 This spanning can be as deep as you'd like.
 
-It works backwards, too. To refer to a "reverse" relationship, just use the
+It works backwards, too. To refer to a "reverse" relationship, use the
 lowercase name of the model.
 
 This example retrieves all ``Blog`` objects which have at least one ``Entry``
@@ -700,8 +700,8 @@ statement, the percent sign signifies a multiple-character wildcard and the
 underscore signifies a single-character wildcard.)
 
 This means things should work intuitively, so the abstraction doesn't leak.
-For example, to retrieve all the entries that contain a percent sign, just use
-the percent sign as any other character::
+For example, to retrieve all the entries that contain a percent sign, use the
+percent sign as any other character::
 
     >>> Entry.objects.filter(headline__contains='%')
 
@@ -746,8 +746,8 @@ your database load. Also, there's a possibility the two lists may not include
 the same database records, because an ``Entry`` may have been added or deleted
 in the split second between the two requests.
 
-To avoid this problem, simply save the
-:class:`~django.db.models.query.QuerySet` and reuse it::
+To avoid this problem, save the :class:`~django.db.models.query.QuerySet` and
+reuse it::
 
     >>> queryset = Entry.objects.all()
     >>> print([p.headline for p in queryset]) # Evaluate the query set.
@@ -875,7 +875,7 @@ precede the definition of any keyword arguments. For example::
 Comparing objects
 =================
 
-To compare two model instances, just use the standard Python comparison operator,
+To compare two model instances, use the standard Python comparison operator,
 the double equals sign: ``==``. Behind the scenes, that compares the primary
 key values of two models.
 
@@ -954,7 +954,7 @@ Copying model instances
 
 Although there is no built-in method for copying model instances, it is
 possible to easily create new instance with all fields' values copied. In the
-simplest case, you can just set ``pk`` to ``None``. Using our blog example::
+simplest case, you can set ``pk`` to ``None``. Using our blog example::
 
     blog = Blog(name='My blog', tagline='Blogging is easy')
     blog.save() # blog.pk == 1
@@ -1040,8 +1040,8 @@ statement. It is a bulk operation for direct updates. It doesn't run any
 :attr:`~django.db.models.DateField.auto_now` field option.
 If you want to save every item in a :class:`~django.db.models.query.QuerySet`
 and make sure that the :meth:`~django.db.models.Model.save` method is called on
-each instance, you don't need any special function to handle that. Just loop
-over them and call :meth:`~django.db.models.Model.save`::
+each instance, you don't need any special function to handle that. Loop over
+them and call :meth:`~django.db.models.Model.save`::
 
     for item in my_queryset:
         item.save()
@@ -1096,8 +1096,7 @@ Forward
 ~~~~~~~
 
 If a model has a :class:`~django.db.models.ForeignKey`, instances of that model
-will have access to the related (foreign) object via a simple attribute of the
-model.
+will have access to the related (foreign) object via an attribute of the model.
 
 Example::
 
@@ -1285,7 +1284,7 @@ One-to-one relationships
 
 One-to-one relationships are very similar to many-to-one relationships. If you
 define a :class:`~django.db.models.OneToOneField` on your model, instances of
-that model will have access to the related object via a simple attribute of the
+that model will have access to the related object via an attribute of the
 model.
 
 For example::

docs/topics/db/search.txt

@@ -16,8 +16,8 @@ Use Cases
 Standard textual queries
 ------------------------
 
-Text-based fields have a selection of simple matching operations. For example,
-you may wish to allow lookup of an author like so::
+Text-based fields have a selection of matching operations. For example, you may
+wish to allow lookup up an author like so::
 
     >>> Author.objects.filter(name__contains='Terry')
     [<Author: Terry Gilliam>, <Author: Terry Jones>]
@@ -77,7 +77,7 @@ enter something close (by varying definitions) to the source data.
 Document-based search
 ---------------------
 
-Simple database operations are too simple an approach when you start
+Standard database operations stop being a useful approach when you start
 considering large blocks of text. Whereas the examples above can be thought of
 as operations on a string of characters, full text search looks at the actual
 words. Depending on the system used, it's likely to use some of the following
@@ -109,8 +109,8 @@ your database and so can easily be combined with other relational queries such
 as categorization.
 
 The :mod:`django.contrib.postgres` module provides some helpers to make these
-queries. For example, a simple query might be to select all the blog entries
-which mention "cheese"::
+queries. For example, a query might select all the blog entries which mention
+"cheese"::
 
     >>> Entry.objects.filter(body_text__search='cheese')
     [<Entry: Cheese on Toast recipes>, <Entry: Pizza recipes>]

docs/topics/db/sql.txt

@@ -46,8 +46,8 @@ return model instances:
 
 This method takes a raw SQL query, executes it, and returns a
 ``django.db.models.query.RawQuerySet`` instance. This ``RawQuerySet`` instance
-can be iterated over just like a normal
-:class:`~django.db.models.query.QuerySet` to provide object instances.
+can be iterated over like a normal :class:`~django.db.models.query.QuerySet` to
+provide object instances.
 
 This is best illustrated with an example. Suppose you have the following model::
 

docs/topics/db/transactions.txt

@@ -61,7 +61,7 @@ either all or none of the changes will be committed.
     generating a streaming response, since there's no sensible way to handle
     errors after starting to send the response.
 
-In practice, this feature simply wraps every view function in the :func:`atomic`
+In practice, this feature wraps every view function in the :func:`atomic`
 decorator described below.
 
 Note that only the execution of your view is enclosed in the transactions.
@@ -410,7 +410,7 @@ For instance, if your database connection is dropped because your process was
 killed without a chance to shut down gracefully, your rollback hook will never
 run.
 
-The solution is simple: instead of doing something during the atomic block
+But there is a solution: instead of doing something during the atomic block
 (transaction) and then undoing it if the transaction fails, use
 :func:`on_commit` to delay doing it in the first place until after the
 transaction succeeds. It's a lot easier to undo something you never did in the
@@ -432,8 +432,8 @@ Low-level APIs
 Autocommit
 ----------
 
-Django provides a straightforward API in the :mod:`django.db.transaction`
-module to manage the autocommit state of each database connection.
+Django provides an API in the :mod:`django.db.transaction` module to manage the
+autocommit state of each database connection.
 
 .. function:: get_autocommit(using=None)
 
@@ -622,7 +622,7 @@ Handling exceptions within PostgreSQL transactions
 Inside a transaction, when a call to a PostgreSQL cursor raises an exception
 (typically ``IntegrityError``), all subsequent SQL in the same transaction
 will fail with the error "current transaction is aborted, queries ignored
-until end of transaction block". While simple use of ``save()`` is unlikely
+until end of transaction block". While the basic use of ``save()`` is unlikely
 to raise an exception in PostgreSQL, there are more advanced usage patterns
 which might, such as saving objects with unique fields, saving using the
 force_insert/force_update flag, or invoking custom SQL.