Link django docs to stable version

docs/advanced_topics/i18n.md

@@ -27,7 +27,7 @@ There are two options for managing translations across different languages in th
 
 This document only covers the internationalisation of content managed by Wagtail.
 For information on how to translate static content in template files, JavaScript
-code, etc, refer to the [Django internationalisation docs](https://docs.djangoproject.com/en/3.1/topics/i18n/translation/).
+code, etc, refer to the [Django internationalisation docs](https://docs.djangoproject.com/en/stable/topics/i18n/translation/).
 Or, if you are building a headless site, refer to the docs of the frontend framework you are using.
 
 ### Wagtail's approach to multi-lingual content
@@ -241,7 +241,7 @@ To allow all of the page trees to be served at the same domain, we need
 to add a URL prefix for each language.
 
 To implement this, we can use Django's built-in
-[i18n_patterns](https://docs.djangoproject.com/en/3.1/topics/i18n/translation/#language-prefix-in-url-patterns)
+[i18n_patterns](https://docs.djangoproject.com/en/stable/topics/i18n/translation/#language-prefix-in-url-patterns)
 function, which adds a language prefix to all of the URL patterns passed into it.
 This activates the language code specified in the URL and Wagtail takes this into
 account when it decides how to route the request.
@@ -408,7 +408,7 @@ This `for` block iterates through all published translations of the current page
 ```
 
 This is a Django built-in tag that gets info about the language of the translation.
-For more information, see [get_language_info() in the Django docs](https://docs.djangoproject.com/en/3.1/topics/i18n/translation/#django.utils.translation.get_language_info).
+For more information, see [get_language_info() in the Django docs](https://docs.djangoproject.com/en/stable/topics/i18n/translation/#django.utils.translation.get_language_info).
 
 ```html+django
 <a href="{% pageurl translation %}" rel="alternate" hreflang="{{ language_code }}">
@@ -427,7 +427,7 @@ languages and finds the page for each one. This works better than the [Basic exa
 above on sites that have extra Django `LANGUAGES` that share the same Wagtail content.
 
 For this example to work, you firstly need to add Django's
-[django.template.context_processors.i18n](https://docs.djangoproject.com/en/3.1/ref/templates/api/#django-template-context-processors-i18n)
+[django.template.context_processors.i18n](https://docs.djangoproject.com/en/stable/ref/templates/api/#django-template-context-processors-i18n)
 context processor to your `TEMPLATES` setting:
 
 ```python

docs/advanced_topics/images/feature_detection.md

@@ -84,7 +84,7 @@ import rustface.willow
 registry.register_plugin(rustface.willow)
 ```
 
-For example, in an app's [AppConfig.ready](https://docs.djangoproject.com/en/2.2/ref/applications/#django.apps.AppConfig.ready).
+For example, in an app's [AppConfig.ready](https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.ready).
 
 ## Cropping
 

docs/getting_started/tutorial.md

@@ -200,7 +200,7 @@ Edit `home/templates/home/home_page.html` to contain the following:
 
 ### Wagtail template tags
 
-In addition to Django's [template tags and filters](https://docs.djangoproject.com/en/3.1/ref/templates/builtins/),
+In addition to Django's [template tags and filters](https://docs.djangoproject.com/en/stable/ref/templates/builtins/),
 Wagtail provides a number of its own [template tags & filters](template_tags_and_filters)
 which can be loaded by including `{% load wagtailcore_tags %}` at the top of
 your template file.

docs/reference/contrib/forms/index.md

@@ -58,7 +58,7 @@ class FormPage(AbstractEmailForm):
 
 `AbstractEmailForm` defines the fields `to_address`, `from_address` and `subject`, and expects `form_fields` to be defined. Any additional fields are treated as ordinary page content - note that `FormPage` is responsible for serving both the form page itself and the landing page after submission, so the model definition should include all necessary content fields for both of those views.
 
-Date and datetime values in a form response will be formatted with the [SHORT_DATE_FORMAT](https://docs.djangoproject.com/en/3.0/ref/settings/#short-date-format) and [SHORT_DATETIME_FORMAT](https://docs.djangoproject.com/en/3.0/ref/settings/#short-datetime-format) respectively. (see [](form_builder_render_email) for how to customise the email content).
+Date and datetime values in a form response will be formatted with the [SHORT_DATE_FORMAT](https://docs.djangoproject.com/en/stable/ref/settings/#short-date-format) and [SHORT_DATETIME_FORMAT](https://docs.djangoproject.com/en/stable/ref/settings/#short-datetime-format) respectively. (see [](form_builder_render_email) for how to customise the email content).
 
 If you do not want your form page type to offer form-to-email functionality, you can inherit from AbstractForm instead of `AbstractEmailForm`, and omit the `to_address`, `from_address` and `subject` fields from the `content_panels` definition.
 

docs/topics/pages.md

@@ -384,7 +384,7 @@ The first argument must match the value of the `related_name` attribute of the `
 
 ## Working with pages
 
-Wagtail uses Django's [multi-table inheritance](https://docs.djangoproject.com/en/3.1/topics/db/models/#multi-table-inheritance) feature to allow multiple page models to be used in the same tree.
+Wagtail uses Django's [multi-table inheritance](https://docs.djangoproject.com/en/stable/topics/db/models/#multi-table-inheritance) feature to allow multiple page models to be used in the same tree.
 
 Each page is added to both Wagtail's built-in {class}`~wagtail.models.Page` model as well as its user-defined model (such as the `BlogPage` model created earlier).