Minecraft Wiki talk:Community portal

Minecraft Wiki Community portal discussion page

This is the community's main discussion page.

Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.
This page is for community discussion; generally, wiki issue reports should go on the Admin's noticeboard and discussions about a single page do not belong here.

Archive basics |archive = /Archive %(counter)d |counter = 32

Template documentation project: Usage section style

Recently I opened a discussion regarding this at Minecraft Wiki talk:Projects/Template documentation cleanup.

The project aims to improve the templates documentation to make them clear to all users. The current way to do this is that big templates use a table to explain their parameters, while the small ones just use text. An example of a small template using a table to explain its parameters is at Template:Work in progress/doc/editcopy.

My goal is to make them consistent, but to do that we should either make all small templates have the same text style and all the big templates have the same table style, or make that both types of templates use tables to explain their parameters. You can discuss here first, and then add proposals on the link above. Thejoaqui777 (talk) 18:55, 2 March 2021 (UTC); edited 03:14, 3 March 2021 (UTC)

I would suggest smaller templates to just have a template data for summary and bigger templates to have both template data and detailed explanation of each parameters below it. TemplateData is necessary for visual editor, where it can provide a brief of explanation of each parameters. Table is inevitable as it's auto generated by TemplateData, though only if we are going to make every possible template to be visual editor-friendly.

Retrieved from Wiki Discord: "It seems that the way Wikipedia does this is with TemplateData on its own section. But since we are a very small wiki when compared to Wikipedia, using TemplateData should be enough for a brief summary of parameters.

If there are additional information or details that need to be addressed, then you may include them below the TemplateData (still within the "Usage" section), for example Template:Exclusive/doc has additional information regarding the "Editions" parameter.

Note that TemplateData description can't include links or other text formattings. So if one explanation has to contain lots of links, you may want to describe the information below the TemplateData (like the one on Template:Exclusive)." – ItsPlantseed ⟨₰|₢⟩ 19:14, 2 March 2021 (UTC)

Making a prototype article for traffic light sytems

does anyone know how to create a new wiki page? i want to make a article for this and show my innovative ideas. here is how it goes so far and i would like improvement suggestions: Minecraft traffic signals have long been red green only or without advanced features such as left turn signals without alternative intersection designs such as the continuous flow intersection. but now the modular parts are here. while at the time, the page editor is working on actuated control, actuated signal control is finally a thing for smart intersections. here is a current list: 26 repeater 4 tick 2 phase yellow light included controller, kill switch comprised of 2 inverters. with a input in between the 2 inverters. this is also the base for the yellow light timer, containing 5 4 tick repeaters. and a actuated control max out timer. call prioritizors are being worked on. no progress has been made due to work on other devices related to actuated control. the next build on the line you can make yourself is the night flash controller. the how to's are somewhere else in the wiki if you look it up once these are created. but the last yet not least product of the line is the protected left turn silo for timing left turn intervals. a single controller may be used to control multiple junctions without building seperate controllers. this remote transmission is very useful. it should be cautioned that servers focusing on beauty and not functionality may not like these systems as wire sorting may make a redstone jungle near the intersection. how all of these work will be explained. first up is the 26 repeater fixed timing controller. it works as expected. a torch clock delayed with repeaters. the rows must be 5 blocks long for the output to work properly or the yellow light WILL be knocked out of tune causing the light to malfunction. the yellow light timer gives an all way yellow light or yellow lights only to the desired streets. only giving the yellow lights to certain streets is most desirable when a left turn signal exists. the actuated control max out timer MUST have a repeater delay where on circuit has a single repeater and the second circuit has a high amount of repeaters. this will prevent malicious users from making the traffic light have a sezuire and malfunction. this protection is required only on actuated control since as long as you keep fixed timers protected from vandals, the fixed timer controllers will not malfunction unless you have set up the controller wrong. left turn silos are a bubble stream based system where a single item is dispensed into the bubble stream. this unlocks the left turn output and activates the arrows. the amount of time that passes before the item returns to the dispenser determines the length of the left turn phase which is fixed. just put a roof o the silo or it will not work and the left turn arrow will be green for all eternity or until you fix the issue. that wil be all for now until i make more innovations on the new 2189 model traffic light controller system:New generation of innovation. the official name of this new system you may build on your world. also, i need help. how do i set up a schematic for redstone--A2189 (talk) 22:51, 8 March 2021 (UTC)

This should go in Tutorials/Traffic light or something. Click on the redlink and add whatever info you desire. Just make sure you look at other tutorials for formatting.Humiebee^{talk contribs} 02:29, 9 March 2021 (UTC)

Template:Unreleased feature

{{Unreleased feature}} leaves a bad taste. To me, it looks like its trying to circumvent article notability. If people want to create articles for unreleased features, why not use MCW:Sandbox? I don't like the idea of articles under redirect, both because its bad for usability, and because it brings back the exact same problem the original articles had which was a lack of proper article content. Warden is an example of that template's usage.

Alternatively, if people you want to keep using {{Unreleased feature}}, let make a proposal to amend the style guide to allow those articles to exist and remove the redirect. For instance, I'd be a lot more likely to support such an article if you had a clear expiration date before an unreleased feature gets downgraded to a section on mentioned features, along with some notability for which "unreleased features" are notable enough for their own article. We can discuss that under this topic if anyone has clear ideas.

From my point of view, {{Unreleased feature}} in its current form violates the style guide, so we need to either amend the style guide to state when its allowed or remove the usages. KnightMiner ^(t/c) 06:11, 11 March 2021 (UTC)

 Support deleting the template outright. As for the proposal to amend the style guide to accept unreleased feature - there is too little information. What info is there on Warden that warrants its own page? With the exception of Warden, there are too little details on Caves & Cliffs to warrant an entire page. I would like {{unreleased feature}} to be in the {{redr}} template.Humiebee^{talk contribs} 23:28, 15 March 2021 (UTC)

 Oppose Deleting it - If we deleted this template, use of {{redr}} won't be enough, and we won't be able to create these pages, as it would be violating much more, than it does now. We would have to say to people who do so "sorry, but you are directly violating our style guide". --TreeIsLife (talk) 07:33, 16 March 2021 (UTC)

That is exactly the point. If it is violating the style guide, why does adding a template make it not in violation? If you think using that template should be allowed, the style guide should be amended to say "articles about unreleased features are fine as long as they are marked with {{Unreleased feature}} and hidden by a redirect".

