Community noticeboard

How about a incubator wiki for Miraheze?
Don't be confused with Incubator Plus 2.0 Wiki.

I am thinking of an incubator wiki design to avoid "trash and bad" wikis (means not suit our standards) to reduce the burden of wiki creators. Since "incubator" was taken, I will use "nest" as the domain link, since nests are the place eggs are. The request wiki task number is 21138. Emojiwiki (talk) 10:12, 26 October 2021 (UTC)


 * About privs: Meta Wiki wiki creators will get admin privs whenever possible (this should be done via config or extension, or bot if this is impossible), and be revoked when his/her wiki creator priv revoked.
 * About test wiki structure: The wiki's page will use this structure:
 * Wiki root page:
 * For example: Main page of  should be:
 * Note that MediaWiki messages should be placed in:, but they won't be applyed yet (except main page setting, we will apply it by templating)
 * Wiki extra settings in the wiki's : , written in PHP inside syntax highlighting Wikitext blocks, or written as a list contains all requirements
 * Restrictions:
 * Translations between Chinese Simplified and Tranditional will be disabled, but seperated and created wikis can enable them themself.
 * Emojiwiki (talk) 10:30, 26 October 2021 (UTC)
 * If I understand this correctly, what you suggest is too big to just make a wiki request for, and would be more in line with the Request for Comment process since it would be changing wiki creation policy. But tbh I don't entirely understand what this is for and why. --Raidarr (talk) 12:15, 26 October 2021 (UTC)
 * About why:
 * Currently the create wiki request is slow, I think a reason is there are a lot of requests.
 * Changing the create wiki policy:
 * This does not require at the start. This will be a test project until its scripts (needs a lot of scripts to manage eggs) and contributing environment (including policy and guidelines)
 * Emojiwiki (talk) 23:06, 29 October 2021 (UTC)
 * Personally, I feel that wiki request handling time is very good, especially in comparison to a few years ago and even a few months ago too. A few years ago when wiki requests took weeks or even months to do, I would have totally supported this idea, even advocated for it, but right now it feels like we don't exactly need an Incubator wiki. While checking the Farmer log, I noticed that very rarely does a wiki request go more than 12 hours without it being handled, in fact, most are handled in 6 hours or less with many handled in less than 3 hours, some even within minutes to an hour! If a user is impatient about having to wait a few hours for their wiki to be created then I think they'll totally get frustrated with how long it takes to actually build up a wiki. Agent Isai  Talk to me! 23:22, 29 October 2021 (UTC)
 * Even though I am misunderstanding the timing of creating a wiki, there are also two major goals:
 * Decine bad wiki requests clearly
 * Nowadays, wiki creators can only guess what the wiki requester wants and will he follow the policy. By adding a nest wiki, they can clearly look inside the box and approve or decline clearly.
 * A place for waking up wikis
 * Sometimes, when a wiki is hibernated and nearly to be deleted, someone wants to continue it. Our hibernate policy allows us to do so directly, but that is not a good choice. The community needs to be rebuilt, and a direct continuation of the old hibernated wiki may cause another hibernate. The nest wiki can be a good place to do so.
 * BTW: Request comment updated, go to the request queue page to know more. Emojiwiki (talk) 23:46, 29 October 2021 (UTC)
 * Again, please note that this idea cannot be approved in the request queue or by any individual. This discussion must be held somewhere else. Since it is so expansive, it should be done through the Requests for Comment process with a full description of what you intend it to do so the community can decide to use it. --Raidarr (talk) 08:37, 30 October 2021 (UTC)
 * If this to move forward, it needs a formal RfC. This nor a wiki request is not the venue for such a major change. This thread may continue to facilitate drafting such an RfC but I advise caution as I think it is extremely unlikely to succeed and would need significant technical work which would in any case take quite a while. ~ RhinosF1 - (chat)· acc· c -  08:50, 30 October 2021 (UTC)

1. Gadgets, and 2. Template Styles and Content Model
I have a few gadgets set as default in my wiki's MediaWiki: Gadgets-definition:. If I do not enable MW: Extension: Gadgets, will the default gadgets still work fine, or will they be disabled along with the Gadget extension?

A template I created with MW: Extension: TemplateStyles is not working. Its styles.css page does not seem to be in the Sanitized CSS content model. How can I enable ? What can I do?

