Community noticeboard

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 or no response in a week, go ahead to step 3.
 * 3) *If the wiki is closed or if there are no active users, 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 no one votes in a week, go ahead to step 4.
 * 7) 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.
 * 8) 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 Free Editing Wiki (anything goes wiki)
 * Anything Goes Wiki

Wikis with overlapping/divided topic and scope
These are the wikis with overlapping or divided topic and scope. Their topics are not related enough to categorize them as duplicates, but they overlap in scope. If you can think of any other topics or other duplicate wikis with already existing topics, please post them in the Comments section. Tali64³ (talk) 18:50, 2 November 2021 (UTC)
 * 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.
 * Minecraft anarchy server wikis (propose to merge all these into the Anarchy Minecraft Servers wiki (currently closed, but it can be adopted or reopened). Also add details to Minecraft Wiki about these servers.)
 * 2b2t Wiki
 * 2B2Tmcpe.org wiki
 * 2builders2tools wiki
 * 5b5t
 * 6b9t (closed)
 * 9b6t
 * The Original 9b9t Wiki
 * Wikis about Microsoft and its products (should all be merged with Microsoft Wiki):
 * Windopedia (wiki about Windows)
 * Everything Windows Official Wiki (another wiki about Windows)

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.

Comments
Have anything you like to share? Please put it below.


 * 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)


 * 1) 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
 * 2) 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.
 * 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)
 * 1) 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)
 * 2) 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)
 * 1) I do not see a strong need to increase the password requirements as proposed. As with K6ka's comment, I do  increased password security and two-factor authentication for users holding global groups (to be clear, wiki creator and interwiki administrator should not count as global groups for this purpose). I'm speaking of the SRE, Trust and Safety, and Stewards groups, principally because the   group on Miraheze is not the same as the   group on other wikis, as Miraheze has ManageWiki which provides for the granting of user group permissions without having to have the   user right that would otherwise provide access to the most sensitive, restricted user groups. I also feel that twelve characters is too much, but would support a 9-10 character minimum, with a combination of a minimum of one capitalized character, one non-alphanumeric character, and a mix of numeric and alphabetic characters. Dmehus (talk) 01:54, 15 November 2021 (UTC)
 * 2) I this as well. Coming from a company where this has been mandatory since years I would like to have this level of security here as well, especially because of the global login. Password managers can deal with even longer PWs, just saying. Soukupmi (talk) 07:58, 15 November 2021 (UTC)
 * 3) You say "latest security standards", yet provide no evidence for how this is considered to be so. Considering that I haven't seen any widely used platforms make such a change to password length, this change seems to lack any sort of proper reason behind it from what I can see. K599 (talk) 20:53, 15 November 2021 (UTC)
 * 4) It is my opinion that in this matter it is necessary to take a balanced and reasonable approach rather than a overreaching one. Unlike some comments above suggest I do not believe that it is unreasonable to require a certain password length and I think this is a sensible approach. That being said I do not agree with imposing a 12 character password for all users indiscriminately. This is because as many users have said before me the SRE team does not provide us with any justification or evidence to justify such a measure. If there have not been any accounts that have been hijacked why is it necessary to take such a measure right now? Is there a security risk we do not know about? I believe that in terms of regular users there is no need to change the current requirements and that users with low level access should make their own decisions regarding password length. I have personally not seen another website that has such strict requirements for lay-users. However, I do think that all global groups with significant power (such as Stewards, System Administrators and Global Sysops) should have this requirement as an extra safety precaution. I would not necessarily disagree with local groups such as administrator and bureaucrat having the requirement but I tend to lean towards the direction of them not having this requirement for the time being unless an actual need is proven. In conclusion, my current opinion is that an all encompassing requirement is inappropriate at the time but I would be willing to change my opinion if the SRE team will provide me with a reasoned explanation and justification for these measures other than just to be very careful. To be more clear after reading all the comments again my opinion is closest to that of Dmehus which I would support and which I find the most reasoned. --DeeM28 (talk) 20:12, 16 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)

