Removed hyphen from pre-/re- prefixes.

"prepopulate", "preload", and "preprocessing" are already in the
spelling_wordlist.

This also removes hyphen from double "e" combinations with "pre" and
"re", e.g. preexisting, preempt, reestablish, or reenter.

See also:
- https://ahdictionary.com/word/search.html?q=rerun
- https://ahdictionary.com/word/search.html?q=recreate
- https://ahdictionary.com/word/search.html?q=predetermined
- https://ahdictionary.com/word/search.html?q=reuse
- https://ahdictionary.com/word/search.html?q=reopening

docs/faq/models.txt

@@ -37,8 +37,8 @@ call ``reset_queries()``, like this::
     from django.db import reset_queries
     reset_queries()
 
-Can I use Django with a pre-existing database?
-==============================================
+Can I use Django with a preexisting database?
+=============================================
 
 Yes. See :doc:`Integrating with a legacy database </howto/legacy-databases>`.
 

docs/howto/custom-model-fields.txt

@@ -98,7 +98,7 @@ Normally, you're either writing a Django field to match a particular database
 column type, or you will need a way to convert your data to, say, a string.
 
 For our ``Hand`` example, we could convert the card data to a string of 104
-characters by concatenating all the cards together in a pre-determined order --
+characters by concatenating all the cards together in a predetermined order --
 say, all the *north* cards first, then the *east*, *south* and *west* cards. So
 ``Hand`` objects can be saved to text or character columns in the database.
 
