Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate.

docs/topics/auth/customizing.txt

@@ -64,7 +64,7 @@ That's the basic authentication backend that checks the Django users database
 and queries the built-in permissions. It does not provide protection against
 brute force attacks via any rate limiting mechanism. You may either implement
 your own rate limiting mechanism in a custom auth backend, or use the
-mechanisms provided by most Web servers.
+mechanisms provided by most web servers.
 
 The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
 username and password is valid in multiple backends, Django will stop

docs/topics/auth/default.txt

@@ -347,7 +347,7 @@ inherit the permissions of the concrete model they subclass::
 
 .. _auth-web-requests:
 
-Authentication in Web requests
+Authentication in web requests
 ==============================
 
 Django uses :doc:`sessions </topics/http/sessions>` and middleware to hook the
@@ -451,7 +451,7 @@ How to log a user out
 
     When you call :func:`~django.contrib.auth.logout()`, the session data for
     the current request is completely cleaned out. All existing data is
-    removed. This is to prevent another person from using the same Web browser
+    removed. This is to prevent another person from using the same web browser
     to log in and have access to the previous user's session data. If you want
     to put anything into the session that will be available to the user
     immediately after logging out, do that *after* calling

docs/topics/cache.txt

@@ -3,13 +3,13 @@ Django's cache framework
 ========================
 
 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 --
+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
 processing-overhead perspective, than your standard
 read-a-file-off-the-filesystem server arrangement.
 
-For most Web applications, this overhead isn't a big deal. Most Web
+For most web applications, this overhead isn't a big deal. Most web
 applications aren't ``washingtonpost.com`` or ``slashdot.org``; they're small-
 to medium-sized sites with so-so traffic. But for medium- to high-traffic
 sites, it's essential to cut as much overhead as possible.
@@ -18,7 +18,7 @@ That's where caching comes in.
 
 To cache something is to save the result of an expensive calculation so that
 you don't have to perform the calculation next time. Here's some pseudocode
-explaining how this would work for a dynamically generated Web page::
+explaining how this would work for a dynamically generated web page::
 
     given a URL, try finding that page in the cache
     if the page is in the cache:
@@ -297,7 +297,7 @@ setting.
 
 Make sure the directory pointed-to by this setting either exists and is
 readable and writable, or that it can be created by the system user under which
-your Web server runs. Continuing the above example, if your server runs as the
+your web server runs. Continuing the above example, if your server runs as the
 user ``apache``, make sure the directory ``/var/tmp/django_cache`` exists and
 is readable and writable by the user ``apache``, or that it can be created by
 the user ``apache``.
@@ -1129,7 +1129,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
+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 website.
 
@@ -1139,7 +1139,7 @@ Here are a few examples of downstream caches:
   certain pages, so if you requested a page from ``http://example.com/``, your
   ISP would send you the page without having to access example.com directly.
   The maintainers of example.com have no knowledge of this caching; the ISP
-  sits between example.com and your Web browser, handling all of the caching
+  sits between example.com and your web browser, handling all of the caching
   transparently. Such caching is not possible under HTTPS as it would
   constitute a man-in-the-middle attack.
 
@@ -1148,17 +1148,17 @@ Here are a few examples of downstream caches:
   performance. In this case, each request first would be handled by the
   proxy, and it would be passed to your application only if needed.
 
-* Your Web browser caches pages, too. If a Web page sends out the
+* Your web browser caches pages, too. If a web page sends out the
   appropriate headers, your browser will use the local cached copy for
-  subsequent requests to that page, without even contacting the Web page
+  subsequent requests to that page, without even contacting the web page
   again to see whether it has changed.
 
 Downstream caching is a nice efficiency boost, but there's a danger to it:
-Many Web pages' contents differ based on authentication and a host of other
+Many web pages' contents differ based on authentication and a host of other
 variables, and cache systems that blindly save pages based purely on URLs could
 expose incorrect or sensitive data to subsequent visitors to those pages.
 
