Community noticeboard

Request for feedback on disabling Citoid and Collection

 * The following discussion is an archived discussion. Please do not modify it.
 * After a full week of this thread being opened, it appears that no one has raised any objections to Collection being removed thus it appears that there is no opposition to SRE to remove Collection. As for Citoid, one of the strongest arguments in opposition to this raised concerns about the possibility of future use of the extension saying that it would not be fair for those who may want to use Miraheze in the future. A few alternatives were demonstrated to the user by SRE which do similar jobs. Additionally, concern was raised in regards to the statistics displayed by SRE to demonstrate that Citoid is not used very much. The statistics were called by at least 2 users to be lacking however, due to limitations, the maximum amount of available statistics of 13 days were released to the community for usage statistics. One other user raised a serious concern saying that they were worried about it being removed but later clarified on Discord that they confused it for the Cite extension. The only other comment on this thread said that it was a cool extension. No further objection was raised on Discord or any other platform even after a mass ping on Discord and a thread being made too to address any concern. Some users on Discord signaled that they found it ok to remove it and as it appears that more are in favor of removal than against. After carefully weighing the singular strong oppose versus the general lack of opposition, and the support that was given to this, it appears that there is no strong opposition to removing Citoid and Collection and that SRE may remove it.  Agent Isai  Talk to me! 20:07, 27 October 2021 (UTC)

Hello Miraheze community,

SRE is soliciting your feedback on the disabling of the Citoid and Collection extensions. The main issue with them is that they require 2 extra servers just for them to host RESTBase. After reviewing usage data, it was found that less than 10 users a day use both of these extensions combined out of the thousands of active daily Miraheze users. In fact, since 00:00UTC of today, 16 October, only 1 user has used Citoid and no one has used Collection. By disabling these 2 extensions, we would be able to better use those now freed up resources by repurposing them and using them in other areas (perhaps another MediaWiki server to decrease loading time, etc.).

