Documentation (and some small source code) edits from [17432] - [17537]

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17540 bcc190cf-cafb-0310-a4f2-bffc1f526a37

3 files changed, 10 insertions, 11 deletions

diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index e0fc2cc930..f3e27ae1f0 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -440,7 +440,7 @@ Including other URLconfs
 At any point, your ``urlpatterns`` can "include" other URLconf modules. This
 essentially "roots" a set of URLs below other ones.
 
-For example, here's an except of the URLconf for the `Django Web site`_
+For example, here's an excerpt of the URLconf for the `Django Web site`_
 itself. It includes a number of other URLconfs::
 
     from django.conf.urls import patterns, url, include
@@ -849,7 +849,7 @@ This ``current_app`` argument is used as a hint to resolve application
 namespaces into URLs on specific application instances, according to the
 :ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`.
 
-You can use ``kwargs`` instead of ``args``, for example::
+You can use ``kwargs`` instead of ``args``. For example::
 
     >>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
     '/admin/auth/'
@@ -976,7 +976,7 @@ A :class:`ResolverMatch` object can also be assigned to a triple::
     information it provides) is not available in earlier Django releases.
 
 One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
-if a view would raise a ``Http404`` error before redirecting to it::
+whether a view would raise a ``Http404`` error before redirecting to it::
 
     from urlparse import urlparse
     from django.core.urlresolvers import resolve
diff --git a/docs/topics/i18n/formatting.txt b/docs/topics/i18n/formatting.txt
index 531e6c0b7c..fa7da5d38e 100644
--- a/docs/topics/i18n/formatting.txt
+++ b/docs/topics/i18n/formatting.txt
@@ -186,16 +186,15 @@ instead of the default for English, a comma.
 Limitations of the provided locale formats
 ==========================================
 
-Some locales use context-sensitive formats for numbers, which Djangos
+Some locales use context-sensitive formats for numbers, which Django's
 localization system cannot handle automatically.
 
-
 Switzerland (German)
 --------------------
 
 The Swiss number formatting depends on the type of number that is being
 formatted. For monetary values, a comma is used as the thousand separator and
-a decimal point for the decimal separator, for all other numbers, a comma is
+a decimal point for the decimal separator. For all other numbers, a comma is
 used as decimal separator and a space as thousand separator. The locale format
 provided by Django uses the generic separators, a comma for decimal and a space
 for thousand separators.
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index e8006a2ad3..ed4b2d4b89 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -297,7 +297,7 @@ Lazy translation
 Use the lazy versions of translation functions in
 :mod:`django.utils.translation` (easily recognizable by the ``lazy`` suffix in
 their names) to translate strings lazily -- when the value is accessed rather
-than when they are called.
+than when they're called.
 
 These functions store a lazy reference to the string -- not the actual
 translation. The translation itself will be done when the string is used in a
@@ -306,10 +306,10 @@ string context, such as in template rendering.
 This is essential when calls to these functions are located in code paths that
 are executed at module load time.
 
-As this is something that can easily happen when defining models, forms and
-model forms (the declarative notation Django offers for them is implemented in a
-way such that their fields are actually class level attributes) this means you
-need to make sure to use lazy translations in the following cases:
+This is something that can easily happen when defining models, forms and
+model forms, because Django implements these such that their fields are
+actually class-level attributes. For that reason, make sure to use lazy
+translations in the following cases:
 
 Model fields and relationships ``verbose_name`` and ``help_text`` option values
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~