My IP is blacklisted
I tried to create an account but after many tries, it shows the message of my IP being a spambot. I waited for 5 hours, then tried again, same error message. Can any sysop remove my IP from the blacklist? Thanks. 14.162.95.11 21:55, 12 November 2021 (UTC)


 * 14.162.95.11, I'm not seeing that this IP is blocked locally on Meta Wiki (this wiki) or globally, so you should be able to create an account. If for some reason you are not able to, please e-mail your desired username to Stewards at, and one of us will create an account for you with that username and e-mail address, with a temporary password delivered to that e-mail address. Thanks. Dmehus (talk) 01:36, 13 November 2021 (UTC)

I requested a private wiki, but can't access it
I requested a private wiki (qxd0008), and it was duly created, but when I try to access it I get the following error:


 * "Erro de permissão


 * Você não possui permissão para ler esta página, pelo seguinte motivo:


 * A ação que você tentou executar está limitada a usuários de um dos seguintes grupos: Membros, Administradores."

which translates to (translation mine):


 * "Permission Error


 * You do not have permission to read this page, because of the following:


 * The action you tried to perform is limited to users of the following groups: Members, Admins."

I believe maybe some configuration step was omitted, or maybe it'll still be performed and I should wait, but I don't know... Ararunaufc (talk) 01:17, 13 November 2021 (UTC)


 * Ararunaufc for your report. It looks like there was a socket read error as part of the jobrunner server's handling of the CreateWiki extension's creation of your wiki job. This is a usually fairly infrequent occurrence, and has been reported to SRE via a Phabricator ticket (can't recall the ticket number off the top of my head). When this happens, the best place to report this is at stewards' noticeboard, so a Steward can manually grant you rights, which I've now ✅. Agent Isai, whenever you see this happen, please also give us a head's up at stewards' noticeboard and also make sure you're proactively checking the CA after ever wiki you approve has been created, to ensure rights are granted. Thanks! Dmehus (talk) 01:28, 13 November 2021 (UTC)

Notice of Private Wiki Search Results Incident
On 12 November, 2021, Site Reliability Engineering was made aware that search results (page titles only) on private wikis may have accidentally been cached and thus publicly visible. SRE took steps immediately to remediate the issue and confirmed only search results were publicly visible. There is currently no indication anyone purposefully viewed private wiki search results through means of the cached version available. If you have any questions, please feel free to email sre@undefinedmiraheze.org or ask on on IRC/Discord. Thank you. Agent Isai Talk to me! 15:20, 13 November 2021 (UTC)


 * This seems quite minor, as it's only the page titles and web search page caching. The problem was remediated once identified, so this is great. Thanks for the head's up! Dmehus (talk) 15:26, 13 November 2021 (UTC)


 * Minor, but good for precedence to hear about. Glad you were on it. --Raidarr (talk) 10:20, 14 November 2021 (UTC)

1. Interwiki table. 2. Reference Tooltips. 3. Wikiplus. 4. Content Model. 5. Gadgets.
I. The interwiki table

Could you please add To the interwiki table of XComhghall Wiki?
 * 1) the prefix   to , and
 * 2) the prefix   to

'''II. Reference Tooltips'''

I enabled the gadgets extension on my wiki, and imported the js and css files, but Reference Tooltips is still not working. What is wrong? What should I do?

'''III. Wikiplus'''

I installed Wikiplus (EN Wikipedia), a user-maintained script (see the  discussion on MW), on  my global.js page on Miraheze. It was working fine in August. The edit box appeared on top of the section I edit, as shown in this gif, and can be expanded and moved. Currently, Wikiplus works fine on EN and ZH Wikipedia, Wikisource, and Wikinews, but I am experiencing problems with it on Miraheze, including my own wiki. The edit box appears at the bottom of the page, cannot be moved, and has lost the original background color, border, design, etc. Do you know what the problem might be? What should I do?

'''IV. Content model'''

Is there a way to enable ? This is for MW: Extension: TemplateStyles.

V. The gadget extension

I have a few gadgets set as default on my wiki's MediaWiki: Gadgets-definition. If I do not enable MW: Extension: Gadgets, will the default gadgets still work, or will they be disabled along with the Gadget extension?