-For example, if you operate a Web email system, then the contents of the
+For example, if you operate a web email system, then the contents of the
 "inbox" page depend on which user is logged in. If an ISP blindly cached your
 site, then the first user who logged in through that ISP would have their
 user-specific inbox page cached for subsequent visitors to the site.  That's
@@ -1176,7 +1176,7 @@ Using ``Vary`` headers
 
 The ``Vary`` header defines which request headers a cache
 mechanism should take into account when building its cache key. For example, if
-the contents of a Web page depend on a user's language preference, the page is
+the contents of a web page depend on a user's language preference, the page is
 said to "vary on language."
 
 By default, Django's cache system creates its cache keys using the requested
@@ -1262,7 +1262,7 @@ A user usually faces two kinds of caches: their own browser cache (a private
 cache) and their provider's cache (a public cache). A public cache is used by
 multiple users and controlled by someone else. This poses problems with
 sensitive data--you don't want, say, your bank account number stored in a
-public cache. So Web applications need a way to tell caches which data is
+public cache. So web applications need a way to tell caches which data is
 private and which is public.
 
 The solution is to indicate a page's cache should be "private." To do this in

docs/topics/class-based-views/generic-display.txt

@@ -2,9 +2,9 @@
 Built-in class-based generic views
 ==================================
 
-Writing Web applications can be monotonous, because we repeat certain patterns
+Writing web applications can be monotonous, because we repeat certain patterns
 again and again. Django tries to take away some of that monotony at the model
-and template layers, but Web developers also experience this boredom at the view
+and template layers, but web developers also experience this boredom at the view
 level.
 
 Django's *generic views* were developed to ease that pain. They take certain

docs/topics/conditional-view-processing.txt

@@ -4,7 +4,7 @@ Conditional View Processing
 
 HTTP clients can send a number of headers to tell the server about copies of a
 resource that they have already seen. This is commonly used when retrieving a
-Web page (using an HTTP ``GET`` request) to avoid sending all the data for
+web page (using an HTTP ``GET`` request) to avoid sending all the data for
 something the client has already retrieved. However, the same headers can be
 used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc.).
 

docs/topics/db/examples/many_to_many.txt

@@ -47,14 +47,14 @@ Create a few ``Publications``::
 
 Create an ``Article``::
 
-    >>> a1 = Article(headline='Django lets you build Web apps easily')
+    >>> a1 = Article(headline='Django lets you build web apps easily')
 
 You can't associate it with a ``Publication`` until it's been saved::
 
     >>> a1.publications.add(p1)
     Traceback (most recent call last):
     ...
-    ValueError: "<Article: Django lets you build Web apps easily>" needs to have a value for field "id" before this many-to-many relationship can be used.
+    ValueError: "<Article: Django lets you build web apps easily>" needs to have a value for field "id" before this many-to-many relationship can be used.
 
 Save it!
 ::
@@ -100,7 +100,7 @@ Create and add a ``Publication`` to an ``Article`` in one step using
     >>> p2.article_set.all()
     <QuerySet [<Article: NASA uses Python>]>
     >>> p1.article_set.all()
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
     >>> Publication.objects.get(id=4).article_set.all()
     <QuerySet [<Article: NASA uses Python>]>
 
@@ -108,13 +108,13 @@ Many-to-many relationships can be queried using :ref:`lookups across
 relationships <lookups-that-span-relationships>`::
 
     >>> Article.objects.filter(publications__id=1)
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
     >>> Article.objects.filter(publications__pk=1)
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
     >>> Article.objects.filter(publications=1)
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
     >>> Article.objects.filter(publications=p1)
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
 
     >>> Article.objects.filter(publications__title__startswith="Science")
     <QuerySet [<Article: NASA uses Python>, <Article: NASA uses Python>]>
