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)

Community Discussion: Wiki creators and creating wikis for themselves
Since an RfC would be too much for just one addition to the Wiki creator policy I am opening a Community Discussion here. As you all know, wiki creators are elected to serve the community and approve/decline wikis that are requested. They can in theory of course also approve their own wikis, but in my view for purposes of objectivity it would be preferred that they had another wiki creator do that.

However, what I'm proposing here isn't a complete ban on wiki creators creating their own wikis, it's simply the possibility for a Steward to remove a wiki creator if they are excessively create wikis for themselves and tend to not be creating wikis for other users.

The following would be added to "Revocation": A wiki creator's rights may also be removed by a Steward if they are mainly creating wikis for their own use and not focusing on their role of creating wikis for other users. Reception123 (talk) ( C ) 08:21, 7 December 2021 (UTC)

Support

 * 1)  as proposer. Reception123 (talk) ( C ) 08:23, 7 December 2021 (UTC)
 * 2)  Wiki creators should serve the community, not themselves. It wouldn't make sense if a wiki creator misused their privileges to create an excessive amount of wikis for themselves without any consequences.  Agent Isai  Talk to me! 08:23, 7 December 2021 (UTC)
 * 3)  The proposal pretty much covered it.  08:25, 7 December 2021 (UTC) ］ |
 * 4)  Why not?  Anpang   Talk   Stuff  08:27, 7 December 2021 (UTC)
 * 5) . This should stop wiki creator spam. TylerMagee (talk) 08:38, 7 December 2021 (UTC)
 * --Magogre (talk) 09:04, 7 December 2021 (UTC)
 * 1)  I don't really have to much to add, the post covered basically what I wanted to say on this issue. TigerBlazer (talk) 11:15, 7 December 2021 (UTC)
 * 2)  Ugochimobi (talk) 11:25, 7 December 2021 (UTC)
 * 3)  Don't get me wrong, I'm fine with wiki creators requesting wikis for themselves and self-approving it, but if it becomes excessive to the point of flooding the farmer log, then it does come off as either disruptive or somewhere between messy and cloggy like a clogged toilet. --DarkMatterMan4500 (talk) (contribs) 11:56, 7 December 2021 (UTC)
 * That's a fair point too, though I was more concerned with objectivity and creating more wikis for yourself rather than for other users. Since it's no secret what actions started this Community Discussion, I would point out that many requests that were made and 'self-approved' would have likely not been approved by another wiki creator, at least not by myself. Wiki creators also decline wiki requests if someone is requesting too many wikis, so it's definitely unfair that a wiki creator can create many wikis for themselves while regular users are told not to create an excessive amount. Reception123 (talk) ( C ) 12:07, 7 December 2021 (UTC)
 * Yes, that's very true. DarkMatterMan4500 (talk) (contribs) 13:50, 7 December 2021 (UTC)
 * 1) All users must respect the content policy and wiki creator is no exception YellowFrogger</b> (✉ Talk </b> ✐ UnEdits </b>) (Bring back patrolled)</b></b> 14:29, 7 December 2021 (UTC)
 * Well the Content Policy as such doesn't mention wiki creators creating an excessive amount of wikis for themselves at all, which is why I opened this Community Discussion, as there needs to be a separate ground beyond the CP removal ground. Reception123 (talk) ( C ) 15:44, 7 December 2021 (UTC)
 * that's right YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 23:19, 7 December 2021 (UTC)
 * 1)  Absolutely. I actually think it would be a good convention for a wiki creator to request a wiki and let another wiki creator approve it in the name of transparency, but I won't push for that here. --Raidarr (talk) 14:49, 7 December 2021 (UTC)
 * That's an interesting point yeah, I'm kind of undecided on that but related to what I say below I feel like if a wiki creator wants to create a wiki that they could see be declined by someone else they should wait for someone else to approve, but that's not really a clear question. Reception123 (talk) ( C ) 15:43, 7 December 2021 (UTC)
 * 1)  I agree with what is said above. Maybe this example is too extreme but it is like a judge deciding their own case. Here of course it is not nearly as serious or complicated but the principle still applies in that a judge is someone who is trusted and knows how to apply the law but that does not mean that they are trusted to apply it if they are involved in a case. In my personal view we are not being strict enough and I would go further than this proposal and vote for not allowing wiki creators to create their own wikis at all for reasons of impartiality; can someone really impartially interpret the Content Policy in regards to their own wiki? That is not however the subject here but in consequence I believe that it is perfectly desirable for a wiki creator to be removed if they are not adhering to their original "oath" which is to create wikis for other users, not for themself. I have seen the comments opposing the Steward discretion aspects of this proposal. While there is a point to the argument of not giving up everything to Stewards in this particular case I agree with what is said by Reception123 and believe that it would not necessarily be desirable to have a "direct democracy" model for these removals as is the case for other more positions. Sometimes it is necessary for the community to delegate their powers to Stewards and this situation is to me is one of those times. If Stewards are not trusted by the community then they should open a revocation request instead of attacking the discretionary powers of Stewards. Accordingly it is my strong view that it is not acceptable for a wiki creator to be focusing on creating multiple wikis for themselves and to not be creating almost any wikis for other users. --DeeM28 (talk) 09:23, 8 December 2021 (UTC)
 * 2)  I don't really see how this could be bad.  &mdash;Lakelimbo (talk)&emsp; 19:22, 15 December 2021 (UTC)