As it stands, the current wording of the style guide means if someone wants to create an article for an unreleased feature, you tell them it violates the style guide. You dislike telling people that? Make a proposal or agree with one to change the style guide. We could change the style guide to describe when unreleased articles are allowed, instead of circumventing it with secret articles. KnightMiner ^(t/c) 02:29, 17 March 2021 (UTC)

I am oppose of this due it will just start a domino effect. You will change this, style guide will probably change too, and based on how those changes will be (i saw more strict idea of style guide), it may even mean page like Warden won't exist, even when announced, but unreleased. Also, even when not in style guide, it became as a "hidden point", and if this template would be deleted, it would probably mean that point won't apply any longer.--TreeIsLife (talk) 07:32, 17 March 2021 (UTC)

So let me get this straight, you think we should leave this template (which violates the style guide) alone because you think the style guide is too strict, and yet do not want to change the style guide to be less strict to make the template be allowed? KnightMiner ^(t/c) 17:08, 17 March 2021 (UTC)

Yes. But probably when I see how other people are voting, i will probably have to accept its removation, and also style guide changes--TreeIsLife (talk) 08:33, 18 March 2021 (UTC)

 Support deletion, and making the style guide more strict; these pages might just as well first be made in the userspace, rather than under the redirect. We have a bunch of stuff in the style guide that goes ignored, including the "page titles should be singular", which was brought up as adiscussion point on discord several times too. I'm getting tired of it just being me who follows the style guide more directly. Dhranios (talk) (Join the wiki videos project!) 09:02, 16 March 2021 (UTC)

 Support deletion of the template. TheGreatSpring (talk | contribs) (Tagalog translation) 11:59, 16 March 2021 (UTC)

How exactly does this template violate the style guide? Fadyblok240 (talk) 01:50, 17 March 2021 (UTC)

The template is to be added to articles that are disallowed under the style guide, using the logic that since the article has a redirect making it hard to get to its okay. Its still an article, it is still about unreleased features, its just that most people won't find it. So maybe its better to say the template itself is not a violation, but using the template for its indented use is a violation. KnightMiner ^(t/c) 02:29, 17 March 2021 (UTC)

 Support deletion: We already have various templates for marking new and changed behavior and items of upcoming versions, for example Drowned's upcoming switch from dropping gold to dropping copper. Currently the changing drops for Drowned are simply noted within their page, and the Skulk Sensor has a page, but the Warden links to a paragraph in the upcoming version page. I see no reason we shouldn't simply have properly-hatted articles (with whatever information is available) for items and/or mobs that have been confirmed as "upcoming". --MentalMouse42 (talk) 12:04, 18 March 2021 (UTC)

Navigation on FandomDesktop

As you may know, FandomDesktop will use the same navigation, as Oasis, therefore we would have to change this one. Unfortunately, this type of navigation would mean the uncollapsed "navigation" would be gone, and we would have to rework it entirely. What are your opinions on this?

Note: It is possible to add 3 layers into navigation --TreeIsLife (talk) 13:42, 16 March 2021 (UTC)

I propose an idea to do this. We can just update MediaWiki:Wiki-navigation to make 4 custom sections. Note that I don't know if the "Explore" category can have many customizations like the others, but it can be modified I think, so I propose that we should update to this only after UCX (FandomDesktop) releases:

Wiki		Minecraft		Dungeons		Help	Explore
Wiki rules		Gameplay		Gameplay		How to help	Recent changes
->	Minecraft style guide	->	Blocks	->	Locations	Help with contents	Random page
	Dungeons style guide		Items		Heads-up display	Standardized views	What links here
	Talk page guidelines		Entities		Daily Trials	Quick reference page	Special pages
	Video policy		Mobs		Ancient Hunts	Schematics	Upload a file
Community portal		Mechanics			Difficulties	Official sources	Missing pages
->	Admin noticeboard	->	Crafting		Mobs
	Projects		Smelting	Gear
	Pending tasks		Brewing		Weapons
	Patroller requests		Enchanting		Armor
Wiki Discord			Trading		Artifacts
Edit testing page		Redstone			Enchanting
		->	Components		Cosmetics
			Circuits		Drops
		Tutorials		Arcade
		Achievements		->	Cards
		Advancements

What do you think of this? Thejoaqui777 (talk) 02:05, 23 May 2021 (UTC)

Convert the Tutorials pages into their own namespaces

I'm reviving Minecraft Wiki talk:Community portal/Archive 26#Should we move all Tutorials pages to a own namespace?

That discussion actually is worth of reopening. Tutorials are an important part of any game wiki, as it is a secure way to keep documentated facts that aren't able to be into normal articles.

This was opposed before mainly because (if I read the old discussion correctly) other namespaces couldn't be accessed with the "Random page" link. However, that is no longer the case, as now Minecraft Dungeons and Minecraft Earth articles can be accessed with the link.

If we do this, then we should do this (see the table):

Original name	New name	Reason
Tutorials and Minecraft Dungeons:Tutorials	Minecraft tutorials and Minecraft Dungeons tutorials	Since both games are active, tutorials need to be split into two namespaces.
Example: Tutorials/Defeating the ender dragon	Example: Minecraft tutorials:Defeating the ender dragon	To be the same as Minecraft Dungeons and Minecraft Earth.
Example: Talk:Tutorials/Defeating the ender dragon	Example: Minecraft tutorials talk:Defeating the ender dragon	To be talk pages of their own pages and not subpages of the general Tutorials talk page.

The reason is that tutorials are an important part of the wiki. Though the Minecraft Wiki is meant to explain factual data about the game, it can't do that completely without the tutorial pages. Things such as redstone circuits, general farms, game quirks, functions, and information about the game's UIs all are stored within tutorials. This is factual evidence that can only really be given in a tutorial format, as the main articles oesn't alllow tutorial-like content.

Now I'll show another table showing the advantages, disadvantages and arguments for them:

