Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fixed #16014 -- numerous documentation typos -- thanks psmith.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16220 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 5ecb88c146c7b4d1adb046d65c43a0b75283c03d 1 parent df6e031
Simon Meers authored
2  docs/howto/custom-management-commands.txt
@@ -71,7 +71,7 @@ The new custom command can be called using ``python manage.py closepoll
71 71
 <poll_id>``.
72 72
 
73 73
 The ``handle()`` method takes zero or more ``poll_ids`` and sets ``poll.opened``
74  
-to ``False`` for each one. If the user referenced any nonexistant polls, a
  74
+to ``False`` for each one. If the user referenced any nonexistent polls, a
75 75
 :class:`CommandError` is raised. The ``poll.opened`` attribute does not exist
76 76
 in the :doc:`tutorial</intro/tutorial01>` and was added to
77 77
 ``polls.models.Poll`` for this example.
2  docs/howto/custom-template-tags.txt
@@ -894,7 +894,7 @@ Here's how you'd use this new version of the tag:
894 894
 .. admonition:: Variable scope in context
895 895
 
896 896
     Any variable set in the context will only be available in the same ``block``
897  
-    of the template in which it was assigned. This behaviour is intentional;
  897
+    of the template in which it was assigned. This behavior is intentional;
898 898
     it provides a scope for variables so that they don't conflict with
899 899
     context in other blocks.
900 900
 
2  docs/howto/error-reporting.txt
@@ -44,7 +44,7 @@ setting.
44 44
    .. versionadded:: 1.3
45 45
 
46 46
    Server error emails are sent using the logging framework, so you can
47  
-   customize this behaviour by :doc:`customizing your logging configuration
  47
+   customize this behavior by :doc:`customizing your logging configuration
48 48
    </topics/logging>`.
49 49
 
50 50
 404 errors
2  docs/howto/jython.txt
@@ -65,7 +65,7 @@ At this point, Django on Jython should behave nearly identically to Django
65 65
 running on standard Python. However, are a few differences to keep in mind:
66 66
 
67 67
     * Remember to use the ``jython`` command instead of ``python``. The
68  
-      documentation uses ``python`` for consistancy, but if you're using Jython
  68
+      documentation uses ``python`` for consistency, but if you're using Jython
69 69
       you'll want to mentally replace ``python`` with ``jython`` every time it
70 70
       occurs.
71 71
 
6  docs/howto/static-files.txt
@@ -137,7 +137,7 @@ A far better way is to use the value of the :setting:`STATIC_URL` setting
137 137
 directly in your templates. This means that a switch of static files servers
138 138
 only requires changing that single value. Much better!
139 139
 
140  
-``staticfiles`` inludes two built-in ways of getting at this setting in your
  140
+``staticfiles`` includes two built-in ways of getting at this setting in your
141 141
 templates: a context processor and a template tag.
142 142
 
143 143
 With a context processor
@@ -170,7 +170,7 @@ As a brief refresher, context processors add variables into the contexts of
170 170
 every template. However, context processors require that you use
171 171
 :class:`~django.template.RequestContext` when rendering templates. This happens
172 172
 automatically if you're using a :doc:`generic view </ref/class-based-views>`,
173  
-but in views written by hand you'll need to explicitally use ``RequestContext``
  173
+but in views written by hand you'll need to explicitly use ``RequestContext``
174 174
 To see how that works, and to read more details, check out
175 175
 :ref:`subclassing-context-requestcontext`.
176 176
 
@@ -439,7 +439,7 @@ For example, if you've written an S3 storage backend in
439 439
 
440 440
 Once that's done, all you have to do is run :djadmin:`collectstatic` and your
441 441
 static files would be pushed through your storage package up to S3. If you
442  
-later needed to swich to a different storage provider, it could be as simple
  442
+later needed to switch to a different storage provider, it could be as simple
443 443
 as changing your :setting:`STATICFILES_STORAGE` setting.
444 444
 
445 445
 For details on how you'd write one of these backends,
2  docs/internals/contributing.txt
@@ -472,7 +472,7 @@ to do:
472 472
     * Then, click the "Join this Team" button to become a member of this team.
473 473
       Every team has at least one coordinator who is responsible to review
474 474
       your membership request. You can of course also contact the team
475  
-      coordinator to clarify procedual problems and handle the actual
  475
+      coordinator to clarify procedural problems and handle the actual
476 476
       translation process.
477 477
 
478 478
     * Once you are a member of a team choose the translation resource you
6  docs/internals/deprecation.txt
@@ -20,7 +20,7 @@ their deprecation, as per the :ref:`Django deprecation policy
20 20
 