Oppose

 * 1) A wiki creator is someone who has the experience and trust to create wikis that can follow Miraheze policy, which you arguably can do best if you yourself are managing it. Whether or not people should be creating their own wikis is a seperate issue, but I don't think there is a distinguishment between doing so "mainly" and not. There is no obligation or commitment as a wiki creator, it is a volunteer position, and I do not support requiring people to "balance" with other wikis. Also, the proposed change is that any Steward can just take the permissions away unilaterally which is definitely a no-go. Changes like that should require consensus. Naleksuh (talk) 21:08, 7 December 2021 (UTC)
 * I also agree with you. No need for early revocation for a single basic reason YellowFrogger</b> (✉ Talk </b> ✐ Edits </b>)</b> 05:20, 8 December 2021 (UTC)
 * No one suggested that someone should be removed based on one instance and without warning. The suggestion that Stewards would take permissions away as they please suggests a lack of trust in the current Stewards to me which is a different issue altoghether.If there is not currently an obligation on a wiki creator to approve other users' wikis and not just create wikis for themselves, I think there should be, and this new addition to the policy would imply that. Stewards can already take permissions away unilaterally for violations of the Content Policy, so in that regard they already have a similar power, just limited to the CP. While "A wiki creator is someone who has the experience and trust to create wikis that can follow Miraheze policy" is true, what if a wiki creator has lost that trust because they're not creating wikis for users but just for themselves? There should be a way for them to be removed. Reception123 (talk) ( C ) 07:46, 8 December 2021 (UTC)
 * There should be a way for them to be removed. Yes, but that doesn't mean that way should be stewards unilaterally removing it. Also, removal should be because of creating wikis against policies, not by not creating enough wikis for people other than themself Naleksuh (talk) 01:05, 10 December 2021 (UTC)
 * 1)  if a wiki creator is only there approving their own requests, provided they are doing it properly, I see no problem with that - indeed it is beneficial to Miraheze as a whole as it means other wiki creators do not have to deal with them. If they are not doing so properly then a better proposal would be to ban wiki creators from approving their own requests. ~ El Komodos Drago (talk to me) 12:43, 10 December 2021 (UTC)
 * Well yes, the issue isn't about creating a few wikis for ones-self, it's basically about abusing the process and creating an amount of wikis for oneself that otherwise would have not reasonably been approved by any other wiki creator. While there is no hard rule, it is a convention that unless they have a good reason we don't really allow users to create a large amount of wikis for themselves. Reception123 (talk) ( C ) 07:00, 13 December 2021 (UTC)
 * Well propose that rule. It seems like you are trying to eliminate one behaviour by creating a rule banning an entirely separate one that seems (alone) to be harmless. This is bad rule making. ~ El Komodos Drago (talk to me) 11:04, 15 December 2021 (UTC)
 * 1)  – Mainly based on the Naleksuh's reasoning. I agree the removal should be performed if the wiki creator is creating wikis only for their own and/or against policy but it shouldn't be the unilateral decision of a steward to remove the rights without consulting the community. Stewards are trusted, but I do not feel comfortable with the rights being removed unilaterally by a steward if the user is elected by community. If community consultation added to the proposal, I'd completely agree with it. --Magogre (talk)  13:41, 10 December 2021 (UTC)
 * 2)  in part, per what others have said above, namely Naleksuh, Magogre, and El Komodos Drago, but also because I feel this proposal was made in response to a user who speaks little to no English, but who I might also add has created wikis for users and whose Content Policy understanding actually not that bad. As our only Chinese language wiki creator, if their bit was hypothetically removed by a Steward per this criterion, I feel they'd have a difficult time getting it back mainly because of their lack of Meta activity and command of the English language. As well, since the proposal is very, very vague, you potentially have a situation where one Steward might agree with revocation and another Steward might not. Moreover, though I generally prefer Steward discretion rather quantified details, I feel this is a case where it's better to be more explicit. What constitutes "for their own purposes"? One wiki? Ten wikis? 100 wikis? I guess I could potentially support something along these lines, but only an alternate proposal that (a) takes into account the above arguments, (b) quantifies specifics, (c) ideally is part of a larger RfC or an acknowledged prelude to a forthcoming RfC to amend the wiki creator inactivity and revocation clauses (i.e., for example, should the SRE revocation clause still exist? if so, under what conditions?), (d) takes into account the multilingual nature of Miraheze and Meta Wiki, and (e) requires at least super-majority (i.e., 75%) of existing Stewards to agree to the removal, if not unanimity, and only after, say, a thirty (30) day notice and remediation plan had been put forward to the wiki creator in question. Dmehus (talk) 07:37, 13 December 2021 (UTC)
 * To respond to your first point about the specific user I will admit I am not aware in respect of which user this request was made but I believe it is problematic for a wiki creator to speak no English especially if they are approving requests in English. I think it is quite obvious why such a situation is not desirable.
 * In regards to discretion I would currently support a wider discretion for Stewards to remove wiki creators generally beyond simply the Content Policy but based on the other opposes it appears to me that such a wide discretion is not desirable.
 * Regarding your proposal it appears to be too lenient for me. Why do wiki creators need to be given such a large measure of remediation options? If they are not creating wikis for other users they should be removed in my opinion and the community can reinstate them if that is what it wants. While there may be no appetite for this change my view is still that it would be simpler to not allow users to create their own wikis for reasons of impartiality.
 * To respond to the vagueness I am not sure how specifics would make sense in this context and how someone would be able to define a number of wikis that a person can create for themselves. I am confused as to the reason why you believe that in this case general Steward discretion is not appropriate; I think it is.
 * In conclusion my general view is that wiki creators need to be held to a higher level of scrutiny and it is better to remove more wiki creators if that is necessary to preserve the integrity of the process. Wiki creators can always be added back if they pledge to respect the rules and conventions in the future but I disagree with being overly lenient if they are not serving the community but are serving themselves. DeeM28 (talk) 18:43, 16 December 2021 (UTC)
 * The issue, though, is for the user in question, there's not really been any Content Policy issues in their wiki approvals. Dmehus (talk) 05:49, 20 December 2021 (UTC)
 * As for the discretion, I'm not necessarily opposed to Steward discretion, but this was hurried and rushed proposal, which even Reception123 admitted to me on IRC, that did not consider all of the procedural ramifications. What if one Steward disagrees with another Steward's removal? Can the rights be re-added without a community vote? Without some sort of readdition clause, or a thorough remediation and corrective action plan, we'd essentially be substituting one form of mob mentality !voting with another. I do agree with you that I feel for some positions, direct democracy is not the best form of appointment. I would be supportive of granting greater authority and discretion to Stewards to remove the  for more than just a defined inactivity clause or repeated Content Policy understanding and application issues, if we also allowed for Stewards to grant the   bit, perhaps on a temporary basis, where the request tends devolve into mere !voting based on English Wikipedia essays, so as to allow reasonable candidates, perhaps candidates who speak languages other than English, a track record by which the community could assess, from a practical standpoint, whether the user can consistently apply their understanding of Content Policy correctly. So, as an example, in such cases, Stewards could be granted the discretion to grant the bit on a temporary basis (say, for a maximum of 30 days), after which the bit would be automatically removed. Either shortly before their temporary status was due to expire, or after it had expired, the candidate would then be able to have a track record to cite to the community in standing for election as a permanent wiki creator. Additionally, I'm more inclined to support some sort of Meta Wiki only activity for the purposes of the inactivity clause, as we have some wiki creators who are globally active, but have not created one wiki. Thus why I feel a more major overhaul of the policy is needed. Dmehus (talk) 06:07, 20 December 2021 (UTC)

Comments

 * While I don't see the problem with self-approving wiki requests that other wiki creators have self-requested, it becomes a distraction to all others who would want to review the wiki request if it becomes excessive. --DarkMatterMan4500 (talk) (contribs) 12:07, 7 December 2021 (UTC)
 * I think it's worth mentioning that the case which lead to this conversation is a holdout of a time when WCs were appointed with little in the way of community input, and it was done two days before the process changed. Just an observation, not to fault the Steward at the time who made the call. --Raidarr (talk) 14:45, 7 December 2021 (UTC)
 * Indeed, the proposal may serve a limited purpose (for a single user) but I think either way it would make clear to any future wiki creators that when creating wikis for themselves if they choose to do so they should take the chance to think: would another wiki creator really have approved this if I was a regular user? Though of course its main point is limiting excessive wiki creations for ones-self which would not otherwise be approved of by any creator Reception123 (talk) ( C ) 15:42, 7 December 2021 (UTC)
 * By all means, this is very reasonable to do regardless of the 'catalyst' to propose. Plus it solidifies the precedent for new requests in the future. --Raidarr (talk) 15:55, 7 December 2021 (UTC)
 * Reception123 said he's open to having this essentially serve as a non-binding community input session, rather than any sort of binding policy-setting discussion, in view of the strong arguments presented in opposition. So essentially, the comments expressed herein would help to refine the aims of the proposal in a broader RfC that looks at reforming the wiki creator policy, perhaps in January or something. Based on the conversations I've had with Agent Isai on IRC, he seemed receptive to the idea as well. Dmehus (talk) 05:54, 20 December 2021 (UTC)
 * As pointed by the Naleksuh, I also believe a steward should not remove the rights unilaterally and I'd like it if somehow there should be a fixed time for the community to comment on the removal. A note on the AN or SN should be sufficient and anyone should be able to request the revocation of other's rights upon misuse. --Magogre (talk) 05:17, 8 December 2021 (UTC)
 * As commented above, this is already possible for Content Policy violations so this isn't some large new change that gives Stewards significant extra power. While this was never discussed before explicitly, my feeling is that the reason for why wiki creator revocations are Steward discretion rather than community consensus/vote is to avoid mob-mentality, for example people teaming up to remove a wiki creator because they disagree with their specific approval/disapproval of wiki requests. Again, that's just my view, it was never actually discussed in this way. Though either way, as I say above, if you disagree with the current Steward discretion that exists for revocation then that's a different issue because it already exists for CP violations. Reception123 (talk) ( C ) 07:50, 8 December 2021 (UTC)

