[03:29:12] COIbot went offline, and https://tools.wmflabs.org/copyvios/ yields 502 errors [03:29:27] must have been about half an hour ago [03:30:11] ah no, even longer [03:30:11] 02:32:01 ⇐ •COIBot quit (tools.coib@wikimedia/bot/coibot) Remote host closed the connection [03:30:11] (now is 04:30:00) [03:32:04] XTools at xtools.wmflabs.org still work, however [03:34:06] Since when did Commons start using webp image files? Or is this just something that my browser is doing? [03:37:07] ToBeFree: There are issues with ToolsDB. See T216208 [03:37:08] T216208: ToolsDB overload and cleanup - https://phabricator.wikimedia.org/T216208 [03:38:02] oh, thanks JJMC89 [03:40:48] benjaminikuta: the browser would need to do a time-intensive conversion after downloading, so the browser itself would have no profit in doing it [03:40:48] I rather guess it's either actually a webp image, or an "accelerating" proxy e.g. as Opera offers it, or https://phabricator.wikimedia.org/T27611 is being implemented [03:40:48] benjaminikuta: any specific image? [03:41:14] https://commons.wikimedia.org/wiki/File:Maximilianeum_Munich_at_Night,_March_2018.jpg [03:41:30] https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Maximilianeum_Munich_at_Night%2C_March_2018.jpg/1280px-Maximilianeum_Munich_at_Night%2C_March_2018.jpg [03:41:55] When I download the largest version, it's a jpg, but when I download the second largest version, it's a webp. [03:44:07] benjaminikuta: now that's interesting. My browser sends an "Accept" header for the image request, and the header contains "image/webp" [03:44:13] using Firefox [03:46:06] and the server responds... with a webp file. Linked in the phabricator discussion: https://www.igvita.com/2013/05/01/deploying-webp-via-accept-content-negotiation/ [03:54:35] Is there any way to get a jpg instead? [03:55:27] benjaminikuta: telling your browser not to request a webp, I guess. If it's firefox, about:config likely has an option [03:55:48] and indeed: image.http.accept it is [03:56:33] How about Chrome? [03:56:45] What's the advantage of the filetype, anyway? [03:56:54] Chrome often requires you to install an extension for similar digging into the config [03:56:59] I've been seeing it more lately, but it seems to be not very compatible. [03:57:05] That's unfortunate. [03:57:08] lower filesize at same quality. Compatibility is coming, slowly [03:57:38] Was there some discussion on Commons about this? [03:57:40] for the same reason, Spotify doesn't use MP3 [03:57:54] Is there a way to get a jpg directly from Commons? [03:58:02] of course! Just download the original file [03:58:24] But I want the smaller file. [03:58:40] I guess I could just resize it myself... [03:58:48] shrink locally, a few clicks in a graphics program of your choice. But I do see that this is a strange workaround for restoring a previous feature [03:59:15] Facebook stopped delivering WebPs after many users complained about being unable to open downloaded images [04:00:06] Yes, I would rather sites not deliver webps. [04:00:33] it's a nice format that offers lossless and lossy compression, even for transparency (the alpha channel), surpassing PNG in lossless and JPEG in lossy compression. But it may well be too early to deliver it to users [15:52:40] Hi, when I parse the stub-meta-history.xml I can't find some pages by id [15:52:52] to give you one example: https://en.wikipedia.org/wiki/Ola_Delight_Smith [15:52:56] any idea why? [19:59:54] What is p4ssw0rd to The Bad Place? [20:12:41] Anyone can help me with a Toolforge problem? [20:12:59] hi, you probably want #wikimedia-cloud [20:13:32] sounds like a plan, thx [20:36:10] Hi [20:36:28] IS there a documentation for what HTML gets generated for certain extensions? [23:15:24] ShakespeareFan00: I don't think there is any centralized documentation of that. There may be docs maintained for the extensions themselves in the Extension namespace on mediawiki.org. Even that is probably pretty hit and miss [23:21:18] what HTML gets generated will depend on the extension code, and vary between releases [23:21:28] the best bet is probably the Extension:Cite [23:21:37] highly supported, with parsertests, etc [23:36:49] So I'm relying on at best underdocumented stuff :( [23:37:11] Such is working with 'volunteer' maintained 'free' software XD [23:37:44] https://en.wikisource.org/wiki/Help:Layout [23:37:54] Mentions certain container CSS classes [23:38:24] It would be helpful to know what parts of that are generated at what point in the hireachy [23:38:53] so relevant floating behaviour and margin/padding widths at each level can be appropriately determined [23:39:29] It doesn't help that the actual scripting that does modfied layout presentation at Wikisource appears to use different names from that on the help page [23:40:01] https://en.wikisource.org/wiki/MediaWiki:PageNumbers.js [23:40:26] I'm asking because having written at least 3 overly complex templates... [23:40:37] I find this layout stuff already existed [23:40:59] and with some improvements would make the ENTIRE template family I wrote unecessary [23:41:33] The scripting above is currently only in that form on English Wikisource [23:41:46] (other Wikisource do it ever so slightly differently) [23:42:20] And the interactions between mediawiki, extensions, inline styles and Templatestyles... eventually makes my head go.... Ouch... :( [23:54:01] Platonides: Oh [23:54:16] And do you have a "legal" cure for coding induced headaches? XD