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 Godwin <andrew@aeracode.org>
|
||||||
Andrew Pinkham <http://AndrewsForge.com>
|
Andrew Pinkham <http://AndrewsForge.com>
|
||||||
Andrews Medina <andrewsmedina@gmail.com>
|
Andrews Medina <andrewsmedina@gmail.com>
|
||||||
|
Andrew Northall <andrew@northall.me.uk>
|
||||||
Andriy Sokolovskiy <me@asokolovskiy.com>
|
Andriy Sokolovskiy <me@asokolovskiy.com>
|
||||||
Andy Chosak <andy@chosak.org>
|
Andy Chosak <andy@chosak.org>
|
||||||
Andy Dustman <farcepest@gmail.com>
|
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
|
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
|
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
|
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:
|
default server to return "444 No Response" on an unrecognized host:
|
||||||
|
|
||||||
.. code-block:: nginx
|
.. code-block:: nginx
|
||||||
|
|
|
@ -37,7 +37,7 @@ Authentication with ``mod_wsgi``
|
||||||
information about this setting.
|
information about this setting.
|
||||||
|
|
||||||
Make sure that mod_wsgi is installed and activated and that you have
|
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>`.
|
</howto/deployment/wsgi/modwsgi>`.
|
||||||
|
|
||||||
Next, edit your Apache configuration to add a location that you want
|
Next, edit your Apache configuration to add a location that you want
|
||||||
|
|
|
@ -65,7 +65,7 @@ following::
|
||||||
...\> py -m venv project-name
|
...\> py -m venv project-name
|
||||||
|
|
||||||
This will create a folder called 'project-name' if it does not already exist
|
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
|
...\> 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
|
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.
|
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>`.
|
and install the Geospatial libraries</ref/contrib/gis/install/index>`.
|
||||||
|
|
||||||
Each of these dependencies is optional. If you're missing any of them, the
|
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
|
Django's `Git repository`_ is hosted on `GitHub`_, and it is recommended
|
||||||
that you also work using GitHub.
|
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::
|
email::
|
||||||
|
|
||||||
$ git config --global user.name "Your Real Name"
|
$ 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.
|
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 that the reference Django repository was the source of your fork of it)::
|
||||||
|
|
||||||
git remote add upstream git@github.com:django/django.git
|
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.
|
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
|
We'll set up the database, create your first model, and get a quick
|
||||||
to Django's automatically-generated admin site.
|
introduction to Django's automatically-generated admin site.
|
||||||
|
|
||||||
.. admonition:: Where to get help:
|
.. 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
|
:meth:`~django.test.utils.setup_test_environment` installs a template renderer
|
||||||
which will allow us to examine some additional attributes on responses such as
|
which will allow us to examine some additional attributes on responses such as
|
||||||
``response.context`` that otherwise wouldn't be available. Note that this
|
``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
|
the existing database and the output may differ slightly depending on what
|
||||||
questions you already created. You might get unexpected results if your
|
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
|
``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
|
.. attribute:: Field.geom_type
|
||||||
|
|
||||||
You generally shouldn't have to set or change that attribute which should
|
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.
|
geometry name.
|
||||||
|
|
||||||
Form field classes
|
Form field classes
|
||||||
|
|
|
@ -261,7 +261,7 @@ transform do not change. For example::
|
||||||
Read about `the performance considerations`_ prior to using it.
|
Read about `the performance considerations`_ prior to using it.
|
||||||
|
|
||||||
To use ``citext``, use the :class:`.CITextExtension` operation to
|
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.
|
PostgreSQL before the first ``CreateModel`` migration operation.
|
||||||
|
|
||||||
If you're using an :class:`~django.contrib.postgres.fields.ArrayField`
|
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:
|
To use this field, you'll need to:
|
||||||
|
|
||||||
#. Add ``'django.contrib.postgres'`` in your :setting:`INSTALLED_APPS`.
|
#. 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.
|
PostgreSQL.
|
||||||
|
|
||||||
You'll see an error like ``can't adapt type 'dict'`` if you skip the first
|
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)
|
return '{}-{}-{}'.format(year, month, day)
|
||||||
|
|
||||||
The constructor creates several :class:`Select` widgets in a list. The
|
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
|
The required method :meth:`~MultiWidget.decompress` breaks up a
|
||||||
``datetime.date`` value into the day, month, and year values corresponding
|
``datetime.date`` value into the day, month, and year values corresponding
|
||||||
|
|
|
@ -130,7 +130,7 @@ for each test.
|
||||||
|
|
||||||
* The class method
|
* The class method
|
||||||
:meth:`TestCase.setUpTestData() <django.test.TestCase.setUpTestData>` adds
|
: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()``.
|
speed up the tests as compared to using ``setUp()``.
|
||||||
|
|
||||||
* Fixture loading within ``TestCase`` is now performed once for the whole
|
* 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
|
* The new :meth:`View.setup <django.views.generic.base.View.setup>` hook
|
||||||
initializes view attributes before calling
|
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.
|
instance attributes for reuse in child classes.
|
||||||
|
|
||||||
Internationalization
|
Internationalization
|
||||||
|
|
|
@ -1145,7 +1145,7 @@ implementation details see :ref:`using-the-views`.
|
||||||
<input type="hidden" name="next" value="{{ next }}">
|
<input type="hidden" name="next" value="{{ next }}">
|
||||||
</form>
|
</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>
|
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>
|
||||||
|
|
||||||
{% endblock %}
|
{% endblock %}
|
||||||
|
|
|
@ -768,7 +768,7 @@ utility methods in the ``django.test.utils`` module.
|
||||||
:func:`teardown_databases` function at the conclusion of testing.
|
:func:`teardown_databases` function at the conclusion of testing.
|
||||||
|
|
||||||
The ``aliases`` argument determines which :setting:`DATABASES` aliases test
|
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.
|
:setting:`DATABASES` aliases.
|
||||||
|
|
||||||
The ``serialized_aliases`` argument determines what subset of ``aliases``
|
The ``serialized_aliases`` argument determines what subset of ``aliases``
|
||||||
|
|
Loading…
Reference in New Issue