[19:56:57] taavi: (If you are online) Where is T363074 showing up ? [19:56:58] T363074: Extension:Wikisource: ResourcesTest::testResourceFiles: HTTP request blocked: https://ocr.wmcloud.org/api/available_langs?engine=google - https://phabricator.wikimedia.org/T363074 [19:57:34] Sohom_Datta: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/1022326 [19:57:41] The code behind it has been around for a while https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/971235 [19:58:20] i would guess that it's some core change that broke the test [19:58:58] maybe https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1003101? [19:59:37] Yeah that's probably the culprit, I'll try to do a bisect [20:02:00] thanks! [21:12:39] It does appear to be that commit based on a bisect :) [21:15:22] The Wikisource module has `"skipStructureTest": true` but I don't think that's being respected by the function ? [21:31:27] I wonder if extending `"skipStructureTest": true` to cover this test as well is a good idea [21:36:29] Tbh the Wikisource module is a bit um unique. I wonder if there is a better way to load a JSON config from a remote server as part of the JS ? [21:37:48] To rephrase the question, is there a better way we could have implemented https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/971235 ? [21:38:01] i guess my first question is 'why are we loading JSON config from a remote server as a part of the JS'? [21:45:29] taavi: The OCR tool has a list of languages that it supports at https://ocr.wmcloud.org/api/available_langs?engine=transkribus and we need to load that list into the JS file that then allows the editor to select a language and send a OCR request [21:45:49] Actually now that I come to think of it, why don't we load it dynamically ? [21:45:59] Through a HTTP request [21:46:16] *dynamically client-side