Do you think this RFC would stand a chance?
I have an idea for an RFC (Requests for Comment) about changes to the Content Policy, but and  suggested that I should ask other users first to prevent it from being snowballed, and Agent Isai specifically suggested I go here to ask. Anyway, here are my ideas for changes: FatBurn0000 (talk) 02:28, 12 December 2021 (UTC)
 * 1) Change the rule "Miraheze does not host wikis with the sole purpose to spread unsubstantiated insult, hate or rumours against a person or group of people" to "Miraheze does not allow any pages on wikis with the sole purpose to spread unsubstantiated insult, hate or rumours against a person or group of people" because we do not need any pages with this purpose, whether or not the wiki itself is made to do so.
 * 2) The rule "A wiki must not create problems which make it difficult for other wikis" should have multiple changes:
 * 3) The rule should apply to all wikis, not just Miraheze wikis, because no wiki should be duplicated; the internet doesn't need two versions of wikis. I understand that it is hard to stop the entire internet from duplicating wikis, but it is something that should be stopped, and Miraheze should play a part in stopping it. I do think that since there are no staff for the entire internet and as a result corrupt staff exist on various sites (including wikis), there can be exceptions for non-Miraheze wikis. However, a user must go through every single option in order before requesting this to be an exception (unless the options say they can do otherwise):
 * 4) Review the wiki's quality. If you want to make an exception, then the most ridiculous reason to duplicate wikis is because they have bad quality. If they have bad quality, then they can be improved. If the changes that need to be made are not against the rules, then just try to clean up the wiki.
 * 5) If the change would concern the rules or requires a lot of cleanup, then ask the owner of the wiki (note that what counts as an "owner" includes the founder, a user who adopted the wiki [this only applies to wikis that are hosted by another wiki-hosting site since independent wikis cannot be adopted], the only bureaucrat [if there is only one bureaucrat] and of course, a user who is stated to be the "owner") or, if there is no bureaucrat who would be considered the "owner", the most active bureaucrat, and talk to them about the change. If there are no bureaucrats or all of the bureaucrats are inactive, you should adopt the wiki. However, note that you should try contacting the bureaucrats first regardless, and if the wiki is independent, you are now free to request an exception.
 * 6) If the bureaucrat you contacted disagrees with you, then do not immediately decide that the bureaucrat is corrupt. Try to have a reasonable discussion with them. If you tried to adopt the wiki and your request was denied, unless you agree with the reason, try to continue talking with the user who denied your request and again, don't immediately decide they're corrupt.
 * 7) If the bureaucrat acts in a way you consider unfair, if you can, calmly talk with them about it. If the same happens with the user who denied your request, do the same thing with them.
 * 8) If the bureaucrat continues to be unfair, then it depends on the case on what you do. If the wiki is hosted by another wiki-hosting site, talk to the users with the highest position (whether or not that is stewards, staff or something else) about dealing with the abusive bureaucrat. If the wiki is independent, however, you are now free to request an exception. If the user who denied your request continues to be unfair, then it depends on what position they have. If they have the highest position, then again, you are now free to request an exception. If they do not, however, and someone is above them, they can be reported to a user with the highest position.
 * 9) If the user with the highest position disagrees, then again, try to have a full conversation with them.
 * 10) If the user with the highest position continues to be unfair after a discussion and there is no point in discussing it anymore, then you should ask the stewards of Miraheze, and if they agree with you, then your wiki can become an exception. In case you're wondering where you can request an exception, request it at Stewards' noticeboard before requesting the wiki, and if your request is approved, then you can now request the wiki at Special:RequestWikiQueue, and make sure you link to the discussion for reference.
 * 11) Although I believe this already applies, I think it should be made more clear that the rule does not just apply to duplicating wikis, but also to the following:
 * 12) Creating pages on wikis that contain destructive criticism towards the wiki.
 * 13) Having any content on wikis that the wiki's staff members have stated that they do not want.
 * 14) There should be a rule that states "A wiki must not have pages that are likely to cause drama". Pages that are considered likely to cause drama are:
 * 15) Negative pages about obscure users on the internet
 * 16) Pages about people who do not want a page about them (this does not apply to informative pages)
 * "A wiki cannot create problems for other wikis". But this already applies to all wikis including non-Miraheze external ones. Does this include humor wikis? Can't they also create an article about another wiki? But all the content of a humor wiki shouldn't be taken seriously, that's a fact. YellowFrogger</b> (✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 02:37, 12 December 2021 (UTC)
 * I agree that humour wikis should be able to create pages about other wikis, but I don't think I said that they couldn't; I only said that if the staff members don't want it they can say that won't allow it. FatBurn0000 (talk) 03:22, 12 December 2021 (UTC)
 * Also, are you sure that Miraheze doesn't allow duplicates of non-Miraheze wikis? According to Raidarr, there are multiple duplicates of Fandom wikis. FatBurn0000 (talk) 03:34, 12 December 2021 (UTC)
 * 1. is intended to address systemic issues. The change is not necessary. The wording is deliberate to reiterate our stance; any pages are included by this wording, and are considered 'content policy issues' already. They can be reported and addressed (by removal at request or if systemic and unaddressed reasonably, by wiki lock until fix or removal).
 * 2. can merit additional, if careful language, so lets see:
 * 2.1. I disagree that Miraheze should gatekeep on this. For one, many Fandom wikis have moved to Miraheze, and Fandom is notorious for being sluggish or unwilling to delete wikis for their ambient revenue, nonetheless the entire staff are typically inclined to move in bypass of your written process altogether. For two, communities with severe enough drama and legitimate enough community schisms should not be subject to your proposed bureaucratic process, especially if the wiki intends to make significant enough stylistic or fundamental changes that would not be feasible for another platform. Again, the level of possibilities make this a potential issue. All in all my stance here is not unlike my stance on politics - 'lets worry about ourselves before worrying about other (nations)'. We actually do have a topical duplication problem in several cases locally even if they don't match the strict requirements that would make content forking an issue, and we could do better from a wiki creation standpoint to be aware of and refuse probable content duplication on Miraheze as well as work to remediate the ones that exist. There are a variety of wikis with strongly overlapped purpose as has researched before. In all I would have to oppose based on the broad stretch of this language, and disagree that it is our role to enforce it anyway.
 * 2.2. 'destructive criticism' is a dangerous precedence for 'your criticism is too steamy for us, delete'. For one that is more of a conduct matter, since it does not pertain directly to wiki content. For two this should be addressed by the local community and local rules. It is not the Content Policy's job to moderate at this level. Indeed, 2.2 here is entirely out of scope for the CP as a whole imo. If you don't like the criticism, rebuke it or ignore it, or if it is sufficiently toxic, remove for incivility and unconstructive purpose, all of which is possible with healthy local management.
 * 3. Already covered in full imo by the premise of the existing rule. Frankly I think this is an attempt to enable your lawyering to bring back a fundamentally problematic concept - pages about people with a critical or negative focus - as a legitimate thing since you will have made the policy more specific, but not actually addressed this detail.
 * Not to assume bad faith, but I believe these changes are born of a desire to enable certain forms of content and to realize a more personal vision of what Miraheze should do and allow which would be more controversial if expressed in full to the wider Meta community. Part of why I suggested to have the concept reviewed first is so this could be expressed informally and if possible, changes made to talk out of this line of thought or even make it malleable instead. Unfortunately given the evident purposes of these points and their niche appeal, I'm afraid this one is not likely to pass in addition to what would be my personal outright oppose in a live RfC. --Raidarr (talk) 11:04, 12 December 2021 (UTC)

FatBurn0000 (talk) 22:03, 12 December 2021 (UTC)
 * 1) Well, it should still be made more clear.
 * 2) This is why there are exceptions to this rule. Also this doesn't necessarily apply to just Fandom wikis.
 * 3) Fair enough.
 * 4) Not all criticism and negativity towards obscure users is guaranteed to be destructive, it is just a common problem that they will be, which has before happened with the Outcasts and other user reception wikis (including Crappy GachaTubers Wiki, a wiki that is unfortunately still open).
 * 1) Not all criticism and negativity towards obscure users is guaranteed to be destructive, it is just a common problem that they will be, which has before happened with the Outcasts and other user reception wikis (including Crappy GachaTubers Wiki, a wiki that is unfortunately still open).
 * I feel like I agree with FatBurn on this, if this is an existing rule, then it should be stated in the content policy. At the very least I think that "sole purpose" is slippery wording. ~ El Komodos Drago (talk to me) 11:22, 15 December 2021 (UTC)
 * And you. Are you going to open an RfC or not? <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:32, 12 December 2021 (UTC)
 * There should be a rule stating, "Only one Miraheze wiki should exist for a topic," because duplicate wikis exist. Tali64³ (talk) 00:41, 13 December 2021 (UTC)
 * What I am suggesting is that the rule should be for all wikis, not just Miraheze wikis, with a few exceptions for non-Miraheze wikis in case of abusive staff. FatBurn0000 (talk) 08:21, 13 December 2021 (UTC)
 * A user named Blubabluba9990 opened an RfC <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 00:00, 14 December 2021 (UTC)


 * 1) There isn't any issue with the creation on Miraheze of a wiki that already exists somewhere on the internet. Some proprietary wiki host having a certain wiki does not give them the rights to it.
 * 2) I'm not entirely sure what you're referring to by "destructive criticism", but being able to criticize a wiki on that wiki is essential to accountability.
 * 3) There is no need for a rule such as 2.2.2, as wiki's generally have some form of content policy or guidelines as to what's allowed. Furthermore, the terminology "staff members have stated that they do not want", as that seems to imply that a wiki belongs to its staff, not its community. — Arcversin (talk) 19:52, 14 December 2021 (UTC)

FatBurn0000 (talk) 21:56, 25 December 2021 (UTC)
 * 1) How is there "no issue" with it? There is no need for two versions of one wiki on the internet.
 * 2) What I am saying is, the pages should not suggest that due to the flaws, users should go against the wiki and possibly fork it.
 * 3) Fair enough.
 * There is no issue with it because while it's generally not a good thing, the community of editors around a particular topic isn't bound to a particular platform, and migration away from Fandom is a positive. Also, wikis don't have "owners", so you won't want to use that word in any proposals. — Arcversin (talk) 23:07, 25 December 2021 (UTC)
 * There are exceptions in certain cases, but wikis should still not have duplicates anywhere unless it is truly necessary. If there is a fair enough reason to fork a wiki from another site, then again, exceptions can be made. FatBurn0000 (talk) 05:12, 26 December 2021 (UTC)
 * Whether a wiki exists some other place on the internet isn't, apart from copyright, relevant to whether Miraheze will host a wiki. It might not be a good thing for communities to be split, but it's best for such situations to be sorted out by the communities themselves, via migration of community members, as opposed to external interference. For other Miraheze wikis, we have the fork provision of the Content policy, but for external wikis, we want to support communities getting out of places like Fandom. — Arcversin (talk) 16:08, 26 December 2021 (UTC)
 * That still isn't a reason to duplicate a wiki. FatBurn0000 (talk) 21:38, 27 December 2021 (UTC)
 * Then please explain your reasoning. — Arcversin (talk) 00:22, 28 December 2021 (UTC)
 * My reason why I would like no wikis to be duplicated is because there is no need for more than one wiki about one topic. Most issues with wikis can be dealt with. FatBurn0000 (talk) 22:28, 28 December 2021 (UTC)

Re: Proposal 3
This is largely covered by the existing rule that "Miraheze does not host wikis with the sole purpose to spread unsubstantiated insult, hate or rumours against a person or group of people". With regards to 3.1, I'm not sure that obscurity should be a big issue - obviously for identifiable individuals there is a GDPR/right to erasure issue here. 3.2 is basically entirely covered and again GDPR/RTE. ~ El Komodos Drago (talk to me) 17:07, 16 December 2021 (UTC)