For the reasons outlined above, SRE wishes to know what you think about disabling Citoid and Collection. We desire to know what users (especially those who use the extension on their wiki) think about the proposed change. Please let us know about any concern you have about this proposed change. This is not a vote! While you may let us know if you support or oppose this change, please do not convert this into a full-blown vote and use the Support/Oppose templates. Thank you! Agent Isai Talk to me! 19:11, 16 October 2021 (UTC)


 * Citoid is cool and I use it on the wiki where I manage (or used). You would just put a business on EditorVisual to name sites (and even give an example). Wikipedia also uses this extension. If you spend resources on the server, and I use little, then it won't be much needed for me YellowFrogger (✉ Talk  ✐ Edits ) 19:29, 16 October 2021 (UTC)
 * The cite tool in VisualEditor will not go. Just automatic citations from URLs and ISBNs. ~ RhinosF1 - (chat)· acc· c -  21:38, 16 October 2021 (UTC)
 * Hrm? How's that? Quite a few wikis use that feature, as far as I'm aware. Cyberpower678 operates an InternetArchiveBot, as I recall, that does just that thing. Not sure how often it runs, or if it runs more frequently on only a few wikis, but they should be consulted here, together with those local wiki communities. (This is in regards to Citoid. The Collection extension is probably not as widely used anymore in terms of its ability to create PDF books of wikis, but the fact it too shows as apparently under-utilized because its very nature suggests it does not need to be run that frequently.) As well, I also question the argument for removing extensions which are so infrequently used. If they're so infrequently used, they shouldn't be using too many resources. My concern here is that we might be trying to replace one apparent resource hog, RESTbase, with another resource hog, ElasticSearch, with little discernible benefit. Dmehus (talk) 00:00, 17 October 2021 (UTC)
 * Cyberpower678 has a bot that does stuff with Citations. It does not use Citoid in any way which is a service to automatically generate them from a URL or ISBN. These extensions are behind the services system & restbase so requires 2 VMs to run everything that need resources allocated to them. If there was usage and people indicated they needed it, I'd do everything I can to consider if it's worth it. ~ RhinosF1 - (chat)· acc· c -  07:38, 17 October 2021 (UTC)
 * You've identified a very compelling potential use case, of which I was not aware. I had thought Citoid was a completely behind-the-scenes extension; I did not realize it was directly interfacing with end users in terms of semi-automated lookups of bibliographic or publication details. This is definitely something I'd be very interested in for a future wiki; no idea why we're only looking at existing wikis. I have no issues with reallocating system resources, but surely we can find a bunch of our unused extensions to remove in order to save this one. Dmehus (talk) 15:35, 17 October 2021 (UTC)
 * The main trick here is that I don't believe other extensions generally require dedicated server space to use (SRE can correct me if I'm wrong), resulting in a unique draw from these extensions that removing any number of very small but mundane and mostly unused extensions would not match. But in all I think cutting to one server and seeing how it works would be a good thing to try if practical. --Raidarr (talk) 18:21, 17 October 2021 (UTC)
 * Yes, I get the rationale, but I'm not convinced of either the need nor its likelihood to be effective. I don't think SRE has articulated a clear case for what they're trying to achieve here. I would also note that John has let me know that this has not been initiated by the SRE Infrastructure team as part of a larger infrastructure needs assessment, so I'm just struggling to see what the benefit would be here in order to weigh it against the costs (and not just on recent use, but likely use that is core to Miraheze's mission). It strikes me that someone wanting to create a bibliographic database wiki, relying on semi-automated data entry population tools like Citoid would be core to Miraheze's mission. Dmehus (talk) 18:39, 17 October 2021 (UTC)
 * https://en.wikipedia.org/w/index.php?title=Wikipedia:CITEGENERATORS has various tools that can be used. ~ RhinosF1 - (chat)· acc· c -  21:30, 17 October 2021 (UTC)
 * A lot of those are based on, or use the, Citoid, extension. I'd rather see some other alternatives explored, which could including consolidating the two RESTbase VMs into one, or making some other modifications to its allocated resources. These are just a couple ideas, but I'm not really convinced here this is the only option. For example, look recently with the related ReplaceText extension, SRE was able to enable database compression on all wikis, on all but the current revision, to wiki pages, and this allowed the ReplaceText extension to still be used. I see a lot more potential use cases to Citoid than I do ReplaceText, as ReplaceText has an alternative extension in MassEditRegex&mdash;and we kept ReplaceText. Dmehus (talk) 21:40, 17 October 2021 (UTC)
 * Only 2 on there use Citoid. I'm seeing a lot of pushback but very little examples of actual use. ~ RhinosF1 - (chat)· acc· c -  07:03, 18 October 2021 (UTC)
 * I'm not satisfied with the articulated rationale for removing/disabling the Citoid extension in particular, or the potential impacts on other extensions. I'm not familiar with the other extension, so have no comment there, but I also question the data used to propose remove the Citoid extension. I'm also not really satisfied that other avenues to free up server resources were explored. Why does it seem to default to a keep/remove this or that extension? Dmehus (talk) 19:33, 16 October 2021 (UTC)
 * To the best of my knowledge, the data was collected by analyzing nginx logs and also usage logs on services3 and services4 (the 2 servers provisioned to host RESTBase on). Something that prompted this conversation was the issue we faced with some automatic processes not being done, one of which was the automatic updating a configuration file that enabled/disabled RESTBase on the wikis. During the time that the configuration was not being updated, thre was not a single user complaint in regards to this which led us to look into usage data on these extensions and caused us to find that they have very low usage. The reason it may seem that in this case it boils down to "remove this or that" is that these extensions require their own dedicated servers. If they didn't, then we'd have no issue with these extensions but they do and their usage doesn't justify the need for 2 extra servers which do nearly nothing other than serving a few requests per day (if any). Agent Isai  Talk to me! 20:15, 16 October 2021 (UTC)
 * It's not default. It's come to our attention that the usage is virtually none. ~ RhinosF1 - (chat)· acc· c -  21:11, 16 October 2021 (UTC)
 * I'd find no real use but real resource consumption to be a pretty simple equation, honestly. It sounds almost practical for SRE to find and directly poke the ones who do use it personally. Other avenues for resource saving I'm sure can be/have been explored, but essentially unused features can surely be one of them in the meantime. --Raidarr (talk) 22:17, 16 October 2021 (UTC)
 * as the only user in the about 14 hour period of logs we checked today that wasn't broken JS imported from Wikipedia that doesn't actually work or me. ~ RhinosF1 - (chat)· acc· c -  22:21, 16 October 2021 (UTC)
 * honestly, I only use this when i'm on mobile - it's a good extension, and I like it, and would be more in favour of allocating fewer resources than getting rid of it entirely, however I still have to do a lot of editing to get citations the way I want. is there a planned replacement/known similar extension that does this? or will all citations have to be manually done after this? Amazingakita (talk) 16:19, 21 October 2021 (UTC)
 * Hi, There's some tools linked at https://en.wikipedia.org/w/index.php?title=Wikipedia:CITEGENERATORS that you may want to evaluate for usefulness. Please let us know what you expect and how you use Citoid (That's the automatic tab only) so we can work on advising you best. ~ RhinosF1 - (chat)· acc· c -  16:22, 21 October 2021 (UTC)
 * Not satisfied. Citoid seems extremely helpful to communities. I, personally, don't use it on my wiki, but sometimes on other users wiki. Bongo Cat (talk) 23:26, 16 October 2021 (UTC)
 * Could you note some of these communities? --Raidarr (talk) 00:15, 17 October 2021 (UTC)
 * For what it's worth, I've asked Cyberpower678, who operates the InternetArchiveBot, to provide input here, which will likely identify some of those communities. Dmehus (talk) 00:19, 17 October 2021 (UTC)
 * As raidarr said, can you please name them? We're not seeing usage of it. ~ RhinosF1 - (chat)· acc· c -  07:39, 17 October 2021 (UTC)
 * I have been asked about the 14 hour data collection period. As such, I will provide usage stats for as long as we retain them for... over a 13 day period the follow are HTTP code results:
 * 200: 150
 * 400: 9
 * 404: 440,832
 * 502: 8
 * This averages out to 11 successful usages per day and ~34,000 unsuccessful usages per day. John (talk) 14:29, 17 October 2021 (UTC)
 * We have now disabled collection. We're allowing more time for feedback regarding Citoid. Unfortunately, unless we see an actual use case, we would still rather see it removed until a future use case arrives, the services system is fully puppetised so would be fairly easy to restore to our mediawiki cluster if it had use. ~ RhinosF1 - (chat)· acc· c -  07:05, 18 October 2021 (UTC)
 * ''The above discussion is preserved as an archive. Please do not modify it.

