[03:45:28] @Agent heeeeeeeeey sorry to bother but since you're online, wanted to ask, i sent the email for a data dump for void archives, what's the time for that to go through? or did i fuck it up again :,) [03:49:43] I saw, have you made a [[Phabricator]] task yet? [03:49:43] https://meta.miraheze.org/wiki/Phabricator [03:49:44]

https://meta.miraheze.org/wiki/Phabricator [03:49:44] [url] Phabricator - Miraheze Meta | meta.miraheze.org [03:50:25] oh it wouldn't let me in [03:50:40] Hmm, what error did you get? [03:51:23] wait i'm just reading the instructions now and i'm realizing i tried to make a phabricator account not log in with miraheze [03:51:31] one sec i'll file the task now then [03:54:23] i'm assuming i can put datadump in the tags? [03:54:34] No, don't put anything in it [03:54:39] and don't assign anyone either [03:54:39] oh okay [04:00:40] Seen, a sysadmin should import it shortly :) [04:39:33] thank you [06:34:02] Hello Guest65! If you have any questions, feel free to ask and someone should answer soon. [10:46:16] Should I ask users not to make edits while the import is still ongoing? [10:46:53] maybe easier to temporarily remove edit rights? [10:48:07] wait, is that Flippy humanisation on your avi? :ThinkingHardMH: lmao [10:50:36] Don't remember, I've been using it for 5 years at this point. I just picked one that looked like my old avi. Anyways so. >Manage this Wiki's permissions>Autoconfirmed users or >Manage this Wiki's permissions > Users [10:51:20] Users, autoconfirmation is not where the basic editing rights lie [10:52:49] Aight, thanks for the help. [13:20:58] thinking about switch function based on the beginning of page's title - is it possible? [13:25:35] the goal is to categorise articles, which have fixed title template, most likely via infobox titles go as: Concert: YYYY-MM-DD - - and say if the show took place in 1994, the beginning gonna be Concert: 19... so, template would put the article into Category:1990s concerts [15:02:14] A relatively significant convention has been changed with the latest update to [[Dormancy Policy]] [15:02:14] https://meta.miraheze.org/wiki/Dormancy_Policy [15:02:15]