21 21
     * 1.4
22 22
         * ``CsrfResponseMiddleware``.  This has been deprecated since the 1.2
23  
-          release, in favour of the template tag method for inserting the CSRF
  23
+          release, in favor of the template tag method for inserting the CSRF
24 24
           token.  ``CsrfMiddleware``, which combines ``CsrfResponseMiddleware``
25 25
           and ``CsrfViewMiddleware``, is also deprecated.
26 26
 
@@ -129,7 +129,7 @@ their deprecation, as per the :ref:`Django deprecation policy
129 129
 
130 130
         * The undocumented function
131 131
           :func:`django.contrib.formtools.utils.security_hash`
132  
-          is deprecated, in favour of :func:`django.contrib.formtools.utils.form_hmac`
  132
+          is deprecated, in favor of :func:`django.contrib.formtools.utils.form_hmac`
133 133
 
134 134
         * The function-based generic views have been deprecated in
135 135
           favor of their class-based cousins. The following modules
@@ -161,7 +161,7 @@ their deprecation, as per the :ref:`Django deprecation policy
161 161
           a :class:`~django.contrib.gis.geos.GEOSException` when called
162 162
           on a geometry with no SRID value.
163 163
 
164  
-        * :class:`~django.http.CompatCookie` will be removed in favour of
  164
+        * :class:`~django.http.CompatCookie` will be removed in favor of
165 165
           :class:`~django.http.SimpleCookie`.
166 166
 
167 167
         * :class:`django.core.context_processors.PermWrapper` and
2  docs/internals/svn.txt
@@ -199,7 +199,7 @@ branch ``django/branches/releases/1.0.X`` was created to receive bug
199 199
 fixes, and shortly after the release of Django 1.1 the branch
200 200
 ``django/branches/releases/1.1.X`` was created.
201 201
 
202  
-Prior to the Django 1.0 release, these branches were maintaind within
  202
+Prior to the Django 1.0 release, these branches were maintained within
203 203
 the top-level ``django/branches`` directory, and so the following
204 204
 branches exist there and provided support for older Django releases:
205 205
 
2  docs/intro/tutorial01.txt
@@ -593,7 +593,7 @@ automatically-generated admin.
593 593
     Unicode string, and ``str(p)`` will return a normal string, with characters
594 594
     encoded as UTF-8.
595 595
 
596  
-    If all of this is jibberish to you, just remember to add
  596
+    If all of this is gibberish to you, just remember to add
597 597
     :meth:`~django.db.models.Model.__unicode__` methods to your models. With any
598 598
     luck, things should Just Work for you.
599 599
 
2  docs/ref/contrib/csrf.txt
@@ -396,7 +396,7 @@ developers of other reusable apps that want the same guarantees also use the
396 396
 Settings
397 397
 ========
398 398
 
399  
-A number of settings can be used to control Django's CSRF behaviour.
  399
+A number of settings can be used to control Django's CSRF behavior.
400 400
 
401 401
 CSRF_COOKIE_DOMAIN
402 402
 ------------------
2  docs/ref/contrib/flatpages.txt
@@ -86,7 +86,7 @@ does all of the work.
86 86
 
87 87
     .. versionchanged:: 1.4
88 88
        Redirects by the middlware are permanent (301 status code) instead of
89  
-       temporary (302) to match behaviour of the
  89
+       temporary (302) to match behavior of the
90 90
        :class:`~django.middleware.common.CommonMiddleware`.
91 91
 
92 92
     If it doesn't find a match, the request continues to be processed as usual.
2  docs/ref/forms/validation.txt
@@ -361,6 +361,6 @@ considering aren't valid, we must remember to remove them from the
361 361
 ``cleaned_data``.
362 362
 
363 363
 In fact, Django will currently completely wipe out the ``cleaned_data``
