Changed e-mail to email throughout documentation and codebase. The one exception is translation strings, which I didn't want to disrupt

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

11 files changed, 56 insertions, 56 deletions

diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt
index 15680029f3..ea6b03858d 100644
--- a/docs/ref/contrib/formtools/form-wizard.txt
+++ b/docs/ref/contrib/formtools/form-wizard.txt
@@ -35,7 +35,7 @@ Here's the basic workflow for how a user would use a wizard:
     3. Step 1 and 2 repeat, for every subsequent form in the wizard.
     4. Once the user has submitted all the forms and all the data has been
        validated, the wizard processes the data -- saving it to the database,
-       sending an e-mail, or whatever the application needs to do.
+       sending an email, or whatever the application needs to do.
 
 Usage
 =====
@@ -67,7 +67,7 @@ convention is to put them in a file called :file:`forms.py` in your
 application.
 
 For example, let's write a "contact form" wizard, where the first page's form
-collects the sender's e-mail address and subject, and the second page collects
+collects the sender's email address and subject, and the second page collects
 the message itself. Here's what the :file:`forms.py` might look like::
 
     from django import forms
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 4730cb2e63..58f66daf02 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -181,9 +181,9 @@ fallback for cases where it is not installed.
 Getting the current domain for display
 --------------------------------------
 
-LJWorld.com and Lawrence.com both have e-mail alert functionality, which lets
+LJWorld.com and Lawrence.com both have email alert functionality, which lets
 readers sign up to get notifications when news happens. It's pretty basic: A
-reader signs up on a Web form, and he immediately gets an e-mail saying,
+reader signs up on a Web form, and he immediately gets an email saying,
 "Thanks for your subscription."
 
 It'd be inefficient and redundant to implement this signup-processing code
@@ -211,9 +211,9 @@ Here's an example of what the form-handling view looks like::
 
         # ...
 
-On Lawrence.com, this e-mail has the subject line "Thanks for subscribing to
-lawrence.com alerts." On LJWorld.com, the e-mail has the subject "Thanks for
-subscribing to LJWorld.com alerts." Same goes for the e-mail's message body.
+On Lawrence.com, this email has the subject line "Thanks for subscribing to
+lawrence.com alerts." On LJWorld.com, the email has the subject "Thanks for
+subscribing to LJWorld.com alerts." Same goes for the email's message body.
 
 Note that an even more flexible (but more heavyweight) way of doing this would
 be to use Django's template system. Assuming Lawrence.com and LJWorld.com have
diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt
index 467152cc13..9a0aa9b149 100644
--- a/docs/ref/contrib/syndication.txt
+++ b/docs/ref/contrib/syndication.txt
@@ -455,15 +455,15 @@ This example illustrates all possible attributes and methods for a
         def author_email(self, obj):
             """
             Takes the object returned by get_object() and returns the feed's
-            author's e-mail as a normal Python string.
+            author's email as a normal Python string.
             """
 
         def author_email(self):
             """
-            Returns the feed's author's e-mail as a normal Python string.
+            Returns the feed's author's email as a normal Python string.
             """
 
-        author_email = 'test@example.com' # Hard-coded author e-mail.
+        author_email = 'test@example.com' # Hard-coded author email.
 
         # AUTHOR LINK --One of the following three is optional. The framework
         # looks for them in this order. In each case, the URL should include
@@ -637,15 +637,15 @@ This example illustrates all possible attributes and methods for a
         def item_author_email(self, obj):
             """
             Takes an item, as returned by items(), and returns the item's
-            author's e-mail as a normal Python string.
+            author's email as a normal Python string.
             """
 
         def item_author_email(self):
             """
-            Returns the author e-mail for every item in the feed.
+            Returns the author email for every item in the feed.
             """
 
