[09:29:10] Hi everyone. We're currently using an extension that compresses and converts uploads by very non-techy users (e.g. converting a bmp or tiff to png, which saves a ton of space). We now noticed that it doesn't play well with another extension. Looking into this, it seems that's because the compression and converting is happening on the UploadForm:BeforeProcessing Hook, and the new extension uses the upload A [09:29:16] PI instead of the upload form. It seems however that the hooks the API calls don't allow for renaming a file after conversion, which is a problem when converting one image format to another. Did we miss some kind of hook that does allow this, is this a bug, is it intended behaviour, or what do people here think? [13:57:22] Hello and big thanks for the awesomest wiki engine in the Laniakea Supercluster [14:01:30] I have a bunch of wikis, and I do link a lot to the Wikipedia using the http://en.wikipedia.org/wiki/Special:Search?go=Go&search=w: interwiki and http://en.wikipedia.org/wiki/Special:Search?go=Go&search=w:fr: en français etc. I want to make sure that the links towards Wikipedia are correct, so when I do an edit I just ctrl-click all of them in the preview before publishing. [14:02:05] This pounding on the WMF servers could be avoided if there was a feature in MediaWiki that it remotely checks the link destination for #1 existence or the lack of (this is most important) and possibly also #2 for being redirect #3 for being disambiguation page, without needing to visit Wikipedia, thus removing unnecessary load on the servers [14:02:55] e.g. When making an interwiki to Wikipedia the MediaWiki would show with some colors or other indicator whether the destination is a blue link or a red link [14:07:19] I guess I'm ultimately suggesting that interwiki tooltip popups would be soooooo nice. Though this would be even more work to implement, but at least I would love it [14:08:57] In theory it's not that difficult [14:09:16] Most of the functionality already exists to be used in the local wiki (various navigation popup implementations) [14:10:32] .. then it would just would need interwiki messaging setup? [14:11:00] there already is the API .. I guess that could be used, but I'm no pro in computers [14:16:28] * Iamthehuman1 that still has trauma recollection from being stuck in VIM in a VT100 terminal the Uni of Helsinki and no cheat sheet anywhere to be seen [14:18:19] somebody could have been more pedagogic and mention to the freshmen that vimtutor exits and where to download and maybe I wouldn't be a nano guy when needing to edit a file without a GUI [14:21:11] Reedy: based on your feedback of "In theory it's not that difficult" I'd like to write a phab ticket on this because this is a win-win for WMF and non-WMF wikis. Which part of the MediaWiki development crew this should be addressed to? [14:23:25] I'd see it as a followon to the work in https://www.mediawiki.org/wiki/Page_Previews [14:24:46] Ok thanks. reading. [14:26:05] Doing a remote (foreign/whatever) wiki is basically just using a different URL base to the current wiki etc [18:01:17] Hi everyone. We're currently using an extension that compresses and converts uploads by very non-techy users (e.g. converting a bmp or tiff to png, which saves a ton of space). We now noticed that it doesn't play well with another extension. Looking into this, it seems that's because the compression and converting is happening on the UploadForm:BeforeProcessing Hook, and the new extension uses the upload A [18:01:23] PI instead of the upload form. It seems however that the hooks the API calls don't allow for renaming a file after conversion, which is a problem when converting one image format to another. Did we miss some kind of hook that does allow this, is this a bug, is it intended behaviour, or what do people here think? [18:02:02] or is there a more dev-y channel to ask these kinds of questions?