Advantage	Disadvantage	Counterargument to disadvantages
Tutorials as their own namespace will be able to be accessed through the Random page link.	Tutorials are often badly written, and its quality is seriously questionable.	Being acessible through that link means that users will be able to see them more often. Also, tutorials themselves can be rewritten, and it's easy to mark them with the {{rewrite}} template.
Tutorials as their own namespaces can receive a standard definition of what are they exactly, which isn't totally defined. Tutorials describe guides, describe processes, can serve as suggestions or warnings for doing things in-game.	The Minecraft Wiki's scope and purpose is to document actual information from the game. Tutorials have a different tone, set of editors, audience and intentions than regular articles.	Tutorials always have been part of the wiki, or at least for so many time. The fact itself that they have a different tone, set of editors, audience and intentions also acts as an advantage, since people wants to document its creations in a secure way, making sure that they will be preserved. Many tutorials do this, containing information for both current/recent and old versions.
Tutorial talk pages will be specific for only one tutorial, and wouldn't be anymore a subpage of the general Tutorials page.	---	---
Their shortcut versions would be "MCT" (Minecraft tutorial) and "MDT" (Minecraft Dungeons tutorial).	Minecraft Dungeons tutorials would have an inconsistent shortcut.	Another proposal can be "MCDT". Though it would be longer and still inconsistent with the usual 3 letter ones, it is more consistent than "MDT".

What do you think of this proposal?, as this really needed to be discussed again. Thejoaqui777 (talk) 00:03, 19 March 2021 (UTC)

 Strong support I actually had forgotten for a while that they weren't a separate namespace. (Or did they used to be? I honestly can't remember.) In any case, Terraria Wiki uses a namespace for their equivalent Guides, so its feasibility is demonstrated by example. --MentalMouse42 (talk) 00:30, 19 March 2021 (UTC)

 Strong support per my comment on #The problem with subpages.Humiebee^{talk contribs} 00:54, 19 March 2021 (UTC)

 Strong oppose. I don't see how any of the four advantages are substantial or valid. Most visitors would get to tutorials from the search engine (not even the on-site search or the random page button), which means optimizing for the latter two ways should not be done at the expense of the first one, and page moves of any kind are harmful to search engine optimization, while the subpage structure is very well understood by search engines. So #1 is an advantage that will be targeted at the expense of the average reader. #2 is invalid, any policy can be changed to adapt to circumstances, and we shouldn't try to adapt circumstances to policy at substantial expense of user experience. The talk page issue doesn't seem problematic at all, at most weird for the more involved of readers (most of who won't even use talk pages). The namespace shortcuts are not going to be used by readers as they won't have any idea of them (and once again, they'll most likely be coming from search engines who at best won't care about shortcuts); in addition, the proposed shortcuts can conflict with potential "talk" shortcuts. --AttemptToCallNil (talk) 10:02, 19 March 2021 (UTC)

 Comment: It is true. The policy can be changed so how to write tutorials should be explained better than how it is done now. The main reason of this is the point #1, which explains that subpages can't be accessed from the Random page link. If this can break the search engine, maybe we could find a solution to this. Subpages can't be shown easily, and that's another reason of why. Thejoaqui777 (talk) 13:15, 19 March 2021 (UTC)

 Strong Oppose - Namespace? No. I feel we should not make an soup opera from Namespaces. Namespaces are here to seperate functions between pages. All namespaces have purporse. With creating new, however, we should consider why it is needed to make a new namespace. For example, with Minecraft Earth and Dungesons - "Different games". Games, which are not 100%-ly Minecraft, but are from Minecraft Universe (Minecraft Earth, Dungeons, Story Mode) and have potential to have more content, yes. This doesn't. It may have more content, but it is really needed? No. --TreeIsLife (talk) 14:09, 19 March 2021 (UTC)

 Strong support. Tutorials serve a very different purpose to definitive fact-based Minecraft Wiki articles, but are a necessary commodity for this Wiki to serve. (Is there anywhere close to as good a resource as we have here for Redstone logic gates? I don't think so.) New and old players utilize these resources, and they are key to this Wiki's helpfulness, while being very different from say, and article about a block or item. For this reason, and since most people find tutorials through the search bar anyway, and for categorization and organaiztion purposes, I dig this idea. --DigiDuncan (talk) 03:59, 21 March 2021 (UTC)

 Extremely strong support These pages have been in the mainspace for far longer than they should have been and are well overdue for being kicked out. The style guide specifically forbids tutorial info from mainspace articles, so why these insisted on remaining mainspace articles for a decade plus is beyond me. - User-12316399 (talk) 04:29, 21 March 2021 (UTC)

For the shortcuts, MCT is already used (Minecraft Wiki talk). Possibly MT and MDT/DT? (consistant) and the talk would be MTT and MDTT or DTT)Humiebee^{talk contribs} 14:05, 13 May 2021 (UTC)

 Strong oppose, for now. Not a single one of the advantages listed is compelling. Going through them one at a time: (1) We don't need badly-written tutorials to be accessible via the Random Page link, as they are not representative of article-quality pages. (2) Lacking a dedicated name space doesn't preclude creating a standard definition for a tutorial, this can be done with or without a name space. (3) Tutorial talk pages are already specific to each tutorial. Tutorials are sub-pages, each sub-page has its own dedicated talk page, and some of those talk pages have already seen heavy use (such as Talk:Tutorials/Drowned_farming, for example). If this isn't a problem for other wikis, I don't see why it's a problem here. (4) Consistent shortcuts can already exist without a name space; we just have to agree on what they are. No name space is needed to create redirect links. Before we rearrange an existing mess, we need to clean up the existing mess, and develop clear guidelines about what should be in a tutorial, how to write them, what the video policy would be (not well defined at the moment) and how to prevent tutorials from growing into indiscriminate lists of "helpful" advice. Amatulic (talk) 03:10, 1 June 2021 (UTC)

 Oppose my own discussion now for a couple of reasons:

• This discussion was opened because the tutorials aren't easily accessible for users and they are difficult to maintain. However, as mentioned, namespaces should be about a topic, and for example Minecraft tutorials being in the (main) namespace makes sense. Same with tutorials on the Minecraft Dungeons namespace.
• Our real issue is handling all those badly written tutorials, the horrible navbox that includes all of them, and their accessibility id just the least important part of their problem.
• Enabling 2 namespaces would reduce our chances to be able to receive/enable more custom namespaces on the future,and there will probably be more Minecraft games on the future.
• Oppose per AttemptToCallNil's, TreeIsLife's and Amatulic's comments.
• A solution I can give is linking them on the main page similar to what Template:DidYouKnow does.

Those are my reasons of why it wouldn't be a good idea. Thejoaqui777 (talk) 14:35, 15 June 2021 (UTC)

Flavors of "renewability"

