Corrected multiply defined labels in docs.

docs/releases/1.2.txt

@@ -16,32 +16,28 @@ Overview
 
 Django 1.2 introduces several large, important new features, including:
 
-* Support for `multiple database connections`_ in a single Django instance.
+* Support for :ref:`multiple database connections
+  <support-for-multiple-databases>` in a single Django instance.
 
 * `Model validation`_ inspired by Django's form validation.
 
-* Vastly `improved protection against Cross-Site Request Forgery`_ (CSRF).
+* Vastly :ref:`improved protection against Cross-Site Request Forgery
+  <improved-csrf-protection>` (CSRF).
 
-* A new `user "messages" framework`_ with support for cookie- and session-based
+* A new :ref:`user "messages" framework <messages-framework>` with support for
-  message for both anonymous and authenticated users.
+  cookie- and session-based message for both anonymous and authenticated users.
 
 * Hooks for `object-level permissions`_, `permissions for anonymous users`_,
-  and `more flexible username requirements`_.
+  and :ref:`more flexible username requirements
+  <relaxed-requirements-for-usernames>`.
 
 * Customization of email sending via `email backends`_.
 
 * New :ref:`"smart" if template tag <new-in-1.2-smart-if>` which supports
   comparison operators.
 
-.. _multiple database connections: `support for multiple databases`_
+These are just the highlights; full details and a complete list of features
-.. _improved protection against Cross-Site Request Forgery: `improved CSRF protection`_
+:ref:`may be found below <whats-new-1.2>`.
-.. _user "messages" framework: `messages framework`_
-.. _more flexible username requirements: `relaxed requirements for usernames`_
-
-These are just the highlights; full details and a complete list of features `may
-be found below`_.
-
-.. _may be found below: `What's new in Django 1.2`_
 
 .. seealso::
 
@@ -80,9 +76,8 @@ backwards-incompatible. The big changes are:
   :func:`~django.contrib.auth.decorators.login_required`, and
   :func:`~django.contrib.auth.decorators.permission_required`, decorators
   from :mod:`django.contrib.auth` only apply to functions and no longer
-  work on methods. There's a simple one-line fix `detailed below`_.
+  work on methods. There's a simple one-line fix :ref:`detailed below
-
+  <user-passes-test-login-required-permission-required>`.
-.. _detailed below: `user_passes_test, login_required and permission_required`_
 
 Again, these are just the big features that will affect the most users. Users
 upgrading from previous versions of Django are heavily encouraged to consult
@@ -118,6 +113,8 @@ announced prior to the release of Django 1.3.
 What's new in Django 1.2
 ========================
 
+.. _support-for-multiple-databases:
+
 Support for multiple databases
 ------------------------------
 
@@ -137,6 +134,8 @@ validation behavior. Note, however, that validation must still be performed
 explicitly. Simply invoking a model instance's ``save()`` method will not
 perform any validation of the instance's data.
 
+.. _improved-csrf-protection:
+
 Improved CSRF protection
 ------------------------
 
@@ -148,6 +147,8 @@ who visits the malicious site in their browser. A related type of attack, "login
 CSRF," where an attacking site tricks a user's browser into logging into a site
 with someone else's credentials, is also covered.
 
+.. _messages-framework:
+
 Messages framework
 ------------------
 
@@ -177,6 +178,8 @@ can always delegate the question of whether something is allowed or not to
 the authorization/authentication backend. See the :doc:`authentication
 docs </topics/auth/index>` for more details.
 
+.. _relaxed-requirements-for-usernames:
+
 Relaxed requirements for usernames
 ----------------------------------
 
@@ -558,6 +561,8 @@ the state of the :ttag:`cycle` tag would leak between multiple
 renderings of the same :ttag:`include`. Now that the :ttag:`cycle` tag
 is thread safe, this leakage no longer occurs.
 
+.. _user-passes-test-login-required-permission-required:
+
 ``user_passes_test``, ``login_required`` and ``permission_required``
 --------------------------------------------------------------------
 

docs/topics/signals.txt

@@ -87,15 +87,13 @@ function or method::
 Notice that the function takes a ``sender`` argument, along with wildcard
 keyword arguments (``**kwargs``); all signal handlers must take these arguments.
 
-We'll look at senders `a bit later`_, but right now look at the ``**kwargs``
+We'll look at senders :ref:`a bit later <connecting-to-specific-signals>`, but
-argument. All signals send keyword arguments, and may change those keyword
+right now look at the ``**kwargs`` argument. All signals send keyword
-arguments at any time. In the case of
+arguments, and may change those keyword arguments at any time. In the case of
 :data:`~django.core.signals.request_finished`, it's documented as sending no
 arguments, which means we might be tempted to write our signal handling as
 ``my_callback(sender)``.
 
-.. _a bit later: `connecting to signals sent by specific senders`_
-
 This would be wrong -- in fact, Django will throw an error if you do so. That's
 because at any point arguments could get added to the signal and your receiver
 must be able to handle those new arguments.

docs/topics/templates.txt

@@ -261,11 +261,11 @@ backend with different options. In that case you should define a unique
 
 :setting:`OPTIONS <TEMPLATES-OPTIONS>` contains backend-specific settings.
 
+.. _template-loading:
+
 Usage
 -----
 
-.. _template-loading:
-
 .. module:: django.template.loader
 
 The ``django.template.loader`` module defines two functions to load templates.