Thank you very much. — XComhghall (talk) 04:56, 14 November 2021 (UTC)


 * 1) I have ✅  to your interwiki table but not  .   seems to redirect to , is it ok if I add that to the interwiki table instead?
 * 2) Have you enabled them on your end?
 * 3) Wikiplus' domain (wikiplus-app.com) is not in our Content Security Policy and as such will always fail to load. Try importing it to your wiki locally or using a script on the English Wikipedia itself.
 * 4) At this moment, no. It is not within ManageWiki. You can ask for it to be added on Phabricator.
 * 5) Gadgets cannot be disabled as far as I know. Agent Isai  Talk to me! 06:40, 14 November 2021 (UTC)
 * Agent Isai I would say that's likely fine, but  is already in the global global interwiki table, as , I believe, so unless XComhghall wants the forward and/or transclude flags enabled, or a different prefix, it may not be needed? Dmehus (talk) 21:10, 14 November 2021 (UTC)
 * Agent Isai, Dmehus:
 * 1. Could you please make  a local interwiki prefix, not an interlanguage prefix?   is fine. I do want the shorter   prefix.
 * 2. The Reference Tooltips gadget is set as default on https://xcomhghall.miraheze.org/wiki/MediaWiki:Gadgets-definition, and is enabled on my https://xcomhghall.miraheze.org/wiki/Special:Preferences#mw-prefsection-gadgets.
 * 3 and 4. Thank you very much.
 * 5. Do you mean that the gadget extension cannot be disabled, or that gadgets set as default on MediaWiki: Gadgets-definition cannot be disabled?
 * Thank you very much. — XComhghall (talk) 21:37, 14 November 2021 (UTC)
 * Regarding, that can't be done, unfortunately, as the language codes are reserved for interlanguage prefixes. You could have a single character in front of, or behind, the   to make it an interwiki prefix, but it would need that character. Dmehus (talk) 21:54, 14 November 2021 (UTC)
 * XComhghall  is ✅. For the Reference Tooltips gadget, yes, that can be disabled. You would just edit your gadgets definition file to make it not be enabled by default and, to disable it locally for yourself, just go into Special:Preferences (on that wiki). Dmehus (talk) 22:02, 14 November 2021 (UTC)
 * Agent Isai, Dmehus:
 * I see! What would happen if forward = yes for the prefix en?
 * The problem with the Reference Tooltips gadget is that I enabled and imported everything, but it is still not working. Do you know what might be wrong? What should I do?
 * I was asking Agent Isai what they meant by 'Gadgets cannot be disabled as far as I know.' I was asking what would happen if the Gadgets extension is not enabled, but MediaWiki: Gadgets-definition defines some gadgets as default.
 * Thank you very much. — XComhghall (talk) 22:15, 14 November 2021 (UTC)
 * For the Reference Tools gadget, it should be able to be disabled by adjusting the flag in the MediaWiki:Gadgets-definition page, if it's enabled by default for all. Some gadgets are not enabled by default for all, so it should be possible. Note that it will conflict with the Reference Previews extension (enabled via ManageWiki). So if you have it enabled for all, or if it cannot be disabled for all, I would personally recommend the gadget over the extension, due to the greater functionality the gadget offers (i.e., ability to apply across namespaces). For the interlanguage prefix, though it has English Wikipedia in the URL, you should be able to use it with other interlanguage English language wikis, but that might require a second  prefix and a different URL. The forward flag just means that bots, API-based tools, and search engines will follow any interwiki links that include the   interlanguage prefix. For example, it's required to be enabled for wm-bot interwiki links in IRC channels. Otherwise, if it's not enabled, search engines will not follow the interwiki links and instead MediaWiki will return a bad title error. Hope that helps. Dmehus (talk) 22:26, 14 November 2021 (UTC)

$wgPFEnableStringFunctions
Why is $wgPFEnableStringFunctions disabled here on meta? It limits the possibility of advanced templates. Why is it disabled, is it some exploit or server issue or something?

