[00:00:22] Bella ciao [05:47:42] Ah that makes sense [07:02:38] [1/7] How do we feel about enabling a few more extensions by default for newly created wikis? [Agent did an RfF a few years ago](https://meta.miraheze.org/wiki/Community_portal/Archive_26#Request_for_Feedback:_Adding_new_default_extensions) to add Purge and WikiSEO, and I think we can do something similar again in light of extension usage statistics. Here are some I have in mind: [07:02:38] [2/7] 1. PortableInfobox. Always a pain to ask new fandom migrants to enable it and then purge all pages so that their infobox works. It makes minimal impact on wikis that do not need it (few will be curious enable to type `` in their editor to see what happens). [07:02:38] [3/7] 2. TimedMediaHandler. Gives audio and video playback functionality out of the box and helps avoid questions like [T14298](https://issue-tracker.miraheze.org/T14298). Wikis that don't upload any audio or video won't see any difference, so the extension won't adversely affect user experience for those who don't need it. [07:02:39] [4/7] 3. TemplateSandbox. This is less popular on MH but is deployed on many WMF wikis. It is very convenient for debugging templates and is crucial when debugging templatestyles stylesheets and Lua modules, though wikis may not know that it exists and is useful. For wikis that don't need it, the extra input box for the extension should cause minimal inconvenience. [07:02:39] [5/7] 4. Thanks. Not much needs to be said besides the fact that it helps build a friendly community without much drawback. [07:02:39] [6/7] Because we have ManageWiki, we were able to get away with fewer default extensions and let wikis enable the ones they need. However, I believe it would be beneficial to enable widely-used extensions that are known to be useful without much side-effect. A wider selection of default extensions will save new wikis significant time figuring out why something is not available and c [07:02:40] [7/7] reate a much more pleasant starting experience. [07:05:27] I also want to remove some default extensions as a longtime MobileFrontend and DarkMode hater, but I think these would be a lot more controversial (especially MobileFrontend), so I'll shelve this for now and see what the community thinks about the extension additions above. [07:15:53] [1/5] Thoughts in no particular order: [07:15:54] [2/5] * PI - good, but maybe breaking soon w/ the next MW release as always? OA and CA are doing a lot to try to avoid this fate. [07:15:54] [3/5] * TimedMediaHandler - easy win, perennially wanted, I see no reason not to enable [07:15:54] [4/5] * TemplateSandbox - I don't see any huge downsides [07:15:55] [5/5] * Thanks - 🤷 👍 [07:16:30] TMH alone seems like a 'doesn't need an RfC/RfF' level of global utility [09:46:26] should add a checkbox somewhere that if you're importing from fandom it automatically enables PI [10:30:54] <90gq29, replying to posix_memalign> yeah super good suggestion, i remember scratching my head when the infoboxes broke after importing from fandom [10:36:02] <90gq29> though im not really super familiar with media extensions, but isnt [EmbedVideo](https://github.com/StarCitizenWiki/mediawiki-extensions-EmbedVideo?tab=readme-ov-file) also a good option? [10:40:34] i do think that embedvideo is better than TMH [12:26:49] I think having PI on by default would be good, would've saved me some headache when my wiki moved and everything exploded, and Thanks wouldn't really hurt anything, it's cute little extension imo so it might be fun to have it on new wikis [12:42:19] Agree with all these [13:11:42] https://discord.com/channels/407504499280707585/1421471464678359071 [13:11:47] big issue [17:11:21] They serve different but overlapping purposes, both could be helpful though [20:40:18] This is similar to https://issue-tracker.miraheze.org/T14089 and I vaguely remember some mention of there being progress made on this front. [20:52:59] [1/2] This is a valid concern for non-WMF extensions in general. The WMF might make some changes to MediaWiki without feeling obligated to fix non-WMF extensions that break as a result. Enabling an extension by default encourages wikis to use it, so it could get us into a worse situation because more wikis depend on a broken extension. [20:53:00] [2/2] I wouldn't be too worried about PI, though. PI is already widely used on MH. If it breaks once MediaWiki 1.47 makes parsoid the default, I think we would be in much bigger trouble and enabling it by default is a minor issue by comparison. [20:55:15] @posix_memalign DarkMode should be dead and buried [20:55:59] just like mobilefrontend [20:56:07] which we enable by default for some reason [20:56:17] At least mobile fronted is cared about by someone [20:56:24] DarkMode isn't even a finished extension [20:57:18] glorified global CSS invert [20:59:20] didnt they change that [21:01:42] [1/3] TMH primarily deals with video and audio playback for local uploads. EmbedVideo mainly plays videos from external sites but can also handle local video playback. The overlap is on playing local videos, and I think both extensions are okay in that respect. [21:01:42] [2/3] The main issue with EmbedVideo is that other extensions can improve user experience with little intervention (e.g. PI magically makes infoboxes work for fandom migrants), but EV requires learning about the syntax `{{#ev`, and at that point the user is more likely to know about how it works than not. [21:01:43] [3/3] I think it's still worth a try, though, especially since both fandom and wiki.gg have it on by default. It could go into a second batch of extension. [21:01:46] Wouldn't the real time preview extension be a good one to have default enabled? :ThinkerMH: [21:02:05] Saves a lot of small edits on Meta as well [21:08:30] it's not an extension, it's a preference [21:17:04] Erm... You enable it in Manage Wiki right? [21:18:18] well, preference is a bit wrong and misleading, an option would be most accurate [21:18:26] but it is still not its own extension [21:19:02] [1/2] Yeah, correct. Found it in Special:ManageWiki/settings [21:19:02] [2/2] Still... Wouldn't it be good to ave that as default? [21:19:38] it’s a wiki setting [21:19:43] :SupportMH: [21:20:21] We could try that on Meta. It would save us so much from all the small edits that users make on their userpages [21:20:32] In theory [21:20:47] Well, at least they see what they are doing 😄 [21:21:08] Or they have to be blind on the right side 😛 [21:21:11] if you wanna get really pedantic it's a feature within wikieditor :3 [21:22:06] I've been using it on my wiki for ages now. It's really nice to have [21:24:50] i would hold off on making it default for now as it makes a load of API requests [21:24:59] one single character added on jwmeeting caused 3 api calls [21:26:02] No, it’s a variable config setting in Extension:WikiEditor controlled in our setup via ManageWiki’s system [21:26:03] (doesn't necessarily mean anything is wrong with your wiki, just saying where I tested it currently) [21:26:43] i think i'm gonna call your mom and tell her you're bullying me :( [21:26:55] I hate this woman [21:27:08] love you too <3 [21:27:40] I think it's a similar situation with DiscussionTools which uses Parsoid to do live preview. It's unusable on a wiki with strict rate-limiting measures because the moment you type something the WAF will block you for making too many requests. [21:28:55] not that we rate-limit any particular wikis [21:29:04] (at least not to my knowledge) [21:32:01] I was thinking of moegirlpedia when I talked about rate-limiting. On MH, aggressively sending requests (e.g. 10 per second) might get a user ratelimited, but it will almost never occur under regular usage. [21:32:11] ah, of course it'd be MGP [21:32:56] Is Meta rate-limeted? [21:33:52] https://cdn.discordapp.com/attachments/1006789349498699827/1421610821464883321/image.png?ex=68d9a9c0&is=68d85840&hm=7d8af65374167e42a633d0145ba4c443defb0079607e076af73eb340de079d22& [21:33:59] (no) [21:34:51] okidokie. Then lets enable it on Meta - yes? Please? Pretty please? [21:34:57] 😄 [21:35:05] up to the stewards [21:43:04] Different rate limits [21:43:25] true but on the mediawiki side of things we dont really have anything [21:44:03] We don't apply rate limits measured over a single second [21:52:10] I see. I was thinking of https://discord.com/channels/407504499280707585/407537962553966603/1413190122572087497, but that was probably an average measured over a longer period of time. [21:53:37] oh you have to make an insane amount to trigger the cloudflare ratelimit [21:53:42] way beyond what you could humanly do [21:56:15] They are measured over longer ye [21:56:48] There is a burst limit measured over a small number of seconds and an extended limit measured over a longer period [21:56:56] He hit the extended one in that case [22:13:04] [1/2] RfF submitted: https://meta.miraheze.org/wiki/Community_portal#Request_for_Feedback%3A_changes_to_default_extensions_for_new_wikis [22:13:05] [2/2] Besides the orignal 4 (PortableInfobox, TimedMediaHandler, TemplateSandbox, Thanks), I added disabling DarkMode as the 5th proposal. [22:14:30] Cool [22:14:50] Feel free to create a PR for if/when it passes [22:57:07] [1/2] About to add the following to MH Monthly's headlines. I wrote it to the best of my knowledge, but someone should look through it to make sure there aren't any issues. [22:57:07] [2/2] > Several outages lasting between a few minutes to two hours occurred near the end of September. FiberState, our server provider, had connection issues that caused two outages, while a software bug is the suspected culprit for the rest. The technology team is working to identify and fix the bug to prevent future outages. [23:41:24] I numbered the options, as when you edit one of these, you will always fall back to the first support, oppose, abstain, comment. By numbering them, you stay in that header.