Community noticeboard

Discussion: Central notice changes
This is for the sake of having an open discussion on the changes proposed in this RfC, though I won't really touch much on the last proposal that was added by another person (of course, you're welcome to talk about that as well nonetheless). Hopefully this comment will at least make it clear what the proposals I brought up are intended to mean. Also, please ask nicely if you would like clarity on anything at all.

The first one to discuss is the following:

Central notices with the purpose of soliciting participation from wiki communities for an event or a discussion should last while that event or discussion is open for people to participate. As in, the central notice would only be removed after the event or discussion has closed.

Let's start by saying that this is not changing what a central notice is made for. It's not saying that every discussion gets a central notice, what it's saying applies in the instance when the people who make central notices decide that a discussion will get a central notice, which is still at their judgement. This talk page comment might show some insight on what such judgement it is, which again they would still retain. What changes is specifically the duration of such particular central notices, in that it would be in relation to the discussion that it would be notifying of.

The discussions being referred to can be gleaned from Special:CentralNotice (click "Show archived campaigns" to see the older ones). It is what is meant to gather people to provide their input and feedback, and this description fits, for example, Requests for Comment or Requests for Stewardship. And if they have yet to be closed by the closer, then the closer presumably decided that it needs more time to gather more comments before a conclusion can be drawn. If so, the methods used to notify of the discussion's existence should get continued use to gather more discussion from people.

Another proposal to discuss is the following:

A campaign type can be set for central notice campaigns, allowing users to opt out of specific campaign types in their preferences, specifically in the "Banners" section. Here is a proposal for what campaign types Miraheze should use:
 * Fundraising
 * Surveys
 * Maintenance
 * Requests for Comment
 * Requests for Stewardship
 * Requests for Community Director

To make it clear how to use preferences to opt-out of campaign types, some text instructing people how to do so should be added to central notices.

In technical terms, campaign types are configured with $wgCentralNoticeCampaignTypes in LocalSettings.php.

This can presumably work with ManageWiki to apply for a whole wiki. To sysadmins, this would presumably be done by using a custom variable to set $wgDefaultUserOptions['centralnotice-display-campaign-type-whatever'] = 0.

Now, in regards to how to decide on the campaign types to be used, I'd say that having the communities' consensus is still relevant, in the case of disputes over what should be grouped together or partitioned. And the RfC does show a dispute over whether Requests for Global Sysop should be included, excluded, or grouped with another type. So it would at least be useful to have some sort of discussion with wiki communities to figure out what's best.

In response to other comments in the RfC: Including Requests for Global Sysop in the list of campaign types does not mean that every single one of that request gets a central notice, it is meant to mean that a RfGS would be allowed to get a central notice, which would still have the judgement of the people who make central notices to actually get one. And people should be able to decide for themselves if they want to opt out of seeing certain central notices, and I figure that if someone desires a tool to stop seeing a certain kind of notification, they likely aren't interested in what's being notified about in the first place. Finally, it was concluded in this RfC that there is consensus for community-oriented posts to be posted on Miraheze's social media accounts, therefore a community-elected role would be appropriate.

Feel free to say your thoughts on any of these topics. K599 (talk) 15:29, 1 December 2021 (UTC)
 * And will there be a way to disable CNotice for some, and leave only fundraising? YellowFrogger (✉ Talk  ✐ Edits ) 15:33, 1 December 2021 (UTC)
 * @YellowFrogger As said in the explanation of how campaign types work, people should be able to go into their preferences and opt-out of the types that they don't want to see. K599 (talk) 16:27, 1 December 2021 (UTC)
 * But there has to be an option to hide it across the whole wiki (not just in preferences), but yes, all visitors to a particular wiki would be better. Nobody is obligated to see CNotice either, so it had to have that. Showing only CNotice for fundraising, which is important for Miraheze to maintain the wikis maintenance, the others don't matter (or only matter in Meta). YellowFrogger (✉ Talk  ✐ Edits ) 19:59, 1 December 2021 (UTC)
 * @YellowFrogger I mentioned above that there's presumably a way to make campaign types work with ManageWiki, though I suppose a sysadmin should comment on the method I talked about. K599 (talk) 20:19, 1 December 2021 (UTC)
 * Note that the list of campaign types proposed in my initial comment is based on past central notices as seen on Special:CentralNotice. Of course, feel free to discuss any desired changes to the list. K599 (talk) 03:04, 8 December 2021 (UTC)
 * For some added context, the banner preferences can be seen in Special:Preferences, where it's currently the extension's defaults. These options have been unused probably due to being unrelated to Miraheze. K599 (talk) 03:46, 22 December 2021 (UTC)
 * This talk page discussion has a review of the proposed list of campaign types. In response:
 * Okay, but I would prefer that "Community Notices" have a page that explains what would fall under this label. Then this page would be linked, if possible, from the related user preference and, if implemented, the related ManageWiki setting proposed in the community wishlist proposal. K599 (talk) 01:29, 2 January 2022 (UTC)
 * I think it'd be useful to consider above suggestions like the instructions thing as well. K599 (talk) 03:25, 13 January 2022 (UTC)

