Fixed #2769 -- Applied some ReST formatting fixes. Thanks, ramiro.

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

AUTHORS

@@ -122,6 +122,7 @@ answer newbie questions, and generally made Django that much better:
     Daniel Poelzleithner <http://poelzi.org/>
     J. Rademaker
     Michael Radziej <mir@noris.de>
+    ramiro
     Brian Ray <http://brianray.chipy.org/>
     rhettg@gmail.com
     Oliver Rutherfurd <http://rutherfurd.net/>

docs/db-api.txt

@@ -1511,7 +1511,7 @@ Many-to-many relationships
 --------------------------
 
 Both ends of a many-to-many relationship get automatic API access to the other
-end. The API works just as a "backward" one-to-many relationship. See _Backward
+end. The API works just as a "backward" one-to-many relationship. See Backward_
 above.
 
 The only difference is in the attribute naming: The model that defines the

docs/forms.txt

@@ -136,7 +136,7 @@ template::
     {% endblock %}
 
 Before we get back to the problems with these naive set of views, let's go over
-some salient points of the above template::
+some salient points of the above template:
 
     * Field "widgets" are handled for you: ``{{ form.field }}`` automatically
       creates the "right" type of widget for the form, as you can see with the
@@ -148,8 +148,8 @@ some salient points of the above template::
       If you must use tables, use tables. If you're a semantic purist, you can
       probably find better HTML than in the above template.
 
-    * To avoid name conflicts, the ``id``s of form elements take the form
-      "id_*fieldname*".
+    * To avoid name conflicts, the ``id`` values of form elements take the
+      form "id_*fieldname*".
 
 By creating a creation form we've solved problem number 3 above, but we still
 don't have any validation. Let's revise the validation issue by writing a new