UI compacting the main navigation menu
Hi! I would love to see main navigation menu on the side be more compact and would suggest removing repetion from 3 sections to be displayed in this way:


 * Request:
 * new wiki
 * new feature
 * adoption
 * RfC's
 * Noticeboard:
 * Community
 * Stewards'
 * Meta Adminis.
 * Miraheze:
 * FAQ
 * Help Center
 * Categories

...what do you think? ZBlace (talk) 07:41, 16 December 2021 (UTC)


 * Isn't it the same? or you meant shortening the text to that? <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 08:01, 16 December 2021 (UTC)
 * YES - shortening the text to this version. I think it makes huge difference in mobile access, visibility of Donation link (which is super low at very end) and maybe a little bit in traffic :-) I think also most basic color coding would bot hurt, but that is more complex to negotiate due to color-blind people and branding issues. ZBlace (talk) 08:15, 16 December 2021 (UTC)
 * Why's meta administrators noticeboard with a "i" and fullstop? "Meta Adminis." Typo? And new wiki, new feature, adoption are spelled with no capital letter.
 * Can it be changed to:
 * Requests:
 * Create wiki
 * Request feature
 * Adopt wiki
 * RfC
 * Noticeboards:
 * Community
 * Stewards'
 * Meta admins'
 * Miraheze:
 * FAQ
 * Help center
 * Categories
 * Also, it'd be better if it was a preference instead of everyone getting the shortened sidebar. And another suggestion: move the Donate to Miraheze to the Miraheze: category and make it "Donate" in the shortened version. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> AP 📨 09:07, 16 December 2021 (UTC)
 * Just from the main menu down it? I don't want Random page removed (which I like to keep squishing to see some pages) <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 19:32, 16 December 2021 (UTC)
 * Yes and Sure. I also like RandomPage on Wikis since C2.com start :-p
 * How can this proposal get picked up? --ZBlace (talk) 17:53, 24 December 2021 (UTC)
 * @ZBlace It's addicting to do that. And why are you wanting to change? The current one looks pretty good, and I don't know where you can make the proposal either, if it's on the Miraheze server on Discord, with RfC or on SN or AN (administrators noticeboard, interace admins can change MediaWiki:Sidebar), so it would be nice if you send there. --YellowFrogger (Talk — ✐) 19:50, 24 December 2021 (UTC)
 * Reasoning? Check my #2post in thread. --ZBlace (talk) 20:41, 24 December 2021 (UTC)
 * I like the spirit here, of using fewer words to convey the concepts. Especially in the noticeboards area, spelling out 'noticeboard' is not really necessary. I do think the 'adoption' wording should change, as it's no longer appropriate for what the page does (but that requires that the page is moved to a renamed version as well, an action that is still pending). I would pick bones with exact choices of words however, and would rather see it explored further if we can get confirmation that a Meta Admin would like to pursue this or raise this to a Meta RfC. Raidarr (talk) 00:48, 25 December 2021 (UTC)
 * @Raidarr thanks for positive feedback. I would also love to hear of any Meta admin now. --ZBlace (talk) 14:58, 25 December 2021 (UTC)
 * Raidarr, this is the shortcut. Good for lazy people looking for a shortcut like this and therefore redirection with these shouldn't be eliminated like Hose Keeping or maintenance, etc. And in response to the above user, admins (and even stewards) unfortunately get that way most of the time, but I don't think it needs to go to the point of a RfC --YellowFrogger (Talk — ✐) 15:15, 25 December 2021 (UTC)
 * I'm afraid I don't understand what you're referring to with this comment, except for the RfC bit. --Raidarr (talk) 15:49, 25 December 2021 (UTC)
 * I was quoting about what you talked about above (spirit of using abbreviated words), this is something from the template:shortcut --YellowFrogger (Talk — ✐) 02:19, 26 December 2021 (UTC)
 * I was quoting about what you talked about above (spirit of using abbreviated words), this is something from the template:shortcut --YellowFrogger (Talk — ✐) 02:19, 26 December 2021 (UTC)

Add Interwiki links to my two Wikis
Hi, I want to add Interwiki links to my two Wikis. The detailed information is as follows.

Wiki to be applied:diamodocs.miraheze.org

Prefix (iw_prefix):dw

Url (iw_url): https://diamowiki.ga/wiki/$1

iw_local:1

Prefix (iw_prefix):hs

Url (iw_url): http://imdchs.rf.gd/$1.html

iw_local:1

Prefix (iw_prefix):hsstudy

Url (iw_url): http://study.imdchs.rf.gd/archives/$1

iw_local:1

Prefix (iw_prefix):dcm

Url (iw_url): http://iamdiamochang.ga/blog/$1

iw_local:1

Prefix (iw_prefix):dcmeta

Url (iw_url): http://iamdiamochang.ga/blog/$1

iw_local:1

Wiki to be applied:diamowiki.ga (diamowiki.miraheze.org)

Prefix (iw_prefix):hs

Url (iw_url): http://imdchs.rf.gd/$1.html

iw_local:1

Prefix (iw_prefix):hsstudy

Url (iw_url): http://study.imdchs.rf.gd/archives/$1

iw_local:1

Prefix (iw_prefix):dcm

Url (iw_url): http://iamdiamochang.ga/blog/$1

iw_local:1

Prefix (iw_prefix):dcmeta

Url (iw_url): http://iamdiamochang.ga/blog/$1

iw_local:1

Thanks. @Diamochang - talk | [mailto:diamochang@gmail.com email me] - 01:19, 18 December 2021 (UTC)


 * This is ✅ at this time, you can visit  and   for the logs. Ugochimobi (talk) 21:47, 18 December 2021 (UTC)

Errors
What errors are you facing? Agent Isai Talk to me! 10:51, 19 December 2021 (UTC)
 * 1) Trying to create or delete this page leads to an error.
 * 2) Trying to import valid XML files also leads to a similar error. Ora &#38; D (talk) 10:44, 19 December 2021 (UTC)


 * 1. Create:
 * The revision #0 of the page does not exist.
 * This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log.
 * Delete:
 * Fatal exception of type "LogicException".
 * 2. Fatal exception of type "Wikimedia\Rdbms\DBTransactionError". Ora &#38; D (talk) 11:00, 19 December 2021 (UTC)
 * This probably should be moved to Phabricator, noting the fatal exception, linking to the permalink to this thread. Dmehus (talk) 06:44, 20 December 2021 (UTC)
 * Thanks. It's being handled there. Ora &#38; D (talk) 16:52, 20 December 2021 (UTC)

Block log message not changing
I was trying to change the block log message for a wiki I run (Decyclopedia), and I noticed that the block log message wasn't changing. I tried looking at MediaWiki help pages to try to figure the problem out. I'm editing MediaWiki:Blocklogentry on that wiki. Tali64³ (talk) 18:26, 20 December 2021 (UTC)


 * The message appears to be MediaWiki:Logentry-block-block. I am not sure where, if any, MediaWiki:Blocklogentry is actually used. By the way, using uselang=qqx parameter in the URL will tell you the names of all the messages used on the page. Dylsss (talk) 19:50, 20 December 2021 (UTC)

My ban, and mental health.
im still around thankfully. Wishing all a merry Christmas. Sorry to be a nuisance but all my wikis are dead, can i possibly get my ban lifted or lightened??? Thank you all. Take care. SperosDurrell (talk) 02:26, 21 December 2021 (UTC)


 * You can undo a wiki inactivity in Special:ManageWiki/core of your wiki <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 02:28, 21 December 2021 (UTC)
 * just want to start fresh that's all. Thanks. SperosDurrell (talk) 02:29, 21 December 2021 (UTC)
 * It's great to see you around but it would be nice for you to focus on the wiki you already have. Agent Isai  Talk to me! 02:31, 21 December 2021 (UTC)
 * which one lol? There all dead.... SperosDurrell (talk) 02:34, 21 December 2021 (UTC)
 * link, me??? SperosDurrell (talk) 02:38, 21 December 2021 (UTC)

Mejoras en la piel vector / Improvements in skin vector
Hola. He realizado una propuesta sobre mejoras de la piel vector pero fue desetimada porque excede el alcance técnico de Miraheze.

Encontré que este asunto se está desarrollando en MediaWiki y existe una consulta a la comunidad: Reading/Web/Desktop Improvements/Third prototype testing. Todos pueden participar y experimentar.

