Depending on where in the order of operations things are at, it's possible to hit the error page before anything loads the template's language files. And JDocumentError isn't loading them either, which can cause untranslated strings to appear. So, load the files if we are able to do so (i.e. a JLanguage object is set to the factory; we won't try to load JLanguage into the factory in case that's the cause of the error).
Testing Instructions
Find a template with language strings in its error page; the core templates have this. For the frontend app, add a throw new RuntimeException('Testing language PR'); line in to JApplicationSite::doExecute() after it's called the initialiseApp() method. Pre-patch, it may or may not have translated strings (I couldn't duplicate this consistently locally but we hit it on the volunteers portal). Post-patch, it should most likely be translated (it only wouldn't if the error triggering the error page came from instantiating JLanguage basically).
I have tested this item✅ successfully on e9b7dc1
Tested with protostar and isis templates
e.g. adding to file:
administrator/templates/isis/error.php
a template language string fron: administrator/templates/isis/language/en-GB/en-GB.tpl_isis.ini
it gets translated after applying the PR
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11676.