-        item_author_email = 'test@example.com' # Hard-coded author e-mail.
+        item_author_email = 'test@example.com' # Hard-coded author email.
 
         # ITEM AUTHOR LINK -- One of the following three is optional. The
         # framework looks for them in this order. In each case, the URL should
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index 33c4c8b8e1..9b3f66d39d 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -1086,7 +1086,7 @@ a password has been manually set for it.
 .. django-admin-option:: --username
 .. django-admin-option:: --email
 
-The username and e-mail address for the new account can be supplied by
+The username and email address for the new account can be supplied by
 using the ``--username`` and ``--email`` arguments on the command
 line. If either of those is not supplied, ``createsuperuser`` will prompt for
 it when running interactively.
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
index 81544ca2b5..bd8948cc08 100644
--- a/docs/ref/forms/api.txt
+++ b/docs/ref/forms/api.txt
@@ -89,11 +89,11 @@ and return a boolean designating whether the data was valid::
 
 Let's try with some invalid data. In this case, ``subject`` is blank (an error,
 because all fields are required by default) and ``sender`` is not a valid
-e-mail address::
+email address::
 
     >>> data = {'subject': '',
     ...         'message': 'Hi there',
-    ...         'sender': 'invalid e-mail address',
+    ...         'sender': 'invalid email address',
     ...         'cc_myself': True}
     >>> f = ContactForm(data)
     >>> f.is_valid()
@@ -105,7 +105,7 @@ Access the :attr:`~Form.errors` attribute to get a dictionary of error
 messages::
 
     >>> f.errors
-    {'sender': [u'Enter a valid e-mail address.'], 'subject': [u'This field is required.']}
+    {'sender': [u'Enter a valid email address.'], 'subject': [u'This field is required.']}
 
 In this dictionary, the keys are the field names, and the values are lists of
 Unicode strings representing the error messages. The error messages are stored
@@ -204,7 +204,7 @@ If your data does *not* validate, your ``Form`` instance will not have a
 
     >>> data = {'subject': '',
     ...         'message': 'Hi there',
-    ...         'sender': 'invalid e-mail address',
+    ...         'sender': 'invalid email address',
     ...         'cc_myself': True}
     >>> f = ContactForm(data)
     >>> f.is_valid()
@@ -531,25 +531,25 @@ method you're using::
 
     >>> data = {'subject': '',
     ...         'message': 'Hi there',
-    ...         'sender': 'invalid e-mail address',
+    ...         'sender': 'invalid email address',
     ...         'cc_myself': True}
     >>> f = ContactForm(data, auto_id=False)
     >>> print f.as_table()
     <tr><th>Subject:</th><td><ul class="errorlist"><li>This field is required.</li></ul><input type="text" name="subject" maxlength="100" /></td></tr>
     <tr><th>Message:</th><td><input type="text" name="message" value="Hi there" /></td></tr>
-    <tr><th>Sender:</th><td><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul><input type="text" name="sender" value="invalid e-mail address" /></td></tr>
+    <tr><th>Sender:</th><td><ul class="errorlist"><li>Enter a valid email address.</li></ul><input type="text" name="sender" value="invalid email address" /></td></tr>
     <tr><th>Cc myself:</th><td><input checked="checked" type="checkbox" name="cc_myself" /></td></tr>
     >>> print f.as_ul()
     <li><ul class="errorlist"><li>This field is required.</li></ul>Subject: <input type="text" name="subject" maxlength="100" /></li>
     <li>Message: <input type="text" name="message" value="Hi there" /></li>
-    <li><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul>Sender: <input type="text" name="sender" value="invalid e-mail address" /></li>
+    <li><ul class="errorlist"><li>Enter a valid email address.</li></ul>Sender: <input type="text" name="sender" value="invalid email address" /></li>
     <li>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></li>
     >>> print f.as_p()
     <p><ul class="errorlist"><li>This field is required.</li></ul></p>
     <p>Subject: <input type="text" name="subject" maxlength="100" /></p>
     <p>Message: <input type="text" name="message" value="Hi there" /></p>
