diff --git a/docs/faq/models.txt b/docs/faq/models.txt index baace7901b..42c9604d53 100644 --- a/docs/faq/models.txt +++ b/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 `. diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt index c4621c8500..5f563d920b 100644 --- a/docs/howto/custom-model-fields.txt +++ b/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 ` 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, diff --git a/docs/howto/initial-data.txt b/docs/howto/initial-data.txt index aafe14cc76..7a43196957 100644 --- a/docs/howto/initial-data.txt +++ b/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 ` ````, where ```` 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. diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt index 2c66ae0e68..af387ac884 100644 --- a/docs/ref/applications.txt +++ b/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: diff --git a/docs/ref/contrib/admin/actions.txt b/docs/ref/contrib/admin/actions.txt index da60bc3bbe..56e8d7feae 100644 --- a/docs/ref/contrib/admin/actions.txt +++ b/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 diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt index 8a9a90e5e8..517c9ef418 100644 --- a/docs/ref/contrib/index.txt +++ b/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 diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 1129be600c..009cce6f97 100644 --- a/docs/ref/databases.txt +++ b/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. diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index fc1f6b7257..1b487c1e18 100644 --- a/docs/ref/django-admin.txt +++ b/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 diff --git a/docs/ref/models/expressions.txt b/docs/ref/models/expressions.txt index 60c4c87dcd..b3702116d7 100644 --- a/docs/ref/models/expressions.txt +++ b/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:: diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index ae1b15eab0..d91e0d5ef5 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -643,7 +643,7 @@ Default: ``False`` If set to ``True``, existing :ref:`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). diff --git a/docs/ref/template-response.txt b/docs/ref/template-response.txt index 1babb220f7..abbc12742b 100644 --- a/docs/ref/template-response.txt +++ b/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 diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt index a2be25f168..7712015929 100644 --- a/docs/ref/utils.txt +++ b/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) diff --git a/docs/ref/validators.txt b/docs/ref/validators.txt index 4230738a2b..5fe1384bd8 100644 --- a/docs/ref/validators.txt +++ b/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:: diff --git a/docs/releases/1.0.txt b/docs/releases/1.0.txt index 84e4837692..1fc48330f6 100644 --- a/docs/releases/1.0.txt +++ b/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 diff --git a/docs/releases/1.1.3.txt b/docs/releases/1.1.3.txt index c88d676f7e..7be4061957 100644 --- a/docs/releases/1.1.3.txt +++ b/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. diff --git a/docs/releases/1.2.4.txt b/docs/releases/1.2.4.txt index 26a67d9d1e..587bffebde 100644 --- a/docs/releases/1.2.4.txt +++ b/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. diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index aac7c80c59..4109565448 100644 --- a/docs/releases/1.6.txt +++ b/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. diff --git a/docs/releases/3.1.1.txt b/docs/releases/3.1.1.txt index 906e52924a..c833807338 100644 --- a/docs/releases/3.1.1.txt +++ b/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 diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index fa33256ba2..29bc732dfe 100644 --- a/docs/spelling_wordlist +++ b/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 diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt index 382fc94a6b..38ee57240f 100644 --- a/docs/topics/auth/customizing.txt +++ b/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. diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt index 166d50710f..ca04c8fd55 100644 --- a/docs/topics/db/optimization.txt +++ b/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 diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt index af26462367..c6349792b7 100644 --- a/docs/topics/db/queries.txt +++ b/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 diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 0e98e50692..e7709834c2 100644 --- a/docs/topics/forms/index.txt +++ b/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. diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt index 26a5fc8b0f..3332709089 100644 --- a/docs/topics/forms/modelforms.txt +++ b/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()) diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt index c5c78a263a..553fb06a61 100644 --- a/docs/topics/http/sessions.txt +++ b/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 diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt index 73dec300e0..3f443e867b 100644 --- a/docs/topics/migrations.txt +++ b/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.