Author: carljm
Date: 2011-09-16 11:06:42 -0700 (Fri, 16 Sep 2011)
New Revision: 16842

Modified:
   django/trunk/docs/howto/custom-model-fields.txt
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/ref/templates/api.txt
   django/trunk/docs/topics/http/middleware.txt
   django/trunk/docs/topics/i18n/localization.txt
Log:
Fixed #16863 -- Corrected ReST markup to avoid errors building docs.

Although directives such as "note" and "warning" will accept content
immediately following the directive, this is technically where arguments to the
directive should go (see http://sphinx.pocoo.org/rest.html#directives). Putting
the content there means that any lines beginning with an inline text role
(e.g. ":setting:`DEBUG`") will be mis-interpreted as an option block for the
directive. To avoid this error, there should always be a blank line between the
directive start and the directive content.

Modified: django/trunk/docs/howto/custom-model-fields.txt
===================================================================
--- django/trunk/docs/howto/custom-model-fields.txt     2011-09-16 17:07:19 UTC 
(rev 16841)
+++ django/trunk/docs/howto/custom-model-fields.txt     2011-09-16 18:06:42 UTC 
(rev 16842)
@@ -177,6 +177,7 @@
 card values plus their suits; 104 characters in total.
 
 .. note::
+
     Many of Django's model fields accept options that they don't do anything
     with. For example, you can pass both
     :attr:`~django.db.models.Field.editable` and
@@ -189,8 +190,8 @@
     This behavior simplifies the field classes, because they don't need to
     check for options that aren't necessary. They just pass all the options to
     the parent class and then don't use them later on. It's up to you whether
-    you want your fields to be more strict about the options they select, or
-    to use the simpler, more permissive behavior of the current fields.
+    you want your fields to be more strict about the options they select, or to
+    use the simpler, more permissive behavior of the current fields.
 
 .. method:: Field.__init__
 

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===================================================================
--- django/trunk/docs/ref/contrib/admin/index.txt       2011-09-16 17:07:19 UTC 
(rev 16841)
+++ django/trunk/docs/ref/contrib/admin/index.txt       2011-09-16 18:06:42 UTC 
(rev 16842)
@@ -1895,12 +1895,13 @@
 a pattern for your new view.
 
 .. note::
+
     Any view you render that uses the admin templates, or extends the base
     admin template, should provide the ``current_app`` argument to
-    :class:`~django.template.RequestContext` or 
:class:`~django.template.Context`
-    when rendering the template.  It should be set to either ``self.name`` if
-    your view is on an ``AdminSite`` or ``self.admin_site.name`` if your view
-    is on a ``ModelAdmin``.
+    :class:`~django.template.RequestContext` or
+    :class:`~django.template.Context` when rendering the template.  It should
+    be set to either ``self.name`` if your view is on an ``AdminSite`` or
+    ``self.admin_site.name`` if your view is on a ``ModelAdmin``.
 
 .. _admin-reverse-urls:
 

Modified: django/trunk/docs/ref/settings.txt
===================================================================
--- django/trunk/docs/ref/settings.txt  2011-09-16 17:07:19 UTC (rev 16841)
+++ django/trunk/docs/ref/settings.txt  2011-09-16 18:06:42 UTC (rev 16842)
@@ -1765,11 +1765,13 @@
 files into this directory. See the howto on :doc:`managing static
 files</howto/static-files>` for more details about usage.
 
-.. warning:: This should be an (initially empty) destination directory for
-    collecting your static files from their permanent locations into one
-    directory for ease of deployment; it is **not** a place to store your
-    static files permanently. You should do that in directories that will be
-    found by :doc:`staticfiles</ref/contrib/staticfiles>`'s
+.. warning::
+
+    This should be an (initially empty) destination directory for collecting
+    your static files from their permanent locations into one directory for
+    ease of deployment; it is **not** a place to store your static files
+    permanently. You should do that in directories that will be found by
+    :doc:`staticfiles</ref/contrib/staticfiles>`'s
     :setting:`finders<STATICFILES_FINDERS>`, which by default, are
     ``'static/'`` app sub-directories and any directories you include in
     :setting:`STATICFILES_DIRS`).
@@ -2059,10 +2061,10 @@
 See also :setting:`USE_I18N` and :setting:`LANGUAGE_CODE`
 
 .. note::
-    The default :file:`settings.py` file created by
-    :djadmin:`django-admin.py startproject <startproject>` includes
-    ``USE_L10N = True`` for convenience.
 