-    <p><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul></p>
-    <p>Sender: <input type="text" name="sender" value="invalid e-mail address" /></p>
+    <p><ul class="errorlist"><li>Enter a valid email address.</li></ul></p>
+    <p>Sender: <input type="text" name="sender" value="invalid email address" /></p>
     <p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
 
 Customizing the error list format
@@ -571,8 +571,8 @@ pass that in at construction time::
     <div class="errorlist"><div class="error">This field is required.</div></div>
     <p>Subject: <input type="text" name="subject" maxlength="100" /></p>
     <p>Message: <input type="text" name="message" value="Hi there" /></p>
-    <div class="errorlist"><div class="error">Enter a valid e-mail address.</div></div>
-    <p>Sender: <input type="text" name="sender" value="invalid e-mail address" /></p>
+    <div class="errorlist"><div class="error">Enter a valid email address.</div></div>
+    <p>Sender: <input type="text" name="sender" value="invalid email address" /></p>
     <p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
 
 More granular output
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index b49864f7cf..73d8b02869 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -27,10 +27,10 @@ exception or returns the clean value::
     u'foo@example.com'
     >>> f.clean(u'foo@example.com')
     u'foo@example.com'
-    >>> f.clean('invalid e-mail address')
+    >>> f.clean('invalid email address')
     Traceback (most recent call last):
     ...
-    ValidationError: [u'Enter a valid e-mail address.']
+    ValidationError: [u'Enter a valid email address.']
 
 Core field arguments
 --------------------
@@ -208,23 +208,23 @@ fields. We've specified ``auto_id=False`` to simplify the output::
     >>> class HelpTextContactForm(forms.Form):
     ...     subject = forms.CharField(max_length=100, help_text='100 characters max.')
     ...     message = forms.CharField()
-    ...     sender = forms.EmailField(help_text='A valid e-mail address, please.')
+    ...     sender = forms.EmailField(help_text='A valid email address, please.')
     ...     cc_myself = forms.BooleanField(required=False)
     >>> f = HelpTextContactForm(auto_id=False)
     >>> print f.as_table()
     <tr><th>Subject:</th><td><input type="text" name="subject" maxlength="100" /><br /><span class="helptext">100 characters max.</span></td></tr>
     <tr><th>Message:</th><td><input type="text" name="message" /></td></tr>
-    <tr><th>Sender:</th><td><input type="text" name="sender" /><br />A valid e-mail address, please.</td></tr>
+    <tr><th>Sender:</th><td><input type="text" name="sender" /><br />A valid email address, please.</td></tr>
     <tr><th>Cc myself:</th><td><input type="checkbox" name="cc_myself" /></td></tr>
     >>> print f.as_ul()
     <li>Subject: <input type="text" name="subject" maxlength="100" /> <span class="helptext">100 characters max.</span></li>
     <li>Message: <input type="text" name="message" /></li>
-    <li>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</li>
+    <li>Sender: <input type="text" name="sender" /> A valid email address, please.</li>
     <li>Cc myself: <input type="checkbox" name="cc_myself" /></li>
     >>> print f.as_p()
     <p>Subject: <input type="text" name="subject" maxlength="100" /> <span class="helptext">100 characters max.</span></p>
     <p>Message: <input type="text" name="message" /></p>
-    <p>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</p>
+    <p>Sender: <input type="text" name="sender" /> A valid email address, please.</p>
     <p>Cc myself: <input type="checkbox" name="cc_myself" /></p>
 
 ``error_messages``
@@ -481,7 +481,7 @@ Takes four optional arguments:
     * Default widget: ``TextInput``
     * Empty value: ``''`` (an empty string)
     * Normalizes to: A Unicode object.
-    * Validates that the given value is a valid e-mail address, using a
+    * Validates that the given value is a valid email address, using a
       moderately complex regular expression.
     * Error message keys: ``required``, ``invalid``
 
@@ -490,7 +490,7 @@ If provided, these arguments ensure that the string is at most or at least the
 given length.
 
 .. versionchanged:: 1.2