Limpar Wiki
Eu gostaria de limpar toda wiki https://wikian.miraheze.org/wiki/ para que eu possa recomeçar do zero pois está tudo bugado e muitos erros estão sendo apresentados. Genuino467 (talk) 13:57, 20 October 2021 (UTC)

Configuring Page Forms
I recently created an new sister wiki, called "Lớp học Mật Ngữ: Fanon Wiki" and I'm configuring Page Forms for Fanfiction Maker. I got some success while making it, but I still need some helps from you guys.

Here's things I need help: Pisces (talk) 05:44, 21 October 2021 (UTC)
 * 1) How could I binding values of the checkboxes and tokens into an category?
 * 2) How could I exactly adding values into templates while doing the form?

Adding prefixes for interwiki (lhmnfanonwiki, lhmnwiki and brawlstarsviwiki)
While waiting for my Interwiki Administrator request, I did got some prefixes need to be changed or added on my wikis.

Effected wikis: lhmnfanonwiki, lhmnwiki and brawlstarsviwiki

into all of the wikis above (with Forwarding, not Transclusion). Thanks for the helps, Pisces (talk) 15:25, 21 October 2021 (UTC)
 * 1) Delete wwtbamvn, lophocmatngu, brawlstarsvn from lhmnwiki and brawlstarsviwiki
 * 2) Adding:
 * lhmn -> lhmn.miraheze.org
 * bsvn -> brawlstarsvi.miraheze.org
 * fanon -> lhmnfanon.miraheze.org


 * This is ✅ at this time. Check the logs for the different wikis. Kind regards. Ugochimobi (talk) 22:44, 21 October 2021 (UTC)

Problem with Slideshow
Hello, so here it is, I have a problem with Slideshow. I would like it to appear to the right of my text, so it appears on, as you can see here: https://personnages.miraheze.org/wiki/Blaze_the_Cat#Pouvoirs_et_capacit%C3%A9s Can you help me? Thanks in advance. Darkrai18 (talk) 20:18, 21 October 2021 (UTC)


 * The slideshow is unable to be fixed even when I add the |right| on the since the slideshow only appears to the right of the text for a while and then switched back to the left after I refresh the page. So I replace the slideshow with the image. SchizoACC (talk) 16:24, 22 October 2021 (UTC)
 * It was nice of you to try. I will add though that it is possible to do it, look here: https://wiki.comakingspace.de/Main_Page/Slideshow Darkrai18 (talk) 16:27, 22 October 2021 (UTC)

criminals wiki.
criminals please join!!! SperosDurrell (talk) 21:56, 22 October 2021 (UTC)

Does miraheze have a storage space limit?
Is there any limit to the number of pages in a wiki, its storage space or the number of uploaded files? WilliamGreenferry (talk) 10:17, 24 October 2021 (UTC)
 * No, Miraheze does not currently have any sort of exact storage limit in terms of what wikis can upload. That being said, our resources are of course finite so that is something to keep in mind. Reception123 (talk) ( C ) 11:29, 24 October 2021 (UTC)