Esperemos que pronto se generen los cambios para disminuir la cantidad de caracteres por línea. Lo sugerido es entre 45 a 75. Actualmente, en pantallas de más 1300px caben más de 130 caracteres por línea. La Wikipedia francesa ya adoptó un cambio muy favorable en la piel vector. Saludos a todos. ¡Felicidad y prosperidad! Hugo Ar (talk) 15:27, 21 December 2021 (UTC)


 * Translated by Google Translator


 * Hello. I have made a proposal on vector skin enhancements but it was rejected because it exceeds the technical scope of Miraheze.


 * I found that this topic is being developed on MediaWiki and there is a community query: Reading/Web/Desktop Improvements/Third prototype testing. Everyone can participate and experiment.


 * We hope that the changes will be generated soon to reduce the amount of characters per line. The suggested is between 45 to 75. Community Wishlist Survey. Currently, screens larger than 1300px can fit more than 130 characters per line. The French Wikipedia has already adopted a very favorable change in vector skin. Greetings to all. Congratulations and prosperity! Hugo Ar (talk) 15:27, 21 December 2021 (UTC)
 * You are trying to switch to the new vector, (as well as the French Wikipedia and Portuguese Wikipedia) and take the old one (legacy vector which is the current one), bu the English wiki and the mediawiki site haven't even done that yet, would be an interesting idea, but let's wait for new updates, both on mediawiki and also on high traffic sites, as the new version is a beta <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 16:56, 21 December 2021 (UTC)


 * Hola. Al parecer puede efectuarse el cambio con esto: / Hello. Apparently the change can be made with this:

$wgVectorDefaultSkinVersion = '2'; $wgVectorDefaultSkinVersionForExistingAccounts = '2'; $wgVectorDefaultSkinVersionForNewAccounts = '2'; $wgVectorIsSearchInHeader = true; $wgVectorLanguageInHeader = true; $wgVectorUseWvuiSearch = true;
 * Saludos / Greetings Hugo Ar (talk) 19:11, 21 December 2021 (UTC)

Can I limit namespaces?
I dont necessarily need to do this, but it may be nice, could I set user group rights in such a way that some groups can only edit certain namespaces? If not thats not a problem for me but was just wondering. Or maybe limit certain namespaces to certain usergroups? (excluding the editprotected and edit semiprotected userrights). Thanks for the advice! EmperorOctopus (talk) 22:18, 21 December 2021 (UTC)
 * You can change in Special:ManageWiki/namespaces page of your wiki, select clicking in "submit" (If you choosed a namespace) and it will have a box with the name: Which userright should be needed to edit this namespace? ($wgNamespaceProtection). You type some user right in it <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 22:32, 21 December 2021 (UTC)
 * Thank You! Ill look when I get home. EmperorOctopus (talk) 01:58, 22 December 2021 (UTC)
 * Yeah, so that only has the options for editprotected and editsemiprotected and editinterface. Again what Im asking may not be possible, but Could I limit a new namespace to a custom usergroup? If not that's fine, I'm just curious. Thanks, EmperorOctopus (talk) 03:31, 22 December 2021 (UTC)
 * I will see, thanks <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 03:38, 22 December 2021 (UTC)

template infobox election not working
Hi, when I try to make the infobox election template it doesnt work and says "Script error: No such module "documentation".Script error: No such module "Check for unknown parameters"." And whenever I put with {Infobox election} (with two of these brackets{ on each side)it just says ""Template:Infobox election""

Any help will be appreciated, thanks Papito19 (talk) 00:52, 22 December 2021 (UTC)
 * When "No such module" error appears, it is because there are no modules to make the infobox work. To fix this, do the following, for example, when EX: "Error no module of this type: Yesno", then you will have to create a module with the name yesno from Wikipedia. Anything invite me to check your wiki infoboxes <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 01:05, 22 December 2021 (UTC)
 * where do you put "yesno" sorry im new Papito19 (talk) 01:59, 22 December 2021 (UTC)
 * Invite me to your wiki for me to review if you want <b style="color: #1965e0;">YellowFrogger</b> <b style="color: #069404;">(<b style="color: #069404;">✉ Talk </b> <b style="color: #069404;">✐ Edits </b>)</b> 03:38, 22 December 2021 (UTC)

EditNotify
Hello! ManageWiki has an EditNotify extension. As I understand it, it allows you to notify about fresh changes through the Echo interface. But when I connected it on my wiki, I did not find anything like this. So what does this extension do? DecabristM (talk) 10:12, 23 December 2021 (UTC)
 * Hello! The extension allows registered user to get notified for:

All users who are subscribed for any of the event listed above will be notified for them with a simple alert message (Echo notification) as well as an email. The possible sets of pages for which users can choose to be notified are: Source: https://www.mediawiki.org/wiki/Extension:EditNotify --YellowFrogger (Talk — ✐) 22:44, 23 December 2021 (UTC)
 * Creation of new pages
 * Edit to existing pages - It includes notification to all changes.
 * Change in specific template field - Users get the notification when there is a change in template field
 * Change in specific template field to specific template value - Users are notified when there is a change in template field value
 * All pages - keep track of change or creation of all pages.
 * All pages in one or more namespaces
 * All pages in one or more categories
 * All pages in one or more categories
 * I saw it. I don't understand where the list of attendees is configured to receive these notifications. The documentation only offers a way to change the system files, which I cannot do. DecabristM (talk) 09:07, 24 December 2021 (UTC)
 * Please file a Phabricator task and we'll help you set it up after Christmas. All config files are public but we'll be happy to help you make the relevant changes and deploy it.
 * Side note: I'm not 100% sure why something that relies so heavily on setup by us is available for you to turn on. ~ RhinosF1 - (chat)· acc· c -  09:35, 24 December 2021 (UTC)
 * I think the best way would be to let the bureaucrats configure this extension via ManageWiki or remove it from those available on ManageWiki. DecabristM (talk) 11:21, 25 December 2021 (UTC)
 * I fully agree that getting it in ManageWiki somehow needs to be done but we're unfortunately without our main developer at the moment and it's the middle of the festive season. ~ RhinosF1 - (chat)· acc· c -  11:24, 25 December 2021 (UTC)
 * I sent a request to the phabricator. DecabristM (talk) 11:58, 25 December 2021 (UTC)

Remove the space between my two tabs
Hi there, I have created two templates, unfortunately there is a gap between them, as you can see on this page : https://fiction.miraheze.org/wiki/Gal_Gadot#R%C3%B4les_principaux I would like to have them "glued" together. How do I remove the space? Thanks in advance. Darkrai18 (talk) 11:46, 23 December 2021 (UTC)


 * You mean you want the 2 tables to be sticked together? <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 11:49, 23 December 2021 (UTC)
 * Basically, yes. Darkrai18 (talk) 12:01, 23 December 2021 (UTC)
 * Something like this:

Which is:


 * Explaination: Tables are seperated because they have margin values, here in the style= css the top and bottom margins have been set to 0, but the bottom border of the top table will still overlap the top border of the bottom table which will make the border thick so the bottom margin of the top table needs to be -1 instead of 0. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 12:34, 23 December 2021 (UTC)
 * I did not understand everything... Concretely, what do I have to change ? Darkrai18 (talk) 12:55, 23 December 2021 (UTC)

Hello, Darkrai18
 * Code
 * Result

Greetings. Hugo Ar (talk) 14:46, 24 December 2021 (UTC)
 * To add, if you want the width of the 2 tables to be matching, you can use 1 table:

Which results in:

Interwiki table
Could you please In the Interwiki table of XComhghall Wiki?
 * 1) Add the prefix   to , and
 * 2) Delete the interlanguage prefix  ,

Thank you very much. — XComhghall (talk) 22:35, 23 December 2021 (UTC)
 * --YellowFrogger (Talk — ✐) 22:40, 23 December 2021 (UTC)
 * This is ✅, thanks. --  Joseph  TB  CT  CA   23:08, 23 December 2021 (UTC)

Huggle
I wondered how to use Huggle with Miraheze. I'd like to continue anti-vandalism efforts easier for the wikis that get vandalized the most. -- Cheers, Bukkit ( Talk • All Contribs ) 00:28, 24 December 2021 (UTC)
 * The Huggle is a great alternative to Twinkle yes, but I ask if it needs to be rollback to revert in Huggle. And also: the recent changes here from Meta is a bit stalled on vandalism; there is not much vandalism here. Even so, vandalism starts mainly with IP addresses. --YellowFrogger (Talk — ✐) 00:39, 24 December 2021 (UTC)
 * Huggle is a tool which was designed with the Wikimedia movement in mind. It seems to require server-side software to be deployed and configured across multiple wikis so this is something that cannot be used on Miraheze. Agent Isai  Talk to me! 00:43, 24 December 2021 (UTC)

Request for Feedback: Adding new default extensions
Community members,

SRE desires to hear your thoughts and opinions on adding new 2 extensions to the default library of extensions enabled on all wikis by default. The proposed extensions are Purge and WikiSEO.

The Purge extension adds an extra button to the "More" dropdown menu which allows for users to clear the page cache easily instead of manually having to append  to the end of page URLs in order to force clear the cache. The ability to see this button can be revoked from users if desired and assigned to admins instead or the extension can be completely disableable if desired by wiki bureaucrats. Note that even if this extension is not enabled, users can always append  at the end of page URLs to force clear the cache, this extension only makes it easier to clear the cache instead of having to go through the hoops.