-   The EmailField previously did not recognize e-mail addresses as valid that
+   The EmailField previously did not recognize email addresses as valid that
    contained an IDN (Internationalized Domain Name; a domain containing
    unicode characters) domain part. This has now been corrected.
 
diff --git a/docs/ref/forms/validation.txt b/docs/ref/forms/validation.txt
index d5f40706a1..d8f896deb2 100644
--- a/docs/ref/forms/validation.txt
+++ b/docs/ref/forms/validation.txt
@@ -77,7 +77,7 @@ overridden:
     * 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 e-mail address and the
+      is supplied, field ``B`` must contain a valid email 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()``
@@ -187,12 +187,12 @@ a look at Django's ``EmailField``::
 
     class EmailField(CharField):
         default_error_messages = {
-            'invalid': _(u'Enter a valid e-mail address.'),
+            'invalid': _(u'Enter a valid email address.'),
         }
         default_validators = [validators.validate_email]
 
 As you can see, ``EmailField`` is just a ``CharField`` with customized error
-message and a validator that validates e-mail addresses. This can also be done
+message and a validator that validates email addresses. This can also be done
 on field definition so::
 
     email = forms.EmailField()
@@ -200,14 +200,14 @@ on field definition so::
 is equivalent to::
 
     email = forms.CharField(validators=[validators.validate_email],
-            error_messages={'invalid': _(u'Enter a valid e-mail address.')})
+            error_messages={'invalid': _(u'Enter a valid email address.')})
 
 
 Form field default cleaning
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Let's firstly create a custom form field that validates its input is a string
-containing comma-separated e-mail addresses. The full class looks like this::
+containing comma-separated email addresses. The full class looks like this::
 
     from django import forms
     from django.core.validators import validate_email
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 66bd04791b..fbd9fb78f8 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -469,7 +469,7 @@ The admin represents this as an ``<input type="text">`` (a single-line input).
 
 .. class:: EmailField([max_length=75, **options])
 
-A :class:`CharField` that checks that the value is a valid e-mail address.
+A :class:`CharField` that checks that the value is a valid email address.
 
 ``FileField``
 -------------
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 8bf0a4e8d0..325b009fe4 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -66,13 +66,13 @@ ADMINS
 Default: ``()`` (Empty tuple)
 
 A tuple that lists people who get code error notifications. When
-``DEBUG=False`` and a view raises an exception, Django will e-mail these people
+``DEBUG=False`` and a view raises an exception, Django will email these people
 with the full exception information. Each member of the tuple should be a tuple
-of (Full name, e-mail address). Example::
+of (Full name, email address). Example::
 
     (('John', 'john@example.com'), ('Mary', 'mary@example.com'))
 
-Note that Django will e-mail *all* of these people whenever an error happens.
+Note that Django will email *all* of these people whenever an error happens.
 See :doc:`/howto/error-reporting` for more information.
 
 .. setting:: ALLOWED_INCLUDE_ROOTS
@@ -756,7 +756,7 @@ DEFAULT_FROM_EMAIL
 
 Default: ``'webmaster@localhost'``
 
-Default e-mail address to use for various automated correspondence from the
+Default email address to use for various automated correspondence from the
 site manager(s).
 
 .. setting:: DEFAULT_INDEX_TABLESPACE
@@ -821,7 +821,7 @@ EMAIL_HOST
 
 Default: ``'localhost'``
 
-The host to use for sending e-mail.
+The host to use for sending email.
 
 See also ``EMAIL_PORT``.
 
@@ -867,7 +867,7 @@ EMAIL_SUBJECT_PREFIX
 
 Default: ``'[Django] '``
 
-Subject-line prefix for e-mail messages sent with ``django.core.mail.mail_admins``
+Subject-line prefix for email messages sent with ``django.core.mail.mail_admins``
 or ``django.core.mail.mail_managers``. You'll probably want to include the
 trailing space.
 