I see a lot of infoboxes listing a resource as "renewable", and simply having a single label for everything renewable gives a false impression about practicality.

It might be useful to readers to have some distinctions between flavors of renewability. Logs are easily renewable by planting the saplings dropped from trees when harvesting them. While it's difficult to get a trident, the only way to get one is from a drowned. But is anybody really going to go through the agony of creating and defeating a wither just to get some coal? Technically coal is renewable, but practically it isn't, so it's kind of misleading to give it the same label as an oak log in terms of renewability.

Seeing "Renewable: Yes" in an infobox, therefore, is not useful information to me as a player. I'd like to see some qualifiers, like "Renewability: Easy/Moderate/Hard", indicating the effort and risk required to obtain the resource by means other than mining, in Survival mode.

Examples:

• Bee nest: Renewability is easy, requiring a small amount of low-risk effort (albeit by grinding) to plant oak or birch trees near flowers.
• Cobblestone: Renewability is easy, requiring resources to obtain a bucket for water and lava.
• Iron ingot: Renewability is moderately difficult given that one generally needs several ingots. One can build a basic iron farm in survival mode, but it's a low risk activity that takes effort and time.
• String: Renewability has variable effort and risk. Risk can be high (going to the Nether to barter, or hunting spiders) or time consuming (relying on chance from fishing, bartering, cat gifts). In my experience, string is one resource I'd like to have early in the game but in some games I have found it extremely difficult to obtain.
• Sand: I'd say moderate; it's technically renewable by trading, but considering the value of emeralds it's a poor exchange, especially if you need a lot of sand and there is no village available.
• Mob heads: Renewability is hard. This is something that is renewable more by accident than intentionally. Not practical at all.
• Clay: Hard, high risk. The only renewable way to get it is to gain Hero of the Village, and then you can get it only if the village has a mason who survived the raid.

I realize there's a lot of subjectivity here, but maybe we could come up with more objective criteria. One idea might be to plot items on a grid with axes representing effort and risk or cost. Amatulic (talk) 18:57, 25 March 2021 (UTC)

@Amatulic:, I have 1 problem, this is opinion based. Also, how do you even make a graph, a poll? At the very most, do something like {{biome}} where it shows only a few options, not something all out.Humiebee^{talk contribs} 19:08, 25 March 2021 (UTC)

 Oppose, simply too subjective to implement; it's not a game definition, so it is entirely opinion based.

People can judge for themselves by reading the obtaining sections. Dhranios (talk) (Join the wiki videos project!) 19:21, 25 March 2021 (UTC)

 Oppose making changes to the infobox field aside from possibly removing it. I agree that the current information isn't super useful (e.g. it's hardly practical to get renewable resources through the wandering trader), but classifying by cost or risk is subjective, and I can't think of many other classifications that would both be useful and clear enough to not warrant an explanation (which would be too much for an infobox field). I wouldn't be opposed to making a bigger deal on renewability in the obtaining sections, especially for items like concrete powder where it's not immediately obvious without reading the pages of its crafting ingredients. –Sonicwave ^talk 20:18, 25 March 2021 (UTC)

 Support moving the renewability out of the infobox and into obtaining. Dhranios (talk) (Join the wiki videos project!) 22:45, 25 March 2021 (UTC)

 Support moving the renewability out of the infobox and into obtaining. It does require more explanation than a simple yes/no. --MentalMouse42 (talk) 02:28, 26 March 2021 (UTC)

 Comment The general issue of difficulty in renewability is something that has come up before; the biggest factor in difficulty is actually gating. In general, an up-front investment can reduce the "cost" (time, effort) of most resources by at least one order of magnitude and sometimes more.

• E.g., String is difficult to obtain in the early game, but once the player has iron armor and weapons, spiders are little threat... and once they can find and farm a spider spawner, it's trivial.
• Likewise for iron -- early in the game it's just easier to mine for it, but once the player has enough resources to manhandle villagers and build an iron farm....
• A similar pattern applies to tradeables in general -- initially subject to random chance, but once you invest the time and resources (cash-crop farms, a trading hall, cultivated trades), that gate is basically passed -- the emerald cost of something turns into "how many do you need?".
  • The wandering trader represents a slightly special case, in that you need to wait for a desired offer, and can only get a limited supply.
• That said, there certainly are a few things where even farming leaves them pretty costly. Nether stars are the poster boy for those...
  • Even on smaller scales: E.g, I recently built a basic music disk farm, where I still need to wait for creepers to come by, lure them into the killing yard, then dodge arrows from my named skelly for a bit. Way better than fooling around in the open night, but not quite trivial.
  • Witch farms probably qualify in this category too, in that the scaling basically means that you really do need to "go big or go home".
• And when the effort for something is totally out of proportion to the value (e.g., the clay example), it might technically be renewable, but not in practical terms.

--MentalMouse42 (talk) 02:28, 26 March 2021 (UTC)

Addendum: Knowledge also matters a lot: E.g., iron golem farms require a lot of technical knowledge (or exact adherence to a plan), witch farms a little less, and (pigman-based) gold farms a fair bit. --MentalMouse42 (talk) 02:52, 26 March 2021 (UTC)

...which is odd, because I can easily create an iron farm but I have never ever gotten a witch farm to work. For gold, I get all I need from drowned farming with a zombie spawner, which is probably less complicated than doing it in the Nether. Amatulic (talk) 00:34, 31 May 2021 (UTC)

 Support removing from infobox and adding to obtaining. Also, string is definatly easier to obtain than bee nests.Humiebee^{talk contribs} 18:57, 26 March 2021 (UTC)

 Support moving from the infobox to the obtaining section. Some items definitely need a more thorough explanation rather than a simple yes/no.--Capopanzo (talk) 00:08, 2 April 2021 (UTC)

 Support (as the person who started this discussion): removing the renewability parameter from the infobox in favor of explaining the renewability in the article text. There are too many flavors of renewability for a single infobox parameter. Amatulic (talk) 00:31, 31 May 2021 (UTC)

To add to all of this, pretty much everything renewable (with the exception of wandering trader exclusives) has a farm. String - has a farm. Bee nests? - has a farm. Villager goods? - make an emerald farm. Clay? - make a raid farm. Beacons? - Obsidian farms exist, nether star farms exist (which is quite OP) and glass can be obtained via trading (emerald farm). Dirt? - make an azalea tree farm or something. Renewablility changes as you progress through the game. Humiebee^{talk contribs} 13:49, 31 May 2021 (UTC)

