[1.9.x] Fixed #25755 -- Unified spelling of "website".

Backport of 1f8dad69158a96d0649d321ce08ecc9c0465f962 from master

8 files changed, 17 insertions, 17 deletions

diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index 558ebd809c..b8923bb389 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -220,7 +220,7 @@ Authorization for anonymous users
 
 An anonymous user is one that is not authenticated i.e. they have provided no
 valid authentication details. However, that does not necessarily mean they are
-not authorized to do anything. At the most basic level, most Web sites
+not authorized to do anything. At the most basic level, most websites
 authorize anonymous users to browse most of the site, and many allow anonymous
 posting of comments etc.
 
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 3c9e1eafda..386c9870e0 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -2,7 +2,7 @@
 Django's cache framework
 ========================
 
-A fundamental trade-off in dynamic Web sites is, well, they're dynamic. Each
+A fundamental trade-off in dynamic websites is, well, they're dynamic. Each
 time a user requests a page, the Web server makes all sorts of calculations --
 from database queries to template rendering to business logic -- to create the
 page that your site's visitor sees. This is a lot more expensive, from a
@@ -1011,7 +1011,7 @@ Downstream caches
 So far, this document has focused on caching your *own* data. But another type
 of caching is relevant to Web development, too: caching performed by
 "downstream" caches. These are systems that cache pages for users even before
-the request reaches your Web site.
+the request reaches your website.
 
 Here are a few examples of downstream caches:
 
@@ -1021,7 +1021,7 @@ Here are a few examples of downstream caches:
   knowledge of this caching; the ISP sits between example.com and your Web
   browser, handling all of the caching transparently.
 
-* Your Django Web site may sit behind a *proxy cache*, such as Squid Web
+* Your Django website may sit behind a *proxy cache*, such as Squid Web
   Proxy Cache (http://www.squid-cache.org/), that caches pages for
   performance. In this case, each request first would be handled by the
   proxy, and it would be passed to your application only if needed.
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
index 16db4976d6..83b47ec4e1 100644
--- a/docs/topics/email.txt
+++ b/docs/topics/email.txt
@@ -625,7 +625,7 @@ Configuring email for development
 =================================
 
 There are times when you do not want Django to send emails at
-all. For example, while developing a Web site, you probably don't want
+all. For example, while developing a website, you probably don't want
 to send out thousands of emails -- but you may want to validate that
 emails will be sent to the right people under the right conditions,
 and that those emails will contain the correct content.
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index 0217b022d1..abdcade6ff 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -11,7 +11,7 @@ Working with forms
     the forms API, see :doc:`/ref/forms/api`, :doc:`/ref/forms/fields`, and
     :doc:`/ref/forms/validation`.
 
-Unless you're planning to build Web sites and applications that do nothing but
+Unless you're planning to build websites and applications that do nothing but
 publish content, and don't accept input from your visitors, you're going to
 need to understand and use forms.
 
@@ -172,7 +172,7 @@ example with:
 * data received from a previous HTML form submission
 
 The last of these cases is the most interesting, because it's what makes it
-possible for users not just to read a Web site, but to send information back
+possible for users not just to read a website, but to send information back
 to it too.
 
 Building a form
@@ -181,7 +181,7 @@ Building a form
 The work that needs to be done
 ------------------------------
 
-Suppose you want to create a simple form on your Web site, in order to obtain
+Suppose you want to create a simple form on your website, in order to obtain
 the user's name. You'd need something like this in your template:
 
 .. code-block:: html+django
@@ -269,7 +269,7 @@ We'll have to provide those ourselves in the template.
 The view
 ^^^^^^^^
 
-Form data sent back to a Django Web site is processed by a view, generally the
+Form data sent back to a Django website is processed by a view, generally the
 same view which published the form. This allows us to reuse some of the same
 logic.
 
@@ -400,7 +400,7 @@ More on fields
 --------------
 
 Consider a more useful form than our minimal example above, which we could use
-to implement "contact me" functionality on a personal Web site:
+to implement "contact me" functionality on a personal website:
 
 .. snippet::
     :filename: forms.py
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index e48ac9d7ee..b00c3d462c 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -274,7 +274,7 @@ Including other URLconfs
 At any point, your ``urlpatterns`` can "include" other URLconf modules. This
 essentially "roots" a set of URLs below other ones.
 
-For example, here's an excerpt of the URLconf for the `Django Web site`_
+For example, here's an excerpt of the URLconf for the `Django website`_
 itself. It includes a number of other URLconfs::
 
     from django.conf.urls import include, url
@@ -343,7 +343,7 @@ the suffixes that differ::
         ])),
     ]
 
-.. _`Django Web site`: https://www.djangoproject.com/
+.. _`Django website`: https://www.djangoproject.com/
 
 Captured parameters
 -------------------
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index 5f1a308876..b964ccadbf 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -16,7 +16,7 @@ translates them to the end user's time zone in templates and forms.
 This is handy if your users live in more than one time zone and you want to
 display datetime information according to each user's wall clock.
 
-Even if your Web site is available in only one time zone, it's still good
+Even if your website is available in only one time zone, it's still good
 practice to store data in UTC in your database. The main reason is Daylight
 Saving Time (DST). Many countries have a system of DST, where clocks are moved
 forward in spring and backward in autumn. If you're working in local time,
@@ -168,7 +168,7 @@ time zone automatically. Instead, Django provides :ref:`time zone selection
 functions <time-zone-selection-functions>`. Use them to build the time zone
 selection logic that makes sense for you.
 
-Most Web sites that care about time zones just ask users in which time zone they
+Most websites that care about time zones just ask users in which time zone they
 live and store this information in the user's profile. For anonymous users,
 they use the time zone of their primary audience or UTC. pytz_ provides
 helpers_, like a list of time zones per country, that you can use to pre-select
diff --git a/docs/topics/security.txt b/docs/topics/security.txt
index 0083d1b5bc..99f16078d0 100644
--- a/docs/topics/security.txt
+++ b/docs/topics/security.txt
@@ -65,7 +65,7 @@ control.
 
 :ref:`CSRF protection works <how-csrf-works>` by checking for a nonce in each
 POST request. This ensures that a malicious user cannot simply "replay" a form
-POST to your Web site and have another logged in user unwittingly submit that
+POST to your website and have another logged in user unwittingly submit that
 form. The malicious user would have to know the nonce, which is user specific
 (using a cookie).
 
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index f1667f757e..97bc136a61 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -757,7 +757,7 @@ TestCase
 .. class:: TestCase()
 
 This class provides some additional capabilities that can be useful for testing
-Web sites.
+websites.
 
 Converting a normal :class:`unittest.TestCase` to a Django :class:`TestCase` is
 easy: Just change the base class of your test from ``'unittest.TestCase'`` to
@@ -1047,7 +1047,7 @@ Fixture loading
 
 .. attribute:: TransactionTestCase.fixtures
 
-A test case for a database-backed Web site isn't much use if there isn't any
+A test case for a database-backed website isn't much use if there isn't any
 data in the database. To make it easy to put test data into the database,
 Django's custom ``TransactionTestCase`` class provides a way of loading
 **fixtures**.