If it can be enabled, please enable it. Anpang  Talk  06:13, 14 November 2021 (UTC)


 * Anpang This seems like a reasonable request, so I've ✅ this for you. Dmehus (talk) 22:07, 14 November 2021 (UTC)
 * Thank you! Anpang   Talk  00:34, 15 November 2021 (UTC)
 * No problem. :) Dmehus (talk) 00:39, 15 November 2021 (UTC)

Problem tabber
Hi, there, Would you know how to make a caption only appear in one tabber window? I know how to make it appear in both, but when I try to do it in one, the caption shows up in bold, as you can see here: Thanks in advance. Darkrai18 (talk) 13:49, 14 November 2021 (UTC)


 * Hello, my apologies for delay in responding. Has this been resolved? I have located the page you mean and it seems like you managed to get the caption going in one and not the other. If you meant something else, I ask for more information on what is intended. --Raidarr (talk) 12:43, 17 November 2021 (UTC)

Professionalization of the donation request
After nice chat about it on the Miraheze IRC channel I figured I'd post about it here. I deeply appreciate the need for donations for this whole project to live, just to make that clear at the outset.

Still, the request notification at the top of all wikis at the moment seems like it could be a lot better in a few ways. Especially on mobile it looks a bit "janky" as someone in the IRC chat said :)

First off: If you don't have a very big phone screen, it fills up the whole of the screen. This might make new visitors confused to the point where they just leave right away. If so, there's no chance that they will actually donate.

Second, the justification of the text together with the logo looks quite unprofessional in a small window. It's very uneven.

Thirdly, If you have a dark skin on your wiki, the message looks very much out of place. I understand the need for it to grab attention, so I'm not saying it should blend too much in, but maybe there's some middle ground here?

Bonus: I fear that this message could turn random visitors away from my wiki, and I also have a hard time imagining first time visitors actually donate. I'm wondering if there is any statistics on this, how many first time visitors click trough from the message, how many non-logged in visitors clicks trough, etc. If almost no first time visitors does click trough, maybe it would be smart to only show the message the second time someone visits? Just a thought. Another thought is that I would be willing to donate more than I have if there was a specific amount I could donate to skip this temporary message for not-logged in visitors one time.

Thank you all so much!

