From 94af19c43fad3e42d64981e22fe15b844f1f9eb6 Mon Sep 17 00:00:00 2001 From: Adrian Holovaty Date: Fri, 1 Apr 2011 16:10:22 +0000 Subject: 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 --- docs/ref/contrib/formtools/form-wizard.txt | 4 ++-- docs/ref/contrib/sites.txt | 10 +++++----- docs/ref/contrib/syndication.txt | 12 ++++++------ docs/ref/django-admin.txt | 2 +- docs/ref/forms/api.txt | 22 +++++++++++----------- docs/ref/forms/fields.txt | 16 ++++++++-------- docs/ref/forms/validation.txt | 10 +++++----- docs/ref/models/fields.txt | 2 +- docs/ref/settings.txt | 20 ++++++++++---------- docs/ref/unicode.txt | 12 ++++++------ docs/ref/validators.txt | 2 +- 11 files changed, 56 insertions(+), 56 deletions(-) (limited to 'docs/ref') 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() Subject: Message: - Sender: + Sender: Cc myself: >>> print f.as_ul()
  • Subject:
  • Message:
    • -
  • Sender:
    • +
  • Sender:
  • Cc myself:
    • >>> print f.as_p()

    Subject:

    Message:

    -

    -

    Sender:

    +

    +

    Sender:

    Cc myself:

    Customizing the error list format @@ -571,8 +571,8 @@ pass that in at construction time::
    This field is required.

    Subject:

    Message:

    -
    Enter a valid e-mail address.
    -

    Sender:

    +
    Enter a valid email address.
    +

    Sender:

    Cc myself:

    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() Subject:
    100 characters max. Message: - Sender:
    A valid e-mail address, please. + Sender:
    A valid email address, please. Cc myself: >>> print f.as_ul()
  • Subject: 100 characters max.
  • Message:
    • -
  • Sender: A valid e-mail address, please.
    • +
  • Sender: A valid email address, please.
  • Cc myself:
    • >>> print f.as_p()

    Subject: 100 characters max.

    Message:

    -

    Sender: A valid e-mail address, please.

    +

    Sender: A valid email address, please.

    Cc myself:

    ``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 ```` (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`` ----------------- -- cgit v1.3