https://meta.miraheze.org/wiki/Dormancy_Policy [15:02:15] [url] Dormancy Policy - Miraheze Meta | meta.miraheze.org [15:02:41] Not to say it hasn't been justified, but it is interesting how the process has continued as long as it did without that observation [15:06:49] It also leaves room for confusion in regards to what adoption actually means at this point, since the process of getting rights to manage a wiki is now another matter entirely and there is really no definition to saying who has 'adopted' it given no ownership or rights are conferred through the adoption process with the current text. [15:11:48] The adoption process was originally just a way to re-open a wiki [15:12:05] adoption isn't a good name but has never been changed or corrected to reflect reality [15:15:41] No one necessarily 'adopts' a wiki, they just request it gets re-opened and it gets re-opened. That is how the process should work - otherwise Stewards get placed in a position where they can subvert the community of the local wiki. Say a wiki gets closed for some reason and you have 10 users suddenly show up who want to manage the wiki - the 10 users should decide who gets the right (if all of them perhaps) rather than a Steward who has to pick [15:15:41] one user out of the 10 [15:19:08] From what you're telling me the way it has been done (even if not necessarily valid by underlying policy) is actually the most accurate use of the term so far. Grounds to adjust it probably. But there's several things that could use that sort of second look on Meta. Mainly though, I think better definition or at least guidance on operating a local election process should be prominent and/or offered right in the request as the [15:19:09] ambiguity is good in some ways, but likely to leave the end user confused especially when they've already been exposed to the term 'request for adoption' and then are told to independently go make an election with an unspecific requirement for the election to be prominently advertised, where in the overwhelming majority of cases it's rare to find two people interested after a wiki has long expired from inactivity. [15:20:02] I don't disagree with the local election step, but I do think it could be far more clear in operation when people are told to use it. [15:20:46] Hi. Is there any way I can force every browser to use the desktop version of my wiki? With the Citizen skin. It's totally broken in mobile view, so it's important that anyone visiting sees the desktop version until that bug has been fixed (I've already reported the bug) [15:20:47] Perhaps a guide page and/or template can be offered to streamline it, with the stipulation that a user can make adjustments that still carry the required substance if they wish so there's agency and they're not just told 'do it this way'. [15:21:03] Citizen, hm, time for a trip to ManageWiki [15:21:49] I looked in ManageWiki, but couldn't find any setting for that. Where should I look? Thanks! [15:22:07] A guide page can be created to be linked, the RfC set out the base standards of 'how Meta does it is the way it should be done' it seems from looking at it [15:22:26] I'm giving it a look, if it's not there I'll have to try and remember who the original developer is so I can involve him [15:22:47] The citizen dev is on discord, but I regret to say I always forget his username >.> [15:23:52] The GitHub is here, if that helps :) https://github.com/StarCitizenTools/mediawiki-skins-Citizen [15:23:52] [url] GitHub - StarCitizenTools/mediawiki-skins-Citizen: A responsive Mediawiki skin designed for the Star Citizen Wiki | github.com [15:23:52] I didn't even think citizen had a unique mobile view tbh [15:24:35] Here's my issue, with a screenshot of how the mobile view looks :) https://github.com/StarCitizenTools/mediawiki-skins-Citizen/issues/409 [15:24:35] [url] Broken articles in mobile view · Issue #409 · StarCitizenTools/mediawiki-skins-Citizen · GitHub | github.com [15:26:55] Re the adoption discussion, I think having an outline of the process and any desired contingencies from Stewards + a usable basic template would be good, which can then be offered whenever that process is invoked [15:30:24] So the trouble regarding the citizen discussion is, I'm looking on mobile with native mobile view and experiencing zero issue [15:31:59] The issue is no longer a matter of mobile behavior being universally borked, but its behavior with your/a type of client; so at the very least you'll need to provide further information regarding the device/browser being used. It may be interesting to know what happens if you force desktop view right through the mobile device to see how the headers respond, because looking more closely I don't even see what changes that would [15:32:00] cause it to uniquely break. [15:32:53] but citizen does not have a mobile view? [15:32:57] it's responsive [15:33:10] Yeah, the more I look the much less likely it has literally anything to do with mobile, and rather a skin-client interaction problem [15:33:36] So I'd test more things including forced desktop view, cache clearing and getting samples of info from what membership you have to see how widely the problem exists [15:33:42] from what I understand, this option to "view like desktop" on mobile browsers only work with websites that have separate versions[ [15:33:47] like Wikipedia [15:34:44] Yeah, reading into it I see it has no particular changes at all for mobile except content placement pretty much [15:35:00] And by mobile I just mean the resolution, ie, something to test with an odd looking browser window [15:35:24] I may be wrong, but when it comes to "responsivity", the thing that matters is the amount of space on the screen [15:35:45] In the footer there's a mobile view/desktop link, which changes the pages from the broken to the not broken view for me, what is that then if it's not a mobile view for the skin? [15:35:45] if you somehow can zoom out in the browser, the layout will adapt [15:36:01] You might have MobileFrontend on, in which case kill that extension with fire [15:36:12] that's mobilefrontend, it's an extension for skins that do not have a mobile version [15:36:12] It helps nothing in my experience and could be the issue right there [15:36:27] but citizen is already responsive, so you don't really need it [15:36:52] Although I still don't get the problem, so it may not be 100%; worth trying [15:37:20] would be better if ManageWiki disabled Mobilefrontend for some skins [15:37:23] automatically [15:37:52] UniversalOmega even made Cosmos disable the extension [15:39:10] Thanks! It's worth a try disabling it! [15:42:07] Ok, that did the trick! Thank you so much! [15:42:58] Excellent [15:48:02] Man, what a great community this is! [15:48:03] Another thing: I'd love it if there was a way for me as a wiki owner to donate some amount and then get the "please donate" message removed from my wiki for other visitors. Just one wiki and one year at a time, but if I want to give more to make sure random visitors won't see the message would be great! [15:48:30] I've already donated, but I'd be willing to give more for this feature [15:48:34] pay to remove doesn't sound good tbh [15:48:40] no? [15:49:00] If something like that is on the table, outright dismissal should be an option on principle as local management discretion [15:49:11] It would be a shame, but it would be more fair than introducing what's basically a paid mechanism [15:50:14] The please donate message is only temporary anyway. I don't see the problem of letting people pay to skip it once [15:51:14] Might be something to raise on the Community Noticeboard, I think [15:51:30] At the least it's interesting to think about [15:53:06] we would need a database for that [15:54:00] I wouldn't feel the same need to get rid of it for other visitors if a) it didn't fill the whole screen on (my) mobile phone and b) it didn't look so out of place on dark skins (and also c) if the way the text adjustment + logo is didn't make it look a bit unprofessional), btw :) [15:54:42] It's a really janky message I must admit, at least the ability to 'integrate' it ''and'' it being more cross-skin and theme friendly would be good [15:55:01] I'm trying to use wikitext on discord, oh dear [16:21:41] So, should I create a Topic in Community Noticeboard about this? [16:29:23] Pay to remove has been suggested before but was declined previously [16:31:15] It could be raised as a discussion with inclusion of the idea's merits, weaknesses, and how to address the spirit behind the idea perhaps including open removal at discretion or ways to make the banner a better fit with various wiki styles.