With much respect, Forteller (talk) 19:56, 14 November 2021 (UTC)


 * @Forteller Here's some good news, you can actually remove the donation banner for free by going to Special:ManageWiki/settings and enabling "Opt out of global Miraheze notices". Hopefully that's suitable for your needs. K599 (talk) 20:08, 14 November 2021 (UTC)
 * This isn't really recommendable as you opt out from all Central Notices, some of which are important and affect wikis closely. Agent Isai  Talk to me! 20:10, 14 November 2021 (UTC)
 * I agree it's not recommended, but we do have one other wiki where it's been suggested to temporarily opt out of the central notices during the annual donation campaign. Dmehus (talk) 20:11, 14 November 2021 (UTC)
 * I would say that it is, in fact, recommendable because having this option be available respects the decisions of the individual communities behind each website being hosted on this wikifarm. K599 (talk) 20:18, 14 November 2021 (UTC)
 * I don't think Agent or I were suggesting that. Each wiki can, absolutely, make their own decisions with respect to configuration settings, but from a recommended best practice standpoint, should they choose to follow it, I would say it's recommended to stay opted into Miraheze central notices. There's still no obligation for wikis to follow that, and where it doesn't fit their needs, we will still advise them on how to opt out&mdash;whether temporarily for this annual campaign or indefinitely. Dmehus (talk) 20:24, 14 November 2021 (UTC)
 * That would only be "best practices" if there were central notices that were absolutely universally important, which while I won't deny that there might be, an example of what that would be should be given. For central notices that don't fit what I just described, I think each individual community can decide for themselves if they're important enough to be displayed on their websites. K599 (talk) 20:37, 14 November 2021 (UTC)
 * They can, absolutely, and that's not what we're saying, but wikis do look to the Miraheze community for guidance, which we're more than happy to give. Dmehus (talk) 20:46, 14 November 2021 (UTC)
 * Well, just to make this clear to anyone reading this discussion, communities don't necessarily need to look for the guidance of the Miraheze meta community to make their own decisions, and even if they do choose to receive guidance from the Miraheze meta community, they don't necessarily need to agree with such guidance. Of course, each community is free to ask for anyone's guidance if they would like it, but again, don't feel like you have to agree when you have good reasons for disagreeing. K599 (talk) 20:59, 14 November 2021 (UTC)
 * Absolutely, and I don't think Agent or were suggesting that. These are just recommended suggestions to wikis on the reason(s) for staying opted into central notices. We can, and have, advised on how to opt out of central notices, but do advise on the reasons for remaining opted in&mdash;chiefly to remain connected to the Miraheze global community and "in the loop," so to speak, on important developments. Interestingly, you and I seem to be making the same point, but just doing so diffently, and I've often advocated for SRE to use central notices, which can be opted out of as it provides for greater local control, rather than the sysadmin sitenotices that are added to, which can't be opted out of, and which can't be customized aesthetically (nor translated). Dmehus (talk) 21:06, 14 November 2021 (UTC)
 * I suppose my point has been made. Thanks for now being descriptive on the apparent reasons. K599 (talk) 21:25, 14 November 2021 (UTC)
 * Thank you for your comments. I personally don't feel that centred looks like "junky." In terms of size of the central notice, one has to consider Miraheze is 100% funded by donations, so we need to balance between saying too much or too little. In short, saying too little and making it too small would make it "blend in" and be too inconspicuous, thus defeating its purpose. It's meant to be "in your face," if you will. Without user donations, there is no Miraheze (well not the ad-free Miraheze we know and love). As well, one has to consider that most people edit Miraheze from a desktop, rather than mobile, device. I personally can't imagine trying to edit on a wiki on a tiny mobile screen. In terms of statistics, SRE might be able to investigate compiling some statistics from Matomo, if that's possible, for you. If after all of that, you should be able to opt your wiki out of central notices in Special:ManageWiki/settings on your wiki. You could then, optionally, replace it with a smaller sitenotice. :) Dmehus (talk) 20:10, 14 November 2021 (UTC)
 * You're probably right that most people edit wikis from desktop, but most people seem to use the web on phones. And it is probable that almost all visitors are readers, not writers :) Maybe a shorter version for phones and a longer one for desktop could be a way to go? Just a thought. Forteller (talk) 21:56, 14 November 2021 (UTC)
 * Yeah, that is definitely possible, I think. We'd just have to design a shorter version of the central notice, set it to mobile devices, and then set the current central notices only to non-mobile devices. I'll try and take a look at that, but if I don't get to it, I'm going to ping Reception123 to this thread. Dmehus (talk) 21:59, 14 November 2021 (UTC)

Template error
I imported a template from Wikipedia and I succeeded in getting it running but it conjured an error in the process. How can I remove "templatestyles src="Template:Multiple image/styles.css" wrapper=".tmulti"> " here? Wingwatchers (talk) 21:09, 14 November 2021 (UTC)


 * Wingwatchers If you go to here, you should be able to delete that page. I can demonstrate, if you'd like, but it seems likely what you need to do is go here, select "Parser functions," and enable TemplateStyles. Again, if you'd like me to do it for you this time, I can. Dmehus (talk) 21:14, 14 November 2021 (UTC)
 * It did nothing. Wingwatchers (talk) 22:42, 14 November 2021 (UTC)
 * Wingwatchers I wondered if maybe the CSS style page needed to be purged, so I undeleted it. However, that didn't do anything, either, so I wondered if maybe the issue was the content model of the page. I asked Universal Omega if  was added to ManageWiki/namespaces, so this could be set on a namespace basis if TemplateStyles is enabled. So, what you need to do is change the content model of the page, as I did here. I'm wondering, though, since the parent template page didn't exist, it didn't automatically format it as a CSS page? In any case, that's an option for you. Dmehus (talk) 23:08, 14 November 2021 (UTC)
 * "Page Template:Multiple image/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "CSS")." There's still some error within the template. Wingwatchers (talk) 01:58, 15 November 2021 (UTC)
 * Wingwatchers, ah, I wasn't sure whether to use CSS or Sanitized CSS. Looks like I chose the incorrect one for this use case! In any case, I've now ✅ this to Sanitized CSS, and purged the page(s). The template error seems to have disappeared. Can you take a look if it has the desired look now? From my layperson's perspective, it seems to look good. :) Dmehus (talk) 02:29, 15 November 2021 (UTC)
 * Thanks for the help! Wingwatchers (talk) 03:29, 15 November 2021 (UTC)
 * No problem! :) Dmehus (talk) 04:19, 15 November 2021 (UTC)

