mirror of
				https://github.com/django/django.git
				synced 2025-10-31 01:25:32 +00:00 
			
		
		
		
	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
This commit is contained in:
		| @@ -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``. | ||||
| ``.help``. | ||||
|   | ||||
| @@ -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 | ||||
|   | ||||
| @@ -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 | ||||
|   | ||||
| @@ -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 | ||||
|   | ||||
| @@ -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 | ||||
|   | ||||
| @@ -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 | ||||
|   | ||||
| @@ -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. | ||||
|   | ||||
| @@ -91,7 +91,7 @@ Finally, it calls that ``detail()`` function like so:: | ||||
| The ``poll_id='23'`` part comes from ``(?P<poll_id>\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<poll_id>`` 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 | ||||
|   | ||||
		Reference in New Issue
	
	Block a user