Adding edit requests on the wiki

Currently, it is relatively hard for editors to request edits to protected pages. I have created {{edit protected}} to facilitate such requests. There is even an edit request at MediaWiki talk:Protectedpagetext, which is essential to bring edit requests to the entire wiki. Please discuss any improvements or your opinion below. Fadyblok240 (talk) 16:13, 31 March 2021 (UTC)

So first, the type of sentence "Copy the contents of this into that" won't work, as changing MediaWiki page is not as easy, as changing module, template,...

Secondly, if correct, the page can't be even edited due Fandom's MediaWiki whitelist (aka Abuse problems), so this would need to be discussed by community, and then pass this to WR.

--TreeIsLife (talk) 17:36, 4 April 2021 (UTC)

I  Oppose. While it is true that it is somewhat difficult to request an edit to be made on a protected page, we should instead make the Admin Noticeboard or the Community Portal have a section about that instead. Thejoaqui777 (talk) 19:28, 4 April 2021 (UTC)

Or better yet, on the page's talk page... Dhranios (talk) (Join the wiki videos project!) 19:36, 4 April 2021 (UTC)

I didn't say that all edit requests were going to be made on that particular page. In fact, the proposed template is designed to be placed on the corresponding talk page of the page to be edited. If you checked the wikicode of User:Fadyblok240/MediaWiki/Protectedpagetext, you would have noticed that. Fadyblok240 (talk) 00:37, 5 April 2021 (UTC)

How about we transfer the contents of some MediaWiki pages into templates, and fully protect these templates? If there is no cascading protection, then any administrator would be able to edit these templates to indirectly edit the MediaWiki pages. Only one edit to each MediaWiki page would need to be made, to make the page transclude the associated template. Fadyblok240 (talk) 00:37, 5 April 2021 (UTC)

Then why we even make these templates, when they will be fully protected? We can actually request few pages to be whitelisted, just you need to request that and say reasons why --TreeIsLife (talk) 09:28, 5 April 2021 (UTC)

I  Support an editprotected template as long as it categorizes things correctly. That's how it works on the English Wikipedia. A user can't edit a page (typically because it's semi-protected, not because only admins can edit it), so the user makes a request on the talk page using the editprotected template. The page then appears in a category listing that anyone can view. It works, although turnaround time is typically quite slow... but then again, there are no deadlines on a wiki. Amatulic (talk) 00:45, 31 May 2021 (UTC)

Message box color criteria

Message boxes are the most used templates. And we defined recently a little criteria to see which templates should use a specific color. It was:

Criteria	Class code	Color displayed
Unclassified templates (default)
Warning for disclaimer/deletion of a page	class = msgbox-red
Suggesting a page to be moved/split/merged	class = msgbox-purple
Advice for maintenance issues	class = msgbox-yellow
Information regarding the status of a page	class = msgbox-green
Notice about a page's content	class = msgbox-orange
Details about editions and/or versions	class = msgbox-blue
Unused/custom purposes	class = msgbox-magenta

But it was changed to:

Criteria	Class code	Color displayed
Unclassified templates (default)
Warning for disclaimer/deletion of a page	class = msgbox-red
Suggesting a page to be moved/split/merged	class = msgbox-purple
Notice for content issues of a page	class = msgbox-orange
Notice for style issues of a page	class = msgbox-yellow
Information regarding the status of a page	class = msgbox-green
Details about editions and/or versions	class = msgbox-blue
Unused/custom purposes	class = msgbox-magenta

Which of the two should be the color criteria? The problem is the yellow and orange colors, so how should we use them?

 Extra comment: What is style? That's the problem with the second one. {{Rewrite}} would be style or content? What about {{update}}? Thejoaqui777 (talk) 14:16, 16 April 2021 (UTC)

 Support for the second one --TreeIsLife (talk) 13:23, 16 April 2021 (UTC)

 Support Same. – Unsigned comment added by MetalManiacMc (talk • contribs) at 13:47, April 16, 2021 (UTC). Sign comments with ~~~~

 Support the second one because of above.Humiebee^{talk contribs} 15:25, 16 April 2021 (UTC)

 Comment I think the first one is a bit more clear but I have updated {{msgbox}} to use a |type= param instead of a raw color class. So all "class=msgbox&lt:col>" should be changed to "type=<type" which makes it easier to tweak the colours later.  Nixinova   T   C   06:02, 27 May 2021 (UTC)

I also like the idea, it lets me translate the templates easily, and have more simple usages. Thejoaqui777 (talk) 13:29, 27 May 2021 (UTC)

Old Wiki theme

Is there any way to go back to the theme before the UCP? The one that actually looked like Minecraft? I think they disabled the option to switch back, but it would be nice if someone managed to replicate it with CSS.

Skywardthedragon (talk) 13:14, 30 April 2021 (UTC)

If you mean the old mobile theme, no, it's no longer available. The desktop theme should be the same for now (it's going to be changed later). --AttemptToCallNil (talk) 15:09, 30 April 2021 (UTC)

You can use user:nixinova/gpmobile.js to re-add it.  Nixinova   T   C   04:38, 21 May 2021 (UTC)

The desktop theme is still the same right now. Is there a way to keep it? Humiebee^{talk contribs} 00:49, 31 May 2021 (UTC)

Minecraft plus exists

The screensaver collection `Minecraft Plus` is not mentioned on the front page of the Minecraft wiki. Even though it's free, and not a game, it's still part of the Minecraft brand so it should really be mentioned--TJC games (talk) 09:00, 1 May 2021 (UTC)

It is a joke feature 🙃 --TreeIsLife (talk) 15:28, 5 May 2021 (UTC)

Yes and there are no updates to it. By their logic, we may as well add 3D Shareware, Mine and Craft Leisure Device and Java Edition 2.0 to the front page, since they're all related to minecraft. James Haydon (talk) 15:21, 13 May 2021 (UTC)

RfC: More admins?