Question
What's the current background theme Iron Sword 23 (talk) 13:51, 15 November 2021 (UTC)


 * What do you mean? If it's skin its probably vector Anpang   Talk  02:58, 17 November 2021 (UTC)

Miraheze @ Wikimania 2023
Hello,

During today's Miraheze Meeting, we confirmed that in 2023 we are considering attending Wikimania. If you'd like to join the party or get further information, please fill out https://forms.gle/GT2VCeRSCw9NdmR6A and we'll be in touch! RhinosF1 (Miraheze) (talk) 22:33, 15 November 2021 (UTC)

Looking for advice on how to include templates within templates
Hello! I've read through template documentation and understand the basics, but the page on advanced templates lost me (https://meta.wikimedia.org/wiki/Help:Advanced_templates). I can't seem to get my page to display the parameters when they are selected on pageforms if the parameters belong to a template within my "main" template.

I'm trying to embed templates within templates and am running into some problems. If you want to see what I'm trying to do:
 * here is a link to a "main" template I am using for a pageform:
 * https://parentratings.miraheze.org/wiki/Template:Page_Test
 * here is a link to a page created with a form that calls that template:
 * https://parentratings.miraheze.org/wiki/Generic_Test_Page_1
 * here is a link to one of the templates that my "main" template calls:
 * https://parentratings.miraheze.org/wiki/Template:PRCD_Table_Test
 * and a link to the template that that sub template calls (this is the one that contains the parameters for my form):
 * https://parentratings.miraheze.org/wiki/Template:Language_Tags

I thought about trying to do this differently, as shown in the "Sites that Use Page Forms" documentation example but I can't for the life of me find where that page is calling the "Print_entry" template. It just tells me it is towards the bottom of the edit page. And this would still require me to understand some advanced template wizardry that I'm struggling to understand. For instance:
 * the layout for this page:
 * https://directory.fsf.org/wiki?title=Blender&action=edit
 * is determined by this template:
 * https://directory.fsf.org/wiki/Template:Print_entry
 * how does it "initialize parameters/variables"? (I think this is the right phrase, but I'm not sure). I see the numbered list, but I can't seem to recreate it. I feel like I need to do something like this, but I'm not sure how.

I've also read about using, but I'm not sure if I need to use that on every single pipe in all my templates except my "main" template, or just the ones dealing with my parameters. Maybe I even need to add extra {} brackets around some of the rest of my template parameters, but I'm not sure how many or when and where.

Lastly, as a separate question, calling a template twice seems to be throwing an error (pages using duplicate arguments in template calls). At least that's what I think is happening. Is it possible for my page to display the forms-selected parameters twice, but in different locations without this error creeping up?

Any help would be greatly appreciated, even if you can just point me in the right direction a little bit. I'm happy to keep cracking at this. Thanks! ParentRatings (talk) 05:38, 16 November 2021 (UTC)


 * While I'm not 100% sure what you're asking for help with or about the entire scope of your request, I can explain how the site you referenced is functioning. You already have Page Forms on your wiki, so that's a good start. The way FSF has their Directory set up, they use Page Forms for all page creations and edits. On creation, Form:Entry is attached to the Print entry template, which Page Forms then substitutes into the finished page once the form is submitted. There is some extra stuff on that wiki because they are using the full suite of semantic extensions, with many functions and capabilities beyond the forms extension. As for the ordered (number) list on that template, that's really just their documentation. It tells power users and admins what the parameter values are supposed to be when editing without the forms. Basically, it just tells you that the first parameter (meaning ) in this case corresponds to wherever the name of the application belongs. Again, this question is asking for a lot of diverse information about templates, so in order to help us understand what you need help with and to be more likely to get the answers you need, it would be helpful to get a bit more specific. I do hope this can answer some of your questions and help you get started though!  dross  (t • c • g) 23:38, 16 November 2021 (UTC)
 * Thanks so much! I tried to give as much information as possible, but I can see now how that can be confusing - sorry about that. I'm also still learning the jargon. You mention that Form:Entry is attached to the Print_entry template. How are they attached? As far as I can tell, the Print_entry template provides the page layout for each Entry on FSF - I want to do something similar on my wiki. But although Form:Entry has and other "for template" sections, I cannot see how this form is attached to the "Print_Entry" template. Understanding how to make that connection to my "layout" template while at the same time building my form around different templates that contain the parameters I want displayed would be a great help.
 * Hope this time was a little more clear. Thank you so much. :) ParentRatings (talk) 05:10, 17 November 2021 (UTC)