The WikiSEO extension extends MediaWiki's default SEO capabilities to allow wiki's to rank better on search engines by default. MediaWiki, out of the box, is horrible at SEO and as such, some wikis take very long to get on search engines or rank very poorly which leads to user dissatisfaction with their wiki. The WikiSEO extension automatically helps generate a description for pages and even automatically inserts an image if needed which allows for nicer looking Discord/Facebook/Twiiter embeds and higher search engine rankings. The extension also allows for wiki operators to manually change the description of a certain page, the image displayed on embeds, and certain other things. Note that even if this extension is not enabled, this will not prevent search engines from indexing your wiki, it will just preclude it from ranking well or correctly on search engines. To prevent indexing from happening, you can change a setting in ManageWiki which would render WikiSEO useless. This extension, like Purge, would be disableable via ManageWiki. We wish to enable this extension by default so that wiki's rank well on SEO out of the box instead of having users guess why their wiki's not doing well on search engines.

Please let us know what you think about this and if you have any thoughts or concerns, thanks! Agent Isai Talk to me! 04:43, 27 December 2021 (UTC)
 * Definitely not enabled by default, both because there should be little to no extensions out of the box and because WikiSEO should not be messing around with the HTML without explicit enabling of the extension. No objections to either one as an option. Naleksuh (talk) 04:54, 27 December 2021 (UTC)
 * I would like to note that there are 42 extensions enabled by default globally. Additionally, all WikiSEO does is add meta tags which don't mess with page contents, styling or anything else. Agent Isai  Talk to me! 05:02, 27 December 2021 (UTC)
 * Why not? <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 06:20, 27 December 2021 (UTC)
 * Why not? I explained why not. I'm much more interested to hear why. Why should they be enabled by default? Naleksuh (talk) 16:50, 27 December 2021 (UTC)
 * A tab appears under the "SEO" name in Special:ManageWiki of each wiki that enables the extension. --YellowFrogger (Talk — ✐) 18:54, 27 December 2021 (UTC)
 * Procedural – it's important to clarify that global and default extensions are enabled by default. Global extensions cannot be disabled, while default extensions can be disabled. Dmehus (talk) 17:48, 27 December 2021 (UTC)
 * mainly with WikiSEO. Miraheze is not good at this (in search engines in relation to FANDOM, which loses from 10 V 0). Even though we need to configure, this extension anyway helps and is important, and maybe it would help to promote Miraheze wikis in search engines if the creators would configure it for sure (ex: Google Search Console). You can see that in the wiki where I manage I already use the extension using the Search Console code, even so, the wiki doesn't display a pace that reaches Wikipedia (which is at the top when you search "Ônibus Wiki") --YellowFrogger (Talk — ✐) 18:51, 27 December 2021 (UTC)
 * Without a doubt re: the Purge extension; I'd even support enabling that globally (as a global extension), to be honest. As for WikiSEO, I'm personally not convinced, as many wikis may not want that configuration enabled by default, and there's a fair bit of configuration for it, so there's a bit of a learning curve. Dmehus (talk) 05:34, 28 December 2021 (UTC)
 * Do note that WikiSEO does not need additional configuration out of the the box and is ready to use 100% once enabled. The configuration available for it is extra and mostly focuses on allowing users to verify that they have ownership of the subdomain on a few platforms like Google, Bing, Pinterest, etc. Agent Isai  Talk to me! 06:41, 28 December 2021 (UTC)
 * Okay, fair enough. I'd be okay with that, but could we make it not be enabled by default on private wikis? Only public wikis. If so, then I'd be okay with that. Dmehus (talk) 06:44, 28 December 2021 (UTC)
 * I don't know if that'd be possible within ManageWiki but WikiSEO doesn't display it's html tags on pages where the user doesn't have read permissions so it wouldn't display a page description/image on a page that visitors don't have access to. Agent Isai  Talk to me! 07:07, 28 December 2021 (UTC)
 * Still, there's admittedly not much point in enabling it on private wikis by default. I'd recommend adding this as a soft blocker on any potential implementation. I do suspect Universal Omega would be able to make the necessary ManageWiki/CreateWiki changes to create an option for default extensions on private wikis. Dmehus (talk) 07:29, 28 December 2021 (UTC)

, I don't believe the appeal of having a 'blank slate' installation (which isn't necessarily true for the amount that comes preinstalled) should preclude default usability for most cases, which is wikis that are highly inexperienced, trying to get somewhere and more than likely fail to realize WikiSEO in particular exists and is useful without hardly having to lift a finger for it to work. Purge is basic QoL, though personally I haven't had a case where I've used it and it actually did something. What this might do is accompany a selection of plugins to enable on wiki creation with the options on by default, but able to be easily ticked off before requesting as well as being able to turn other common extensions on. --Raidarr (talk) 09:35, 28 December 2021 (UTC)

Request for overturn on Requests for Comment/Local IP Block Exemption
<div class="boilerplate metadata discussion-archived" style="background-color: #F2F4FC; margin: 2em 0 0 0; padding: 0 10px 0 10px; border: 1px solid #aaa">
 * ''The following discussion is an archived discussion. Please do not modify it.
 * <span style="">Close overturned. <span style=""> Naleksuh (talk) 17:23, 28 December 2021 (UTC)

Requests for Comment/Local IP Block Exemption has recently been closed, with the statement that Requests for Comment/Local IP Block Exemption is successful.

It clearly is not. Just look at it.

One person defended this closure on the grounds that "consensus is not merely counting !votes" (but did not mention anything about the closure or arguments at all).

To get that out of the way, let's go over the !votes. We see that there is one support, five neutral (which appears to be leaning oppose) and four oppose. One support is not enough to declare something successful no matter what, it is at best no consensus. But of course, it is not even that. Consensus is clearly against it.

You see, as has been pointed out before, consensus is determined by cluocracy, not merrely counting votes. Which is why it is important that several major problems from multiple editors were pointed out, yet pretty much no reason established in favor of it. At all. Even the one single support said they preferred the other proposal and that was it.

Regardless of whether you go by counting !votes or by arguments consensus is clearly, near-unanimously, and without a doubt against this proposal, and I cannot see how any reasonable person would see this as successful. Please overturn it.