Currently, there are 5 admins with only 2 truly active (AttemptToCallNil (talk • contribs • logs)) and Nixinova (talk • contribs • logs), Sonicwave mentioned in a comment that he wanted to reduce activity on the wiki, KnightMiner and Madminecrafter12 don't edit that much). I think we need more admins (For example, I noticed that Category:Pending deletion has more than 300 pages/files in it and Category:Pending speedy deletion even has more than 3 pages in it). Currently, there are 8 9 active patrollers (TheGreatFall, Magiczocker, PancakeIdentity, Amatulic, HaydenBobMutthew, NineTreyBlud, BDJP007301, and User-12316399) with 6 7 registering (shown in bold) before 2020 and one who is already a director (shown in italics). I also made this post because there has been a decrease in 2 admins within the past 7 months (Majr exactly 7 months ago and Dhranios about 2 ¹⁄₂ months ago). I am no expert in this and I just created this because the amount of clutter in the wiki (pending deletion files and other things) were increasing a lot and I was worried that too little admins would result in a decrease in moderation and an increase in vandalism (yes, there is no vandalism that remains on the wiki today but it often takes days to weeks for an admin to respond in the Block requests and Protection requests. I also recall Skylord wars in the RfC: Appoint a new bureaucrat discussion said that 9 admins was too little. If 9 admins is too little, than 5 admins (and especially 2 active admins) is far too little.

Update, Auldrick is also in the list now bringing the total from 8 to 9. Also changed 6 mo to 7 mo Humiebee^{talk contribs} 01:19, 8 June 2021 (UTC)

All in all,

1. Do we need a new admin? (I feel that we do)
2. If so, how many? (Probably 2 to replace the 2 that were demoted/self-demoted in the past 2 months)
3. And who should it be? (A patroller, probably someone in bold)

Humiebee^{talk contribs} 17:29, 15 May 2021 (UTC)

We have 6 admins from Fandom's original MCW, so there is no need to do this, until we will know their decision to become admin. --TreeIsLife (talk) 19:10, 15 May 2021 (UTC)

And don't forget that Majr has been completely inactive for over a year now, it was only 6 months ago that they finally got demoted, thanks to my AN post. James Haydon (talk) 19:57, 15 May 2021 (UTC)

I mentioned that... (the past 6 months (Majr exactly 6 months ago and Dhranios about 1 ¹⁄₂ months ago).) Humiebee^{talk contribs} 21:45, 15 May 2021 (UTC)

