[1.2.X] Fixed #14842 - Indent the model Meta options. Thanks adamv.

Backport of r15110 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@15111 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/ref/models/options.txt

@@ -3,8 +3,8 @@ Model ``Meta`` options
 ======================
 
 This document explains all the possible :ref:`metadata options
-<meta-options>` that you can give your model in its internal ``class
-Meta``.
+<meta-options>` that you can give your model in its internal
+``class Meta``.
 
 Available ``Meta`` options
 ==========================
@@ -16,16 +16,17 @@ Available ``Meta`` options
 
 .. attribute:: Options.abstract
 
-If ``True``, this model will be an :ref:`abstract base class <abstract-base-classes>`.
+    If ``abstract = True``, this model will be an
+    :ref:`abstract base class <abstract-base-classes>`.
 
 ``app_label``
 -------------
 
 .. attribute:: Options.app_label
 
-If a model exists outside of the standard :file:`models.py` (for instance, if
-the app's models are in submodules of ``myapp.models``), the model must define
-which app it is part of::
+    If a model exists outside of the standard :file:`models.py` (for instance,
+    if the app's models are in submodules of ``myapp.models``), the model must
+    define which app it is part of::
 
         app_label = 'myapp'
 
@@ -46,8 +47,8 @@ Table names
 To save you time, Django automatically derives the name of the database table
 from the name of your model class and the app that contains it. A model's
 database table name is constructed by joining the model's "app label" -- the
-name you used in ``manage.py startapp`` -- to the model's class name, with an
-underscore between them.
+name you used in :djadmin:`manage.py startapp <startapp>` -- to the model's
+class name, with an underscore between them.
 
 For example, if you have an app ``bookstore`` (as created by
 ``manage.py startapp bookstore``), a model defined as ``class Book`` will have
@@ -65,16 +66,16 @@ Django quotes column and table names behind the scenes.
 
 .. attribute:: Options.db_tablespace
 
-The name of the database tablespace to use for the model. If the backend doesn't
-support tablespaces, this option is ignored.
+    The name of the database tablespace to use for the model. If the backend
+    doesn't support tablespaces, this option is ignored.
 
 ``get_latest_by``
 -----------------
 
 .. attribute:: Options.get_latest_by
 
-The name of a :class:`DateField` or :class:`DateTimeField` in the model. This
-specifies the default field to use in your model :class:`Manager`'s
+    The name of a :class:`DateField` or :class:`DateTimeField` in the model.
+    This specifies the default field to use in your model :class:`Manager`'s
     :class:`~QuerySet.latest` method.
 
     Example::
@@ -84,7 +85,7 @@ Example::
     See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
 
 ``managed``
------------------------
+-----------
 
 .. attribute:: Options.managed
 
@@ -97,7 +98,7 @@ management command. That is, Django *manages* the database tables' lifecycles.
     If ``False``, no database table creation or deletion operations will be
     performed for this model. This is useful if the model represents an existing
     table or a database view that has been created by some other means. This is
-the *only* difference when ``managed`` is ``False``. All other aspects of
+    the *only* difference when ``managed=False``. All other aspects of
     model handling are exactly the same as normal. This includes
 
         1. Adding an automatic primary key field to the model if you don't declare
@@ -219,7 +220,7 @@ human_readable_permission_name)``.
 
     .. versionadded:: 1.1
 
-If set to ``True``, a model which subclasses another model will be treated as
+    If ``proxy = True``, a model which subclasses another model will be treated as
     a :ref:`proxy model <proxy-models>`.
 
 ``unique_together``