diff --git a/docs/api_stability.txt b/docs/api_stability.txt index 2a10f34a41a..051db25735b 100644 --- a/docs/api_stability.txt +++ b/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/ diff --git a/docs/authentication.txt b/docs/authentication.txt index 5e6b4b1a8b3..acd378fcab9 100644 --- a/docs/authentication.txt +++ b/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. diff --git a/docs/csrf.txt b/docs/csrf.txt index 7d79e39502a..8d56e2f5db8 100644 --- a/docs/csrf.txt +++ b/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. \ No newline at end of file +CSRF token and ensure that is included when your form is submitted. diff --git a/docs/db-api.txt b/docs/db-api.txt index ecd2a17e7a5..31a842a35f5 100644 --- a/docs/db-api.txt +++ b/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). diff --git a/docs/django-admin.txt b/docs/django-admin.txt index f5cc02ee529..71c4cf545ac 100644 --- a/docs/django-admin.txt +++ b/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. diff --git a/docs/forms.txt b/docs/forms.txt index 7a1ce301ce0..b20abf0ee9a 100644 --- a/docs/forms.txt +++ b/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::