[09:38:18] [1/3] I thought I'd see if I can get some SMW testing done while Cargo, wikibase, and DPL4 all have problems big and small. [09:38:18] [2/3] https://meta.mirabeta.org/wiki/Special:RequestWikiQueue/24 [09:38:18] [3/3] Since SMW doesn't seem to be up-to-date on Mirabeta, someone will probably need to run the update script so that it's compatible with MW 1.44. [09:38:49] Oh wait SomeRandomDeveloper already approved it. [09:45:58] created [09:46:32] im off to sleep now though. If you dont mind, could you DM me issues you found with DPL4 so I can look more into it again? [21:32:50] what do you all think about making ManageWiki change reasons optional [21:58:58] {{support|strongest}} [21:59:23] I've seen so many people just write gibberish, I don't think it should be required [21:59:40] the people that write detailed reasons will keep doing so [21:59:50] those that don't won't have to bother with them anymore [22:00:49] {{support}} as well. If left unfilled, the reason can be auto-generated from the change. This is pretty easy for extensions but may require some work for settings since they are more diverse. [22:00:50]

[22:02:44] it already comes with an autofilled change summary anyway [22:02:51] works for me [22:10:45] +10291838 [22:10:53] that's like +1 but more [22:11:22] The format is not very intuitive, though. It doesn't say whether an extension is enabled or disabled, just that it has been toggled. Permission changes are the worst because the autofilled summary is unnecessarily verbose. [22:13:14] Yes, the logging should be made more explicit. [22:13:51] in an ideal world we'd pass the previous state for permission and the new state, and then use a diff engine to show what actually changed but that's too complex for MediaWiki's built in log [22:13:57] (By ideal world, thats what Gamepedia did) [22:29:57] [1/2] The i18n file needs to be overhauled to accomplish that. For example, the rights entry would be split into several ones so that only changes are shown. [22:29:57] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1406404645059952792/image.png?ex=68a257e5&is=68a10665&hm=35f0a8bf0e600ba43be30a0774d39fd363fab7c68bab827ee52ed820ce004b91& [22:35:31] I proposed this years ago somewhere and the idea was shut down. Can't remember why. But we could do it if thats what is wanted (I've always thought it was a good idea to) [22:36:06] do you wanna do this in one sleepless night or shall I procrastinate 2 weeks on it [22:38:15] I can maybe do it sometime (not today but maybe tomorrow) if that's what's really desired. [22:54:39] [1/14] https://discord.com/channels/407504499280707585/1405956217360093225 is caused by UserFunctions expecting an associative array like [22:54:39] [2/14] ```php [22:54:39] [3/14] [ [22:54:40] [4/14] 0 => true [22:54:40] [5/14] ] [22:54:40] [6/14] ``` [22:54:40] [7/14] instead of [22:54:41] [8/14] ```php [22:54:41] [9/14] [ [22:54:41] [10/14] 0 [22:54:42] [11/14] ] [22:54:42] [12/14] ``` [22:54:43] [13/14] which ManageWiki currently produces. This breaks the extension in the main namespace as `$wgUFAllowedNamespaces[0]` is `0`, which evaluates to false in PHP [22:54:43] [14/14] I don't think that the `check` type for namespace settings supports associative arrays, so would this require a new setting type in ManageWiki? [23:55:38] I'm pretty sure there is a type somewhere in there that's actually an associative array, but I forget off the top of my head [23:57:35] Yeah, check the comment at the start of the file, `vestyle` is a checkbox type input stored as an associative array. [23:58:57] Oh, I read over that line but somehow didn't realize that it was exactly what I'm looking for [23:58:58] thx [23:59:41] Yeah, no worries, it's thrown me off just about every time this kind of thing has come up too