Finding a conclusion on campaign types
It would be good to at least have some course of action that outlines whether or not this wikifarm will make use of campaign types, and what those campaign types will be. K599 (talk) 03:51, 26 January 2022 (UTC)
 * There was a talk page discussion that reviewed a list of campaign types, but it seems that no sort of action has been concretely decided on.
 * Reiterating what's been explained before, campaign types refers to Special:Preferences, a user preference that is used to choose what types of central notices to have displayed for your own account.
 * Currently, as can be seen by checking your preferences, the configured campaign types don't particularly reflect how Miraheze uses central notices (see Special:CentralNotice). Hence the suggestion above for a more appropriate list of campaign types. The description for the preference also makes reference to Wikimedia rather than this wikifarm, which probably confuses people.
 * This community wishlist proposal would also need campaign types to be configured to be useful. I'll also note the suggestion of using ManageWiki on a custom variable to set $wgDefaultUserOptions['centralnotice-display-campaign-type-whatever'] = 0.
 * If campaign types do get properly configured and used, it would be helpful to take the suggestion of including some text in central notices that instructs people how to use the user preference and ManageWiki setting, to make it clear that the banner isn't forced to appear.


 * I still want some sort of concrete conclusion on this, as I do think this would be helpful to people. K599 (talk) 23:03, 4 February 2022 (UTC)
 * I'd still like a resolution on this. It would be a useful feature for allowing individual control over what notices are shown to people. K599 (talk) 22:35, 4 March 2022 (UTC)
 * Asking for discussion again. This feature, as it's been explained in the above points, would help improve communication, so please have some consideration. K599 (talk) 22:02, 18 March 2022 (UTC)
 * As stated before, would like a discussion on appropriate options for the "Banners" user preference, as this would be a useful feature, if it were actually implemented. K599 (talk) 22:02, 1 April 2022 (UTC)
 * As much as this would be interesting to realize, it seems clear there is neither traffic nor interest in the topic at any wider level. --Raidarr (talk) 13:17, 3 April 2022 (UTC)
 * Well, the list of campaign types that I suggested above was reviewed in this talk page discussion, but further action has not occurred. What would be needed here is to get to the next step to eventually get these ideas implemented, and that's why I've summarized the details about campaign types in the bullet points above, to discuss implementation of them. K599 (talk) 22:22, 15 April 2022 (UTC)
 * It's a feature that would be useful for people if it were actually implemented, so I would like it to be considered. K599 (talk) 22:24, 29 April 2022 (UTC)
 * I still would be interested in some discussion for making this happen. K599 (talk) 22:22, 13 May 2022 (UTC)
 * Still would like discussion on this, to make this happen sometime. K599 (talk) 22:21, 27 May 2022 (UTC)
 * Noting again the suggestion of having a ManageWiki setting to set $wgDefaultUserOptions['centralnotice-display-campaign-type-whatever'] = 0 for each campaign type. This would be useful by allowing to set a default user preference for individual wikis that makes central notices opt-in for each user, rather than opt-out. K599 (talk) 22:22, 10 June 2022 (UTC)

Additional suggestion: Make a page detailing CentralNotice
I would still like a response to the above section on campaign types, and also have another suggestion to make.

If campaign types come into use, a page that details central notices, mainly the campaign types as stated before, would help people understand what these notices are for. Some other info, like what Wikimedia's pages cover, would likely also be a bit helpful. And to allow people to easily find such a page, it should at least be linked from user preferences and any ManageWiki settings related to central notices. K599 (talk) 01:16, 19 February 2022 (UTC)