Thank you very much! — XComhghall (talk) 17:58, 29 October 2021 (UTC)
 * , hello. You need to enable the TemplateStyles extension (enable on your wiki) and change the content model of Template:Block/styles.css into sanitized CSS (use Special:ChangeContentModel on your wiki to do that). The template should work properly, then. Ma͡gogre (talk) 18:54, 29 October 2021 (UTC)

Ask a question to an administrator
Hi, To which active administrator could I ask a question (or more precisely, request permission)? Dmehus is not active at all, neither on Miraheze nor on Discord. Do you have someone to advise me? Thanks a lot. Darkrai18 (talk) 14:51, 31 October 2021 (UTC)
 * Hello, you can ask genuine questions and request permissions at AN. Though you can also request on the talk page of a recently active administrators, I'd recommend you to use AN. --Magogre (talk) 15:02, 31 October 2021 (UTC)
 * Hello, if this is an extension of the question posted here, the most appropriate place is the Stewards' noticeboard so any Steward may easily find it and/or so a knowledgeable enough community member can advise you. If it is another inquiry I'd need to know what it is as it may go to another place. Dmehus is active in sprees and engages in order of priority; I want to say he'd likely address your concern within a few days (just one is not enough in most cases I'm afraid). It's also worth noting he has distinctly less activity on Discord as a platform, and if you wish to reach him by chat then IRC is more reliable (relayed via #miraheze-relay and related channels on Discord). For a general Steward inquiry though, the given noticeboard is preferable. The location posted above (AN) is if you request something from the local administrators on Meta. --Raidarr (talk) 15:07, 31 October 2021 (UTC)
 * Followup; Dmehus is available today and has replied to the inquiry I referenced on his talk page. --Raidarr (talk) 15:50, 31 October 2021 (UTC)

Problem with duplicate wikis
Recently, I noticed that there are many duplicate wikis on Miraheze. While wiki requests that seem similar to existing wikis are likely to be declined, already existing duplicate wikis and wikis with similar topics still exist. This is a problem that needs to be corrected. As quoted on Fandom's help page about duplicate wikis: "Where multiple wikis on the same topic exist, however, fans split their efforts and compete with each other for readers, editors and authority. The duplicate content they create is penalized by search engines such as Google, especially when a new wiki copies pages of an existing wiki. As a result, both wikis will appear lower in search results, receive fewer visitors and attract fewer community members." So, if duplicate wikis were merged with the original wikis, they would rank higher in search results and thus attract more contributors. We need to find and merge these duplicate communities, so that one wiki can move forward. I have several wikis that could be considered duplicates. I'm merging these with the original wikis.

Proposed merging process

 * 1) A request to merge is presented to the founder or active bureaucrats and admins on a wiki.
 * 2) *If there are no active bureaucrats and admins, go ahead to step 3.
 * 3) *If there is no response in a week, go ahead and start moving content.
 * 4) If the request is denied, the wiki stays separate.
 * 5) If the request is accepted, the community of the wiki to be merged votes on whether their wiki should be merged into the other wiki.
 * 6) If at least a 2/3 majority of the community of the wiki to be merged votes in favor of the merger, the wiki's content would be transferred to the wiki that receives the merge. Voting must remain open for a week before the results can be considered valid.
 * 7) The wiki to be merged is closed and deleted, and its URL is redirected to the wiki that receives the merge.

List of duplicate wikis
These are some of the wikis that are duplicates of others. These should be merged first.
 * Duplicates of Mirapedia (no notability guidelines encyclopedia):
 * Allpedia
 * Anypedia
 * Duplicates of Good Software Wiki (good software):
 * Great, Amazing and Useful Software Wiki (Focuses on useful software, which is usually good.)
 * Duplicates of Windopedia (wiki about Windows, the operating system by Microsoft):
 * Everything Windows Official Wiki
 * Duplicates of Free Editing Wiki (anything goes wiki)
 * Anything Goes Wiki