1. Who are they?
2. Have they even made an edit on the wiki?
3. The original fandom mc wiki was a LOT different than this wiki (it was less popular so less moderating needed, protection needed if it was low-traffic, did the MediaWiki: namespace exist?

Humiebee^{talk contribs} 21:45, 15 May 2021 (UTC)

 Comment: I would like to comment something. While it is true that some editors you mentioned have been editing for many time and they may be very trustable, I'm not sure if more admins is the solution. Of course more admins mean more maintenance, but they would have acces also to some special tools, and I don't know what can happen.
So I propose this: Giving some of them the content moderator user group. I can say that as a content moderator on the Spanish wiki I can delete and protect and unprotect pages, and do the same things that patrollers, but I can't edit some pages and I can't give user rights to other people as they are locked for me since I don't have complete admin rights.
I think that giving some people the content moderator role would make more sense since we can get more moderation on the things that need moderation, but also making sure that private admin-only pages are protected. What do you think about this? Thejoaqui777 (talk) 23:42, 20 May 2021 (UTC)

For main-space maintenance work (which is mostly what is needed), I think that's a perfect solution. Amatulic (talk) 23:49, 20 May 2021 (UTC)

 Weak support content moderator role and 1 - 2 new admins. Content moderator would take load off of admins (and solve the pending deletion and protection requests problem) and 1 - 2 new admins would replace the -2 in the past 7 mo. Humiebee^{talk contribs} 20:20, 27 May 2021 (UTC)

Update, see my comment below. Humiebee^{talk contribs} 13:31, 31 May 2021 (UTC)

I've been an admin on the English Wikipedia since 2010 (can't believe it's been over a decade). I could probably do the job here too if needed, although I suspect there are a number of features on this wiki that I have no knowledge about. But for general "janitorial" work (protection, deletion, blocking), it's no problem. On the other hand, I've been quite happy as a regular contributor here, and I enjoy not doing admin work for a change. Once you're an admin, you find there's no end of cleanup work to do (especially on en-wiki) and you hardly have time anymore to contribute content. Amatulic (talk) 23:36, 20 May 2021 (UTC)

Agree that the wiki needs more higher level users. Content moderator sounds like a good tool to hand out to a few people but we also need a new admin or too as there's not too many active.  Nixinova   T   C   04:36, 21 May 2021 (UTC)

I think all of the users Humiebee listed in boldface above, as well as Humiebee, can be trusted with the content moderator role, if any of them are willing to take it on. Speaking for myself, I'm more willing to serve as a content moderator than an admin at this time. More content moderators would take some load off admins, reducing the load to more serious duties such as blocking and page protection. What's the process here for making it happen? Amatulic (talk) 05:35, 21 May 2021 (UTC)

Agree that the wiki needs more people to handle daily requests like page deletion, block users and revert vandalism. I can also act as content moderator if needed. MysticNebula70 _T  05:40, 21 May 2021 (UTC)

As for admin roles, I don't think I have that much time to do it since I'm also admin on zh wiki (and helper on Fandom, which takes even more time). But I can give some advice though. MysticNebula70 _T  05:44, 21 May 2021 (UTC)

I would also really want to have the content moderator role for myself even though I'm a new user. It would help a lot with handling all the speculation pages that get created on the MCD side of the wiki, and the vandals here as well. James Haydon (talk) 15:35, 21 May 2021 (UTC)

I just noticed that this discussion exists and I'm listed above in bold text. The content moderator role don't add anything new to my abilities. As example, I can protect pages for vandalism as SOAP and patrol pages as patroller. - Magiczocker (talk) 15:47, 21 May 2021 (UTC)

I agree that there should be more admins and content moderators to handle vandalism and especially the deletion category, which tends to become massive often within days. I would like to note however that content moderators would be able to edit the main page, rules and other admin-protected pages/templates. This isn't necessarily a downside since they could respond to front page version syncing requests, but it's something that should be considered. –Sonicwave ^talk 19:32, 25 May 2021 (UTC)

I know that content moderators would be able to edit the main page, but that's the same situation if we promote a new admin too. The reason of why content moderators can help us is that they would be able to handle page maintenance and vandalism with more measures than patrollers, but without access to some admin stuff that probably should be handled with caution. I also agree that maybe one or two new admins would be really welcomed too. Thejoaqui777 (talk) 22:45, 25 May 2021 (UTC)

I disagree with need of another user group being used on Minecraft Wiki, I don't think it's necessary to employ a new group to do things that are being done today with other group.

I agree that Minecraft Wiki desperately needs more administrators, I think that's a fact, yet Minecraft Wiki already uses two roles that would be considered non-standard, such as Directors and Patrollers. I think adding more complexity to wiki group structure makes the wiki less clear on who is managing it, what are their roles and what groups do. "Content moderator" in the name itself is better described than Directors but it's not perfect either, what is content and what isn't? Of course, I know what it does from Special:ListGroupRights but that's because I've been on wikis for 8 years or something. What I believe the wiki needs is administration. I don't think the problem should be resolved with yet another group, I think using existing groups for this purpose such as administrators (sysops) is just fine. If you trust someone enough to delete pages, edit protected pages, or read deleted content I think there is no reason not to give such a person an administrator. People mentioned above in bold have been on the wiki for a long time and are pretty known in the community for those who interact in it.

So I guess, my question is, why exactly do we need to utilize yet another group to do the same tasks that were previously handled fine by administrators? What exactly are the things that you define as "admin stuff that probably should be handled with caution"? Wikis are built with reversibility in mind, anything that is done by the user or an admin alike should be reversible. Unless you suggest that new Content Moderator candidates would be in the future working in bad faith I don't see a reason why not just use administrator group instead. Sometimes the real solution is simpler than needlessly adding more variables to (in my opinion) already bureaucratic and complex equation. Frisk (talk) 12:22, 31 May 2021 (UTC)

@Frisk: What is the difference between content moderator and administrator? They both can edit the main page, rules, protected templates, delete and restore pages, block and unblock people, what do content moderators not have that administrators have @Thejoaqui777:? Humiebee^{talk contribs} 13:31, 31 May 2021 (UTC)

@Humiebee: Content Moderators don't have as many permissions as admins. They can't block users and they can only edit some admin-only pages. They can still delete pages, restore pages and protect pages, and edit protected pages though. James Haydon (talk) 13:36, 31 May 2021 (UTC)

Still, I feel like anyone who can be trusted with content moderator should be trusted with blocking (patrollers have experience with vandalism) and editing protected pages (like what happened with splash and human). I don't get how the current patrollers can't be trusted with 2 additional features. What I also noticed is that there are a lot of autopatrol people that can be trusted with admin/content mod such as Thejoaqui777 as well. Humiebee^{talk contribs} 13:41, 31 May 2021 (UTC)

I do strongly agree that Content Moderator should come with the block permission. Would make it useful as a vandalism fighting role. James Haydon (talk) 13:45, 31 May 2021 (UTC)

@NineTreyBlud:, then what would be the difference... Also, if content moderators can protect pages, why can't they edit those pages that were just protected??????????????????????????????????????????????? Humiebee^{talk contribs} 13:50, 31 May 2021 (UTC)

They can. Their editing permissions = admins, except they can't edit MW ns --TreeIsLife (talk) 14:46, 31 May 2021 (UTC)

Well they still can't edit all protected pages then. James Haydon (talk) 15:17, 31 May 2021 (UTC)

If they can edit the rules, the only difference between content moderator and admin is that they can't edit MCW:About, MCW:Copyrights, MCW:Directors, MCW:General Disclaimer, and MCW:Issues subpages... Either downgrade content moderator (to the same rights as what MysticNebula70 said) or don't use it (like what Frisk said). They can't be trusted with editing MCW:Protected pages???? Humiebee^{talk contribs} 21:13, 1 June 2021 (UTC)

On zh wiki we just modified the Patroller's rights, so they can block users, delete pages, however they cannot edit fully-protected pages. MysticNebula70 _T  14:42, 31 May 2021 (UTC)

I feel like there is enough support to promote at least 1 admin though content moderator still needs to be discussed. Humiebee^{talk contribs} 21:20, 3 June 2021 (UTC)

Who?

Who should be the admin? Like I said above, it should be a patroller.

• Amatulic (talk • contribs • logs) did not want to be an admin.
• Madminecrafter12 (talk • contribs • logs) in Nixinova's talk page said this

“	Being an admin doesn't require being an autopatrol or patroller, nor does it require a certain number of edits or account tenure. It requires having demonstrated through lots of experience that you have a clear use for the administrative tools and that you would manage them well. If you really want to become an admin, I'd recommend forgetting that idea for a while and just keep editing as a user. It may turn out that the type of work you prefer to do on the wiki doesn't even require being an administrator.	„
	— Madminecrafter12

In my opinion, this is the person who should become the administrator (with 1. being my top choice and 8. being my botton choice)

1. TIED
2. See below
3. The rest of the names I did not mention - Longtime contributer, active patrollers, never blocked
4. User-12316399 - Was blocked from editing File: for several months but a very helpful longtime contributer.
5. TIED - see below
6. NineTreyBlud and Magiczocker - First became active in August 2020 so still somewhat new, Giving admin to second does not change their roles much.
7. TheGreatFall - Still quite new and not as active in the past month.
8. Amatulic - does not wish to be an admin.

Humiebee^{talk contribs} 21:20, 3 June 2021 (UTC)

How does being new hinder my chances at becoming an admin? I know I haven't been here for very long, but that doesn't mean I'm not a trustworthy person. James Haydon (talk) 13:50, 4 June 2021 (UTC)

Didn't you say on User talk:Nixinova that an admin would need 2 - 4 years of editing? Humiebee^{talk contribs} 22:02, 4 June 2021 (UTC)

Well that would be highly recommended but some people can prove themselves worthy in a year or two. I have been editing since June 2020, with me starting to become majorly active in August. Long term activity is a very good thing to have for such a role, but there are newer editors that have proven themselves trustworthy enough, like you. James Haydon (talk) 22:05, 4 June 2021 (UTC)

True though all the people on the lis can be trusted, we can only select a few (which is why I made a priority list). It would be cool to be an admin but I would probably want to keep editing until July 2021 (1 year editing mark), then I would consider requesting for admin. Instead, I want to be a patroller. Humiebee^{talk contribs} 22:25, 4 June 2021 (UTC)

I do not wish to be an admin. TheGreatFall (talk) 13:58, 4 June 2021 (UTC)

Might as well drop my eight cents here. I'm pretty sure we can all agree that we need more admins here, but we need to make sure to pick the right person/people to be given these responsibilities so we don't get someone who never does anything or possibly someone who doesn't have the best interests of the wiki in mind. I guess I'll just do what you did and rank each candidate by how much I support each one being given admin rights.

1. Amatulic - I know he said he didn't want to be an admin here at all. But he didn't necessarily say he'd oppose being given the content mod role, and if that becomes a thing, I'd definitely support him being given that given their nearly 11 years of admin experience on Wikipedia
2. BDJP007301 - definitely wouldn't have supported giving them admin when I first joined the wiki, but it's been like six years and I don't really see any reason to oppose giving 'em admin rights now. I feel like that came off kinda harsh. The point I'm tryin' to make here is that they've grown ever since they joined this place
3. NineTreyBlud - being a newer user hasn't stopped people from becoming admins on this wiki in the past - Kizzycocoa became an admin just 17 days after he created his account for example. 2010 was definitely a different time here, but still. If you can get that much experience in that little time, then I don't see a problem with going ahead and making you an admin. I personally have a couple of small nitpicks with NineTreyBlud's overall behavior here, but I can definitely see him becoming an admin in the future if he's still active
4. Magiczocker - no real reason to oppose giving 'em admin rights, but as you said, giving 'em admin rights wouldn't do too much since they're already a SOAP member
5. PancakeIdentity - active on discord, but her overall activity on the wiki itself appears to have been declining over the past year or so, meaning we could potentially just get another admin that barely does anything
6. HaydenBobMutthew - not much in the way of edits in the past few months; we don't need another inactive admin here
7. User-12316399 - has been blocked multiple times since 2018 for large-scale disruptive actions in the file namespace; can't really be trusted with page deletions as a result
8. TheGreatFall - along with what you said, their understanding of English isn't the greatest and they've since stated they don't want to be an admin anyway

If eight cents wasn't enough, I'll drop additional cents if needed – JEC _talk @ 06:29, 7 June 2021 (UTC)

Pretty sure the info about HaydenBobMutthew and PancakeIdentity should change my list so i'll make a new one.

1. BDJP007301 (talk • contribs • logs • block log) - active, long time contributer, never blocked.
2. NineTreyBlud (talk • contribs • logs • block log) - active, not a long time contributer, never blocked (though moderation for MCD would be helpful).
3. Magiczocker (talk • contribs • logs • block log) - same as BDJP but admin adds barely any new roles, just editing admin-protected pages/templates (can edit all director protected pages).
4. Auldrick (talk • contribs • logs • block log) - semi-active (comparable to Sonicwave), long time contributer, never blocked.
5. HaydenBobMutthew (talk • contribs • logs • block log) - semi-active (as of VERY recently), long time contributer, never blocked.
6. User-12316399 (talk • contribs • logs • block log) - active, long time contributer, blocked before.
7. PancakeIdentity (talk • contribs • logs • block log) - not active, long time contributer, never blocked.
8. Amatulic (talk • contribs • logs • block log) - same as BDJP but does not want to be admin.
9. TheGreatFall (talk • contribs • logs • block log) - same as NineTreyBlud but does not want to be admin.

Pretty much the same except that the semi-active patrollers were moved down and NineTreyBlud was moved up because of MCD. Humiebee^{talk contribs} 18:16, 7 June 2021 (UTC)

@JEC6789:, Auldrick is now in the list of active patrollers. Humiebee^{talk contribs} 01:15, 8 June 2021 (UTC)

Not enough for an outdent Humiebee^{talk contribs}

This discussion had been completely dormant for a few days. I'm curious to know what the final plan is going to be, and who will become admin/content moderator. James Haydon (talk) 14:53, 10 June 2021 (UTC)

It generally seems that you and BDJP are the top canditates for admin followed by Magiczoker and Auldrick. I have no idea how promotion works though we need community consensus. I still don't like the idea of content mod as the only difference is not being able to block people as well as editing a few admin (not director) MCW: namespace protected pages. Humiebee^{talk contribs} 00:09, 11 June 2021 (UTC)

Generally  Support for top candidates. TheGreatFall (talk | contribs) (Tagalog translation) 05:02, 11 June 2021 (UTC)

Silesian wiki

Who is responsible for making new-language wikis and can make silesian wiki with help of another people? MegaHerc ([[1]]) 13:33, 18 May 2021 (UTC)

@MegaHerc: Hello! I'm Rail, Fandom Helper for Polish community. I'm sorry to let you know that Silesian language is not supported at Fandom and you can't create wikis in it. I would recommend contributing to the Polish wiki instead. Have a good one! — Rail (talk | contribs) 16:47, 18 May 2021 (UTC)

@Rail: there also is a project for a Catalan Minecraft Wiki, is that language officially recognized/supported by FANDOM? James Haydon (talk) 16:49, 18 May 2021 (UTC)

@NineTreyBlud: There are different levels of unsupported really. You can create wikis in Catalan, but it isn't officially supported by the IVT (at least at the moment). Languages such as Silesian are not supported at all and you can't set them as your default language in preferences or create wikis in them. I hope that works as a clarification! — Rail (talk | contribs) 16:54, 18 May 2021 (UTC)

Okay I get it now. James Haydon (talk) 16:55, 18 May 2021 (UTC)

What happened to achievement icons?

I just happened to look at my profile tab and noticed that all the achievement icons are now question marks.

I'm curious when this happened. It doesn't seem to do any harm, but it's weird. Amatulic (talk) 20:02, 22 May 2021 (UTC)

It's due to commons wiki breaking down, which serves those images. MysticNebula70 _T  03:19, 23 May 2021 (UTC)

Renaming topic titles which aren't correctly written

Recently I saw so many topics with titles that were poorly written, not only because they don't summarize adequately nor introduce their topic, but also because they may be very unrelated. So what I propose is the ability of renaming them, because the MCW:Wiki rules as far as I know forbid doing that on any talk page. So what do you think? Thejoaqui777 (talk) 14:41, 15 June 2021 (UTC)

When we should archive sections here

I want to discuss a thing of when to archive discussions on CP.

There are few possibilities

• Archiving based on when discussion ended
• Archiving based on when discussion started and "some" days/weeks passed since last comment
• Archiving, when the article has more then "number" KB of discussion
• Archiving, when there are "number" of sections
• Archiving based on 3 months cycle
• And different

Making it clear may help everybody to haave some rules about when we can close and archive the discussion --TreeIsLife (talk) 20:39, 15 June 2021 (UTC)