Again, problem with infoboxes
It's not the first time I post about this, be it on the Steward's or here in the community noticeboard. To cite the other times I posted about it: "After importing some .xml files from other wikis, I somehow managed to break all my infoboxes, as shown on this link: ".

Being honest, it was a long time ago that I imported these .xml files, and I don't really remember any specific details. In any case, it was said to me that I would have to make the wiki public for troubleshooting. That wouldn't be an issue. I hope that, this time, I can get some closure on this issue.

Any help is appreciated. -- IvanCastroTheFool (talk) 12:39, 10 May 2022 (UTC)


 * It's been more than a week, already. Does anybody have any ideas about how to solve this? -- IvanCastroTheFool (talk) 18:07, 22 May 2022 (UTC)
 * Still waiting. -- IvanCastroTheFool (talk) 22:19, 27 May 2022 (UTC)
 * And still waiting. Nobody has any ideas about this? -- IvanCastroTheFool (talk) 23:08, 6 June 2022 (UTC)


 * First question: Did you overwrite something important when you imported the xml files? If you did, then you'll need to choose which you want more - whatever is in those the xml files or the infoboxes. If you want the infoboxes more and you did overwrite something, you'll need to re-import the infobox template; see Importing Wikipedia infoboxes tutorial for the easiest way to make an xml file for infoboxes. --Robkelk (talk) 14:38, 10 June 2022 (UTC)

About special:RequestWikiQueue/24793
Excuse me. I don't know should writing this comment here, but I want my question answer. Why special:RequestWikiQueue/24793 wait yesterday to today? I don't know here system. other request accept, but my request late one day. Do you forgot it? Something cause be maybe. Though, I worry it. I'll ask, please answer. I can't speak English, so this comment may have angry you. And, I think only here in can communication, so wrote here. Long comment sorry. 段ボール (talk) 08:09, 28 May 2022 (UTC)


 * Olá @段ボール, A equipe da Miraheze se dedica ao máximo para responder todos os usuários, como a demanda é grande talvez possa demorar algumas horas ou dias para atenderem a sua solicitação, peço que seja mais paciente, eles não esqueceram de você, espero ter respondido sua pergunta, tenha uma boa noite. Genuino123 (talk) 22:09, 10 June 2022 (UTC)

Revisiting Extension:PdfBook
...now that we're closing in on the MW 1.38 era, and talk of this utility hasn't been touched upon on Miraheze in ages.

This contributor deployed PdfBook in a test run on Saturday, May 21, replacing the promising but much-flawed Display Title in his site's lineup. On-and-off reports of its ineffectiveness elsewhere have diminished its long-term prospects; while preparing this post, rendering with ?action=pdfbook at the end of a wiki URL has led to an error message when trying to view the output. On Android devices with Google Docs (like mine), this reads:


 * Cannot display PDF (Title.pdf is of invalid format)

...thanks to which I'm dropping it for good right after this goes to press. (Alerting developers Aran Dunkley and Igor Absorto, and XPosting this message on the extension's talk page, later on; also paging for any additional word.)

At Phabricator last December, Universal Omega himself remarked on its fate:

"PdfBook is mostly unmaintained, and not on Wikimedia Gerrit, so I don't see any fix happening there. We should consider removal."

A real shame, as something like it would sure come in handy for my future books. Let's hope it actually gets fixed soon enough.... Routhwick (talk) 11:32, 29 May 2022 (UTC) on your wiki and select "vector" as the default skin. See also phabricator:T9389 Naleksuh (talk) 00:45, 16 June 2022 (UTC)

Mobile view not right
I recently opened a wiki with articles imported from Wikipedia as XML (Mandaepedia). I imported all the modules and templates, but still the mobile view is off. I added the file to get the info boxes to appear correctly and that is basically the only thing working right. Also, the sidebar with collapsible lists shows the entities vertically, one below the other, making it too long if it is expanded affecting the rest of the article. Is there a file I need to add or adjustment I need to make to get the mobile view to show correctly as well as the sidebar with collapsible lists?