@@ -234,7 +234,7 @@ The counterpoint to writing your ``__init__()`` method is writing the
 :meth:`~.Field.deconstruct` method. It's used during :doc:`model migrations
 </topics/migrations>` to tell Django how to take an instance of your new field
 and reduce it to a serialized form - in particular, what arguments to pass to
-``__init__()`` to re-create it.
+``__init__()`` to recreate it.
 
 If you haven't added any extra options on top of the field you inherited from,
 then there's no need to write a new ``deconstruct()`` method. If, however,

docs/howto/initial-data.txt

@@ -2,7 +2,7 @@
 How to provide initial data for models
 ======================================
 
-It's sometimes useful to pre-populate your database with hard-coded data when
+It's sometimes useful to prepopulate your database with hard-coded data when
 you're first setting up an app. You can provide initial data with migrations or
 fixtures.
 
@@ -76,7 +76,7 @@ You'll store this data in a ``fixtures`` directory inside your app.
 You can load data by calling :djadmin:`manage.py loaddata <loaddata>`
 ``<fixturename>``, where ``<fixturename>`` is the name of the fixture file
 you've created. Each time you run :djadmin:`loaddata`, the data will be read
-from the fixture and re-loaded into the database. Note this means that if you
+from the fixture and reloaded into the database. Note this means that if you
 change one of the rows created by a fixture and then run :djadmin:`loaddata`
 again, you'll wipe out any changes you've made.
 

docs/ref/applications.txt

@@ -311,7 +311,7 @@ Methods
         once by Django. But in some corner cases, particularly in tests which
         are fiddling with installed applications, ``ready`` might be called more
         than once. In that case, either write idempotent methods, or put a flag
-        on your ``AppConfig`` classes to prevent re-running code which should
+        on your ``AppConfig`` classes to prevent rerunning code which should
         be executed exactly one time.
 
 .. _namespace package:

docs/ref/contrib/admin/actions.txt

@@ -312,7 +312,7 @@ Disabling a site-wide action
     Once you've done the above, that action will no longer be available
     site-wide.
 
-    If, however, you need to re-enable a globally-disabled action for one
+    If, however, you need to reenable a globally-disabled action for one
     particular model, list it explicitly in your ``ModelAdmin.actions`` list::
 
         # Globally disable delete selected

docs/ref/contrib/index.txt

@@ -15,7 +15,7 @@ those packages have.
     For most of these add-ons -- specifically, the add-ons that include either
     models or template tags -- you'll need to add the package name (e.g.,
     ``'django.contrib.redirects'``) to your :setting:`INSTALLED_APPS` setting
-    and re-run ``manage.py migrate``.
+    and rerun ``manage.py migrate``.
 
 .. toctree::
    :maxdepth: 1

docs/ref/databases.txt

@@ -30,7 +30,7 @@ General notes
 Persistent connections
 ----------------------
 
-Persistent connections avoid the overhead of re-establishing a connection to
+Persistent connections avoid the overhead of reestablishing a connection to
 the database in each request. They're controlled by the
 :setting:`CONN_MAX_AGE` parameter which defines the maximum lifetime of a
 connection. It can be set independently for each database.

docs/ref/django-admin.txt

@@ -377,7 +377,7 @@ For example, to output the data as a compressed JSON file::
 Removes all data from the database and re-executes any post-synchronization
 handlers. The table of which migrations have been applied is not cleared.
 
-If you would rather start from an empty database and re-run all migrations, you
+If you would rather start from an empty database and rerun all migrations, you
 should drop and recreate the database and then run :djadmin:`migrate` instead.
 
 .. django-admin-option:: --noinput, --no-input

docs/ref/models/expressions.txt

@@ -972,7 +972,7 @@ calling the appropriate methods on the wrapped expression.
 
     .. method:: resolve_expression(query=None, allow_joins=True, reuse=None, summarize=False, for_save=False)
 
-        Provides the chance to do any pre-processing or validation of
+        Provides the chance to do any preprocessing or validation of
         the expression before it's added to the query. ``resolve_expression()``
         must also be called on any nested expressions. A ``copy()`` of ``self``
         should be returned with any necessary transformations.
@@ -1091,7 +1091,7 @@ We do some basic validation on the parameters, including requiring at least
 ``output_field`` here so that Django knows what kind of model field to assign
 the eventual result to.
 
-Now we implement the pre-processing and validation. Since we do not have
+Now we implement the preprocessing and validation. Since we do not have
 any of our own validation at this point, we delegate to the nested
 expressions::
 

docs/ref/settings.txt

@@ -643,7 +643,7 @@ Default: ``False``
 If set to ``True``, existing :ref:`persistent database connections
 <persistent-database-connections>` will be health checked before they are
 reused in each request performing database access. If the health check fails,
-the connection will be re-established without failing the request when the
+the connection will be reestablished without failing the request when the
 connection is no longer usable but the database server is ready to accept and
 serve new connections (e.g. after database server restart closing existing
 connections).

docs/ref/template-response.txt

@@ -217,7 +217,7 @@ subsequent rendering calls do not change the response content.
 
 However, when ``response.content`` is explicitly assigned, the
 change is always applied. If you want to force the content to be
-re-rendered, you can re-evaluate the rendered content, and assign
+re-rendered, you can reevaluate the rendered content, and assign
 the content of the response manually::
 
     # Set up a rendered TemplateResponse

docs/ref/utils.txt

@@ -601,7 +601,7 @@ escaping HTML.
 
 .. function:: conditional_escape(text)
 
-    Similar to ``escape()``, except that it doesn't operate on pre-escaped
+    Similar to ``escape()``, except that it doesn't operate on preescaped
     strings, so it will not double escape.
 
 .. function:: format_html(format_string, *args, **kwargs)

docs/ref/validators.txt

@@ -10,7 +10,7 @@ Writing validators
 
 A validator is a callable that takes a value and raises a
 :exc:`~django.core.exceptions.ValidationError` if it doesn't meet some
-criteria. Validators can be useful for re-using validation logic between
+criteria. Validators can be useful for reusing validation logic between
 different types of fields.
 
 For example, here's a validator that only allows even numbers::

docs/releases/1.0.txt

@@ -73,8 +73,8 @@ You'll know that you're looking at something new or changed.
 
 The other major highlights of Django 1.0 are:
 
-Re-factored admin application
------------------------------
+Refactored admin application
+----------------------------
 
 The Django administrative interface (``django.contrib.admin``) has been
 completely refactored; admin definitions are now completely decoupled from model

docs/releases/1.1.3.txt

@@ -45,6 +45,6 @@ password hashes.
 To remedy this, ``django.contrib.admin`` will now validate that
 querystring lookup arguments either specify only fields on the model
 being viewed, or cross relations which have been explicitly
-allowed by the application developer using the pre-existing
+allowed by the application developer using the preexisting
 mechanism mentioned above. This is backwards-incompatible for any
 users relying on the prior ability to insert arbitrary lookups.

docs/releases/1.2.4.txt

@@ -45,7 +45,7 @@ password hashes.
 To remedy this, ``django.contrib.admin`` will now validate that
 querystring lookup arguments either specify only fields on the model
 being viewed, or cross relations which have been explicitly
-allowed by the application developer using the pre-existing
+allowed by the application developer using the preexisting
 mechanism mentioned above. This is backwards-incompatible for any
 users relying on the prior ability to insert arbitrary lookups.
 

docs/releases/1.6.txt

@@ -74,7 +74,7 @@ Persistent database connections
 -------------------------------
 
 Django now supports reusing the same database connection for several requests.
-This avoids the overhead of re-establishing a connection at the beginning of
+This avoids the overhead of reestablishing a connection at the beginning of
 each request. For backwards compatibility, this feature is disabled by
 default. See :ref:`persistent-database-connections` for details.
 

docs/releases/3.1.1.txt

@@ -74,7 +74,7 @@ Bugfixes
   grouping by :class:`~django.db.models.JSONField` with a custom
   :attr:`~django.db.models.JSONField.decoder` (:ticket:`31956`). As a
   consequence, fetching a ``JSONField`` with raw SQL now returns a string
-  instead of pre-loaded data. You will need to explicitly call ``json.loads()``
+  instead of preloaded data. You will need to explicitly call ``json.loads()``
   in such cases.
 
 * Fixed a ``QuerySet.delete()`` crash on MySQL, following a performance

docs/spelling_wordlist

@@ -360,11 +360,13 @@ pre
 precisions
 precomputation
 preconfigured
+preescaped
 prefetch
 prefetched
 prefetches
 prefetching
 preload
+preloaded
 prepend
 prepended
 prepending
@@ -411,6 +413,7 @@ redisplay
 redisplayed
 redisplaying
 redisplays
+reenable
 referer
 referers
 reflow

docs/topics/auth/customizing.txt

@@ -77,7 +77,7 @@ backends that follow.
 .. note::
 
     Once a user has authenticated, Django stores which backend was used to
-    authenticate the user in the user's session, and re-uses the same backend
+    authenticate the user in the user's session, and reuses the same backend
     for the duration of that session whenever access to the currently
     authenticated user is needed. This effectively means that authentication
     sources are cached on a per-session basis, so if you change
@@ -229,7 +229,7 @@ Django's permission framework does not have a place to store permissions for
 anonymous users. However, the user object passed to an authentication backend
 may be an :class:`django.contrib.auth.models.AnonymousUser` object, allowing
 the backend to specify custom authorization behavior for anonymous users. This
-is especially useful for the authors of re-usable apps, who can delegate all
+is especially useful for the authors of reusable apps, who can delegate all
 questions of authorization to the auth backend, rather than needing settings,
 for example, to control anonymous access.
 

docs/topics/db/optimization.txt

@@ -289,7 +289,7 @@ It is optimal because:
    ``display_group_members`` is ``False``.
 
 #. Storing ``group.members.all()`` in the ``members`` variable allows its
-   result cache to be re-used.
+   result cache to be reused.
 
 #. The line ``if members:`` causes ``QuerySet.__bool__()`` to be called, which
    causes the ``group.members.all()`` query to be run on the database. If there

docs/topics/db/queries.txt

@@ -810,7 +810,7 @@ reuse it::
 
     >>> queryset = Entry.objects.all()
     >>> print([p.headline for p in queryset]) # Evaluate the query set.
-    >>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation.
+    >>> print([p.pub_date for p in queryset]) # Reuse the cache from the evaluation.
 
 When ``QuerySet``\s are not cached
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1640,7 +1640,7 @@ instances::
     b = Blog.objects.get(id=1)
     b.entry_set.set([e1, e2])
 
-If the ``clear()`` method is available, any pre-existing objects will be
+If the ``clear()`` method is available, any preexisting objects will be
 removed from the ``entry_set`` before all objects in the iterable (in this
 case, a list) are added to the set. If the ``clear()`` method is *not*
 available, all objects in the iterable will be added without removing any

docs/topics/forms/index.txt

@@ -164,7 +164,7 @@ So when we handle a model instance in a view, we typically retrieve it from the
 database. When we're dealing with a form we typically instantiate it in the
 view.
 
-When we instantiate a form, we can opt to leave it empty or pre-populate it, for
+When we instantiate a form, we can opt to leave it empty or prepopulate it, for
 example with:
 
 * data from a saved model instance (as in the case of admin forms for editing)
@@ -207,7 +207,7 @@ Now you'll also need a view corresponding to that ``/your-name/`` URL which will
 find the appropriate key/value pairs in the request, and then process them.
 
 This is a very simple form. In practice, a form might contain dozens or
-hundreds of fields, many of which might need to be pre-populated, and we might
+hundreds of fields, many of which might need to be prepopulated, and we might
 expect the user to work through the edit-submit cycle several times before
 concluding the operation.
 

docs/topics/forms/modelforms.txt

@@ -820,7 +820,7 @@ Then, pass your ``BaseAuthorFormSet`` class to the factory function::
     >>> AuthorFormSet = modelformset_factory(
     ...     Author, fields=('name', 'title'), formset=BaseAuthorFormSet)
 
-If you want to return a formset that doesn't include *any* pre-existing
+If you want to return a formset that doesn't include *any* preexisting
 instances of the model, you can specify an empty QuerySet::
 
    >>> AuthorFormSet(queryset=Author.objects.none())

docs/topics/http/sessions.txt

@@ -609,7 +609,7 @@ of ``request.session`` as described above in `using sessions in views`_.
 .. note::
 
     Some browsers (Chrome, for example) provide settings that allow users to
-    continue browsing sessions after closing and re-opening the browser. In
+    continue browsing sessions after closing and reopening the browser. In
     some cases, this can interfere with the
     :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` setting and prevent sessions
     from expiring on browser close. Please be aware of this while testing

docs/topics/migrations.txt

@@ -426,7 +426,7 @@ historical model versions rather than importing them directly.
 
   If you import models directly rather than using the historical models,
   your migrations *may work initially* but will fail in the future when you
-  try to re-run old migrations (commonly, when you set up a new installation
+  try to rerun old migrations (commonly, when you set up a new installation
   and run through all the migrations to set up the database).
 
   This means that historical model problems may not be immediately obvious.