+    The default :file:`settings.py` file created by :djadmin:`django-admin.py
+    startproject <startproject>` includes ``USE_L10N = True`` for convenience.
+
 .. setting:: USE_THOUSAND_SEPARATOR
 
 USE_THOUSAND_SEPARATOR

Modified: django/trunk/docs/ref/templates/api.txt
===================================================================
--- django/trunk/docs/ref/templates/api.txt     2011-09-16 17:07:19 UTC (rev 
16841)
+++ django/trunk/docs/ref/templates/api.txt     2011-09-16 18:06:42 UTC (rev 
16842)
@@ -404,11 +404,12 @@
         return HttpResponse(t.render(c))
 
 .. note::
+
     If you're using Django's :func:`~django.shortcuts.render_to_response()`
     shortcut to populate a template with the contents of a dictionary, your
     template will be passed a ``Context`` instance by default (not a
-    ``RequestContext``). To use a ``RequestContext`` in your template 
rendering,
-    pass an optional third argument to
+    ``RequestContext``). To use a ``RequestContext`` in your template
+    rendering, pass an optional third argument to
     :func:`~django.shortcuts.render_to_response()`: a ``RequestContext``
     instance. Your code might look like this::
 
@@ -704,13 +705,14 @@
         )
 
     .. note::
-        All of the built-in Django template tags are safe to use with the 
cached
-        loader, but if you're using custom template tags that come from third
-        party packages, or that you wrote yourself, you should ensure that the
-        ``Node`` implementation for each tag is thread-safe. For more
-        information, see
-        :ref:`template tag thread safety 
considerations<template_tag_thread_safety>`.
 
+        All of the built-in Django template tags are safe to use with the
+        cached loader, but if you're using custom template tags that come from
+        third party packages, or that you wrote yourself, you should ensure
+        that the ``Node`` implementation for each tag is thread-safe. For more
+        information, see :ref:`template tag thread safety
+        considerations<template_tag_thread_safety>`.
+
     This loader is disabled by default.
 
 Django uses the template loaders in order according to the

Modified: django/trunk/docs/topics/http/middleware.txt
===================================================================
--- django/trunk/docs/topics/http/middleware.txt        2011-09-16 17:07:19 UTC 
(rev 16841)
+++ django/trunk/docs/topics/http/middleware.txt        2011-09-16 18:06:42 UTC 
(rev 16842)
@@ -98,14 +98,14 @@
 middleware is always called on every response.
 
 .. note::
-    Accessing :attr:`request.POST <django.http.HttpRequest.POST>` or 
-    :attr:`request.REQUEST <django.http.HttpRequest.REQUEST>` inside 
-    middleware from ``process_request`` or ``process_view`` will prevent any
-    view running after the middleware from being able to
-    :ref:`modify the upload handlers for the 
-    request <modifying_upload_handlers_on_the_fly>`, and should normally be
-    avoided.
 
+    Accessing :attr:`request.POST <django.http.HttpRequest.POST>` or
+    :attr:`request.REQUEST <django.http.HttpRequest.REQUEST>` inside middleware
+    from ``process_request`` or ``process_view`` will prevent any view running
+    after the middleware from being able to :ref:`modify the upload handlers
+    for the request <modifying_upload_handlers_on_the_fly>`, and should
+    normally be avoided.
+
     The :class:`~django.middleware.csrf.CsrfViewMiddleware` class can be
     considered an exception, as it provides the
     :func:`~django.views.decorators.csrf.csrf_exempt` and

Modified: django/trunk/docs/topics/i18n/localization.txt
===================================================================
--- django/trunk/docs/topics/i18n/localization.txt      2011-09-16 17:07:19 UTC 
(rev 16841)
+++ django/trunk/docs/topics/i18n/localization.txt      2011-09-16 18:06:42 UTC 
(rev 16842)
@@ -260,10 +260,11 @@
 necessary to set :setting:`USE_L10N = True <USE_L10N>` in your settings file.
 
 .. note::
-    The default :file:`settings.py` file created by
-    :djadmin:`django-admin.py startproject <startproject>` includes
-    :setting:`USE_L10N = True <USE_L10N>` for convenience.
 
+    The default :file:`settings.py` file created by :djadmin:`django-admin.py
+    startproject <startproject>` includes :setting:`USE_L10N = True <USE_L10N>`
+    for convenience.
+
 When using Django's formatting system, dates and numbers on templates will be
 displayed using the format specified for the current locale. Two users
 accessing the same content, but in different language, will see date and

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to