@@ -132,9 +132,9 @@ The :meth:`~django.db.models.query.QuerySet.count` function respects
     1
 
     >>> Article.objects.filter(publications__in=[1,2]).distinct()
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
     >>> Article.objects.filter(publications__in=[p1,p2]).distinct()
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA uses Python>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA uses Python>]>
 
 Reverse m2m queries are supported (i.e., starting at the table that doesn't have
 a :class:`~django.db.models.ManyToManyField`)::
@@ -165,7 +165,7 @@ Excluding a related item works as you would expect, too (although the SQL
 involved is a little complex)::
 
     >>> Article.objects.exclude(publications=p2)
-    <QuerySet [<Article: Django lets you build Web apps easily>]>
+    <QuerySet [<Article: Django lets you build web apps easily>]>
 
 If we delete a ``Publication``, its ``Articles`` won't be able to access it::
 
@@ -180,7 +180,7 @@ If we delete an ``Article``, its ``Publications`` won't be able to access it::
 
     >>> a2.delete()
     >>> Article.objects.all()
-    <QuerySet [<Article: Django lets you build Web apps easily>]>
+    <QuerySet [<Article: Django lets you build web apps easily>]>
     >>> p2.article_set.all()
     <QuerySet []>
 
@@ -261,7 +261,7 @@ go::
     >>> Publication.objects.all()
     <QuerySet [<Publication: Highlights for Children>, <Publication: The Python Journal>]>
     >>> Article.objects.all()
-    <QuerySet [<Article: Django lets you build Web apps easily>, <Article: NASA finds intelligent life on Earth>, <Article: NASA uses Python>, <Article: Oxygen-free diet works wonders>]>
+    <QuerySet [<Article: Django lets you build web apps easily>, <Article: NASA finds intelligent life on Earth>, <Article: NASA uses Python>, <Article: Oxygen-free diet works wonders>]>
     >>> a2.publications.all()
     <QuerySet [<Publication: The Python Journal>]>
 
@@ -269,7 +269,7 @@ Bulk delete some articles - references to deleted objects should go::
 
     >>> q = Article.objects.filter(headline__startswith='Django')
     >>> print(q)
-    <QuerySet [<Article: Django lets you build Web apps easily>]>
+    <QuerySet [<Article: Django lets you build web apps easily>]>
     >>> q.delete()
 
 After the :meth:`~django.db.models.query.QuerySet.delete`, the

docs/topics/db/optimization.txt

@@ -81,7 +81,7 @@ Understand cached attributes
 
 As well as caching of the whole ``QuerySet``, there is caching of the result of
 attributes on ORM objects. In general, attributes that are not callable will be
-cached. For example, assuming the :ref:`example Weblog models
+cached. For example, assuming the :ref:`example blog models
 <queryset-model-example>`::
 
   >>> entry = Entry.objects.get(id=1)
@@ -164,7 +164,7 @@ First, the query will be quicker because of the underlying database index.
 Also, the query could run much slower if multiple objects match the lookup;
 having a unique constraint on the column guarantees this will never happen.
 
-So using the :ref:`example Weblog models <queryset-model-example>`::
+So using the :ref:`example blog models <queryset-model-example>`::
 
   >>> entry = Entry.objects.get(id=10)
 

docs/topics/db/queries.txt

@@ -11,7 +11,7 @@ API. Refer to the :doc:`data model reference </ref/models/index>` for full
 details of all the various model lookup options.
 
 Throughout this guide (and in the reference), we'll refer to the following
-models, which comprise a Weblog application:
+models, which comprise a blog application:
 
 .. _queryset-model-example:
 
@@ -1181,7 +1181,7 @@ object and returns the number of objects deleted and a dictionary with
 the number of deletions per object type. Example::
 
     >>> e.delete()
-    (1, {'weblog.Entry': 1})
+    (1, {'blog.Entry': 1})
 
 You can also delete objects in bulk. Every
 :class:`~django.db.models.query.QuerySet` has a

docs/topics/forms/index.txt

@@ -77,7 +77,7 @@ should be used only for requests that do not affect the state of the system.
 ``GET`` would also be unsuitable for a password form, because the password
 would appear in the URL, and thus, also in browser history and server logs,
 all in plain text. Neither would it be suitable for large quantities of data,
-or for binary data, such as an image. A Web application that uses ``GET``
+or for binary data, such as an image. A web application that uses ``GET``
 requests for admin forms is a security risk: it can be easy for an attacker to
 mimic a form's request to gain access to sensitive parts of the system.
 ``POST``, coupled with other protections like Django's :doc:`CSRF protection
