Fixed #7814 -- Fixed a number of style inconsistencies in the docs. Thanks, uzi and programmerq

git-svn-id: http://code.djangoproject.com/svn/django/trunk@8043 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/api_stability.txt

@@ -59,7 +59,7 @@ These APIs are stable:
    
    - `Request/response objects`_.
    
-   - `Sending email`_.
+   - `Sending e-mail`_.
    
    - `Sessions`_.
    
@@ -108,7 +108,7 @@ change:
 .. _mod_python integration: ../modpython/
 .. _redirects: ../redirects/
 .. _request/response objects: ../request_response/
-.. _sending email: ../email/
+.. _sending e-mail: ../email/
 .. _sessions: ../sessions/
 .. _settings: ../settings/
 .. _syndication: ../syndication_feeds/

docs/authentication.txt

@@ -631,7 +631,7 @@ The page shown after a user has changed their password.
 **Description:**
 
 Allows a user to reset their password, and sends them the new password
-in an email.
+in an e-mail.
 
 **Optional arguments:**
 
@@ -640,7 +640,7 @@ in an email.
       ``registration/password_reset_form.html`` if not supplied.
 
     * ``email_template_name``: The full name of a template to use for
-      generating the email with the new password. This will default to
+      generating the e-mail with the new password. This will default to
       ``registration/password_reset_email.html`` if not supplied.
 
 **Template context:**
@@ -696,7 +696,7 @@ system provides several built-in forms:
       user to change their password.
 
     * ``django.contrib.auth.forms.PasswordResetForm``: A form for resetting a
-      user's password and emailing the new password to them.
+      user's password and e-mailing the new password to them.
 
     * ``django.contrib.auth.forms.UserCreationForm``: A form for creating a
       new user.

docs/csrf.txt

@@ -4,8 +4,8 @@ Cross Site Request Forgery protection
 
 The CsrfMiddleware class provides easy-to-use protection against
 `Cross Site Request Forgeries`_.  This type of attack occurs when a malicious
-web site creates a link or form button that is intended to perform some action
-on your web site, using the credentials of a logged-in user who is tricked
+Web site creates a link or form button that is intended to perform some action
+on your Web site, using the credentials of a logged-in user who is tricked
 into clicking on the link in their browser.
 
 The first defense against CSRF attacks is to ensure that GET requests
@@ -38,7 +38,7 @@ CsrfMiddleware does two things:
    checks that the 'csrfmiddlewaretoken' is present and correct. If it
    isn't, the user will get a 403 error.
 
-This ensures that only forms that have originated from your web site
+This ensures that only forms that have originated from your Web site
 can be used to POST data back.
 
 It deliberately only targets HTTP POST requests (and the corresponding POST
@@ -47,7 +47,7 @@ effects (see `9.1.1 Safe Methods, HTTP 1.1, RFC 2616`_), and so a
 CSRF attack with a GET request ought to be harmless.
 
 POST requests that are not accompanied by a session cookie are not protected,
-but they do not need to be protected, since the 'attacking' web site
+but they do not need to be protected, since the 'attacking' Web site
 could make these kind of requests anyway.
 
 The Content-Type is checked before modifying the response, and only
@@ -68,4 +68,4 @@ it sends fragments of HTML in javascript document.write statements)
 you might bypass the filter that adds the hidden field to the form,
 in which case form submission will always fail.  It may still be possible
 to use the middleware, provided you can find some way to get the
-CSRF token and ensure that is included when your form is submitted.
+CSRF token and ensure that is included when your form is submitted.

docs/db-api.txt

@@ -463,7 +463,7 @@ Be careful, if you are using ``extra()`` to add custom handling to your
 may or may not make sense. If you are using custom SQL fragments in your
 ``extra()`` calls, Django will not inspect these fragments to see if they need
 to be rewritten because of changes in the merged query. So test the effects
-carefully. Also realise that if you are combining two ``QuerySets`` with
+carefully. Also realize that if you are combining two ``QuerySets`` with
 ``|``, you cannot use ``extra(select=...)`` or ``extra(where=...)`` on *both*
 ``QuerySets``. You can only use those calls on one or the other (Django will
 raise a ``ValueError`` if you try to use this incorrectly).

docs/django-admin.txt

@@ -395,7 +395,7 @@ makemessages
 
 Runs over the entire source tree of the current directory and pulls out all
 strings marked for translation. It creates (or updates) a message file in the
-conf/locale (in the django tree) or locale (for project and application)
+conf/locale (in the Django tree) or locale (for project and application)
 directory. After making changes to the messages files you need to compile them
 with ``compilemessages`` for use with the builtin gettext support. See the
 `i18n documentation`_ for details.

docs/forms.txt

@@ -1557,7 +1557,7 @@ mentioned above (``required``, ``label``, ``initial``, ``widget``,
 Custom form and field validation
 ---------------------------------
 
-Form validation happens when the data is cleaned. If you want to customise
+Form validation happens when the data is cleaned. If you want to customize
 this process, there are various places you can change, each one serving a
 different purpose. Three types of cleaning methods are run during form
 processing. These are normally executed when you call the ``is_valid()``
@@ -1568,7 +1568,7 @@ directly), but normally they won't be needed.
 In general, any cleaning method can raise ``ValidationError`` if there is a
 problem with the data it is processing, passing the relevant error message to
 the ``ValidationError`` constructor. If no ``ValidationError`` is raised, the