Wikis with overlapping topic and scope
These are the wikis with overlapping topic and scope. Their topics are not related enough to categorize them as duplicates, but they overlap in scope.
 * Trollpasta/Bad Creepypasta Wikis:
 * Trollpasta Wiki (primarily about trollpastas, but also has several thousand bad creepypastas. Famous examples of bad creepypastas may be kept, but others should be moved to Bad Creepypasta Wiki)
 * Bad Creepypasta Wiki (primarily about bad creepypastas, but also has a number of trollpastas. Famous examples of trollpastas may be kept, but others should be moved to Trollpasta Wiki)
 * Reading/Writing Stories:
 * Stories Wiki (This is a wiki of mine in which users can read and write stories. I've banned fanfiction to prevent overlap with any fanfiction wikis. I can't think of anything that needs to be changed, but there may be one or two.)
 * Short Stories & Prompts (This wiki focuses on stories and writing prompts, while Stories Wiki just focuses on stories. I've already contacted the founder of this wiki about merging this wiki with Stories Wiki, and we ended up coming on an agreement where we could mirror each other's content. My plan for this wiki is to make it about writing prompts only and move the stories on Stories Wiki.)
 * Stories about an existing character in a franchise (fanfiction):
 * Fanfiction Wiki (Fanworks) (Primarily about writing fanfiction and chatting about it.)
 * My Fan Fiction (Focuses solely on fanfiction. I think Fanworks should be rebranded to "Fanfiction Wiki" or something similar, and this wiki should be merged with that one.

If you can think of any other topics or other duplicate wikis with already existing topics, please post them! Tali64³ (talk) 18:50, 2 November 2021 (UTC)

Updates
This process, I believe, will stop most instances of abuse of merging. Tali64³ (talk) 22:35, 2 November 2021 (UTC)
 * I've been informed that duplicate wikis actually aren't against the Content Policy. Still, you should merge them with other wikis to help the communities. That's why I propose this process to merging wikis:
 * A request to merge is presented to the founder or active bureaucrats and admins.
 * If the request is accepted, the community of the wiki to be merged votes on whether their wiki should be merged into the other wiki.
 * If at least a 2/3 majority of the community of the wiki to be merged votes in favor of the merger, the wiki's content would be transferred to the wiki that receives the merge. Voting must remain open for a week before the vote can be considered valid.
 * The wiki to be merged is closed and deleted, and its URL is redirected to the wiki that receives the merge.
 * While I don't have specific links and am working off the top of my head, I know there are multiple wikis for aggregate worldbuilding (putting any kind of worldbuilding stuff in one place), creepypastas, and 'do whatever' types that may be found even through the Gazetteer of wikis. From a policy perspective however, an overlapping or duplicate-ish premise isn't strictly against Content Policy; its most relevant clause is:
 * "An example of hinderance caused to other wikis is a direct fork of another Miraheze wiki where little to no attempts have been made to mediate situations on the existing wiki or existing community. If mediation has been attempted and failed, contact a steward who will be able to support the community through any follow up processes deemed necessary including but not limited to acceptance of a fork wiki as an exemption to this clause. "
 * In the generic wiki responses for approval through the request wiki function, one specific statement is provided: "Please be advised this approval does not preclude other wikis from being approved and created that share this topic, provided they aren't 95-100% content forks of your wiki." I do think up to 95% is exceedingly generous and maybe should be reduced since even 3/4ths identical is enough to invoke the condition you describe, and is enough to substantively be a direct fork. However I think it's worth distinguishing between overlapping premise and what these clauses talk about (word for word page lifting and identical scopes); not much action may be taken if the respective wikis you link do go their own way managerially and have somewhat distinctive content of their own, even if I agree they fill essentially the same niche and in my opinion a much too broad one. Either way seeing them come together to actually collaborate in community building would be welcome, even if Miraheze deliberately tries to avoid forcing wikis together the way fandom does. --Raidarr (talk) 19:55, 2 November 2021 (UTC)
 * I respect your opinion, but what about the community? It's inconvenient for users to have to look to another wiki for one page that could have been easily found on a more active wiki. And even if the less active wiki isn't a content fork of the more active wiki, the less active wiki should be merged into the more active wiki. And I see your point about how Miraheze keeps duplicate wikis together. Even Fandom doesn't merge wikis for certain reasons, as can be seen on the page I quoted in my post. Also, do you have any specific wikis that are duplicates or have similar topics to other wikis? Tali64³ (talk) 22:24, 2 November 2021 (UTC)
 * Much of the above was addressing from a practical action perspective; my opinion is actually largely agreement, since I do think communities are better off coming together to do something than splintering into forks that cover the same ground for both the editing base and potential viewers and I do think the 'weaker' wikis without a truly discernible function should merge into more complete ones for a better result. It's probably a topic to raise on the various local communities linked above and see if an overall compromise can be made since I'm still skeptical that the action could truly be forced, again unless there is truly proven content duplication. If the scopes are too similar regardless though, would be an interesting thing to have a Steward comment on - perhaps . if that's the case and there is something actionable, I can try to find more scope duplication including follow up on the above where I'm fairly sure multiple 'pasta compilations' with the same practical function exist. For now at a communal level, perhaps we can take a closer look at the above examples and see if we can resolve them to have an approach with any more close overlaps we can find. --Raidarr (talk) 17:24, 3 November 2021 (UTC)
 * I proposed a method to merging wikis above. It involves a community vote to see if they want the wiki to be merged, so the process won't feel forced. Tali64³ (talk) 18:17, 3 November 2021 (UTC)
 * Vote is reasonable and standard for established communities, but there are also cases with very few users or only the founding contributor, and yet other cases essentially abandoned and on the brink of true inactivity only being strung along; in these cases the responsible users can be contacted directly with an inquiry, or even an adoption request for the last scenario could be made. --Raidarr (talk) 19:31, 3 November 2021 (UTC)
 * Thanks for your input. I'll amend the process. Tali64³ (talk) 16:20, 4 November 2021 (UTC)
 * Mirapedia seems to be more of a wikipedia copy kind wiki but allpedia seems to be a similar wiki without copying content Anpang

Talk 01:04, 3 November 2021 (UTC)


 * I looked, and I can't find any content policies or notability guidelines there. That's why I classified it as a no notability guidelines encyclopedia. Tali64³ (talk) 16:23, 3 November 2021 (UTC)

Problem with Small
Hi, I am encountering a slight problem with the " " code. It puts me in an insane space every time I use it, as you can see here:

Do you have a solution? Thanks in advance. Darkrai18 (talk) 19:33, 2 November 2021 (UTC)


 * Hmm, maybe put style="vertical-align:text-top" or use  instead, that will put the text on top. If you want it centered, maybe do something like text  (it puts margin to the bottom so it kinda floats) i dont know if either of these works havent tested  Anpang

Talk 01:01, 3 November 2021 (UTC)
 * It doesn't worked. --Darkrai18 (talk) 19:47, 3 November 2021 (UTC)
 * you can try . You can see the result on my sandbox. アンジェロ先輩 (talk) 22:28, 3 November 2021 (UTC)
 * It still hasn't worked. --Darkrai18 (talk) 17:28, 4 November 2021 (UTC)
 * Can you explain more about the small tag "putting in an insane position"? Did you mean when you put multiple lines of small tags and they create lots of space or the small tags text aren't centered? — Preceding unsigned comment added by Anpang (talk • contribs) 01:43, 5 November 2021 (UTC)

How to change the logo
Hello everyone, i feel stupid for asking this but, as a novice when it comes to computer, i'm lost. And i can't succeed in changing the logo. I followed this tuto https://meta.miraheze.org/wiki/ManageWiki#How_do_I_change_my_logo.2Ffavicon.3F but it doesn't work. I can't find how or where to upload the logo. Thank you ! MF4884 (talk) 14:01, 4 November 2021 (UTC)


 * You upload your logo like a regular image on your wiki's Special:Upload. Once you've uploaded it, hover over the image, right click and press "Copy image address". Return to Special:ManageWiki/settings -> Styling and paste the link there and it should work. Agent Isai  Talk to me! 20:13, 4 November 2021 (UTC)
 * Thank you ! It works perfectly :) MF4884 (talk) 19:09, 5 November 2021 (UTC)

