Fixed #32964 -- Corrected 'setup'/'set up' usage in docs.
This commit is contained in:
parent
6c3525a09d
commit
c23aa73626
1
AUTHORS
1
AUTHORS
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 %}
|
||||
|
|
|
@ -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``
|
||||
|
|
Loading…
Reference in New Issue