Fixed #35233 -- Moved template engine system checks to backend methods.

Thanks Adam Johnson for reviews.

docs/ref/checks.txt

@@ -575,7 +575,9 @@ configured:
 
 * **templates.E001**: You have ``'APP_DIRS': True`` in your
   :setting:`TEMPLATES` but also specify ``'loaders'`` in ``OPTIONS``. Either
-  remove ``APP_DIRS`` or remove the ``'loaders'`` option.
+  remove ``APP_DIRS`` or remove the ``'loaders'`` option. *This check is
+  removed in Django 5.1 as system checks may now raise*
+  ``ImproperlyConfigured`` *instead.*
 * **templates.E002**: ``string_if_invalid`` in :setting:`TEMPLATES`
   :setting:`OPTIONS <TEMPLATES-OPTIONS>` must be a string but got: ``{value}``
   (``{type}``).

docs/releases/5.1.txt

@@ -307,6 +307,9 @@ Templates
   example, to generate a link to the next page while keeping any filtering
   options in place.
 
+* :ref:`Template engines <field-checking>` now implement a ``check()`` method
+  that is already registered with the check framework.
+
 Tests
 ~~~~~
 

docs/topics/checks.txt

@@ -130,18 +130,18 @@ The code below is equivalent to the code above::
 
 .. _field-checking:
 
-Field, model, manager, and database checks
-------------------------------------------
+Field, model, manager, template engine, and database checks
+-----------------------------------------------------------
 
 In some cases, you won't need to register your check function -- you can
 piggyback on an existing registration.
 
-Fields, models, model managers, and database backends all implement a
-``check()`` method that is already registered with the check framework. If you
-want to add extra checks, you can extend the implementation on the base class,
-perform any extra checks you need, and append any messages to those generated
-by the base class. It's recommended that you delegate each check to separate
-methods.
+Fields, models, model managers, template engines, and database backends all
+implement a ``check()`` method that is already registered with the check
+framework. If you want to add extra checks, you can extend the implementation
+on the base class, perform any extra checks you need, and append any messages
+to those generated by the base class. It's recommended that you delegate each
+check to separate methods.
 
 Consider an example where you are implementing a custom field named
 ``RangedIntegerField``. This field adds ``min`` and ``max`` arguments to the
@@ -195,6 +195,10 @@ the only difference is that the check is a classmethod, not an instance method::
             # ... your own checks ...
             return errors
 
+.. versionchanged:: 5.1
+
+    In older versions, template engines didn't implement a ``check()`` method.
+
 Writing tests
 -------------