is sus if you're potentially in a

[03:55:39] as in the first comment of a section [03:55:48] or an outdented one [03:56:04] which diff are you looking at? [03:56:19] the brfa description [03:56:21] 🙂 [03:56:24] oh [03:56:29] I will read some more of the brfa [03:56:41] it only uses div if it contains a block element [03:57:11] so what's more wrong, having a span wrap a block element or the div in inside a paragraph? [03:57:12] yes, but it should probably not do so if the bot's in the context of a

[03:57:54] neither's good, but we can detect the first in some cases today in Special:Linterrors [03:58:42] should be straightforward enough to make sure it's not a child of a

[03:59:09] I first need to fix the excessive color wrapping in e.g. https://delinterbot.toolforge.org/demo1/3900234_diff.html [03:59:09] I don't think the second one is detected, though it would be great if Linter actually did identify not just bad HTML parses but also bad HTML content model [04:02:09] replicating the p-wrapping algorithm may not be fair on its own of course, so, do what you think you can :^) [04:02:58] I'm working with Parsoid HTML, so I can literally just look at the DOM to see if it's nested in a p [04:03:05] 😄 [04:03:09] Parsoid being useful [04:04:17] https://gitlab.wikimedia.org/repos/mwbot-rs/contrib/-/blob/main/generic/delinter/src/main.rs#L175 [04:04:57] ` // So: ... -> ...` can you spot the comment error [04:05:33] oops [04:06:21] fixed [04:29:37] I'll save you a ping leg/oktm, but https://gerrit.wikimedia.org/r/c/mediawiki/core/+/762102 is again ready for review [04:32:06] Is there something going on with the user creation on mediawiki.org? [04:32:20] Edit thon? [04:32:21] :P [04:32:59] Donnnnnnnn't think that's it. [04:34:06] https://www.mediawiki.org/wiki/Special:Log/newusers [04:35:48] What's going on here? [04:36:10] 4 accounts created a minute since about 02:00 UTC [04:36:29] kind of looks like spam bot activity tbh [04:40:52] Wow, i totally did not know that https://www.php.net/manual/en/functions.arrow.php was a thing [04:40:52] spamathon? :D [04:41:13] people spamming mediawiki.org just means its a day ending in y [04:41:43] ok, wow, that is excessive [04:42:03] yeah [04:42:18] There's no active edithon? [04:42:44] editathon* [04:42:48] Not that im aware of, but i don't follow what the wikipedians do. There's no active mediawiki specific editathon [04:43:04] Or a hackathon? [04:45:18] they all only joined media and meta... odd so not coming from other wikis [04:46:33] bawolff, so now PHP can be unreadable now too! [04:47:07] Bsadowski1: I sent you a pm [04:47:32] Oh [05:00:44] Bsadowski1: it's bawolff plan for WorldWiki Domination! [05:16:42] AntiComposite (@_discord_396629348024582144:t2bot.io) what should be put in the topic? [06:02:29] hi PleaseStand, I sent you an email a few days ago [08:47:59] Hello, I made "extension" which loads CSS and JS, and it is supposed to show a button when someone clicks on it + when someone clicks it to scroll back on top. [08:48:03] https://github.com/kizule/mediawiki-extensions-Kicksecure [08:48:29] But it's not working. CSS and JS don't get loaded. Is there something wrong what I'm not aware about? [13:35:35] Prodigion3714[m] , that it bridges to #mediawiki on libera.chat / #mediawiki:libera.chat on Matrix [13:36:34] * AntiComposite grumbles about the bridge disconnecting [13:36:51] Prodigion3714[m] , that it bridges to #mediawiki on libera.chat / #mediawiki:libera.chat on Matrix [14:07:34] Does this look right? [17:07:51] Hmm, NativeSVGHandler is a really popular extension [17:08:04] Kind of feel that at this point that should be the MW default behaviour maybe [17:08:13] rasterizing svgs seems so 2001 [17:09:06] fonts and complexity of paths are relevant issues [17:09:24] hmm, that's a good point [17:09:44] Wikipedia is also weird with its 20 mb svg map files that rasterize to 10 kb [17:09:49] but most people don't do that [17:10:22] still, native should be default and people that need raster should just switch to that imo [17:10:23] I saw TheDJ give a good overview of issues with native SVG somewhere recently. Maybe in the enwiki Discord? [17:10:58] At the very least "Missing delegate rsvg" seems like a bad default ;) [17:11:29] enwiki might be one of the outliers that would still benefit from raster perhaps, but I'd think most people uploading svgs aren't uploading super complicated things (hopefully) [17:12:06] I'm inclined to support the native handling of SVG files but this is also not my specialty so consider this a +1 rather than a +2 :) [17:12:29] Well I'm just ranting, not exactly a patch ;) [17:13:22] NativeSVGHandler is the 28th most downloaded extension this month, which basically puts it as one of the top extensions that aren't used by wikimedia or related to ldap [17:14:19] although the sample size on this is pretty low, so take that with a lot of salt [17:15:40] (wrt. native SVG, https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multimedia_and_Commons/Native_SVG_support) [17:16:26] I'd put that pretty high up on "Things that shouldn't be decided via a poll" :) [17:17:47] bawolff: a comment at that proposal might be helpful in that case, just in case it turns out to be very popular & gets considered :) [17:18:29] Well I'm sure the actual experts on the topic will comment if that happens [17:18:51] I just think generally community wishlist is a bad place for things where there are trade-offs and less then clear right answers [17:19:26] Like if everyone agreed we should do this, we could have it done in 10 minutes [17:21:55] Interesting point, and I think I understand and agree with what you're saying.. [17:29:43] I think there's pretty good agreement that we *should* do client-side SVG rendering, the question is "how much work will it take" "should it be opt in/opt out/only option" "how do fonts work" "how does security work" "how does i18n work" [17:36:13] Security is actually pretty easy [17:36:25] as long as you use an tag, you are secure [17:36:36] If you want scripted svgs that is a different story [17:36:48] But even then, definitely not impossible [17:37:19] most of the svg authors I've talked to don't want scripts, but do want consistent fonts [17:37:31] and iirc means no webfonts [17:37:43] i18n is a non-issue imo; there's currently no expectation of i18n right now with images and that can just remain true afterwards [17:38:00] there's already a SVG translation system built [17:38:03] and in use [17:38:07] Yeah, you're right, means no web fonts [17:38:38] I suppose we could it if we really needed to, but i think there might be some performance issues if you have 100 iframes on a page [17:40:12] <ashley> the TranslateSvg extension is indeed a thing and IIRC it's fascinating but sadly somewhat unmaintained right now; that said, not changing the status quo radically is usually the best option, and I'm not just referring to svg files here :) [17:40:31] <moonmoon> AntiComposite: yeah but that system makes a different file per translation; it's not like [[File:Foo.svg]] magically changes based on the user's selected language [17:40:40] <AntiComposite> moonmoon, you are wrong, it does :) [17:40:55] <AntiComposite> with the <switch> element [17:41:10] <AntiComposite> https://commons.wikimedia.org/wiki/Commons:Translation_possible/Learn_more#Multiple_translations_within_one_SVG_file [17:41:22] <moonmoon> ah [17:41:40] <moonmoon> so how does that work with the current raster process? [17:41:54] <AntiComposite> the page language gets passed to Thumbor in the thumbnail URL [17:41:55] <moonmoon> does it somehow know the svg contains that element and splits the thumbnail cache per language? [17:42:02] <bawolff> yes [17:42:27] <bawolff> If we went native svg and wanted to keep this, we'd have to post-process the svg [17:42:46] <bawolff> annoying, but ultimately not that hard [17:43:35] <AntiComposite> right [17:44:24] <AntiComposite> (just using built-in browser support for <switch> is a bad idea because it limits to only the systemLanguage, so if you set your system language to en and went to sv.wiki all the SVGs would still be in en) [17:45:09] <bawolff> relying on user set system-language (just like accept-language header) is a road to misery in general. its never correct [17:45:20] <AntiComposite> yup [17:45:24] <moonmoon> the post-processing still seems probably quicker than a full rasterization process [17:45:38] <bawolff> you also only need to do it once [17:45:55] <bawolff> well once for each language [17:45:58] <moonmoon> yeah [17:47:12] <bawolff> I still think its sad that browsers didn't interpret the system language as being the languahe of the html page including the img. I think in many ways that would have made much more sense, and arguably isn't even inconsistent with what the super ambigious spec says if i rememeber right [17:48:06] <moonmoon> for webfonts, I think that would likely be highly limited (i.e. only able to load fonts that are hosted on wikimedia servers) if native happened [17:48:17] <moonmoon> still enough to ensure consistent viewing, at least [17:48:36] <AntiComposite> yes, we wouldn't want to load external webfonts [17:49:15] <AntiComposite> current rasterization is limited to a set of free fonts anyway, so that wouldn't be a new restriction https://noc.wikimedia.org/conf/fc-list [18:02:51] <TheresNoTime> moonmoon! *awoo!* [18:47:46] <TheDJ1626[m]> And just for kicks, ur gonna have to implement the SVG postprocessing twice (once for php, once for thumbor). Still, it would be relatively easy to implement compared to some of the feature requests.