-method should return the cleaned (normalised) data as a Python object.
+method should return the cleaned (normalized) data as a Python object.
 
 If you detect multiple errors during a cleaning method and wish to signal all
 of them to the form submitter, it is possible to pass a list of errors to the
@@ -1601,7 +1601,7 @@ The three types of cleaning methods are:
     * The Form subclass's ``clean()`` method. This method can perform
       any validation that requires access to multiple fields from the form at
       once. This is where you might put in things to check that if field ``A``
-      is supplied, field ``B`` must contain a valid email address and the
+      is supplied, field ``B`` must contain a valid e-mail address and the
       like. The data that this method returns is the final ``cleaned_data``
       attribute for the form, so don't forget to return the full list of
       cleaned data if you override this method (by default, ``Form.clean()``
@@ -1723,7 +1723,7 @@ Customizing widget instances
 When Django renders a widget as HTML, it only renders the bare minimum
 HTML - Django doesn't add a class definition, or any other widget-specific
 attributes. This means that all 'TextInput' widgets will appear the same
-on your web page.
+on your Web page.
 
 If you want to make one widget look different to another, you need to
 specify additional attributes for each widget. When you specify a
@@ -1747,7 +1747,7 @@ each widget will be rendered exactly the same::
     <tr><th>Url:</th><td><input type="text" name="url"/></td></tr>
     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
 
-On a real web page, you probably don't want every widget to look the same. You
+On a real Web page, you probably don't want every widget to look the same. You
 might want a larger input element for the comment, and you might want the
 'name' widget to have some special CSS class. To do this, you specify a
 custom widget for your fields, and specify some attributes to use

docs/i18n.txt

@@ -888,7 +888,7 @@ does translation:
     * The string domain is ``django`` or ``djangojs``. This string domain is
       used to differentiate between different programs that store their data
       in a common message-file library (usually ``/usr/share/locale/``). The
-      ``django`` domain is used for python and template translation strings
+      ``django`` domain is used for Python and template translation strings
       and is loaded into the global translation catalogs. The ``djangojs``
       domain is only used for JavaScript translation catalogs to make sure
       that those are as small as possible.

docs/install.txt

@@ -18,7 +18,7 @@ Install Apache and mod_python
 =============================
 
 If you just want to experiment with Django, skip ahead to the next
-section; Django includes a lightweight web server you can use for
+section; Django includes a lightweight Web server you can use for
 testing, so you won't need to set up Apache until you're ready to
 deploy Django in production.
 
@@ -64,7 +64,7 @@ installed.
   You will also want to read the database-specific notes for the `MySQL backend`_.
 
 * If you're using SQLite and either Python 2.3 or Python 2.4, you'll need
-  pysqlite_. Use version 2.0.3 or higher. Python 2.5 ships with an sqlite
+  pysqlite_. Use version 2.0.3 or higher. Python 2.5 ships with an SQLite
   wrapper in the standard library, so you don't need to install anything extra
   in that case.
 

docs/release_notes_0.95.txt

@@ -99,7 +99,7 @@ Problem reports and getting help
 ================================
 
 Need help resolving a problem with Django? The documentation in the
-distribution is also available online_ at the `Django website`_. The FAQ_
+distribution is also available online_ at the `Django Web site`_. The FAQ_
 document is especially recommended, as it contains a number of issues that
 come up time and again.
 
@@ -115,7 +115,7 @@ Django users and developers from around the world. Friendly people are usually
 available at any hour of the day -- to help, or just to chat.
 
 .. _online: http://www.djangoproject.com/documentation/0.95/
-.. _Django website: http://www.djangoproject.com/
+.. _Django Web site: http://www.djangoproject.com/
 .. _FAQ: http://www.djangoproject.com/documentation/faq/
 .. _django-users: http://groups.google.com/group/django-users
 

docs/templates.txt

@@ -1945,7 +1945,7 @@ information.
 django.contrib.webdesign
 ------------------------
 
-A collection of template tags that can be useful while designing a website,
+A collection of template tags that can be useful while designing a Web site,
 such as a generator of Lorem Ipsum text. See the `webdesign documentation`_.
 
 .. _webdesign documentation: ../webdesign/

docs/tutorial03.txt

@@ -441,11 +441,11 @@ Here's what happens if a user goes to "/polls/34/" in this system:
 
 * Django will find the match at ``'^polls/'``
 * It will strip off the matching text (``"polls/"``) and send the remaining
-  text -- ``"34/"`` -- to the 'mysite.polls.urls' urlconf for
+  text -- ``"34/"`` -- to the 'mysite.polls.urls' URLconf for
   further processing.
 
 Now that we've decoupled that, we need to decouple the
-'mysite.polls.urls' urlconf by removing the leading "polls/" from each
+'mysite.polls.urls' URLconf by removing the leading "polls/" from each
 line::
 
     urlpatterns = patterns('mysite.polls.views',

docs/url_dispatch.txt

@@ -373,7 +373,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 the URLconf for the `Django website`_ itself. It includes a
+For example, here's the URLconf for the `Django Web site`_ itself. It includes a
 number of other URLconfs::
 
     from django.conf.urls.defaults import *
@@ -390,7 +390,7 @@ Django encounters ``include()``, it chops off whatever part of the URL matched
 up to that point and sends the remaining string to the included URLconf for
 further processing.
 
-.. _`Django website`: http://www.djangoproject.com/
+.. _`Django Web site`: http://www.djangoproject.com/
 
 Captured parameters
 -------------------