Thank you, Mandaepedia001 (talk) 19:06, 16 June 2022 (UTC)
 * What exactly is "off" in mobile view? Agent Isai  Talk to me! 02:51, 17 June 2022 (UTC)
 * Try to enable MobileFrontend. Cigaryno (talk) 12:28, 17 June 2022 (UTC)
 * I checked under the extensions, other tab, and the MobileFrontend is enabled. I am using the vector skin. Mandaepedia001 (talk) 15:22, 17 June 2022 (UTC)
 * 'Read', 'View Source', 'View history' tabs appear at the top of the mobile view followed by the entire sidebar (Main page, tools etc.) After scrolling down through that, you get to the article with the infobox and images not centered on the page. Here is an example of an article where you can see the mobile view and sidebar with collapsible list
 * Mandaepedia001 (talk) 15:43, 17 June 2022 (UTC)
 * I see the issue. Vector 2022 isn't designed to be responsive for mobile devices just yet. Because it's mostly a mobile-first extension, it does that because it doesn't really focus on phones. I suggest you set the mobile default skin to something else as Vector 2022 isn't really meant for phones just yet. Agent Isai  Talk to me! 03:59, 18 June 2022 (UTC)
 * I did as you suggested and changed the mobile skin to minerva which seems to have solved the problem. In desktop minerva skin, the sidebar with collapsible lists shows the links correctly, but is missing the small bullets that are supposed to separate them. Is there a way to correct that? Mandaepedia001 (talk) 16:17, 19 June 2022 (UTC)

Suggestion
Member in private wikis do have the right to change content, but they should have only the right to read Xerbam (talk) 21:09, 16 June 2022 (UTC)
 * Please note that I have moved this from the Meta administrators' noticeboard to the Community noticeboard where it's better suited. As for your enquiry, you can always revoke the  right from the   group to prevent editing.  Agent Isai  Talk to me! 02:51, 17 June 2022 (UTC)

MY NAME
My old name miraheze is still viewable. It's seen on redirects and in search engines on this wiki and other ones. Usually ones that rant about pointless things. Can you figure out a way?

ROLLBACK THIS POST AFTER IM DONE Vanished user 7e47db1e70d176137a1338195b6cd179 (talk) 01:44, 17 June 2022 (UTC)
 * We cannot help you with the search engines. They will index everything at their own pace and update them accordingly so you will have to wait. Agent Isai  Talk to me! 02:51, 17 June 2022 (UTC)
 * Per above with indexing. With redirects I've half a mind that acting on them would simply draw further attention. But feel free to drop an email to stewards@ with the name and perhaps they can be purged for confidentiality depending on the circumstances. --23:40, 17 June 2022 (UTC) Raidarr (talk) 23:40, 17 June 2022 (UTC)

Tasks submitted in Phabricator
I submitted a task in Phabricator T9360 and not a single thing has been resolved. Is this normal? And if not, what should I do? If I don't get an answer, I will move to a new wiki. Funa-enpitu（talk/Posting Record） 05:24, 17 June 2022 (UTC)
 * Please keep in mind that we're all unpaid volunteers and that technical issues take a while to debug, especially if not widespread. It seems you're the only one with that issue so it may suggest a local network issue. Please be patient but if you must, we do wish you all the best if you choose to move. Agent Isai  Talk to me! 06:57, 17 June 2022 (UTC)

Upgrade to MediaWiki 1.39 developer release/alpha
Hello, I think Miraheze should run the latest alpha/DR build of MediaWiki 1.39 4 days after the release of a build. Cigaryno (talk) 12:27, 17 June 2022 (UTC)


 * No way Miraheze is going to go to cutting edge without significant extension testing and a stable release to work from. --Raidarr (talk) 23:38, 17 June 2022 (UTC)
 * We won't upgrade the entire farm to MediaWiki 1.39 (we would quite literally break every single extension as MediaWiki 1.39 introduces many, many breaking changes that breaks about 95% of extensions) but we will definitely upgrade our beta cluster to begin testing for that version once the time draws near for it's release. Agent Isai  Talk to me! 03:57, 18 June 2022 (UTC)
 * By "break[ing] about 95% of extensions", what do you mean? --Routhwick (talk) 23:26, 18 June 2022 (UTC)
 * As the co-moderator of the largest wiki on Miraheze, I think that staying on the "bleeding edge" by installing alpha releases of software is a Very Bad Idea. All The Tropes needs a stable platform; we do not need the latest bells and whistles. --Robkelk (talk) 12:32, 18 June 2022 (UTC)

frblayout and frbmessages - not dismissible
The frblayout and frbmessages are used by Miraheze to solicit donations, but they are not dismissible on the other wikis like they are here on Meta. DrJaySensei (talk) 00:13, 19 June 2022 (UTC)