@@ -1028,7 +1028,7 @@ IGNORABLE_404_ENDS
 
 Default: ``('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi', 'favicon.ico', '.php')``
 
-See also ``IGNORABLE_404_STARTS`` and ``Error reporting via e-mail``.
+See also ``IGNORABLE_404_STARTS`` and ``Error reporting via email``.
 
 .. setting:: IGNORABLE_404_STARTS
 
@@ -1038,7 +1038,7 @@ IGNORABLE_404_STARTS
 Default: ``('/cgi-bin/', '/_vti_bin', '/_vti_inf')``
 
 A tuple of strings that specify beginnings of URLs that should be ignored by
-the 404 e-mailer. See ``SEND_BROKEN_LINK_EMAILS``, ``IGNORABLE_404_ENDS`` and
+the 404 emailer. See ``SEND_BROKEN_LINK_EMAILS``, ``IGNORABLE_404_ENDS`` and
 the :doc:`/howto/error-reporting`.
 
 .. setting:: INSTALLED_APPS
@@ -1433,7 +1433,7 @@ SEND_BROKEN_LINK_EMAILS
 
 Default: ``False``
 
-Whether to send an e-mail to the ``MANAGERS`` each time somebody visits a
+Whether to send an email to the ``MANAGERS`` each time somebody visits a
 Django-powered page that is 404ed with a non-empty referer (i.e., a broken
 link). This is only used if ``CommonMiddleware`` is installed (see
 :doc:`/topics/http/middleware`. See also ``IGNORABLE_404_STARTS``,
@@ -1459,7 +1459,7 @@ SERVER_EMAIL
 
 Default: ``'root@localhost'``
 
-The e-mail address that error messages come from, such as those sent to
+The email address that error messages come from, such as those sent to
 ``ADMINS`` and ``MANAGERS``.
 
 .. setting:: SESSION_COOKIE_AGE
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index c84347844b..bd11d2a4b8 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -61,7 +61,7 @@ passing them around at will, because ASCII is a subset of UTF-8.
 Don't be fooled into thinking that if your :setting:`DEFAULT_CHARSET` setting is set
 to something other than ``'utf-8'`` you can use that other encoding in your
 bytestrings! :setting:`DEFAULT_CHARSET` only applies to the strings generated as
-the result of template rendering (and e-mail). Django will always assume UTF-8
+the result of template rendering (and email). Django will always assume UTF-8
 encoding for internal bytestrings. The reason for this is that the
 :setting:`DEFAULT_CHARSET` setting is not actually under your control (if you are the
 application developer). It's under the control of the person installing and
@@ -304,16 +304,16 @@ A couple of tips to remember when writing your own template tags and filters:
       translation objects into strings. It's easier to work solely with Unicode
       strings at that point.
 
-E-mail
+Email
 ======
 
-Django's e-mail framework (in ``django.core.mail``) supports Unicode
+Django's email framework (in ``django.core.mail``) supports Unicode
 transparently. You can use Unicode data in the message bodies and any headers.
-However, you're still obligated to respect the requirements of the e-mail
-specifications, so, for example, e-mail addresses should use only ASCII
+However, you're still obligated to respect the requirements of the email
+specifications, so, for example, email addresses should use only ASCII
 characters.
 
-The following code example demonstrates that everything except e-mail addresses
+The following code example demonstrates that everything except email addresses
 can be non-ASCII::
 
     from django.core.mail import EmailMessage
diff --git a/docs/ref/validators.txt b/docs/ref/validators.txt
index 0451f65dc0..472fd62a8c 100644
--- a/docs/ref/validators.txt
+++ b/docs/ref/validators.txt
@@ -106,7 +106,7 @@ to, or in lieu of custom ``field.clean()`` methods.
 .. data:: validate_email
 
     A :class:`RegexValidator` instance that ensures a value looks like an
-    e-mail address.
+    email address.
 
 ``validate_slug``
 -----------------