@@ -115,7 +115,7 @@ Forms in Django
 We've described HTML forms briefly, but an HTML ``<form>`` is just one part of
 the machinery required.
 
-In the context of a Web application, 'form' might refer to that HTML
+In the context of a web application, 'form' might refer to that HTML
 ``<form>``, or to the Django :class:`Form` that produces it, or to the
 structured data returned when it is submitted, or to the end-to-end working
 collection of these parts.

docs/topics/forms/media.txt

@@ -2,11 +2,11 @@
 Form Assets (the ``Media`` class)
 =================================
 
-Rendering an attractive and easy-to-use Web form requires more than just
-HTML - it also requires CSS stylesheets, and if you want to use fancy
-"Web2.0" widgets, you may also need to include some JavaScript on each
-page. The exact combination of CSS and JavaScript that is required for
-any given page will depend upon the widgets that are in use on that page.
+Rendering an attractive and easy-to-use web form requires more than just
+HTML - it also requires CSS stylesheets, and if you want to use fancy widgets,
+you may also need to include some JavaScript on each page. The exact
+combination of CSS and JavaScript that is required for any given page will
+depend upon the widgets that are in use on that page.
 
 This is where asset definitions come in. Django allows you to
 associate different files -- like stylesheets and scripts -- with the
@@ -16,7 +16,7 @@ Calendar widget. This widget can then be associated with the CSS and
 JavaScript that is required to render the calendar. When the Calendar
 widget is used on a form, Django is able to identify the CSS and
 JavaScript files that are required, and provide the list of file names
-in a form suitable for inclusion on your Web page.
+in a form suitable for inclusion on your web page.
 
 .. admonition:: Assets and Django Admin
 

docs/topics/http/middleware.txt

@@ -88,7 +88,7 @@ caveats:
   so you can't define ``__init__()`` as requiring any other arguments.
 
 * Unlike the ``__call__()`` method which is called once per request,
-  ``__init__()`` is called only *once*, when the Web server starts.
+  ``__init__()`` is called only *once*, when the web server starts.
 
 Marking middleware as unused
 ----------------------------

docs/topics/http/sessions.txt