364  
-dictionary if there are any errors in the form. However, this behaviour may
  364
+dictionary if there are any errors in the form. However, this behavior may
365 365
 change in the future, so it's not a bad idea to clean up after yourself in the
366 366
 first place.
4  docs/ref/models/querysets.txt
@@ -986,7 +986,7 @@ locks on them.
986 986
 
987 987
 Usually, if another transaction has already acquired a lock on one of the
988 988
 selected rows, the query will block until the lock is released. If this is
989  
-not the behaviour you want, call ``select_for_update(nowait=True)``. This will
  989
+not the behavior you want, call ``select_for_update(nowait=True)``. This will
990 990
 make the call non-blocking. If a conflicting lock is already acquired by
991 991
 another transaction, ``django.db.utils.DatabaseError`` will be raised when
992 992
 the queryset is evaluated.
@@ -1124,7 +1124,7 @@ If you have a field named ``defaults`` and want to use it as an exact lookup in
1124 1124
     Foo.objects.get_or_create(defaults__exact='bar', defaults={'defaults': 'baz'})
1125 1125
 
1126 1126
 
1127  
-The ``get_or_create()`` method has similar error behaviour to ``create()``
  1127
+The ``get_or_create()`` method has similar error behavior to ``create()``
1128 1128
 when you are using manually specified primary keys. If an object needs to be
1129 1129
 created and the key already exists in the database, an ``IntegrityError`` will
1130 1130
 be raised.
2  docs/releases/1.3-beta-1.txt
@@ -27,7 +27,7 @@ The :mod:`~django.contrib.staticfiles` app ships with the ability to
27 27
 automatically serve static files during development (if the :setting:`DEBUG`
28 28
 setting is ``True``) when using the :djadmin:`runserver` management command.
29 29
 Based on feedback from the community this release adds two new options to the
30  
-:djadmin:`runserver` command to modify this behaviour:
  30
+:djadmin:`runserver` command to modify this behavior:
31 31
 
32 32
     * ``--nostatic``: prevents the :djadmin:`runserver` command from serving
33 33
       files completely.
4  docs/releases/1.3.txt
@@ -521,7 +521,7 @@ Callables in templates
521 521
 Previously, a callable in a template would only be called automatically as part
522 522
 of the variable resolution process if it was retrieved via attribute
523 523
 lookup. This was an inconsistency that could result in confusing and unhelpful
524  
-behaviour::
  524
+behavior::
525 525
 
526 526
     >>> Template("{{ user.get_full_name }}").render(Context({'user': user}))
527 527
     u'Joe Bloggs'
@@ -529,7 +529,7 @@ behaviour::
529 529
     u'&lt;bound method User.get_full_name of &lt;...
530 530
 
531 531
 This has been resolved in Django 1.3 - the result in both cases will be ``u'Joe
532  
-Bloggs'``. Although the previous behaviour was not useful for a template language
  532
+Bloggs'``. Although the previous behavior was not useful for a template language
533 533
 designed for web designers, and was never deliberately supported, it is possible
534 534
 that some templates may be broken by this change.
535 535
 
4  docs/releases/1.4.txt
@@ -132,7 +132,7 @@ flatpage. For example, requesting ``/notaflatpageoravalidurl`` in a previous
132 132
 version would redirect to ``/notaflatpageoravalidurl/``, which would
133 133
 subsequently raise a 404. Requesting ``/notaflatpageoravalidurl`` now will
134 134
 immediately raise a 404. Additionally redirects returned by flatpages are now
135  
-permanent (301 status code) to match the behaviour of the
  135
+permanent (301 status code) to match the behavior of the
136 136
 :class:`~django.middleware.common.CommonMiddleware`.
137 137
 
138 138
 `COMMENTS_BANNED_USERS_GROUP` setting
@@ -144,7 +144,7 @@ the feature properly and didn't enforce the exclusion in other parts of the
144 144
 app, e.g. the template tags. To fix this problem the code was removed from
145 145
 the feed class.
146 146
 
147  
-If you rely on the feature and want to restore the old behaviour, simply use
  147
+If you rely on the feature and want to restore the old behavior, simply use
148 148
 a custom comment model manager to exclude the user group, e.g.::
