Fixed #32964 -- Corrected 'setup'/'set up' usage in docs.

This commit is contained in:
Andrew Northall 2021-08-15 20:11:25 +01:00 committed by Carlton Gibson
parent 6c3525a09d
commit c23aa73626
15 changed files with 18 additions and 17 deletions

View File

@ -74,6 +74,7 @@ answer newbie questions, and generally made Django that much better:
Andrew Godwin <andrew@aeracode.org>
Andrew Pinkham <http://AndrewsForge.com>
Andrews Medina <andrewsmedina@gmail.com>
Andrew Northall <andrew@northall.me.uk>
Andriy Sokolovskiy <me@asokolovskiy.com>
Andy Chosak <andy@chosak.org>
Andy Dustman <farcepest@gmail.com>

View File

@ -89,7 +89,7 @@ You should also configure the web server that sits in front of Django to
validate the host. It should respond with a static error page or ignore
requests for incorrect hosts instead of forwarding the request to Django. This
way you'll avoid spurious errors in your Django logs (or emails if you have
error reporting configured that way). For example, on nginx you might setup a
error reporting configured that way). For example, on nginx you might set up a
default server to return "444 No Response" on an unrecognized host:
.. code-block:: nginx

View File

@ -37,7 +37,7 @@ Authentication with ``mod_wsgi``
information about this setting.
Make sure that mod_wsgi is installed and activated and that you have
followed the steps to setup :doc:`Apache with mod_wsgi
followed the steps to set up :doc:`Apache with mod_wsgi
</howto/deployment/wsgi/modwsgi>`.
Next, edit your Apache configuration to add a location that you want

View File

@ -65,7 +65,7 @@ following::
...\> py -m venv project-name
This will create a folder called 'project-name' if it does not already exist
and setup the virtual environment. To activate the environment, run::
and set up the virtual environment. To activate the environment, run::
...\> project-name\Scripts\activate.bat

View File

@ -311,7 +311,7 @@ You can also install the database adapter(s) of your choice using
If you want to test the memcached cache backend, you'll also need to define
a :setting:`CACHES` setting that points at your memcached instance.
To run the GeoDjango tests, you will need to :doc:`setup a spatial database
To run the GeoDjango tests, you will need to :doc:`set up a spatial database
and install the Geospatial libraries</ref/contrib/gis/install/index>`.
Each of these dependencies is optional. If you're missing any of them, the

View File

@ -24,7 +24,7 @@ your operating system's package manager.
Django's `Git repository`_ is hosted on `GitHub`_, and it is recommended
that you also work using GitHub.
After installing Git, the first thing you should do is setup your name and
After installing Git, the first thing you should do is set up your name and
email::
$ git config --global user.name "Your Real Name"
@ -55,7 +55,7 @@ cloned directory, so switch to it now::
Your GitHub repository will be called "origin" in Git.
You should also setup ``django/django`` as an "upstream" remote (that is, tell
You should also set up ``django/django`` as an "upstream" remote (that is, tell
git that the reference Django repository was the source of your fork of it)::
git remote add upstream git@github.com:django/django.git

View File

@ -3,8 +3,8 @@ Writing your first Django app, part 2
=====================================
This tutorial begins where :doc:`Tutorial 1 </intro/tutorial01>` left off.
We'll setup the database, create your first model, and get a quick introduction
to Django's automatically-generated admin site.
We'll set up the database, create your first model, and get a quick
introduction to Django's automatically-generated admin site.
.. admonition:: Where to get help:

View File

@ -368,7 +368,7 @@ environment in the :djadmin:`shell`:
:meth:`~django.test.utils.setup_test_environment` installs a template renderer
which will allow us to examine some additional attributes on responses such as
``response.context`` that otherwise wouldn't be available. Note that this
method *does not* setup a test database, so the following will be run against
method *does not* set up a test database, so the following will be run against
the existing database and the output may differ slightly depending on what
questions you already created. You might get unexpected results if your
``TIME_ZONE`` in ``settings.py`` isn't correct. If you don't remember setting

View File

@ -33,7 +33,7 @@ GeoDjango form fields take the following optional arguments.
.. attribute:: Field.geom_type
You generally shouldn't have to set or change that attribute which should
be setup depending on the field class. It matches the OpenGIS standard
be set up depending on the field class. It matches the OpenGIS standard
geometry name.
Form field classes

View File

@ -261,7 +261,7 @@ transform do not change. For example::
Read about `the performance considerations`_ prior to using it.
To use ``citext``, use the :class:`.CITextExtension` operation to
:ref:`setup the citext extension <create-postgresql-extensions>` in
:ref:`set up the citext extension <create-postgresql-extensions>` in
PostgreSQL before the first ``CreateModel`` migration operation.
If you're using an :class:`~django.contrib.postgres.fields.ArrayField`
@ -307,7 +307,7 @@ transform do not change. For example::
To use this field, you'll need to:
#. Add ``'django.contrib.postgres'`` in your :setting:`INSTALLED_APPS`.
#. :ref:`Setup the hstore extension <create-postgresql-extensions>` in
#. :ref:`Set up the hstore extension <create-postgresql-extensions>` in
PostgreSQL.
You'll see an error like ``can't adapt type 'dict'`` if you skip the first

View File

@ -454,7 +454,7 @@ foundation for custom widgets.
return '{}-{}-{}'.format(year, month, day)
The constructor creates several :class:`Select` widgets in a list. The
``super()`` method uses this list to setup the widget.
``super()`` method uses this list to set up the widget.
The required method :meth:`~MultiWidget.decompress` breaks up a
``datetime.date`` value into the day, month, and year values corresponding

View File

@ -130,7 +130,7 @@ for each test.
* The class method
:meth:`TestCase.setUpTestData() <django.test.TestCase.setUpTestData>` adds
the ability to setup test data at the class level. Using this technique can
the ability to set up test data at the class level. Using this technique can
speed up the tests as compared to using ``setUp()``.
* Fixture loading within ``TestCase`` is now performed once for the whole

View File

@ -100,7 +100,7 @@ Generic Views
* The new :meth:`View.setup <django.views.generic.base.View.setup>` hook
initializes view attributes before calling
:meth:`~django.views.generic.base.View.dispatch`. It allows mixins to setup
:meth:`~django.views.generic.base.View.dispatch`. It allows mixins to set up
instance attributes for reuse in child classes.
Internationalization

View File

@ -1145,7 +1145,7 @@ implementation details see :ref:`using-the-views`.
<input type="hidden" name="next" value="{{ next }}">
</form>
{# Assumes you setup the password_reset view in your URLconf #}
{# Assumes you set up the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>
{% endblock %}

View File

@ -768,7 +768,7 @@ utility methods in the ``django.test.utils`` module.
:func:`teardown_databases` function at the conclusion of testing.
The ``aliases`` argument determines which :setting:`DATABASES` aliases test
databases should be setup for. If it's not provided, it defaults to all of
databases should be set up for. If it's not provided, it defaults to all of
:setting:`DATABASES` aliases.
The ``serialized_aliases`` argument determines what subset of ``aliases``