@@ -103,7 +103,7 @@ To use file-based sessions, set the :setting:`SESSION_ENGINE` setting to
 
 You might also want to set the :setting:`SESSION_FILE_PATH` setting (which
 defaults to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to
-control where Django stores session files. Be sure to check that your Web
+control where Django stores session files. Be sure to check that your web
 server has permissions to read and write to this location.
 
 .. _cookie-session-backend:
@@ -264,7 +264,7 @@ You can edit it multiple times.
         :class:`~django.contrib.sessions.serializers.PickleSerializer`.
 
       * If ``value`` is ``0``, the user's session cookie will expire
-        when the user's Web browser is closed.
+        when the user's web browser is closed.
 
       * If ``value`` is ``None``, the session reverts to using the global
         session expiry policy.
@@ -299,7 +299,7 @@ You can edit it multiple times.
     .. method:: get_expire_at_browser_close()
 
       Returns either ``True`` or ``False``, depending on whether the user's
-      session cookie will expire when the user's Web browser is closed.
+      session cookie will expire when the user's web browser is closed.
 
     .. method:: clear_expired()
 

docs/topics/http/urls.txt

@@ -2,7 +2,7 @@
 URL dispatcher
 ==============
 
-A clean, elegant URL scheme is an important detail in a high-quality Web
+A clean, elegant URL scheme is an important detail in a high-quality web
 application. Django lets you design URLs however you want, with no framework
 limitations.
 

docs/topics/http/views.txt

@@ -3,8 +3,8 @@ Writing views
 =============
 
 A view function, or *view* for short, is a Python function that takes a
-Web request and returns a Web response. This response can be the HTML contents
-of a Web page, or a redirect, or a 404 error, or an XML document, or an image .
+web request and returns a web response. This response can be the HTML contents
+of a web page, or a redirect, or a 404 error, or an XML document, or an image .
 . . or anything, really. The view itself contains whatever arbitrary logic is
 necessary to return that response. This code can live anywhere you want, as long
 as it's on your Python path. There's no other requirement--no "magic," so to
@@ -137,7 +137,7 @@ template.
 Customizing error views
 =======================
 
-The default error views in Django should suffice for most Web applications,
+The default error views in Django should suffice for most web applications,
 but can easily be overridden if you need any custom behavior. Specify the
 handlers as seen below in your URLconf (setting them anywhere else will have no
 effect).

docs/topics/i18n/index.txt

@@ -13,7 +13,7 @@ Internationalization and localization
 Overview
 ========
 
-The goal of internationalization and localization is to allow a single Web
+The goal of internationalization and localization is to allow a single web
 application to offer its content in languages and formats tailored to the
 audience.
 
@@ -25,7 +25,7 @@ Essentially, Django does two things:
 
 * It allows developers and template authors to specify which parts of their apps
   should be translated or formatted for local languages and cultures.
-* It uses these hooks to localize Web apps for particular users according to
+* It uses these hooks to localize web apps for particular users according to
   their preferences.
 
 Translation depends on the target language, and formatting usually depends on

docs/topics/i18n/timezones.txt

@@ -503,7 +503,7 @@ Setup
    datetimes, and vice-versa.
 
    If your application connects to other systems -- for instance, if it queries
-   a Web service -- make sure datetimes are properly specified. To transmit
+   a web service -- make sure datetimes are properly specified. To transmit
    datetimes safely, their representation should include the UTC offset, or
    their values should be in UTC (or both!).
 

docs/topics/i18n/translation.txt

@@ -20,7 +20,7 @@ the equivalent of the translation strings in the target language. Once the
 translators have filled in the message file, it must be compiled. This process
 relies on the GNU gettext toolset.
 
-Once this is done, Django takes care of translating Web apps on the fly in each
+Once this is done, Django takes care of translating web apps on the fly in each
 available language, according to users' language preferences.
 
 Django's internationalization hooks are on by default, and that means there's a

docs/topics/install.txt

@@ -7,7 +7,7 @@ This document will get you up and running with Django.
 Install Python
 ==============
 
-Django is a Python Web framework. See :ref:`faq-python-version-support` for
+Django is a Python web framework. See :ref:`faq-python-version-support` for
 details.
 
 Get the latest version of Python at https://www.python.org/downloads/ or with
@@ -34,9 +34,9 @@ memory when the server starts. Code stays in memory throughout the
 life of an Apache process, which leads to significant performance
 gains over other server arrangements. In daemon mode, mod_wsgi spawns
 an independent daemon process that handles requests. The daemon
-process can run as a different user than the Web server, possibly
+process can run as a different user than the web server, possibly
 leading to improved security. The daemon process can be restarted
-without restarting the entire Apache Web server, possibly making
+without restarting the entire Apache web server, possibly making
 refreshing your codebase more seamless. Consult the mod_wsgi
 documentation to determine which mode is right for your setup. Make
 sure you have Apache installed with the mod_wsgi module activated.

docs/topics/security.txt

@@ -17,7 +17,7 @@ other users. This is usually achieved by storing the malicious scripts in the
 database where it will be retrieved and displayed to other users, or by getting
 users to click a link which will cause the attacker's JavaScript to be executed
 by the user's browser. However, XSS attacks can originate from any untrusted
-source of data, such as cookies or Web services, whenever the data is not
+source of data, such as cookies or web services, whenever the data is not
 sufficiently sanitized before including in a page.
 
 Using Django templates protects you against the majority of XSS attacks.
@@ -144,7 +144,7 @@ server, there are some additional steps you may need:
 
   Please note the caveats under :setting:`SECURE_PROXY_SSL_HEADER`. For the
   case of a reverse proxy, it may be easier or more secure to configure the
-  main Web server to do the redirect to HTTPS.
+  main web server to do the redirect to HTTPS.
 
 * Use 'secure' cookies.
 
@@ -165,7 +165,7 @@ server, there are some additional steps you may need:
   the added security of SSL provided one successful connection has occurred.
   HSTS may either be configured with :setting:`SECURE_HSTS_SECONDS`,
   :setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS`, and :setting:`SECURE_HSTS_PRELOAD`,
-  or on the Web server.
+  or on the web server.
 
 .. _host-headers-virtual-hosting:
 
@@ -244,7 +244,7 @@ User-uploaded content
     <staticfiles-from-cdn>` to avoid some of these issues.
 
 * If your site accepts file uploads, it is strongly advised that you limit
-  these uploads in your Web server configuration to a reasonable
+  these uploads in your web server configuration to a reasonable
   size in order to prevent denial of service (DOS) attacks. In Apache, this
   can be easily set using the LimitRequestBody_ directive.
 
@@ -287,15 +287,15 @@ Additional security topics
 
 While Django provides good security protection out of the box, it is still
 important to properly deploy your application and take advantage of the
-security protection of the Web server, operating system and other components.
+security protection of the web server, operating system and other components.
 
-* Make sure that your Python code is outside of the Web server's root. This
+* Make sure that your Python code is outside of the web server's root. This
   will ensure that your Python code is not accidentally served as plain text
   (or accidentally executed).
 * Take care with any :ref:`user uploaded files <file-upload-security>`.
 * Django does not throttle requests to authenticate users. To protect against
   brute-force attacks against the authentication system, you may consider
-  deploying a Django plugin or Web server module to throttle these requests.
+  deploying a Django plugin or web server module to throttle these requests.
 * Keep your :setting:`SECRET_KEY` a secret.
 * It is a good idea to limit the accessibility of your caching system and
   database using a firewall.

docs/topics/settings.txt

@@ -148,7 +148,7 @@ Security
 
 Because a settings file contains sensitive information, such as the database
 password, you should make every attempt to limit access to it. For example,
-change its file permissions so that only you and your Web server's user can
+change its file permissions so that only you and your web server's user can
 read it. This is especially important in a shared-hosting environment.
 
 Available settings
@@ -287,7 +287,7 @@ settings and populate Django's application registry. For example::
     from myapp import models
 
 Note that calling ``django.setup()`` is only necessary if your code is truly
-standalone. When invoked by your Web server, or through :doc:`django-admin
+standalone. When invoked by your web server, or through :doc:`django-admin
 </ref/django-admin>`, Django will handle this for you.
 
 .. admonition:: ``django.setup()`` may only be called once.

docs/topics/signing.txt

@@ -5,14 +5,14 @@ Cryptographic signing
 .. module:: django.core.signing
    :synopsis: Django's signing framework.
 
-The golden rule of Web application security is to never trust data from
+The golden rule of web application security is to never trust data from
 untrusted sources. Sometimes it can be useful to pass data through an
 untrusted medium. Cryptographically signed values can be passed through an
 untrusted channel safe in the knowledge that any tampering will be detected.
 
 Django provides both a low-level API for signing values and a high-level API
 for setting and reading signed cookies, one of the most common uses of
-signing in Web applications.
+signing in web applications.
 
 You may also find signing useful for the following:
 

docs/topics/testing/index.txt

@@ -3,7 +3,7 @@ Testing in Django
 =================
 
 Automated testing is an extremely useful bug-killing tool for the modern
-Web developer. You can use a collection of tests -- a **test suite** -- to
+web developer. You can use a collection of tests -- a **test suite** -- to
 solve, or avoid, a number of problems:
 
 * When you're writing new code, you can use tests to validate your code
@@ -13,7 +13,7 @@ solve, or avoid, a number of problems:
   ensure your changes haven't affected your application's behavior
   unexpectedly.
 
-Testing a Web application is a complex task, because a Web application is made
+Testing a web application is a complex task, because a web application is made
 of several layers of logic -- from HTTP-level request handling, to form
 validation and processing, to template rendering. With Django's test-execution
 framework and assorted utilities, you can simulate requests, insert test data,

docs/topics/testing/tools.txt

@@ -11,7 +11,7 @@ Django provides a small set of tools that come in handy when writing tests.
 The test client
 ===============
 
-The test client is a Python class that acts as a dummy Web browser, allowing
+The test client is a Python class that acts as a dummy web browser, allowing
 you to test your views and interact with your Django-powered application
 programmatically.
 
@@ -35,7 +35,7 @@ short:
   rendered and that the template is passed the correct context data.
 
 * Use in-browser frameworks like Selenium_ to test *rendered* HTML and the
-  *behavior* of Web pages, namely JavaScript functionality. Django also
+  *behavior* of web pages, namely JavaScript functionality. Django also
   provides special support for those frameworks; see the section on
   :class:`~django.test.LiveServerTestCase` for more details.
 
@@ -45,7 +45,7 @@ Overview and a quick example
 ----------------------------
 
 To use the test client, instantiate ``django.test.Client`` and retrieve
-Web pages::
+web pages::
 
     >>> from django.test import Client
     >>> c = Client()
@@ -61,8 +61,8 @@ of the Python interactive interpreter.
 
 Note a few important things about how the test client works:
 
-* The test client does *not* require the Web server to be running. In fact,
-  it will run just fine with no Web server running at all! That's because
+* The test client does *not* require the web server to be running. In fact,
+  it will run just fine with no web server running at all! That's because
   it avoids the overhead of HTTP and deals directly with the Django
   framework. This helps make the unit tests run quickly.
 
@@ -75,8 +75,8 @@ Note a few important things about how the test client works:
 
       >>> c.get('https://www.example.com/login/')
 
-  The test client is not capable of retrieving Web pages that are not
-  powered by your Django project. If you need to retrieve other Web pages,
+  The test client is not capable of retrieving web pages that are not
+  powered by your Django project. If you need to retrieve other web pages,
   use a Python standard library module such as :mod:`urllib`.
 
 * To resolve URLs, the test client uses whatever URLconf is pointed-to by
@@ -1018,7 +1018,7 @@ out the `full reference`_ for more details.
                 lambda driver: driver.find_element_by_tag_name('body'))
 
     The tricky thing here is that there's really no such thing as a "page load,"
-    especially in modern Web apps that generate HTML dynamically after the
+    especially in modern web apps that generate HTML dynamically after the
     server generates the initial document. So, checking for the presence of
     ``<body>`` in the response might not necessarily be appropriate for all use
     cases. Please refer to the `Selenium FAQ`_ and `Selenium documentation`_
@@ -1422,7 +1422,7 @@ Assertions
 As Python's normal :class:`unittest.TestCase` class implements assertion methods
 such as :meth:`~unittest.TestCase.assertTrue` and
 :meth:`~unittest.TestCase.assertEqual`, Django's custom :class:`TestCase` class
-provides a number of custom assertion methods that are useful for testing Web
+provides a number of custom assertion methods that are useful for testing web
 applications:
 
 The failure messages given by most of these assertion methods can be customized