Browse Source

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

Andrew Northall 3 years ago
parent
commit
c23aa73626

+ 1 - 0
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>

+ 1 - 1
docs/howto/deployment/checklist.txt

@@ -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

+ 1 - 1
docs/howto/deployment/wsgi/apache-auth.txt

@@ -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

+ 1 - 1
docs/howto/windows.txt

@@ -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
 

+ 1 - 1
docs/internals/contributing/writing-code/unit-tests.txt

@@ -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

+ 2 - 2
docs/internals/contributing/writing-code/working-with-git.txt

@@ -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

+ 2 - 2
docs/intro/tutorial02.txt

@@ -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:
 

+ 1 - 1
docs/intro/tutorial05.txt

@@ -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

+ 1 - 1
docs/ref/contrib/gis/forms-api.txt

@@ -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

+ 2 - 2
docs/ref/contrib/postgres/fields.txt

@@ -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

+ 1 - 1
docs/ref/forms/widgets.txt

@@ -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

+ 1 - 1
docs/releases/1.8.txt

@@ -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

+ 1 - 1
docs/releases/2.2.txt

@@ -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

+ 1 - 1
docs/topics/auth/default.txt

@@ -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 %}

+ 1 - 1
docs/topics/testing/advanced.txt

@@ -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``