Problem with Tab
Hi, I have a slight problem with my Tab (this: ) I would like it to be lower in my page (and centered too but it's less important.) Right now it's too high, as you can see here: I'd like it to be a bit like on this page: https://equestripedia.org/wiki/Twilight_Sparkle_(Friendship_is_Magic) Thanks in advance. Darkrai18 (talk) 17:32, 4 November 2021 (UTC)


 * Si tu veux qu'il soit centré il faut insérer {| style="margin: 1em auto;" . Pour le reste je sais pas quoi faire. アンジェロ先輩 (talk) 19:59, 4 November 2021 (UTC)
 * ah non c'est pas un tableau, je suis pas pratique avec la balise table... アンジェロ先輩 (talk) 20:03, 4 November 2021 (UTC)
 * Tu es français ou tu fais l'effort de me parler dans ma langue ? --Darkrai18 (talk) 21:35, 4 November 2021 (UTC)
 * Polyglotte, donc j'ai pas de souci avec la langue française.--アンジェロ先輩 (talk) 07:38, 5 November 2021 (UTC)

Problem with Phabricator
Hi, I can't login with my Miraheze account on Phabricator. It says my password is incorrect when it is correct, and attempts to reset my password fail too. Thank you in advance for your help. Darkrai18 (talk) 15:16, 5 November 2021 (UTC)
 * , I am not sure about the issue but you should be able to login via MediaWiki. See Phabricator for more details. --Magogre (talk) 16:07, 5 November 2021 (UTC)

Changing URL for local interwiki prefix (archiopediawiki)
We kindly request that you change the URL connected to archiopediagrc prefix from https://archiopediagrc.miraheze.org/wiki/$1 to https://grc.repository.archiopedia.org/wiki/$1.

Thank you in advance!

Wiki: repository.archiopedia.org (Page: https://repository.archiopedia.org/wiki/Special:Interwiki)

Reason: We are using a custom domain, so archiopediagrc.miraheze.org = grc.repository.archiopedia.org. See https://phabricator.miraheze.org/T8239. Publisher (Archiopedia) (talk) 09:19, 7 November 2021 (UTC)


 * Hello; thank you for the request and a sysadmin may be able to get to it anyway, but for reference these technical changes should be requested through Phabricator, where they can typically see it more quickly and handle it by default. --Raidarr (talk) 10:38, 7 November 2021 (UTC)
 * @Raidarr Thank you for your answer!
 * We figured that our request falls within the category “Request changes to your wiki's local interwiki table” (i.e. it is a request that should be made on Community noticeboard).
 * In any case, should we create a new request on Phabricator or just wait? Publisher (Archiopedia) (talk) 11:37, 7 November 2021 (UTC)
 * Oh dear, I'm not doing good today. I assumed you were requesting something different and completely missed the title, so disregard what I said as I ping a competent IW admin to have a look via Discord. --Raidarr (talk) 11:44, 7 November 2021 (UTC)
 * @Raidarr No worries! In any case, thank you for your speedy response. :) Publisher (Archiopedia) (talk) 12:19, 7 November 2021 (UTC)
 * This is ✅ right now.
 * Thanks for bringing this to my notice, you're awesome. Ugochimobi (talk) 12:28, 7 November 2021 (UTC)
 * o7, best of luck on the project and thank you for speedy resolution. --Raidarr (talk) 12:38, 7 November 2021 (UTC)
 * @Raidarr @Ugochimobi Thank you all very much! Publisher (Archiopedia) (talk) 13:11, 7 November 2021 (UTC)
 * Looks like this got sorted, but to correct something Raidarr said above. Requests for changing a wiki's local interwiki table should not be requested on Phabricator, they should be ideally requested here, for a global interwiki administrator or steward to handle. I can, however, see the reason for Raidarr's initial response, as you noted your custom domain, which is requested on Phabricator. Dmehus (talk) 15:32, 7 November 2021 (UTC)
 * This was an oversight I corrected relatively quickly and forwarded to for resolution, as I realized upon second read that I had completely mis-evaluated the request and pinged an interwiki admin to handle it upon recognizing what it was, per the subsequent discussion above this post. --Raidarr (talk) 15:56, 7 November 2021 (UTC)
 * Thank you for your intervention, @Dmehus; it confirms what @Raidarr had already clarified after the initial mistake.
 * We noted our custom domain (by referring to the relevant task on Phabricator, no less), because we thought that it would be helpful for the Interwiki admin who would check the new link in order to add it our Special:Interwiki.
 * But, apparently, our desire for precision created confusion. A fine example of unintended consequences or of the unity of opposites? Well, an issue resolved and philosophical food for thought: what else could we ask for? :D
 * Thank you again! Publisher (Archiopedia) (talk) 18:17, 7 November 2021 (UTC)
 * It was much more a consequence of my addled early morning mind than any error in the reporting or its clarity, I'd say. --Raidarr (talk) 18:24, 7 November 2021 (UTC)
 * Not a problem either way. Thanks everyone! Dmehus (talk) 18:38, 7 November 2021 (UTC)

Question (idk if this is the right place)
Uhhh is there any way to change the default skin of my wiki ?

Sorry first time using miraheze i have too many questions and my english is bad i just wanted to know how to change the default skin to monobook or something else ;-; Alexthefluffy1 (talk) 11:09, 7 November 2021 (UTC)


 * Yes. If you want a built in skin (MonoBook is one of them so you should be set), you shouldn't have to enable it via ManageWiki's extensions menu. If you want 'something else' and it's not an original option (you can see what you have in the next step), you'll have to go to Special:ManageWiki/extensions and enable it in the Skins tab.
 * Having it, you can go to Special:ManageWiki/settings (also listed as 'additional settings' on the sidebar), Styling tab (the last one), and select it from the dropdown list. It should be the first listed setting there.
 * Feel free to ask more questions like this, it's what the CW is for! Although I do recommend browsing through the MediaWiki help area, which can get you by on most things. But since ManageWiki (the way to change things that would normally be a trip to server files) is a Miraheze creation, you can learn more about it here. It's a little big, but I'm sure you'll get the hang of it. --Raidarr (talk) 11:56, 7 November 2021 (UTC)

Improving password standards on Miraheze
Hello all,

In order to comply with the latest security standards, the SRE team wishes to slowly increase password requirements to require that passwords are at least 12 characters.

The plan we thought of would be to progressively institute these requirements: first for global groups, after for local administrators, bureaucrats and bots and finally to extend the longer password requirements to the entire user base.

Before we go ahead with these changes we would like to get feedback from the community, so please do feel free to raise any concerns or provide any feedback you may have or ask us questions about this change and we would be happy to respond.

Thanks, Reception123 (talk) ( C ) 15:09, 4 September 2021 (UTC)


 * My feedback is that this policy is as dumb as most of our Covid-related policy that assumes attaining Zero Risk is more important than living our lives. Anyone who wants the additional security of a longer password can have one instantly.  There is no need to mandate that the entire user base do anything (except perhaps to those with power over the website) except to pat yourselves on the backs for having done something.  If someone is actually asking for this, then implement a customization option for individual wikis where their administration can enforce password length if desired.   20:34 4-Sep-2021


 * 1) Is there a demonstrated need on Miraheze that would entail people changing in this way? I have not seen enough of a wider requirement or evidence on the internet of widespread compromise to think this is in any way necessary. --Raidarr (talk) 00:26, 5 September 2021 (UTC)
 * Hmmmm, not sure if this is exactly necessary. I have yet to see any reports of recent account attacks. DarkMatterMan4500 (talk) (contribs) 23:02, 9 November 2021 (UTC)
 * How is the server protected against such attacks? I think that adding a one second delay after each failed login attempt for a specific user name and IP would prevent such attacks from beeing successful, am I wrong? WHen yes, where is the flow in my considerations? LilyLilyu - smile.svg talk and I will listen · Lilypond Wiki 08:13, 11 November 2021 (UTC)
 * 1) Support for global groups, but not for local groups. The current status quo for many of Miraheze's affairs is to let local wikis govern themselves and decide on their own policies, and only intervene when there is a legal obligation to do so, or if there is a ToU violation. Global groups should absolutely have strict password policies, because users with such groups can affect all of Miraheze. However, for local admins and bureaucrats, it's best to leave strong passwords as a recommendation rather than a requirement. Local wiki communities can decide on their own password policies if they so choose. As for the entire user base, I don't think it's necessary. A good idea in theory, but in practice it might not do much to encourage better password use. For all we know, someone who's password is the unacceptably insecure "password" could easily change it to "passwordpassword" to get their password up to 16 characters and meet the requirement, yet still have a terrible password.
 * 2) Also, may I ask, what exactly are the "latest security standards" that you're referring to? If by "latest security standards", we mean "using HTTPS", "hashing passwords", and "keeping up to speed with security patches", we're already doing that, right? — k6ka  🍁 ( Talk ·  Contributions ) 23:24, 9 November 2021 (UTC)
 * 3) not sure what that current mandated length is, but 12 seems too long to me. 8, sure, I'd understand, that's common practice. enforcing numbers and special characters, also good. but 12 digits? for casual users? we'd see a huge uptick in password resets. I can maybe see the benefits for global groups, admins, bots, the like (i.e. people who's accounts could damage wikis if compromised) but for someone who logs in once every six months? not worth it imo. also, which security standards are you referring to? you mention "the latest" - who's latest? Amazingakita (talk) 08:57, 10 November 2021 (UTC)
 * 4) I only want to say that lenght and complexity checkings are ok (mine already is complex and long enough) but I don't agree with checks that compare the previous password with the new one. If I change a password (imagine, because I want it, not because a data breach) I don't want to lose that password forever. Jakeukalane (talk)
 * Hi, I'm also wondering what the "latest security standards" are. Is it some kind of policy that Miraheze has to abide by? Regardless of that, I'm ok with enforcing stronger passwords for users who have potentially destructive permissions, both locally and globally (deleting, blocking, editing interface, etc.). For users without these permissions, maybe there could be a warning with a "your password is not secure" message that the user can dismiss? Just an idea! --Ondo (talk) 10:45, 10 November 2021 (UTC)
 * 1) Pls do not change the current standards for passwords on Miraheze. I totally agree with Spike that everyone is free to chose a password as long as he likes. I would really hate to change my Miraheze passwords. All these password requirements (special character, number, small/big letter etc.) on many websites are really annoying me, so pls do not introduce a new password policy, thank you, LilyLilyu - smile.svg talk and I will listen · Lilypond Wiki 21:29, 10 November 2021 (UTC)
 * 2) Please DO increase password security. This is common sense, and a reality online to protect people's accounts from being easily broken into. I use a password manager that generates random string 20+ character passwords. Working in tech, I can say that increases in password security is just the way things are going to keep modernizing. Fighting that makes little sense because it's going to have to be done elsewhere eventually anyhow and is increasingly insisted on, on other sites. Insecure accounts can affect the Miraheze community because of the unified login; these logins being usable on other wikis can be problematic when an account is easily broken into. I would hope people would consider please keeping up with the tech and being realistic about what that often looks like today. CrystalClear (talk) 22:10, 10 November 2021 (UTC)
 * This is frankly not my experience even including services like Discord, Protonmail and Gmail (though Gmail is aggressive in pushing alternative functions anyways). The path of inevitability is not as clear cut as this would make it seem, at least from allegorical experience that would be easy to find. Though this is not to say that these password changes wouldn't have some benefit, and that people shouldn't be going well past them anyways. But frankly, unless you have responsibility that obliges you to more cutting edge protection, it's discretion I'd rather see users retain until it is demonstrably no longer viable on the internet. --Raidarr (talk) 09:18, 11 November 2021 (UTC)

