[1.5.x] Fixed #19516 - Fixed remaining broken links.

Added -n to sphinx builds to catch issues going forward.

Backport of 9b5f64cc6e from master.

2 files changed, 5 insertions, 7 deletions

diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 310dcb5ae6..6cc174a248 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -24,9 +24,8 @@ return model instances:
 .. method:: Manager.raw(raw_query, params=None, translations=None)
 
 This method method takes a raw SQL query, executes it, and returns a
-:class:`~django.db.models.query.RawQuerySet` instance. This
-:class:`~django.db.models.query.RawQuerySet` instance can be iterated
-over just like an normal QuerySet to provide object instances.
+``django.db.models.query.RawQuerySet`` instance. This ``RawQuerySet`` instance
+can be iterated over just like an normal QuerySet to provide object instances.
 
 This is best illustrated with an example. Suppose you've got the following model::
 
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index e3c2cadf6d..d9b846bbf0 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -48,10 +48,9 @@ you use the session middleware after the transaction middleware, session
 creation will be part of the transaction.
 
 The various cache middlewares are an exception:
-:class:`~django.middleware.cache.CacheMiddleware`,
-:class:`~django.middleware.cache.UpdateCacheMiddleware`, and
-:class:`~django.middleware.cache.FetchFromCacheMiddleware` are never affected.
-Even when using database caching, Django's cache backend uses its own
+``CacheMiddleware``, :class:`~django.middleware.cache.UpdateCacheMiddleware`,
+and :class:`~django.middleware.cache.FetchFromCacheMiddleware` are never
+affected. Even when using database caching, Django's cache backend uses its own
 database cursor (which is mapped to its own database connection internally).
 
 .. note::