149 149
 
150 150
     from django.conf import settings
4  docs/topics/auth.txt
@@ -283,7 +283,7 @@ Manager functions
283 283
         The :attr:`~django.contrib.auth.models.User.username` and
284 284
         :attr:`~django.contrib.auth.models.User.password` are set as given. The
285 285
         domain portion of :attr:`~django.contrib.auth.models.User.email` is
286  
-        automatically convered to lowercase, and the returned
  286
+        automatically converted to lowercase, and the returned
287 287
         :class:`~django.contrib.auth.models.User` object will have
288 288
         :attr:`~models.User.is_active` set to ``True``.
289 289
 
@@ -1244,7 +1244,7 @@ To create custom permissions for a given model object, use the ``permissions``
1244 1244
 :ref:`model Meta attribute <meta-options>`.
1245 1245
 
1246 1246
 This example Task model creates three custom permissions, i.e., actions users
1247  
-can or cannot do with Task instances, specific to your appication::
  1247
+can or cannot do with Task instances, specific to your application::
1248 1248
 
1249 1249
     class Task(models.Model):
1250 1250
         ...
4  docs/topics/cache.txt
@@ -615,7 +615,7 @@ If :setting:`USE_I18N` is set to ``True`` the per-site middleware cache will
615 615
 :ref:`respect the active language<i18n-cache-key>`. For the ``cache`` template
616 616
 tag you could use one of the
617 617
 :ref:`translation-specific variables<template-translation-vars>` available in
618  
-templates to archieve the same result:
  618
+templates to achieve the same result:
619 619
 
620 620
 .. code-block:: html+django
621 621
 
@@ -843,7 +843,7 @@ keys unaffected. Continuing our previous example::
843 843
     # Version 2 isn't available, either
844 844
     >>> cache.get('my_key', version=2)
845 845
     None
846  
-    # But version 3 *is* availble
  846
+    # But version 3 *is* available
847 847
     >>> cache.get('my_key', version=3)
848 848
     'hello world!'
849 849
 
2  docs/topics/class-based-views.txt
@@ -72,7 +72,7 @@ so we can just subclass it, and override the template name::
72 72
 
73 73
 Then, we just need to add this new view into our URLconf. As the class-based
74 74
 views themselves are classes, we point the URL to the as_view class method
75  
-instead, which is the entrypoint for class-based views::
  75
+instead, which is the entry point for class-based views::
76 76
 
77 77
     # urls.py
78 78
     from django.conf.urls.defaults import *
2  docs/topics/db/aggregation.txt
@@ -233,7 +233,7 @@ the first query will provide the total number of all books published by the
233 233
 publisher; the second query will only include good books in the annotated
234 234
 count. In the first query, the annotation precedes the filter, so the
235 235
 filter has no effect on the annotation. In the second query, the filter
236  
-preceeds the annotation, and as a result, the filter constrains the objects
  236
+precedes the annotation, and as a result, the filter constrains the objects
237 237
 considered when calculating the annotation.
238 238
 
239 239
 ``order_by()``
6  docs/topics/db/models.txt
@@ -188,7 +188,7 @@ ones:
188 188
 
189 189
         ::
190 190
 
191  
-            >>> p = Person(name="Fred Flinstone", gender="M")
  191
+            >>> p = Person(name="Fred Flintstone", gender="M")
192 192
             >>> p.save()
193 193
             >>> p.gender
194 194
             u'M'
@@ -791,7 +791,7 @@ There are three styles of inheritance that are possible in Django.
791 791
  2. If you're subclassing an existing model (perhaps something from another
792 792
     application entirely) and want each model to have its own database table,
793 793
     :ref:`multi-table-inheritance` is the way to go.
794  
- 3. Finally, if you only want to modify the Python-level behaviour of a model,
  794
+ 3. Finally, if you only want to modify the Python-level behavior of a model,
795 795
     without changing the models fields in any way, you can use
796 796
     :ref:`proxy-models`.
797 797
 
@@ -1218,7 +1218,7 @@ cannot create another model field called ``author`` in any class that inherits
1218 1218
 from that base class.
1219 1219
 
1220 1220
 Overriding fields in a parent model leads to difficulties in areas such as
