[00:10:46] (03PS2) 10Aaron Schulz: Added $wgJobBackoffThrottling to replace wmf sleep() hack [core] - 10https://gerrit.wikimedia.org/r/103190 [00:13:03] (03CR) 10Aaron Schulz: "Made https://gerrit.wikimedia.org/r/#/c/103190/2 instead" [core] - 10https://gerrit.wikimedia.org/r/91858 (owner: 10Reedy) [00:15:29] (03PS3) 10Nikerabbit: Fix comment edited text for comments which have since been deleted [extensions/LiquidThreads] - 10https://gerrit.wikimedia.org/r/103187 (owner: 10Alex Monk) [00:15:41] (03CR) 10Nikerabbit: [C: 032] Fix comment edited text for comments which have since been deleted [extensions/LiquidThreads] - 10https://gerrit.wikimedia.org/r/103187 (owner: 10Alex Monk) [00:15:43] (03Merged) 10jenkins-bot: Fix comment edited text for comments which have since been deleted [extensions/LiquidThreads] - 10https://gerrit.wikimedia.org/r/103187 (owner: 10Alex Monk) [00:16:43] thanks Nikerabbit :) [00:17:19] Nemo_bis: pro tip: make sure that there is clear description of the issue to help the reviewer [00:19:18] Nikerabbit: this is an ideal we all strive to but hard to achieve :) [00:19:49] what's perfectly clear in our head turns into mud as soon as it exits it to go towards another head, very often [00:30:30] (03CR) 10Bartosz Dziewoński: "Well, and now I need to rebase this, because of how volatile the mediawiki.ui stuff is :/ Can we have it merged already before it's rewrit" [core] - 10https://gerrit.wikimedia.org/r/98589 (owner: 10Bartosz Dziewoński) [00:31:07] (03PS4) 10Bartosz Dziewoński: Refactor RL modules related to Special:Userlogin [core] - 10https://gerrit.wikimedia.org/r/98589 [00:31:17] (03CR) 10Ori.livneh: Change modal to use API instead of special page, refactor (032 comments) [extensions/GettingStarted] - 10https://gerrit.wikimedia.org/r/103079 (owner: 10Mattflaschen) [00:32:15] (03PS2) 10Ori.livneh: vector: Switch around regular and HD content padding [core] - 10https://gerrit.wikimedia.org/r/102703 (owner: 10Bartosz Dziewoński) [00:32:22] (03CR) 10Ori.livneh: [C: 032] vector: Switch around regular and HD content padding [core] - 10https://gerrit.wikimedia.org/r/102703 (owner: 10Bartosz Dziewoński) [00:36:19] (03CR) 10Bartosz Dziewoński: "Okay, I'll do this since it's apparently blocking merging (judging by lack of followup from you). I definitely disapprove of this, though." (031 comment) [core] - 10https://gerrit.wikimedia.org/r/98380 (owner: 10Bartosz Dziewoński) [00:38:18] (03Merged) 10jenkins-bot: vector: Switch around regular and HD content padding [core] - 10https://gerrit.wikimedia.org/r/102703 (owner: 10Bartosz Dziewoński) [00:39:29] (03PS6) 10Bartosz Dziewoński: JSDuck-ify /resources/mediawiki.language/* [core] - 10https://gerrit.wikimedia.org/r/98380 [00:44:06] (03CR) 10Ori.livneh: [C: 031] "Looks good and verified. Could you may make hidePasswordOnEmail an anonymous $( function () { ... } ) ? The function call from the event h" [core] - 10https://gerrit.wikimedia.org/r/98589 (owner: 10Bartosz Dziewoński) [00:44:08] you know, i'm starting to feel that the time necessary for review is inversely proportional to diff size. [00:46:38] (03CR) 10Bartosz Dziewoński: "Oh, I missed that. It was pretty silly, yeah." [core] - 10https://gerrit.wikimedia.org/r/98589 (owner: 10Bartosz Dziewoński) [00:46:40] (03PS5) 10Bartosz Dziewoński: Refactor RL modules related to Special:Userlogin [core] - 10https://gerrit.wikimedia.org/r/98589 [00:48:48] (03PS6) 10Ori.livneh: Refactor RL modules related to Special:Userlogin [core] - 10https://gerrit.wikimedia.org/r/98589 (owner: 10Bartosz Dziewoński) [00:48:53] (03CR) 10Ori.livneh: [C: 032] Refactor RL modules related to Special:Userlogin [core] - 10https://gerrit.wikimedia.org/r/98589 (owner: 10Bartosz Dziewoński) [00:49:52] ilu ori-l [00:53:56] (03Merged) 10jenkins-bot: Refactor RL modules related to Special:Userlogin [core] - 10https://gerrit.wikimedia.org/r/98589 (owner: 10Bartosz Dziewoński) [01:00:34] (03PS56) 10Physikerwelt: Math 2.0 [extensions/Math] - 10https://gerrit.wikimedia.org/r/85801 [01:01:52] (03PS1) 10Bartosz Dziewoński: Changes list legend modules cleanup [core] - 10https://gerrit.wikimedia.org/r/103197 [01:02:03] (03CR) 10Bartosz Dziewoński: "Cleanup follow-up: https://gerrit.wikimedia.org/r/103197" [core] - 10https://gerrit.wikimedia.org/r/101446 (owner: 10Bartosz Dziewoński) [01:05:44] (03CR) 10Physikerwelt: "@Frédéric: I did not found all the files you mentioned. Feel free to remove the files we don't need." [extensions/Math] - 10https://gerrit.wikimedia.org/r/85801 (owner: 10Physikerwelt) [02:55:20] (03PS5) 10Bartosz Dziewoński: Create ChangesListSpecialPage as a base class for Watchlist and RC [core] - 10https://gerrit.wikimedia.org/r/102458 [02:55:21] (03PS2) 10Bartosz Dziewoński: Changes list legend modules cleanup [core] - 10https://gerrit.wikimedia.org/r/103197 [02:55:22] (03PS1) 10Bartosz Dziewoński: ChangesListSpecialPage and subclasses: Reorder functions [core] - 10https://gerrit.wikimedia.org/r/103200 [02:56:52] (03CR) 10Aaron Schulz: [C: 04-2] Add sleep call to HTMLCacheUpdateJob update loop [core] - 10https://gerrit.wikimedia.org/r/91858 (owner: 10Reedy) [03:10:55] (03PS1) 10Aaron Schulz: Move BitmapHandler::canRotate() call out of Setup.php [core] - 10https://gerrit.wikimedia.org/r/103201 [03:12:19] (03CR) 10jenkins-bot: [V: 04-1] Move BitmapHandler::canRotate() call out of Setup.php [core] - 10https://gerrit.wikimedia.org/r/103201 (owner: 10Aaron Schulz) [03:55:31] i am sure ori-l is here somewhere... [03:55:55] * yurik is debating how to organize extension setup... [04:45:18] hi, yurik [04:45:27] hi ori [04:45:39] i'm debating how to set up jsonconfig configuration... [04:45:50] you might have some ideas :) [04:45:59] does anyone know how github -> gerrit patch management works these days? can i just merge ? [04:46:13] yurik: ok, though I have to admit I haven't read through your patch yet :/ [04:46:13] this is what i have now : https://www.mediawiki.org/wiki/Requests_for_comment/Json_Config_pages_in_wiki#Configuration [04:46:22] ori-l, patch is secondary [04:46:27] RFC has most of the info [04:46:53] i'm thinking of how to a) make it so that all configuration is self-hosting [04:47:12] in other words the config for pages should reside on a config page [04:47:34] and if its actually needed [04:47:45] * ori-l reads. [04:48:35] ori-l, start from https://www.mediawiki.org/wiki/Requests_for_comment/Json_Config_pages_in_wiki#General_Usage [04:48:41] better info [04:51:26] yurik: is there going to be a configuration namespace? [04:51:36] up to us how to set it up [04:51:47] the fact that you are using ':' twice to specify the path to a particular configuration object confuses me a little [04:51:51] the extension can work with multiple full namespaces as well as subnamespaces [04:52:31] ori-l, if we stay with meta, we will want to keep our configs away from everyone :) [04:52:33] i know that it's not what you're asking about now, but can we talk about it for a moment? [04:52:43] sure [04:53:07] i am invisioning this: config:myext for the most typical but individual configuratinos [04:53:29] so, i think i understand better why you're going that route: you don't want an explosion of namespaces, but at the same time, you want individual extensions to enjoy the possibility of having many different configuration objects [04:53:41] and it'd be good to delineate those from the configuration pages of other extensions [04:53:50] and config:proxy:opera, or config:zero:250-99 for when there are lots of them [04:53:52] yes [04:54:24] the problem is that subnamespaces aren't really a thing [04:54:40] if at some point in the future we decide to have a config site, we could of course migrate to individual namespaces... although that is still bad for just one page per extension [04:54:47] why's that? [04:54:53] its just a naming convention [04:54:57] right [04:55:11] they work well with other tools like api's prefix filtering [04:55:14] i think we should have a config site [04:55:35] ori-l, all this is fine, and can be achieved with various configurations :) [04:55:37] there's precedence for this (centralauth's loginwiki) [04:56:31] its up to us all to figure out how exactly to set it up. There are some reasons why it would be bad - 1) we would need a new SSL cert, and 2) we would need to convince all carriers to update their URL whitelisting [04:56:35] both suck :) [04:56:45] i dunno, part of me recoils from this mixing-up of naming topologies that have some existence in code and naming topologies that are convention only [04:56:54] it's like a javascript object with keys that have ':' in the name [04:57:31] hehe :) yes, i understand - but that's the best interim solution, and it is absolutely not mandatory - we can set up the system and than change ti [04:57:34] it [04:57:58] why would you need a new SSL cert? [04:58:12] doesn't SSL cert list all domains? [04:58:18] this would be yet another domain [04:58:29] we have *.wikimedia.org [04:58:39] do we have *.wikipedia ? [04:59:03] how come https://en.zero.wikipedia.org doesn't work? [04:59:23] yes [04:59:29] you tell me :) [04:59:47] hehe, probably because *. is different from *.*. [05:00:15] in any case, setting up a new domain is a long term goal, not current one [05:00:34] while now we have a config namespace on meta, and we have two existing namespaces to support - schema & zero [05:00:54] yeah, * is different from *.* [05:00:55] the extra support for sub-namespaces is just a few lines of code [05:00:59] up to us not to use it [05:02:46] ok, up to you. i share your aversion to solutions that involve lots of process and bureaucracy but i think it's cleaner and it might be worth doing it from the start [05:02:59] s/might be/is [05:03:10] hehe, but we are not setting anything up in stone [05:03:25] we can deploy it, and later decide to move it to a new domain - very easy process [05:03:50] why does it have to be en.zero, btw? [05:03:57] are zero configs wiki-specific? [05:04:04] i switch between storage backends tons of times - you simply change config on the local machine where to go to get data [05:04:09] no, global [05:04:31] here are my thoughts - the extension could allow both local and global storage [05:04:44] for some configs - they can be local, for other global [05:05:00] each config could be set to be stored here (locally), or somewhere else (remote) [05:05:32] access to local is via internal objects (Article->getContent), remote - via API [05:05:47] so now i'm a bit stuck on how best to describe all that [05:06:36] i have a global API url for all remotes... and it in theory could be used even on the system that is hosting them [05:06:37] what is the point of making it self-hosting, other it being intellectually neat? [05:07:00] because than you don't have to have configuration clones on all wikis [05:07:15] how so? [05:08:06] $wgJsonConfigs[] = array( ... ) -- sets up the configuration for a specific type of config page(s) [05:08:19] such as their naming schema, model, etc [05:08:35] that info would be needed on both host and consumer [05:09:05] consumer - so it knows how to convert Title::makeTitle( NS_CONFIG, 'Proxy:Opera' ); into an object [05:09:49] host - to know that any page that matches those settings need to have a specific model ID [05:10:39] let me re-read the RFC [05:10:42] this is pretty confusing [05:10:54] someone could even have a remote setup - where the hosting site is physically different net from consumer (this is at least useful for local debugging) [05:11:36] :( i was hoping to make it easy to understand. ori-l , if something is confusing in the RFC, please fix or tell me [05:16:42] yurik: would local configs be overriding cluster configs, or would cluster configs simply be more general? [05:16:53] ori-l, no overrides [05:17:01] i wasn't planning on that - too complex [05:17:28] or in other words - it could be up to the individual extensions [05:18:00] cluster config & local configs shouldn't collide in naming [05:18:16] i have had this patch staged for the last few months: https://gerrit.wikimedia.org/r/#/c/68941/ [05:19:12] which partially implements json refs: http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-00 [05:19:15] ori-l, not sure what it would do - is that a link to another page? [05:19:18] url? [05:19:26] or is it for json schema? [05:19:49] you basically specify that the current object extends or includes objects specified by URL reference rather than value [05:20:58] so instead of { person: { name: 'yurik', profession: 'developer' } } you have { person: { $ref: '/some/url' } } [05:21:20] yes, but that would be a feature of the individual content object, not the jsonconfig, right? [05:21:26] well, it's a means for specifying how local and remote content can be composed [05:22:30] yes, but this is about merging individual contents - my concern is not with merging, but rather with the enwiki having some configurations enwiki - specific, and hosted locally for extension A, and some - hosted on meta, used by all other sites (like for zero) [05:23:30] so you would specify two setting arrays - one which describes model='jc-zero', and the other - model='jc-extA' [05:24:01] and in their settings you would say that for zero you should go to the global storage (meta), whereas jc-extA pages are locally hosted in Config:extA for example [05:36:45] i think you should walk the reader of the RFC through a specific use-case [05:37:15] showing how the behavior of Zero needs to be derived from configuration data that is part local, part remote [05:37:33] ori-l, i don't plan to have part local and part remote zero config [05:37:54] i think a single extension should get all of its data from one source [05:38:04] but there will be multiple extensions [05:38:13] each could choose a local or remote storage [05:38:31] where would zero be getting its configs? [05:38:37] from meta [05:38:53] (or if we move them - from the central configwiki) [05:39:08] zero needs one global settings [05:39:18] ok, I get that now [05:39:34] sorry, not one - multiple pages of global settings [05:39:41] one per partner [05:39:41] yeah [05:39:50] same with proxies - one config per proxy [05:39:56] but they are also global [05:40:07] but if you have flagged revs extension, we could set it up as local [05:40:40] flagged revs extension settings would be stored locally [05:40:50] because each wiki wants them differently [05:40:54] what does the client wiki need from the config wiki, in the case of centralized config? [05:41:05] other than just the raw content of the remote config [05:41:22] well, client wiki needs to know how to find it [05:41:39] how to map a title object to a remote API call [05:42:05] it needs to know if it can pull that info from memcached [05:42:59] memcached would be the alternative path to get that info [05:43:05] instead of the remote API call [05:43:39] have you seen http://wardcunningham.github.io/ ? [05:44:00] i heard about it, haven't seen it yet [05:44:17] well, it's federated wikis that share json data [05:44:36] i'm not suggesting it's a perfect match or even a close match of the requirements of this extension [05:44:41] btw, it might be that its not worth keeping settings in a page of itself - because getting it from memcached is much slower [05:44:55] (03PS2) 10Aaron Schulz: Move BitmapHandler::canRotate() call out of Setup.php [core] - 10https://gerrit.wikimedia.org/r/103201 [05:44:57] i will take a loko - seems like lots of videos [05:45:01] but the issue with the RFC as i see it is that it somehow straddles several Big Questions [05:45:20] which are...? :) [05:45:38] federated wikis (cross-wiki content sharing) [05:45:56] mediawiki as generic versioned object store [05:46:30] and configuration-as-data on wiki [05:46:48] true, but i'm trying to solve it for a very limited scope (which i heard is the key to success) :) [05:47:05] my goal - shared configs across the cluster [05:47:13] with everything optimized towards that goal [05:47:36] if we can easily introduce something else - sure, we can do it, as long as the main goal is unaffected [05:48:05] for example - now that i thought about it, i think that non-localsettings configs for other configs is too slow [05:48:10] it might be wiser to just defer the cross-wiki config-sharing for now. this would come with the cost that the extension wouldn't work out of the box for either zero or EL [05:48:33] we'd have to inherit some ConfigPage title and override methods to make it retrieve a remote title [05:49:02] I'm working on this bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=30700 . I can't find which component of wikimedia I should edit. [05:49:41] ori-l, so far i had no issues with remote retrieval - the zero config is built on that, no issues so far [05:50:00] tinaj: Hmm, that's AcaWiki, which isn't really part of Wikimedia [05:50:06] its more with the settings that i was thinking of the best path... [05:50:33] ori-l, when you have a chance, please review the code (now that we can't do any depls for two weeks :))) [05:50:47] i hope it will explain better my idea [05:50:49] ok [05:51:06] thx! and i will think of how to make the setup easier [05:51:13] tinaj: The bug is probably in this extension: https://www.mediawiki.org/wiki/Extension:BibTexImport [05:51:18] but the fact that i've struggled so much to understand all the pieces should be alarming to you [05:51:30] bawolff: Yeah.But do you know where the repository is ? [05:51:46] i can be pretty slow, but still, i'm familiar with the context, and i still struggled quite a bit [05:51:46] huh, that page doesn't even have a link [05:51:59] ori-l, true, it should ... want to help with the RFC cleanup? :D [05:52:16] i was rereading it several times, looked simple enough [05:52:18] i'm having a hard time finishing up the ones i already committed to [05:52:27] RFCs? [05:52:31] yeah [05:52:35] tinaj: I think it might be an unreleased extension [05:53:00] bawolff: oh! [05:53:13] tinaj: Anyhow, Acawiki is pretty separate from us, so I don't really know [05:53:16] oki. ori-l , i think i will persue the minimalist path - i will make that extension just slightly more than the current zero functionality, and will deploy it site-wide [05:53:21] and migrate zero to it [05:53:27] basically this is a simple refactoring [05:53:39] tinaj: Try asking in #acawiki channel on irc, or on their mailing list http://acawiki.org/AcaWiki:Communications [05:53:40] later we can see if your schema can reuse those components [05:53:44] bawolff: what about this: https://bugzilla.wikimedia.org/show_bug.cgi?id=30700 [05:54:08] ori-l, what do you think? [05:54:16] bawolff: sorry i meant: http://www.mediawiki.org/wiki/Extension:Bibtex#Sites_Using_this_Extension [05:54:41] that's a different extension I think [05:54:56] tinaj: There was a time a while back where acawiki was going to work in closer cordination with WMF, that never really happened, but one of the results was they got a component in our bugzilla [05:55:25] tinaj: For the bug, you could try leaving a comment on it saying you're interested in helping out, and asking where the source is [05:55:26] bawolff: oh! [05:55:52] bawolff: ok. I'll do that. [05:56:30] Hmm, acawiki doesn't seem to be the most active of wikis now a days... http://acawiki.org/index.php?title=Special:RecentChanges&days=30&from= [05:58:14] oh acawiki [05:58:16] bawolff: hmm.. Anyway I'll leave a comment and see [05:58:25] such a decent idea [05:58:38] I love how mako and mlinksva did a bunch on there, but that's about it ;) [05:58:49] greg-g: That can describe most abandoned wikis :P [05:58:59] yep [05:59:08] just a soft spot in my heart for that one [05:59:38] if the WMF Education Program would focus on something other than 'pedias, that'd be a huge success [06:00:44] How will I reporduce this page in my local MW installation ? https://en.wikipedia.org/wiki/MediaWiki:Abusefilter-edit-lastmod-text [06:01:08] greg-g: How often does the WMF focus on something other than the 'pedias, ever? [06:01:34] tonythomas01: Install the AbuseFilter extension [06:02:13] tonythomas01: However what specificly are you trying to do, as I feel like that technically answers your question, but is not the answer you need [06:02:40] bawolff: I installed ! I was working on this https://bugzilla.wikimedia.org/show_bug.cgi?id=56267 [06:03:23] bawolff: touche [06:03:41] bawolff: I was just grumbling [06:03:48] yurik, hello [06:03:56] hi d [06:04:06] tonythomas01: You do realize that the message you linked is a different one from the one mentioned in the bug you linked [06:05:19] bawolff: oops. was working on 2 similar things . This is the one https://bugzilla.wikimedia.org/show_bug.cgi?id=51382 [06:05:24] greg-g: I'm very happy to see recently that more effort has been put towards commons. If the trend continues, maybe things like wikisource will eventually get love [06:05:30] bawolff: sorry [06:05:38] yurik, i made sections but by mistake i made four sections and as the course is made by you i dnt have a delete right. please delete the last section [06:05:38] tonythomas01: no worries [06:06:54] tonythomas01: If you installed abuse filter, it should be there. Did you install the latest version? [06:07:01] bawolff: happens [06:07:58] diwanship, why do you want to delete it? [06:08:03] its about modifications? [06:08:12] you can probably rename it [06:08:32] diwanship, deleted [06:08:37] tonythomas01: btw, to answer your question on that bug, I would suggest writing separate code to generate the link. Best to keep i18n messages as simple as possible [06:08:41] bawolff: don't get your hopes up ;) [06:09:04] * greg-g doesn't have his WMF hat on right now, btw ;) [06:09:39] lol, I imagine not. The WMF party line usually doesn't phrase it as "don't get your hopes up" ;) [06:10:19] (03PS1) 10Theopolisme: Clearer message for range blocks on CreateAccount [core] - 10https://gerrit.wikimedia.org/r/103204 [06:10:48] bawolff: so it would look similar to https://gerrit.wikimedia.org/r/#/c/87701/ right ? [06:10:55] greg-g: And I do understand the reasoning. Limited resources, makes sense to concentrate on bigger targets [06:12:04] tonythomas01_: yeah, I think so [06:12:34] bawolff: ok. I will try writing. :) [06:13:16] yurik thanks [06:13:17] greg-g: My hope in that area would be that one day WMF decides to make a small "sister project" team. Consisting of say 2-3 devs, who just go around fixing things/other small projects for sister projects that don't have any other resources dedicated to them [06:13:40] interesting [06:13:48] the sister project swat team [06:16:07] (03CR) 10Tinaj1234: "Are there any more changes to be made? Can anyone please review it?" [extensions/WikiEditor] - 10https://gerrit.wikimedia.org/r/94500 (owner: 10Tinaj1234) [06:23:14] (03PS1) 10Niharika29: Learning Gerrit! [test/mediawiki/extensions/examples] - 10https://gerrit.wikimedia.org/r/103205 [06:26:49] (03PS2) 10Niharika29: Learning Gerrit! [test/mediawiki/extensions/examples] - 10https://gerrit.wikimedia.org/r/103205 [06:31:14] (03CR) 10Kambiz Darabi: "I'd be happy if you could review the latest patchset again." [core] - 10https://gerrit.wikimedia.org/r/99162 (owner: 10Kambiz Darabi) [06:41:46] (03CR) 10Brian Wolff: Clearer message for range blocks on CreateAccount (031 comment) [core] - 10https://gerrit.wikimedia.org/r/103204 (owner: 10Theopolisme) [06:43:16] (03PS5) 10Kambiz Darabi: Allow MediaWiki class to be instantiated inside another PHP application [core] - 10https://gerrit.wikimedia.org/r/99162 [06:53:58] yurik, i have put the lesson plan on my userpage and also have added one more tutorial to it pls review it comment [06:54:37] this is the link [06:54:39] https://docs.google.com/document/d/1vLsowCkFqROERAluweKDji0TSM2KJmCm2FwbEZPNpHE/edit [06:54:42] (03PS2) 10Theopolisme: Clearer message for range blocks on CreateAccount [core] - 10https://gerrit.wikimedia.org/r/103204 [07:23:46] (03CR) 10Brian Wolff: Clearer message for range blocks on CreateAccount (031 comment) [core] - 10https://gerrit.wikimedia.org/r/103204 (owner: 10Theopolisme) [07:27:01] (03PS3) 10Theopolisme: Clearer message for range blocks on CreateAccount [core] - 10https://gerrit.wikimedia.org/r/103204 [07:27:18] bawolff: better? ;) [07:27:52] yep [07:33:24] (03CR) 10Brian Wolff: [C: 032] "looks good. Thanks" [core] - 10https://gerrit.wikimedia.org/r/103204 (owner: 10Theopolisme) [07:36:04] hey bawolff, can we talk for a moment about timedmediahandler? [07:36:11] Sure [07:36:18] (03Merged) 10jenkins-bot: Clearer message for range blocks on CreateAccount [core] - 10https://gerrit.wikimedia.org/r/103204 (owner: 10Theopolisme) [07:37:18] i'm probably about to embarrass myself by exposing the depth of my ignorance here [07:37:48] ori-l: The answer to your question is probably going to be, yes TMH does suck :) [07:38:28] but i'm basically a bit confused about why the functions that do the work that results in timedmediahandler HTML being present on the page can't also inject the RL modules [07:39:07] it feels a bit like we're hiding something in the bushes and then embarking on an expedition to go look for it [07:39:28] You mean why can't it inject on special pages? [07:39:44] yeah [07:40:17] Basically, the interface for injecting resource loader modules from a media handler really sucks [07:40:38] Currently the only way is this one method that gets called by the parser, which expects a parser object [07:40:50] On special pages there is no parser object to pass that method [07:42:39] So the only way currently to really do it would be for TimedMediaHandler to mess about with a global $wgOut object, which would be bad as people sometimes create thumbnails without actually outputting them on a page [07:42:54] I think the solution here is to make a better interface [07:43:54] what exactly do you mean, create thumbnails without actually outputting them on a page? [07:45:13] ori-l: Well like someone might call the methods that create a thumbnail, without actually outputting it on the real page. e.g. In the api. So we shouldn't use globals [07:47:26] Currently everytime you create a thumbnail, the method returns a MediaTransformObject. Normally you put an image on a page, by calling the toHtml() method of that object. The better interface that comes to mind would be to also have a getModules() method of the MediaTransformObject [07:47:39] instead of the current parser callback hook in the MediaHandler object [07:48:45] that sounds very sensible [07:49:37] The alternative approach, which brion suggested is to give up on the whole media handlers injecting resource loader modules, and have anything that is not a straight tag, be an