Looking for documentation for the "Whitelist Read ($wmgWhitelistRead)" setting
I am considering setting a small number of pages on a private wiki to be pages anyone may view. I see the setting "Whitelist Read ($wmgWhitelistRead)" on the Permissions tab of "Manage this wiki's additional settings" that appears to be what I want... but I don't see any documentation on how to list the pages.

Is this a field that I have to enter pages into one at a time, or do I enter a string listing multiple pages? If the latter, what is the syntax and maximum length of the string?

Can I list files to be displayed on the pages that I want to make public? If yes, do I specify them as "file:foo.jpg", "media:foo.jpg", or "foo.jpg", or something else?

What is the maximum number of entries that I can add to this field? Robkelk (talk) 23:42, 25 October 2021 (UTC)


 * You should get a dropdown with a list of pages according to our config. You can insert as many as you like. The limit will be as much as can fit in the DB without running out of room in the settings column which is a very big number. ~ RhinosF1 - (chat)· acc· c -  07:57, 26 October 2021 (UTC)

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)

Interwiki table
I would like to request to in the interwiki table of XComhghall Wiki. Thank you very much. — XComhghall (talk) 15:23, 26 October 2021 (UTC)
 * Set  of the prefixes   and   to  ,
 * Add the prefixes  and   to , and
 * Add the prefix  to


 * This is ✅ at this time Ugochimobi (talk) 20:32, 27 October 2021 (UTC)
 * Could you please
 * Add the prefix  to , and
 * Add the prefix  to  ?
 * Thank you very much. — XComhghall (talk) 19:36, 28 October 2021 (UTC)

Reference Tooltips, EditTop Gadgets, Wikiplus
I would like to add the Reference Tooltips and EditTop gadgets to my wiki, XComhghall Wiki. But Reference Tooltips requires the dependencies mediawiki.cookie and jquery.client, and MW: Extension: Gadgets. And EditTop requires the dependencies user.options and mediawiki.util. What can I do? Could you please help me?

Regarding Wikiplus, here is a previous conversation on the community noticeboard: https://meta.miraheze.org/w/index.php?title=Community_noticeboard&oldid=208443#EditTop_Gadget,_and_Wikiplus.

Wikiplus is working fine on Wikipedia. I just imported it to my global.js page. This is what I did on both Wikipedia and Miraheze. It was working fine on Miraheze in August, but currently it is not working on any Miraheze wikis, even my own wiki, where I am the bureaucrat, sysop, autoconfirmed, and confirmed.

It is supposed to show an edit window above the section edited, and can be expanded and moved. But currently on Miraheze, it shows a shrunk edit box at the bottom of the page, without background color, border, design, etc., and cannot be moved.

What should I do? Could you please help me?

Thank you very much. — XComhghall (talk) 16:01, 26 October 2021 (UTC)


 * The two gadgets you want can be handled by yourself, They can be installed on your wiki as a gadget too, plus, the libraries you mentions are what are already on MediaWiki and as such, you don't need to install them separately. You only need to enable the mw:Extension:Gadgets on your wiki.


 * For the latter, you should confirm if Wikiplus is currently not broken on English Wikipedia, if it is then it's not our fault, it's coming from upstream. After looking through the codes, I doubt if it will work on here when it's not locally installed though, tbh. Ugochimobi (talk) 20:41, 27 October 2021 (UTC)
 * I just confirmed that Wikiplus works fine on the English and Chinese Wikipedias, Wikisources, and Wikinews. It used to work fine on Miraheze too. — XComhghall (talk) 19:34, 28 October 2021 (UTC)

what does "The database name may not contain non-alphanumeric characters." mean when i request a miraheze
same as title.

i would show a pic but i cant for some reason ZX-EXE (talk) 18:35, 28 October 2021 (UTC)


 * This may be because you entered something like 'yourwikiname.miraheze.org' instead of 'yourwikiname' when putting in a subdomain. Only offer the subdomain name, miraheze.org is not required. If this isn't the case, please mention what you tried for the wiki's subdomain since this is what it means by database name. --Raidarr (talk) 18:50, 28 October 2021 (UTC)
 * A request was made, so it appears this issue was resolved. --Raidarr (talk) 19:10, 28 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.

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

Other wikis
These are the wikis with similar topics as others. They should have their topic modified so that there is no overlap of topic.
 * Wikis with a similar purpose to Stories Wiki (reading and writing stories):
 * 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.)

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