1221  
-initialising new instances (specifying which field is being initialized in
  1221
+initializing new instances (specifying which field is being initialized in
1222 1222
 ``Model.__init__``) and serialization. These are features which normal Python
1223 1223
 class inheritance doesn't have to deal with in quite the same way, so the
1224 1224
 difference between Django model inheritance and Python class inheritance isn't
6  docs/topics/db/optimization.txt
@@ -93,13 +93,13 @@ caching.
93 93
 Use the ``with`` template tag
94 94
 -----------------------------
95 95
 
96  
-To make use of the caching behaviour of ``QuerySet``, you may need to use the
  96
+To make use of the caching behavior of ``QuerySet``, you may need to use the
97 97
 :ttag:`with` template tag.
98 98
 
99 99
 Use ``iterator()``
100 100
 ------------------
101 101
 
102  
-When you have a lot of objects, the caching behaviour of the ``QuerySet`` can
  102
+When you have a lot of objects, the caching behavior of the ``QuerySet`` can
103 103
 cause a large amount of memory to be used. In this case,
104 104
 :meth:`~django.db.models.QuerySet.iterator()` may help.
105 105
 
@@ -252,7 +252,7 @@ individual, use a bulk SQL UPDATE statement, via :ref:`QuerySet.update()
252 252
 
253 253
 Note, however, that these bulk update methods cannot call the ``save()`` or
254 254
 ``delete()`` methods of individual instances, which means that any custom
255  
-behaviour you have added for these methods will not be executed, including
  255
+behavior you have added for these methods will not be executed, including
256 256
 anything driven from the normal database object :doc:`signals </ref/signals>`.
257 257
 
258 258
 Use foreign key values directly
2  docs/topics/db/transactions.txt
@@ -234,7 +234,7 @@ provide the savepoint functions, but they are empty operations - they won't
234 234
 actually do anything.
235 235
 
236 236
 Savepoints aren't especially useful if you are using the default
237  
-``autocommit`` behaviour of Django. However, if you are using
  237
+``autocommit`` behavior of Django. However, if you are using
238 238
 ``commit_on_success`` or ``commit_manually``, each open transaction will build
239 239
 up a series of database operations, awaiting a commit or rollback. If you
240 240
 issue a rollback, the entire transaction is rolled back. Savepoints provide
2  docs/topics/http/shortcuts.txt
@@ -4,7 +4,7 @@ Django shortcut functions
4 4
 
5 5
 .. module:: django.shortcuts
6 6
    :synopsis:
7  
-       Convience shortcuts that spam multiple levels of Django's MVC stack.
  7
+       Convenience shortcuts that spam multiple levels of Django's MVC stack.
8 8
 
9 9
 .. index:: shortcuts
10 10
 
2  docs/topics/logging.txt
@@ -156,7 +156,7 @@ and handle logging calls on a per-module basis. However, if you have
156 156
 some other way of organizing your logging messages, you can provide
157 157
 any dot-separated name to identify your logger::
158 158
 
159  
-    # Get an instance of a specfic named logger
  159
+    # Get an instance of a specific named logger
160 160
     logger = logging.getLogger('project.interesting.stuff')
161 161
 
162 162
 The dotted paths of logger names define a hierarchy. The
2  docs/topics/signals.txt
@@ -106,7 +106,7 @@ must be able to handle those new arguments.
106 106
 Connecting receiver functions
107 107
 -----------------------------
108 108
 
109  
-There are two ways you can connect a receiever to a signal. You can take the
  109
+There are two ways you can connect a receiver to a signal. You can take the
110 110
 manual connect route:
111 111
 
112 112
 .. code-block:: python
2  docs/topics/testing.txt
@@ -95,7 +95,7 @@ module defines tests in class-based approach.
95 95
 
96 96
         import unittest
97 97
 
98  
-    If you want to continue to use the base unittest libary, you can --
  98
+    If you want to continue to use the base unittest library, you can --
99 99
     you just won't get any of the nice new unittest2 features.
100 100
 
101 101
 .. _unittest2: http://pypi.python.org/pypi/unittest2

0 notes on commit 5ecb88c

Please sign in to comment.
Something went wrong with that request. Please try again.