Request for interwiki prefix on mtccs
Please add this prefix to mtccs: Thanks. Emojiwiki (talk) 13:38, 10 November 2021 (UTC)
 * and  to


 * ✅, see your local mh:mtccs:Special:Log/interwiki for more information. Agent Isai  Talk to me! 16:35, 10 November 2021 (UTC)

Invalid subdomain
Hi, when I made the request to create my wiki, I asked for the subdomain pzwiki.miraheze.org, but instead I got pz.miraheze.org. I can see the subdomain has been changed in my request. Is it possible to change subdomain from pz.miraheze.org to pzwiki.miraheze.org please? Co (talk) 20:47, 10 November 2021 (UTC)


 * Hi there, I handled your request, request #21369. In the request comments, you requested that the database name be changed from  to  . The part before the -wiki prefix is what your subdomain is so your original request was was for   with the subdomain pzwiki.miraheze.org. By asking to rename the database to , you basically asked to change the subdomain to pz.miraheze.org. To request it be renamed, please make a Phabricator task. Thanks.  Agent Isai  Talk to me! 20:56, 10 November 2021 (UTC)
 * Thanks! I just thought it was weird to have a database named pzwikiwiki, but I had no idea it would change the subdomain I selected. Thanks for the clarification! Co (talk) 21:37, 10 November 2021 (UTC)