Interlanguage request
I would like to send those interwiki links: To the wiki:
 * cs - https://csup.miraheze.org/wiki/
 * de - https://polandballde.miraheze.org/wiki/
 * en - https://polandballwiki.com/wiki/
 * es - https://polandballes.miraheze.org/wiki/
 * hy - https://hypolandball.miraheze.org/wiki/
 * ja - https://japolandball.miraheze.org/wiki/
 * pl - https://plpolandball.miraheze.org/wiki/
 * pt - https://pt.polandballwiki.com/wiki/
 * ru - https://polandballru.miraheze.org/wiki/
 * zh - https://zhpolandball.miraheze.org/wiki/
 * id - https://bolapolandia.miraheze.org/wiki/

LegoFan506 (talk) 12:00, 16 November 2021 (UTC)
 * ✅, check your local mh:bolapolandia:Special:Log/interwiki for more information. Agent Isai  Talk to me! 15:03, 16 November 2021 (UTC)
 * Can you send the interwiki link (id) https://bolapolandia.miraheze.org/wiki/ to (en) https://www.polandballwiki.com/wiki/Polandball_Wiki? --LegoFan506 (talk) 10:59, 17 November 2021 (UTC)
 * I think Agent already did that along. Ugochimobi (talk) 16:05, 17 November 2021 (UTC)
 * Indeed, as Ugochimobi has pointed out, I have ✅ this. Note for future reference though that generally speaking, only local administrators or bureaucrats can request a global Interwiki administrator add an interwiki prefix to a wiki. However, seeing as I am a local  on , I have completed this reasonable request.  Agent Isai  Talk to me! 17:57, 17 November 2021 (UTC)

How to import or move an existing MediaWiki to Miraheze
I have a MediaWiki and downloaded the content. How can import that package here in Miraheze?? 84.21.34.146 13:22, 17 November 2021 (UTC)


 * After you've requested a wiki, please make a Phabricator task and link the XML dump. Your XML dump should be first uploaded to an external storage service such as Google Drive or MEGA. Agent Isai  Talk to me! 14:49, 17 November 2021 (UTC)
 * Worth noting that creating a user account will be necessary for this if you haven't already. --Raidarr (talk) 17:50, 17 November 2021 (UTC)

A proper way to report users
For example, I've found a suspicious user (that should be globally locked) in recent changes or cvt-feed or something like that. What's the best way to report them? Community noticeboard? Well if I find 10 over a week I'll make atleast 3 topics, too much. If there's no good way yet, I suggest a noticeboard only for reporting users, the noticeboard will be archived very often. Anpang  Talk  03:42, 18 November 2021 (UTC)
 * You can do it on the Stewards noticeboard (a lot of people report there) or you can also send an email to Miraheze. Community noticeboard is intended to get help from other Miraheze users/community. YellowFrogger (✉ Talk  ✐ Edits ) 04:23, 18 November 2021 (UTC)
 * Hmm yes. Thank you! Anpang   Talk  05:05, 18 November 2021 (UTC)