From fa8a1d252a4e928e5bed2cf7002e38943d80f753 Mon Sep 17 00:00:00 2001 From: Malcolm Tredinnick Date: Fri, 29 Sep 2006 02:30:42 +0000 Subject: [PATCH] Fixed #2845 -- Corrected a few spelling errors in the docs and changed a couple of correctly spelt words to their North American counterparts for consistency. Thanks, treborhudson@gmail.com git-svn-id: http://code.djangoproject.com/svn/django/trunk@3883 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/admin_css.txt | 4 ++-- docs/api_stability.txt | 4 ++-- docs/faq.txt | 2 +- docs/forms.txt | 2 +- docs/templates.txt | 2 +- docs/templates_python.txt | 2 +- docs/testing.txt | 6 +++--- docs/tutorial03.txt | 2 +- 8 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/admin_css.txt b/docs/admin_css.txt index ec402f7142..5822e26e45 100644 --- a/docs/admin_css.txt +++ b/docs/admin_css.txt @@ -82,7 +82,7 @@ There are also a few styles for styling text. .help This is a custom class for blocks of inline help text explaining the function of form elements. It makes text smaller and gray, and when applied - to ``p`` elements withing ``.form-row`` elements (see Form Styles below), + to ``p`` elements within ``.form-row`` elements (see Form Styles below), it will offset the text to align with the form field. Use this for help text, instead of ``small quiet``. It works on other elements, but try to put the class on a ``p`` whenever you can. @@ -170,4 +170,4 @@ Labels Form labels should always precede the field, except in the case of checkboxes and radio buttons, where the ``input`` should come first. Any explanation or help text should follow the ``label`` in a ``p`` with class -``.help``. \ No newline at end of file +``.help``. diff --git a/docs/api_stability.txt b/docs/api_stability.txt index a9d6904735..18885fbe63 100644 --- a/docs/api_stability.txt +++ b/docs/api_stability.txt @@ -82,7 +82,7 @@ that 90% of Django can be considered forwards-compatible at this point. That said, these APIs should *not* be considered stable, and are likely to change: - - `Forms and validation`_ will most likely be compeltely rewritten to + - `Forms and validation`_ will most likely be completely rewritten to deemphasize Manipulators in favor of validation-aware models. - `Serialization`_ is under heavy development; changes are likely. @@ -91,7 +91,7 @@ change: API changes may be necessary. - Generic relations will most likely be moved out of core and into the - content-types contrib package to avoid core dependacies on optional + content-types contrib package to avoid core dependancies on optional components. - The comments framework, which is yet undocumented, will likely get a complete diff --git a/docs/faq.txt b/docs/faq.txt index e1f344c811..c7f92d3580 100644 --- a/docs/faq.txt +++ b/docs/faq.txt @@ -499,7 +499,7 @@ specify an object to edit or delete. How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type? ------------------------------------------------------------------------------------------------------------------ -We try to avoid adding special cases in the Django code to accomodate all the +We try to avoid adding special cases in the Django code to accommodate all the database-specific options such as table type, etc. If you'd like to use any of these options, create an `SQL initial data file`_ that contains ``ALTER TABLE`` statements that do what you want to do. The initial data files are executed in diff --git a/docs/forms.txt b/docs/forms.txt index 2b00cb67d6..767225cfd4 100644 --- a/docs/forms.txt +++ b/docs/forms.txt @@ -489,7 +489,7 @@ required fields are present and non-empty. For each field that passes that test *and if the form submission contained data* for that field, all the validators for that field are called in turn. The emphasized portion in the last sentence is important: if a form field is not submitted (because it -contains no data -- which is normal HTML behaviour), the validators are not +contains no data -- which is normal HTML behavior), the validators are not run against the field. This feature is particularly important for models using diff --git a/docs/templates.txt b/docs/templates.txt index 35537d6e5f..b263a64aec 100644 --- a/docs/templates.txt +++ b/docs/templates.txt @@ -1056,7 +1056,7 @@ Formats a date as the time since that date (i.e. "4 days, 6 hours"). Takes an optional argument that is a variable containing the date to use as the comparison point (without the argument, the comparison point is *now*). For example, if ``blog_date`` is a date instance representing midnight on 1 -June 2006, and ``comment_date`` is a date instanace for 08:00 on 1 June 2006, +June 2006, and ``comment_date`` is a date instance for 08:00 on 1 June 2006, then ``{{ comment_date|timesince:blog_date }}`` would return "8 hours". timeuntil diff --git a/docs/templates_python.txt b/docs/templates_python.txt index 39e5b9d91a..8129b209c7 100644 --- a/docs/templates_python.txt +++ b/docs/templates_python.txt @@ -817,7 +817,7 @@ Inclusion tags Another common type of template tag is the type that displays some data by rendering *another* template. For example, Django's admin interface uses custom -template tags to display the buttons along the botton of the "add/change" form +template tags to display the buttons along the bottom of the "add/change" form pages. Those buttons always look the same, but the link targets change depending on the object being edited -- so they're a perfect case for using a small template that is filled with details from the current object. (In the admin's diff --git a/docs/testing.txt b/docs/testing.txt index b1ede3e4cc..19eef9f071 100644 --- a/docs/testing.txt +++ b/docs/testing.txt @@ -389,7 +389,7 @@ an alternative framework as if they were normal Django tests. When you run ``./manage.py test``, Django looks at the ``TEST_RUNNER`` setting to determine what to do. By default, ``TEST_RUNNER`` points to ``django.test.simple.run_tests``. This method defines the default Django -testing behaviour. This behaviour involves: +testing behavior. This behavior involves: #. Performing global pre-test setup #. Creating the test database @@ -435,7 +435,7 @@ a number of utility methods in the ``django.test.utils`` module. ``create_test_db(verbosity=1, autoclobber=False)`` Creates a new test database, and run ``syncdb`` against it. - ``verbosity`` has the same behaviour as in the test runner. + ``verbosity`` has the same behavior as in the test runner. ``Autoclobber`` describes the behavior that will occur if a database with the same name as the test database is discovered. If ``autoclobber`` is False, @@ -450,4 +450,4 @@ a number of utility methods in the ``django.test.utils`` module. Destroys the database with the name ``settings.DATABASE_NAME`` matching, and restores the value of ``settings.DATABASE_NAME`` to the provided name. - ``verbosity`` has the same behaviour as in the test runner. + ``verbosity`` has the same behavior as in the test runner. diff --git a/docs/tutorial03.txt b/docs/tutorial03.txt index 248d234043..b4f1d303dc 100644 --- a/docs/tutorial03.txt +++ b/docs/tutorial03.txt @@ -91,7 +91,7 @@ Finally, it calls that ``detail()`` function like so:: The ``poll_id='23'`` part comes from ``(?P\d+)``. Using parenthesis around a pattern "captures" the text matched by that pattern and sends it as an argument to the view function; the ``?P`` defines the name that will be used to -identify the matched pattern; and ``\d+`` is a regular experession to match a sequence of +identify the matched pattern; and ``\d+`` is a regular expression to match a sequence of digits (i.e., a number). Because the URL patterns are regular expressions, there really is no limit on