Naleksuh (talk) 04:48, 28 December 2021 (UTC)


 * Naleksuh, that is not that case at all. The "neutral" arguments were not opposed at all, and there was no indication that it was binary outcome to the RFC in that, if one proposal passed, the other proposal must fail. As Reception123 articulated in this close, local IP block exemptions would be chiefly granted by Meta administrators, but Meta Wiki is a bit different than other Miraheze wikis because of the role it plays. Likewise, there may be cases where (a) a user requests a global IP block exemption privately from Stewards, but the user only needs the exemption on Meta Wiki, it would be inappropriate, in my view, for the Steward to share a private e-mailed request with a Meta administrator, (b) an unaffected user would be adversely impacted by a hypothetical Meta rangeblock, and the user is also active on Meta Wiki, (c) a Meta administrator refers a case a Meta IP block exemption to a Steward, or (d) Meta administrators have not responded to a request within a reasonable period of time. While it's true that all Stewards are also Meta administrators, we have to consider this may not always be the case. As to the "neutral" arguments, they were either (a) not opposed or (b) in most cases, generally supportive. Dmehus (talk) 05:01, 28 December 2021 (UTC)
 * That RFC had nothing to do with global IP block exemption, it was strictly about local IP block exemption. And yes, you are right that it would be innapropriate to share a private email. That does not mean it would be appropriate to grant the request. It should be declined and the user referred to meta sysops, both given previous practices and the (unsuccessful) outcome of that request. Naleksuh (talk) 05:13, 28 December 2021 (UTC)
 * For one thing, it would seem to me to be quite bureaucratic to decline a valid request that a user requested privately for a valid reason. A Steward could grant a global IP block exemption in such cases, but in considering the need, for example, if a user was chiefly only active on Meta Wiki or only the local Meta rangeblock was a hard block, it would seem to me to only grant the user a local IP block exemption request. Where the Steward is also a Meta administrator, the point is moot, but we have to consider future scenarios where this may not always be the case. You keep saying Proposal 2 was unsuccessful, but I'm not sure how you see that, considering the neutral arguments were either (a) conditional supportive arguments, (b) secondarily supportive arguments, or (c) not opposed arguments. As Reception123 correctly closed, the local IP block exemption is chiefly granted by Meta administrators, usually via Administrators' noticeboard, but there may be scenarios, which are context dependent, where a local IP block exemption could need to be granted by a non-Meta administrator Steward. Dmehus (talk) 05:21, 28 December 2021 (UTC)
 * We are not here to re-discuss the original proposal, we are here to discuss whether or not it closed correctly, which it seems you are basing on your own !vote not the outcome. I'd first like to give Reception123 the opportunity to explain their thinking, then comments from others about whether they think it was closed correctly or incorrectly. Naleksuh (talk) 05:26, 28 December 2021 (UTC)
 * Certainly, absolutely. Other users are free to comment, and I'd be particularly interested to hear what users sharing their neutral/conditionally supportive/secondarily supportive views thought. I was just trying to explain some of the possible explanations for the way in which it was closed, which, I'd also point out, was that Meta IP block exemptions, when requested on-wiki, would be granted chiefly by Meta administrators. I suspect Reception123 will have additional reasons for his reading of consensus. I'm just pointing out that it was a correct reading of consensus, in my view. Dmehus (talk) 05:31, 28 December 2021 (UTC)
 * I understand (and expected) that there might be some controversy regarding the close as it was difficult. Regarding Proposal 2, while the votes appear to be "Neutral" it seems to me that they lean towards a conditional support or at the very least allowing Stewards to grant IPBE in limited circumstances. In RfCs it's important to look at arguments rather than merely votes. For example, if we look at Proposal 1 only five votes had arguments attached while for Proposal 2 almost all did. So the votes with arguments would carry more weight than the ones without. Generally I would say that the RfC was too vague for my liking which contributed to the problem, it should have been made clear whether Proposal 2 and Proposal 1 were mutually exclusive and otherwise I don't think that can simply be assumed and there was no indication that that was the intention. Reception123 (talk) ( C ) 06:39, 28 December 2021 (UTC)
 * Thanks for your comments. Yes, I'm aware that it is arguments over !vote counts, and even addresses this on the OP. The arguments seem to be in favor against it as the only support did not have any argument and the multiple opposes cited many reasons why it should not happen. Naleksuh (talk) 06:46, 28 December 2021 (UTC)
 * Well there weren't really "many reasons" in Proposal 2, just a single reason repeated. There are indeed reasons for doing it, such as the fact that if a user edits only on Meta and requests a GIBPE privately a Steward could grant IPBE on Meta instead rather than having to ask a Meta administrator (assuming they aren't one), since it would be a tricky situation if there's a private email. I would mention though that as I said in my close, it's clear that Meta administrators are the ones granting the role and Stewards should only do so in limited circumstances, like in the example given. Reception123 (talk) ( C ) 07:00, 28 December 2021 (UTC)
 * I agree that it seemed that most of the neutral !votes looked like they leaned toward conditional support, even though they were neutral. In fact, all of the neutral votes except Anpang's looked like they were leaning toward conditional support. Agent Isai  Talk to me! 06:45, 28 December 2021 (UTC)
 * That's exactly how I viewed that as well. Dmehus (talk) 06:45, 28 December 2021 (UTC)
 * Here's how I would put this: in order to develop expectations for the standards stewards should follow, you must first understand that stewards act solely on trust from the global community. Remember, stewards are not bound by any policy, and may be removed from the position of trust at any time, by any user. It must be acknowledged that, even if Proposal 2 had been considered successful, and stewards effectively "forbidden" from granting local exceptions on meta, there would be no binding force except the expression of the community on the matter. Though, consider—would there be enough support for the removal of a steward for a violation of this kind? Proposal 2 was, in the current contexts and circumstances, closed correctly. You should also notice, Proposal 2 was not closed as "successful". The closure of the RfC with respect to Proposal 2 specifically, refuses to acknowledge either support or oppose, instead synthesizing and summarizing all expressed vantages and opinions. Call it a summary of compromise, or caveat even, if you will. dross  (t • c • g) 09:04, 28 December 2021 (UTC)


 * From my view, the RFC was closed while the users were still participating in it and there could have been opposition to those who were leaning towards support or supporting the proposal. I support the overturn and I share and agree with what Naleksuh has already said above. Generally, I prefer Stewards to not to interfere in local (meta) matters and act only where the situation is global. The neutral votes looked like they were leaning towards support but there existed an opposition to it too. Many claimed that local group should be only granted by local admins whose views should also be respected and counted. IMO, the RFC was very vague and it should have been left open for more broader consensus especially if you believed you are going to make a controversial close. --Magogre (talk)  07:29, 28 December 2021 (UTC)
 * Magogre, please do note that nothing in the closed RFC says that non-Meta administrator Stewards would be granting a local Meta IP block exemption with a valid need (i.e., to edit through Tor) to trusted users on Meta. Indeed, that's the way Reception123 closed this. Also, the fact that the RFC itself was vague or lacked the necessary details or specifics would not necessarily be fixed by additional views being expressed. As Reception123 has articulated above, Stewards would only be granting a local Meta IP block exemption in a very limited set of circumstances where non-Steward Meta administrators are not privy to private details of either the request, or where the user would potentially be impacted by a hard Meta rangeblock, and other limited circumstances such as that. Dmehus (talk) 07:36, 28 December 2021 (UTC)
 * As a bureaucrat on Meta, I have reviewed this closure and will discuss it with Reception as personally I believe the autonomy of Meta should be retained and there ‘’’ is not’’’ consensus for allowing stewards to manage local IPBE. If we look at raw consensus values, 1/5 = 20% support. If the users who abstained from voting on the proposal, had supported it, they should have supported it directly and clearly. Going through the arguments, its one of equal grounding. All the neutral says ‘stewards should be able to assign it’ while all the opposes going ‘only meta administrators should be able to assign it’. Neither side make convincing arguments why or why not their side is the ‘correct’ one. If we take all !votes into consideration that have an argument attached, we get 5/9 = 56%, which to me is still far too low to consider a consensus in favour of passing a proposal. With regards to comments above saying ‘Reception didn’t say the proposal passed’, he said Stewards can grant it - which is the proposal. John (talk) 09:40, 28 December 2021 (UTC)
 * I do agree the consensus for either proposal is weak, and concur with your assessment in terms of the support for Proposal 1 being 5/9, but I also not feel that reopening an RFC which Reception123 noted was vague and lacked necessary detail. Two of those that expressed views in Proposal 1 stated their support was conditional on the limited use case arguments expressed in Proposal 2. One person in Proposal 2 said their support was per the first user whose support for Proposal 1 was conditional. As well, I would also add that Reception123 didn't say that non-Meta administrators Stewards can grant the local IP block exemption in the same way Meta administrators might; he said that it would be granted mainly by Meta administrators. If I have that wrong, perhaps he can refine or tweak the wording of his close. However, given the vagueness of the RFC, as well as the fact that three users in this thread concur that the RFC was properly closed, it would be problematic to overturn the close. I would propose a new RFC be drafted, one that proposes to adopt IP block exemption as the first proposal, revert to the status quo (by deleting the local IP block exemption) as a second option, or introduces a third option, to add  to the   group on Meta Wiki, consistent with the default permissions. Dmehus (talk) 10:00, 28 December 2021 (UTC)
 * I am not proposing we reopen the RfC, rather we modify the closure to reflect reality and remove all mention of Stewards being able to legitimately grant a local user right on an active community where local users are capable of doing so and there is no consensus to allow them to. If we had this situation apply anywhere else, people would contest and argue the infringement of central/global control of a local community - yet Meta seems to be the exception. We always bring up ‘we need better local engagement’ on meta, and then hand control of local groups to Stewards legitimately in policy that do not have global consequences. Also the point of ‘ it stewards can only grant it in situation x or y’, has been the case in the past, and it has been controversial as well. Stewards should push local process and procedure first and foremost, rather than having a back door key in policy to just do it themselves without holding themselves to local community scrutiny. What if a steward consistently misgrants local IPBE? It’s unlikely they’ll lose Steward rights because it’s such a minor point that most won’t even consider it for revocation. But if a local sysop did that, it’s likely they’d lose their rights. John (talk) 10:10, 28 December 2021 (UTC)
 * Well, yes, I'm not saying, and the RFC is not saying, non-Meta administrator Stewards should be granting IP block exemptions to be able to edit through Tor on Meta Wiki; that can be granted to trusted users by Meta administrators. I was just thinking in terms of the hypothetical scenario where an unaffiliated user would be caught in a potential hard IP local rangeblock, and the user was not active on any other wiki besides Meta Wiki, would it not be more appropriate to grant the user a local IP block exemption than a global IP block exemption? I realize it's a niche scenario, but that's the neutral/conditionally supportive arguments in favour of Proposal 2 said. Dmehus (talk) 10:17, 28 December 2021 (UTC)
 * I personally would like to see  added to the   user group, consistent with the default user groups as it doesn't make sense to have Tor blocked locally but yet have global blocks technically not apply to Meta.  Agent Isai  Talk to me! 10:13, 28 December 2021 (UTC)
 * Per the comments above and after discussion with John, the outcome of Proposal 2 has been reverted. Reception123 (talk) ( C ) 10:33, 28 December 2021 (UTC)
 * ''The above discussion is preserved as an archive. Please do not modify it.

Problem with Tab
Hi there, I have created a "Tab" template for my pages. Problem, I would like the two ends to be rounded. However, this is only the case on one end. It is only rounded when my Tab has this shape:

Either when it's staggered. My page link : https://fiction.miraheze.org/wiki/Wonder_Woman_(Univers_%C3%A9tendu_DC) My template link : https://fiction.miraheze.org/wiki/Mod%C3%A8le:Tab Thanks in advance. Darkrai18 (talk) 11:35, 28 December 2021 (UTC)


 * The two ends are already rounded?
 * Or you mean all 4 corners to be rounded?
 * Then  should work <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨  11:45, 28 December 2021 (UTC)
 * I'm talking about this : Tab1111111.PNG. I would like both ends to be rounded. Darkrai18 (talk) 11:58, 28 December 2021 (UTC)
 * Oh, then that I have no idea. Maybe an {{if: checking if the next one exists, if not set to rounded else not rounded and continue?
 * Like i have no idea.... <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 12:02, 28 December 2021 (UTC)
 * Thanks for trying. I'm waiting for more answers. Darkrai18 (talk) 12:32, 28 December 2021 (UTC)
 * This current theme of your wiki (mw:Skin:Monobook) is weird. But let's show the rounded borders preview CSS in the Vector theme: border-top-left-radius: 2em; border-bottom-left-radius: 2em; --YellowFrogger {{bullet}} (Talk — ✐) 16:44, 28 December 2021 (UTC)


 * {{ping|Darkrai18}} Your template is too complex for me to locate where to added Template:Border-radius in the other tabs. I have recreated it in a simpler design on the Test Wiki
 * Template - Template:Tab
 * Test Page - Wonder Woman (Univers étendu DC)/Personnalité PercyUK (talk) 21:21, 28 December 2021 (UTC)

Comments disabled
On 28 December 2021, we experienced severe performance issues globally which led to hours long downtime across all Miraheze wikis. While investigating the issue, we found that the  API module (used by the Comments extension) was at fault as it used an excessive amount of resources whenever called and disabled it which seems to have put an end to the hours of downtime. However, as a result of the  API module being disabled, the Comments extension cannot load comments. We apologize for the inconvenience and are actively working with the upstream developers of the extension to find a solution to this and to re-enable the API module as soon as possible.

In the meanwhile, we encourage you to consider alternatives to the Comments extension such as CommentStreams.

Please note that even though the API module is disabled, extensions that rely on Comments such as BlogPage are not affected and can be used as normal. Agent Isai Talk to me! 01:31, 30 December 2021 (UTC)
 * This here will have an impact mainly on Qualitipedia wikis, which often use these comments in their articles from what I see. --YellowFrogger (Talk — ✐) 01:37, 30 December 2021 (UTC)
 * This is correct; QP cannot reasonably just consider alternatives outright given the lengthy history of existing comments and the familiarity of their use, and losing history is indeed an impact. Then when switched a new history is made to wipe out the old one, or the plugin is switched back to result in a blind period for comment history since from what I understand the data is not compatible between them. I understand Miraheze is doing what it can, but in case of the above it does have an impact and it would be preferable to see a fix than to make an intermediate switch. --Raidarr (talk) 17:25, 30 December 2021 (UTC)
 * We migrated from CommentStreams... How difficult is to do a module that works and don't spent tons of resources? All the ones we have tried have performance issues or were difficult to comment... Thanks for resolving the downtime :) Jakeukalane (talk) 09:28, 30 December 2021 (UTC)
 * Ultimately, it would depend on the upstream maintainer of the extension. A variety of factors come into play such as the complexity of the issue and whether the maintainer has the time to fix the issue. Because of that, we can't give you an ETA unfortunately, sorry! Disabling an API module isn't something we take lightly, it was an emergency measure taken to combat the hours of downtime we suffered yesterday. We are actively working with the maintainer to hopefully find a fix and restore functionality of the Comments extension. However, in the meanwhile, have you tried revisiting CommentStreams? The latest update gave it a facelift and it acts snappier, perhaps you may like that as a temporary alternative.  Agent Isai  Talk to me! 09:51, 30 December 2021 (UTC)
 * There was some confusion on my part. We migrated to CommentStreams but it is not working right now. That lead me to believe that we had the problematic comment extension. Greetings. Jakeukalane (talk) 12:55, 30 December 2021 (UTC)
 * I still have Miraheze taking 7 seconds to boot. DecabristM (talk) 16:49, 30 December 2021 (UTC)
 * We still aren't perfect, but the actions taken did resolve the major downtime and improved things. 16:55, 30 December 2021 (UTC) ］ |

A few concerns:
 * 1) When will this be back?
 * 2) What is CommentStreams exactly? Can I perhaps see a picture of what it looks like, since the MediaWiki page does not have one. I also would not recommend the Commentbox extension as it just edits the page which is quite annoying.
 * 3) I wonder if this is why it would not let me use the reply button to reply here, so I had to actually edit the page. Blubabluba9990 (talk) 17:42, 31 December 2021 (UTC)
 * I figured out what CommentStreams is, since I enabled it on my wiki. Blubabluba9990 (talk) 19:35, 31 December 2021 (UTC)

Bug with the article counter
Hey! I am using the article counter on the main page for readers. But despite the fact that there are already three articles on my wiki, the article counter has been displaying zero for several days. What could be the problem? DecabristM (talk) 13:02, 30 December 2021 (UTC)
 * Please note that MediaWiki only counts pages with links to them so if a page doesn't have any other pages linking to it, it won't show up in Special:Statistics. Additionally, Statistics gets stuck every so often but gets manually refreshed every 2 weeks so if all your pages have links to each other than Statistics should show them once they get refreshed. Agent Isai  Talk to me! 14:14, 30 December 2021 (UTC)
 * Yes, the problem was missing links. Thanks! DecabristM (talk) 16:45, 30 December 2021 (UTC)
 * As Agent Isai said above (even if the page is large and has the main namespace, if it doesn't have links, it doesn't count as articles). And, very small pages in the main namespace don't count as articles, but as pages. --YellowFrogger (Talk — ✐) 17:41, 30 December 2021 (UTC)

Problem with Tab, part 2
Hey there. The tab works very well, I'm very happy with it and I thank you all. I made some modifications but a problem persists: The text appears in white when I'm not on the main page, while I would like it to appear in black when I'm not on the said page. For example, here it appears in white and it's fine : https://fiction.miraheze.org/wiki/Rey_(Star_Wars) But here it stays white : https://fiction.miraheze.org/wiki/Rey_(Star_Wars)/Galerie I would like it to be black. Do you have a solution? Thanks in advance. Darkrai18 (talk) 14:03, 30 December 2021 (UTC) Darkrai18 (talk) 14:03, 30 December 2021 (UTC)


 * Template updated - Template:Tab
 * Test Page 1 - Wonder Woman (Univers étendu DC)
 * Test Page 2 - Rey (Star Wars)/Galerie
 * Test Page 3 - Wonder Woman (Univers étendu DC)/Personnalité PercyUK (talk) 14:47, 30 December 2021 (UTC)
 * Thank you very much, . Darkrai18 (talk) 16:31, 30 December 2021 (UTC)
 * Thank you very much, . Darkrai18 (talk) 16:31, 30 December 2021 (UTC)

Issue with our wikis
Hi, I am one of the admins at the music reception wikis. Today we turned on video functionality for the best music wiki, and it appears it allows us to import videos properly. However, there is an issue. When the video is in, it says "Click to load content" which I do not know why, do you know why it appears this way and how we could fix it? FullInterTurn (talk) 22:33, 30 December 2021 (UTC)
 * I would expect an admin to talk about this first, but as I write this review no response. With that, I advise you then, as it is an error of an extension, to open a ticket in the phabricator so they will probably check if there is an error in the extension that is preventing such thing. And if you want, you can invite me to review the wiki. --YellowFrogger (Talk — ✐) 01:34, 31 December 2021 (UTC)

A bit of a problem
So I went to reply to the notice about the Comments extension being (hopefully temporarily) disabled, but when I clicked the reply button it took a few seconds to load and then displayed an error screen. I had to end up editing the actual page itself in order to reply. I do hope all of this is fixed soon because Miraheze is the last good wiki-hosting platform: Fandom has multiple problems, ShoutWiki is broken and inactive, Wikisite and EditThis run on ancient MediaWiki software and are inactive, and all of the other wiki hosts and wiki farms use other software and are pay-to-use. Blubabluba9990 (talk) 17:54, 31 December 2021 (UTC)
 * Oh and that isn't the only issue. When you click Save Changes, it takes like 30 seconds to save the changes. Blubabluba9990 (talk) 17:55, 31 December 2021 (UTC)
 * See the section above. Current comments extension is currently disabled due to a problem. --YellowFrogger (Talk — ✐) 22:36, 31 December 2021 (UTC)

How do I post a template multiple times to the same page without "Pages using duplicate arguments in template calls"?
Is there a way around this? I want my user to fill out a form that selects some values and then have those values displayed simultaneously in two different spots within the page. Thanks for your help! ParentRatings (talk) 21:43, 31 December 2021 (UTC)
 * This is happening because you are using two parameters with the same name (duplicated). To avoid this, you should set the parameter and remove the duplicate, and leave only one. What is your wiki? Could you invite me to analyze the error? --YellowFrogger (Talk — ✐) 22:32, 31 December 2021 (UTC)

Interwiki changes for planetariumwiki
Please edit the following Interwiki prefixes.


 * Wikitroid
 * Prefix:


 * Content:


 * Metroid Wiki
 * Prefix:


 * Content:

No need for transclusion or forwarding on either. dross (t • c • g) 07:22, 1 January 2022 (UTC)