Minecraft Wiki

The Minecraft Wiki is no longer considered as official by Microsoft and therefore several changes are required to be made, including to the wiki's logo. Please read this announcement for more information.


Minecraft Wiki
Minecraft Wiki
This page is an archive of past discussions for the period of January to April 2021. Do not edit the contents of this page. 
If you wish to start a new discussion or revive an old one, please do so on the current talk page.


Consistency in "Pre-Release" Capitalization

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Article titles should follow the official name. Pre-release and Pre-Release spelling appear in different dates. However, feel free to create redirects from r -> R and vise versa.Humiebeetalk contribs 21:25, 10 January 2021 (UTC)

While editing the server.properties page, I noticed that there is considerable inconsistency in how "Pre-Release" is capitalized across the wiki. Some pages choose to uppercase the "R" in "Release", some do not. Some choose to redirect the opposite case, some do not.

For example, 1.14.4 Pre-Release 1 is an uppercase "R" and trying to navigate to "1.14.4 Pre-release 1" fails. On the other hand, 1.16.4 Pre-release 1 is a lowercase "r", and trying to navigate to "1.16.4 Pre-Release 1" similarly fails. Some pages (e.g. 1.15 Pre-release 5) have a redirect but many do not. The net effect of this is that editors have no idea which capitalization is "correct", or even which one will work correctly. It leads to overall inconsistency and unnecessary redirects across the Wiki.

My suggestion is for the Wiki to come to a consensus on which capitalization should be used. Personally, I feel that "Pre-Release" with an uppercase "R" should be preferred, as that is what Mojang uses in its official communications. Once consensus is reached, incorrect pages should be moved to the correct title, and any errant capitalization in article bodies fixed.

AMNOTBANANAAMA (talk) 23:48, 5 January 2021 (UTC)

The name of pre-releases follow the name in-game, so  Weak oppose The Great Spring (talk | contribs) (Tagalog translation) 23:50, 5 January 2021 (UTC)
If the decision is to prefer "pre-release" as the page names I am fine with that, as long as it is consistent. The current inconsistency is my primary concern, ultimately which one is chosen is less important to me. AMNOTBANANAAMA (talk) 00:01, 6 January 2021 (UTC)
For example, if you want to put this at the start it would be

1.16.4 Pre-release 1 (known as 1.16.4-pre1 in the launcher) is the first pre-release for Java Edition 1.16.4, released on October 15, 2020, which adds the social interactions screen and fixes two bugs.

instead of

1.16.4 Pre-Release 1 (known as 1.16.4-pre1 in the launcher) is the first pre-release for Java Edition 1.16.4, released on October 15, 2020, which adds the social interactions screen and fixes two bugs.

The Great Spring (talk | contribs) (Tagalog translation) 00:10, 6 January 2021 (UTC)
We follow the in-game names, so they are not to be moved. However, feel free to make redirects for the opposite capitalization. Dhranios (talk) (Join the wiki videos project!) 09:32, 6 January 2021 (UTC)

More Facts In Did You Know...

On the main page, the Did You Know... section always has the same 5 facts. I think it would be neat if there was a large pool of random facts and every time the page loads, it picks a random 5 from that list. Any thoughts would be appreciated! || Remember this thing? Nether Reactor Core BE1.png Because I do. --Ninji2701 03:17, 27 December 2020 (UTC)

The did you know relies on a certain template, Template:DidYouKnow. It does not always have the same facts, it refreshes every day. There are not 5 facts, here are all the facts. If you want to add more facts, you can add them in the editcopy. Keep in mind you can edit the editcopy and add what you think is good, but it will not show up on the front page until an admin decides they belong there. Blockofnetherite Talk Contributions 04:45, 27 December 2020 (UTC)
Oh, cool! I guess this topic is totally irrelevant then. || Remember this thing? Nether Reactor Core BE1.png Because I do. --Ninji2701 13:50, 27 December 2020 (UTC)


I personally think that the template should show more than 5 facts. It could show 7 facts instead of 5. The reason is that the Minecraft Wiki/editcopy page shows too few facts on the template, so if we increase a little bit the amount of facts this can be solved. Thejoaqui777 (talk) 23:12, 18 March 2021 (UTC)

5000 content pages milestone

I just wanted to say that I noticed, as of now, Special:Statistics lists exactly 5,000 content pages on this wiki. Amatulic (talk) 03:00, 16 January 2021 (UTC)

I noticed that a few days back, so you aren't the first to see this. James Haydon (talk) 04:02, 16 January 2021 (UTC)
BDJP007301 created the 5000th article yesterday. Also, does this also includes deleted pages? TheGreatSpring (talk) 04:22, 16 January 2021 (UTC)
It does not, hence why it has become this milestone several times already. Dhranios (talk) (Join the wiki videos project!) 05:53, 16 January 2021 (UTC)
Well there are subpages of articles which are not articles (many of them are templates only meant to be transcluded on one page) which are counted as articles, which means there are probably less than 5,000 "proper" articles. (Note that redirects, project pages, template pages, category pages, file pages, user pages, etc. are not counted as articles. )Fadyblok240 (talk) 17:36, 21 January 2021 (UTC)

Articles about Mojang employees: A proposal

Reviving both this discussion from 2015 and this discussion from 2019-2020, I feel like it should finally be time to take action regarding articles about Mojang employees, whether they are notable or not. I'm using the Wikipedia policy on biographies of living persons as a blueprint for this, so bear with me here.

  • We should try to include as much information on employees that is publicly available through reliable sources, whether it be through LinkedIn profiles, interviews with publications such as news sites, or simply through the Twitter accounts of the employees themselves. As long as the information is available publicly, it should be documented on the wiki, sourced back to the article or tweet in question.
  • However, there has to be a limit as to what information should indeed be allowed on here. Of course, its general understanding that emails, addresses, and phone numbers are never to be added to articles out of respect for privacy. In regards to concessions that have been made in the past, such as the situation with Ez, or retracting information that had been OK up until recently, such concessions should be reviewed as to whether they should remain as is, or be considered null and void pending as to when this policy does become active.

Understanding that this is a style guide policy, I figured it would be best to instead post it here, considering that this policy would cover several hundreds of employees of one company.

The proposed change to the policy is as follows, which would be separated from the "Notability" section and split into its own section (new additions in bold):

Articles about people are only allowed if the person in question is a developer of Minecraft and/or either a part of or closely related to Mojang Studios. The article should cover information about the person that is publicly available through reliable sources, and should remain neutral and fair to the person. Self-published sources, such as tweets or books, are not allowed unless the person is the one who authored or published it. Edits to the article about the person may be reverted / deleted if they contain phone numbers, email, or postal addresses.

This is just a stepping stone. I am open to any additional input regarding any further changes to this. BDJP (t|c) 19:19, 2 February 2021 (UTC)

I still think this should be taken further, and say that articles should only exist for notable employees where the majority of the content is about their work. We shouldn't encourage going into details about personal lives and such, which having all these stub articles does.  Nixinova T  C   19:29, 2 February 2021 (UTC)
Definitely keep the personal life stuff to a minimum at best. BDJP (t|c) 20:42, 2 February 2021 (UTC)
In my opinion, we should keep any pages that have a lot of content (pages without stubs) but pages with stubs should be put into like a draft. Anyone is free to make a page but it needs more content. As for not having like personal details, I also support that but a notable exception would be Helen Zbihlyj as she directly put a little bit of her personal life on her user page as it is a primary and the most reliable source possible. I would like the employee pages to also have more about their work as well and all those stub articles can be clumped into an Employees article.
All in all, I  Support keeping all pages which have enough content and  Removing or converting any pages with a stub and have no content (for instance, Peter Hont which is just one of the many pages that has no info, only saying that they work in Minecraft Dungeons.) For birth dates, I really don't see any harm if they posted it on twitter or some other social media thing. Also I wish to  Remove all pages with no sources as well.Humiebee (talk) 21:35, 2 February 2021 (UTC)
I’ve created an example of how an expanded article would look here. BDJP (t|c) 01:02, 9 February 2021 (UTC)
I  Support the revised article.Humiebee (talk) 03:05, 15 February 2021 (UTC)
I'm going to wait on any further comments for a week, but if there are no further objections then I will implement this on the bio page. BDJP (t|c) 14:36, 19 February 2021 (UTC)
Support the new proposal, but it would make absolutely no sense for the new guideline to be part of the style guide but not part of the notability guideline. What about splitting the notability guidelines from the style guide? Fadyblok240 (talk) 23:12, 19 February 2021 (UTC)

Are pufferfish passive, neutral or hostile

Personally, I think that pufferfish are passive because they can't chase you but some users change "Passive" to "Neutral" or "Hostile". Are pufferfish passive, neutral or hostile? TheGreatSpring (talk) 08:08, 7 February 2021 (UTC)

Per Talk:Pufferfish#Pufferfish behavior, we stated that they are passive, so I think that they should stay as Passive. Thejoaqui777 (talk) 22:55, 7 February 2021 (UTC)

Splitting PS4 history

Recenty, RondiMarco splits the PS4 part from the LCE section without discussion. Can we split the PS4 part or not? Any thoughts? The Great Spring (talk | contribs) (Tagalog translation) 12:11, 6 January 2021 (UTC)

 Neutral, while it is done the same with PE and bedrock, PS4 is a legacy console edition, as it was also replaced by bedrock. I don't see harm in doing it this way, nor harm in reverting it. Dhranios (talk) (Join the wiki videos project!) 12:13, 6 January 2021 (UTC)
 Oppose PS4 is part of LCE, no reason to split its history.  Nixinova T  C   19:29, 7 January 2021 (UTC)
 Comment I get your point, but the PS4 edition outlasted all the other Legacy Console editions, and was the only legacy console version to have the Texture Update. James Haydon (talk) 19:32, 7 January 2021 (UTC)
Barely, only for like 10 updates.  Nixinova T  C   21:27, 10 January 2021 (UTC)
True, they only spanned 1.14, or Bedrock Edition 1.8.0 - 1.13.0.Humiebeetalk contribs 21:30, 10 January 2021 (UTC)
 Weak support becuase of consistancy with pe and be but it is part of lce and is diffferent than pe and be as they are separated until the Better Together Update but ps4 IS part of lce. Idk, I would keep it though.Humiebeetalk contribs 21:45, 30 December 2020 (UTC) 22:21, 7 January 2021 (UTC)

Something discussing renewability of the Lava Bucket and other items that are not renewable in snapshots but are going to be in the full release

Yes, I know that the ip constantly got reverted for changing it, they did have a good point but the wiki uses current status, not upcoming status. The ip got reverted with understandable edit summaries and I personally would revert the ip. They were doing it in good-faith though. Something odd about that is that the template is the {{upcoming}} template, implying that the thing that is upcoming IS upcoming in <version>. In the case of 1.17, the full release. Now the wiki trys to be as informative as possible and trys to give the reader a clear understanding. In my opinion, I am  Semi-weak support. It would be confusing for the reader if they watched like say for example, xisumavoid and went to the minecraft wiki. They would notice that the renewability of lava buckets would be incorrect, misleading the reader. Note that I mean No‌[until JE 1.17]/Yes‌[upcoming: JE 1.17] Any thoughts?Humiebeetalk contribs 22:35, 7 January 2021 (UTC)

The same can be said the other way around. If we end up saying yes in 1.17, while it's not in the snapshots yet, people who open the snapshots will be presented with misinformation.
It's better to stick with the current latest release and snapshot info, not the whole planned update. (Plans can change, after all...) Dhranios (talk) (Join the wiki videos project!) 23:33, 7 January 2021 (UTC)
True... but it would be more helpful in general becuase more Java Edition players use Java Edition 1.16.4 than 21w42a.Humiebeetalk contribs 23:37, 7 January 2021 (UTC)
For those people, those templates don't really concern them. When the update releases, they'll check the update page instead and go from there. Dhranios (talk) (Join the wiki videos project!) 23:40, 7 January 2021 (UTC)

Wanted Page: Moving minecart

The minecarts that move are supposed to be mobs / entities, right? -THENOMNOM (talk) 00:26, 11 January 2021 (UTC)

Yes. They are entities. TheGreatSpring (talk | contribs) (Tagalog translation) 00:28, 11 January 2021 (UTC)
Minecarts themselves are already entities. Moving minecrafts are no different, just that they are moving, similar to a player walking. So no need for a new pageHumiebee (talk) 00:39, 11 January 2021 (UTC)
Exactly, in the same way as evoker fangs. They only damage they player and have no real behavior nor do they interact with them. James Haydon (talk) 00:51, 11 January 2021 (UTC)

Should Caves & Cliffs features in Bedrock Edition be considered from 1.17.0 or from 1.16.210 in history sections

There's a bit of a inconsistency with Caves & Cliffs features in added in the betas of 1.16.X in the form of Experimental Gameplay, for example, this is the history section for pointed dripstone:

Upcoming Bedrock Edition
1.17.0beta Dripstone Base (D) JE1 BE1.png Pointed Dripstone Middle (D) JE1 BE1.png Pointed Dripstone Frustum (D) JE1 BE1.png Pointed Dripstone Tip (D) JE1 BE1.png Pointed Dripstone Tip Merge (D) JE1 BE1.png
Pointed Dripstone Base (U) JE1 BE1.png Pointed Dripstone Middle (U) JE1 BE1.png Pointed Dripstone Frustum (U) JE1 BE1.png Pointed Dripstone Tip (U) JE1 BE1.png Pointed Dripstone Tip Merge (U) JE1 BE1.png Pointed Dripstone Frustum (up texture) JE1.png Added pointed dripstone.

However, this is the history section for goats:

Bedrock Edition
1.16.200beta JE1 BE1.png Goat JE1 BE1.png Added goats and kids, which are available only via Experimental Gameplay.
Goats make the sound of a player being hit.
Goats currently uses the vex's charging sound as a placeholder when preparing to ram charge.[1]
releaseGoats have been made inaccessible in the full release.
Upcoming Bedrock Edition
1.16.210beta now only drop 2 goat horns each.
Goats now drop 1-2 mutton.
Goat (one horn) BE1.png Goat (no horn) BE1.png Goats now show missing goat horns in the model.
Baby goats now have half knockback when using a ram attack.
Goats no longer attack armor stands.[2]
Goats now attack shulkers.
Goats now only produce one baby goat at a time when breeding.
beta now avoid walking onto powder snow while path-finding.
  1. MCPE-104156
  2. MCPE-104159 – "Goat attacks armor stands" – resolved as "Fixed"

Notice how the former shows the features as a part of 1.17.0, while the latter shows it as part of 1.16.200 and 1.16.210. I prefer the former option as the Caves & Cliffs features added in the betas of 1.16.X don't end up in the full release, but instead will be a part of 1.17.0.

Unavailablehoax (talk) 23:36, 26 January 2021 (UTC)

I  Support to use the first, because the features won't be part of 1.16.x releases, and it's more specific. Thejoaqui777 (talk) 23:54, 26 January 2021 (UTC)
They are part of the 1.16.210 betas, and it should be declared that way. Saying the beta is for 1.17 is false information. Dhranios (talk) (Join the wiki videos project!) 00:16, 27 January 2021 (UTC)
Should say 1.16.210, with "added under experimental gameplay", then 1.17 with "fully implemented".  Nixinova T  C   00:26, 1 February 2021 (UTC)

Proposal for a Crossovers page, replacing the current Smash page

I talk about this more on Talk:Super Smash Bros. Ultimate, but since that page doesn't get much traffic for obvious reasons, I thought I'd bring it up here.

My argument boils down to it making more sense than adding a new page for every game that references Minecraft, and being more consistent to what Wiki readers might expect and enjoy. Thoughts? -- DigiDuncan (talk) 00:14, 1 February 2021 (UTC)

Request for a new page - but I need your help

I want to create a new page that lists from the longest name for an item to the shortest name, but I don't know how should I create it. I hope you can help me. - Melvintnh327 (talk) 05:04, 7 February 2021 (UTC)

It is unnotable to be given an article. TheGreatSpring (talk) 05:28, 7 February 2021 (UTC)
It is completely trivial information, so it doesn't belong anywhere on this wiki, except perhaps a subpage of your userpage. Fadyblok240 (talk) 05:40, 7 February 2021 (UTC); updated 06:12, 7 February 2021 (UTC)
Okay then...I guess I would not create it - Melvintnh327 (talk) 02:23, 11 February 2021 (UTC)

What happened?

The wiki stopped working for some time. Why? Gameking1happy (talk) 16:40, 11 February 2021 (UTC)

Another glitch with UCP, this is the worst one so far. James Haydon (talk) 16:41, 11 February 2021 (UTC)
Fandom rolled out an update that broke the platform. They quickly rolled it back though.
While they were rolling it back though, Minecraft Wiki played the roles of: 1) London Bird Club Wiki; 2) Wookieepedia; 3) the Pixel Gun Wiki and the Game of Thrones Wiki simultaneously. Oh, and half the platform was the Raft Wiki for a few moments. --AttemptToCallNil (talk) 16:58, 11 February 2021 (UTC)
I don't think there even is a Game of Thrones wiki on Gamepedia because its not a game. So it also is affecting FANDOM wikis as well. James Haydon (talk) 17:01, 11 February 2021 (UTC)
Yes, it affected the entire platform, including all Fandom wikis. --AttemptToCallNil (talk) 17:04, 11 February 2021 (UTC)

Minecraft Story Mode NS


We already discussed about Minecraft Earth and Minecraft Dungeons namespaces, but i think we still miss "Minecraft: Story Mode" namespace. This namespace was already discussed in "Moving Minecraft Story Mode Wiki to this wiki", but as Minecraft Story Mode Wiki discussion was really not great, and it failed, we were exploring possibility of exporting articles from "Fandom's Minecraft Wiki". But unfortunately, these will also need rewrite. So, articles are created manually, as stubs, which will need to expand.

So, we have to create these articles by ourselves. Unfortunately, we won't be able to beat Minecraft Story Mode Wiki, until we will have own namespace, and own production of articles.

On Google, we ended really far from top, on 5th place. On Bing, we were more successful, reaching 3rd, but on both searches, MC Story Mode Wiki was on top.

So, should we create Minecraft Story Mode NS?--TreeIsLife (talk) 19:05, 13 February 2021 (UTC)

 Support We have pretty bad situation, on Google, even Fandom's MCW has higher ranking, so we are in bad situation --TreeIsLife (talk) 19:05, 13 February 2021 (UTC)
 Temporal oppose, let me explain. It has been some months since the discussion, but I think that we should contact first their admins. I don't want them to think that we try to compete with them, instead to colaborate. Your words look very competitive, which isn't how this wiki wants to get information. We talk with people, and try to get a deal with them to make both parts happy. So, I think that we should wait 2 months more at least to begin talking with them again, because they refused to merge due to bad communication. Thejoaqui777 (talk) 19:21, 13 February 2021 (UTC)
 Comment TreeIsLife, I agree with Thejoaqui777, why are you making this a competition? MC wiki isnt a promotion wiki. Minecraft Story Mode is a WIP and the Minecraft Story Mode in FANDOM is fine, what makes you think that MC wiki is a promotional wiki? I also  Oppose per my comment on the previous discussion. I'm fine with the namespace but not trying to outmanuver fandom, gamepedia is owned by fandom anywaysHumiebee (talk) 19:25, 13 February 2021 (UTC)
This, this, this, this, this, this and this. It's not a competition. This exact behavior is what made the initial merge proposal fail badly. Dhranios (talk) (Join the wiki videos project!) 19:33, 13 February 2021 (UTC)
 Comment to all. This is not about competition. We tried... but... it did not go well. Hummie may not know about that, but there is great server, called Minecraft Wiki Crossover, where we discussed future of MC Wikis (all of them). We had a big dream. 3 big wikis for everything Minecraft - Minecraft Wiki, Minecraft Community Wiki and Minecraft Mods Wiki. And, we wanted to start with merging of all wikis from "Minecraft Wiki Network" into this wiki. Anddddd... I created discussion post, and we had protest on that wiki. I was critized about how i wrote it, and that i wrote it into discussions. Then, i decided i will left server, and do discussion by myself. So great, i had another conflict on another wiki (double problem). Unfortunately, discussion just failed and that's it. And now everybody hates me 😔. That was joke, obviously, I said it was my fault, and we discussed we won't say nothing to community, until we will lock the wiki (meaning only discussing with admins). And now, let's say why i want to do this. Well, they are inactive and only 1 person said something, but his timestamp between answers were 1 week.--TreeIsLife (talk) 19:41, 13 February 2021 (UTC)


There are 5 Minecraft games: Minecraft, Minecraft Story Mode, Minecraft Earth and Minecraft Dungeons and, Minicraft. They all have page(s) other than Minicraft witch only has 1 reference on the whole wiki. I think Minicraft should have a page, if not may pages for the things in the game (mobs, items, etc). --Gtbot2007 (talk) 22:22, 13 February 2021 (UTC)

 Weak oppose this wiki is about Minecraft. TheGreatSpring (talk) 23:04, 13 February 2021 (UTC)
 Comment Well, 0x10c has its own wiki page, and yet it isn't a minecraft related game, it was developed by mojang, but wasn't really minecraft-like. James Haydon (talk) 23:23, 13 February 2021 (UTC)
 Comment But it was made by Notch, and has a lot of things from Minecraft (such as creepers), even the name is based on Minecraft --Gtbot2007 (talk) 23:53, 13 February 2021 (UTC)
Minicraft already has a page, but it is a redirect. Fadyblok240 (talk) 01:26, 14 February 2021 (UTC)
I guess because it wasn't developed by mojang unlike 0x10c and it wasn't nearly publicized as much. Makes sense why it doesn't have its own page. James Haydon (talk) 01:30, 14 February 2021 (UTC)
Redirects are pages too. Fadyblok240 (talk) 02:58, 14 February 2021 (UTC)
@Fadyblok240: By page I meant articles, no need to correct me about that. James Haydon (talk) 18:41, 14 February 2021 (UTC)
But its a minecraft game unlike 0x10c
 Comment The reason I felt the need to create the 0x10c page is because, unlike other games made by Notch or Mojang, you can't actually play it because it never came out, and so it doesn't have a wiki of its own (not anymore anyway). Now, on the other hand, Minicraft is a game you can play and it does have its own wiki, but, keep in mind, it is technically an official Minecraft spinoff game, and all the other official Minecraft spinoffs get to be on this wiki, so why not that one too? Plus the Minicraft wiki is really messy and incomplete, so I definitely wouldn't be opposed to something better being added to this wiki. AlienAgent124 (talk) 03:08, 14 February 2021 (UTC)
This is what I mean -- 09:27, 14 February 2021 (UTC)

Pocket/Bedrock Edition version pages

As the title, the Chinese Wiki is also disussing the same problem. See here.

Here, the problem is slightly different. It's mainly about {{version nav}}.

The documentation doesn't mention the usage of parameter {{{internal}}}. The number filled in this parameter shouldn't called "Internal version no.", and it should be "Full version no.". The correct "Internal version no." is a long string of numbers in file AndroidManifest.xml or in something else. "Full version no." is also in the file. For example, the Internal version no. of Pocket Edition 1.1.3 is 871010352 and the Full version no. is Some of the pages on the Wiki need to split according to this, because we found that some apk files of very old version that shows the same Full version no. but they have different Internal version numbers.

About the articles, Style guide says that "naming specification is currently under discussion", but it was shelved obviously. Some version pages is different from the naming specification it stated. Also, MCW:SG/V needs to update.

In addition, The Chinese wiki is discussing renaming Bedrock/Pocket Edition version articles, and we are having an argument about if development versions should have "beta" or "alpha" on their names. Some people think that "the version number is for distinction", and they suggest to delete all the parts in the title that are not useful for distinction, include "alpha/beta" and "v" (the abbreviation of word "version"). Articles like "Bedrock Edition" or "Pocket Edition 0.10.0.b9" is enough to explain it's a development version, does not need to be like "Bedrock Edition beta" or "Pocket Edition v0.10.0 alpha build 9". The articles don't need to be exactly the same as shown in game, just like we don't name the page Java Edition 21w06a "Java Edition Minecraft 21w06a/snapshot".

If we changed the articles, the parameter {{{title}}} and {{{protocol_manual}}} of {{version nav}} also need to be changed. Do you think it's necessary?--SkyE | Talk · Contributions · Logs 08:00, 14 February 2021 (UTC)

Necessary, no, but it is a change I'd support. The only thing is that bedrock's beta builds aren't as distinguishable from the full build, compared to java's snapshots; betas only have 1 additional ".X", unlike snapshots which use a vastly different naming altogether. Dhranios (talk) (Join the wiki videos project!) 08:36, 14 February 2021 (UTC)
Oppose new naming scheme (the example given isn't actually relevant, the "/snapshot" isn't part of the version), and "beta" is useful for disambiguating. "The articles don't need to be exactly the same as shown in game"; they are though. Support parameter rename.  Nixinova T  C   18:55, 14 February 2021 (UTC)
Although the existence of "alpha/beta" , "v" , parentheses and spaces have certain significance, it's not so significant as to benefit from changing the title. Now the whole title is long and scattered. According to what you said, "it is useful for disambiguating". But most of the time, the correct page cannot be found. In daily communication, few people would say "beta", most people would say "" directly. Personally, I’m used to find pages directly with URLs instead of search functions. If the users who don’t know much about Wiki type an extra space or a wrong letter, and then find that the page does not exist, they won't know what to do (for example, I want to find "Bedrock Edition beta" but input "Bedrock Edition v1.16.210.59" or "Bedrock Edition"). If you ask "Why not use the search function?", if the title is changed to "Bedrock Edition", wouldn't the search function still be useful? Without various prefixes and suffixes, wouldn't the search efficiency be higher?--SkyE |  Talk · Contributions · Logs 13:24, 16 February 2021 (UTC)
 One more problem. Word "alpha" was not shown since 0.14, can we recognize that versions from 0.14 to 0.16 belong the Alpha development stage? --Lxazl5770zh.admin) 14:47, 17 February 2021 (UTC)

Some current issues

Even if there is no need to change the naming specification, some Pocket Edition/Bedrock Edition pages still have problems.

  • Bedrock Edition and Bedrock Edition 1.2.16 are two different versions. They just updated the same things and are in the same changelog on the Minecraft feedback website. The correct process is: First, Mojang changed the version number in the source code to and released a version. This version didn't compile for iOS. Then Mojang changed the version number to, and bumped another version. They just used the same protocol version so they were still multiplayer compatible with each other. In order to prove that they are two versions, let me give an example: if I made an add-on, max_engine_version and min_engine_version in the manifest.json are both, then the version on iOS (1.2.16) cannot load this add-on.
  • The arcticles of Pocket Edition Alpha Realms build 1, build 2 and build 4 are different from other Pocket Edition Alpha versions. What's the naming specification exactly?
  • Mojang's naming specifications are very messy. Sometimes the version numbers show in different places are different.
    • For example, Bedrock Edition should be "Bedrock Edition". In Google Play changelog and Mojira's this page], Mojang said it's, but in game it displays 1.2.6. In source code and MCPE-17100 on Mojira it's The full version no. of Bedrock Edition 1.2.6 is We know that if you want to update an app, the version number must be higher than the original installed version. Otherwise, the update will fail. So the correct article is "Bedrock Edition". There was an argument about this on the talk page.
    • @Nixinova: Your statement is incorrect. This also shows that the version number displayed in the game is unreliable, and the articles must be named according to the source code.
  • We found some versions that you thought did not exist (e.g. If you want, we can provide the original apk files. We made a table to show this:
Wiki page Version no. displayed in game Internal version no. Recommended version no. (ver1) Recommended version no. (ver2)
0.1.0 0.1 1 0.1 0.1
0.1.0 0.1 2 0.1_Rev2 0.1_Rev2
0.1.0 0.1 4 0.1_Demo 0.1_Demo
0.1.1 0.1.1 1013 0.1.1_j 0.1.1_j
0.1.1 0.1.1 1015 0.1.1 0.1.1
0.1.2 0.1.2 1023 0.1.2_j 0.1.2_j
0.1.2 0.1.2 1025 0.1.2 0.1.2
0.1.3 0.1.3 1033 0.1.3_j 0.1.3_j
0.1.3 0.1.3 1035 0.1.3 0.1.3
None 0.1.3 1036 0.1.3_Rev2 0.1.3_Rev2
0.2.0 0.2.0 2003 0.2.0_j 0.2.0_j
0.2.0 0.2.0 2005 0.2.0 0.2.0
0.2.0 0.2.0 2006 0.2.0_Rev2 0.2.0_Rev2
None 0.2.1 2013 0.2.1_j 0.2.1_j
0.2.1 0.2.1 2015 0.2.1 0.2.1
0.2.1 (2) 0.2.1 2016 0.2.1_Rev2 0.2.1_Rev2
None 0.2.1 2017 0.2.1_Rev3 0.2.1_Rev3
None 0.2.2 2023 0.2.2_j 0.2.2_j
0.2.2 0.2.2 2025 0.2.2 0.2.2
None 0.3.0 3003 0.3.0_j 0.3.0_j
0.3.0 0.3.0 3005 0.3.0 0.3.0
None 0.3.0 3006 0.3.0_Rev2 0.3.0_Rev2
None 0.3.0 3007 0.3.0_Rev3 0.3.0_Rev3
None 0.3.2 3023 0.3.2_j 0.3.2_j
0.3.2 0.3.2 3025 0.3.2 0.3.2
None 0.3.3 3030 0.3.3_j 0.3.3_j
0.3.3 0.3.3 3035 0.3.3 0.3.3
0.4.0 0.4.0 4000 0.4.0_j 0.4.0_j
0.4.0 0.4.0 4005 0.4.0 0.4.0
0.4.0 rev 2 0.4.0_Rev2 0.4.0_Rev2
0.4.0 rev 3 0.4.0_Rev3 0.4.0_Rev3
0.5.0 0.5.0 5000 0.5.0 0.5.0
0.5.0 0.5.0 5005 0.5.0 0.5.0
0.6.0 0.6.0 6006 0.6.0 0.6.0
0.6.1 0.6.1 30006010 0.6.1 0.6.1
0.7.0 0.7.0 30007000 0.7.0 0.7.0
0.7.1 0.7.1 30007010 0.7.1 0.7.1
0.7.2 0.7.2 30007020 0.7.2 0.7.2
0.7.3 0.7.3 40007040 0.7.3 0.7.3
0.7.4 0.7.4 50007040 0.7.4 0.7.4
0.7.5 0.7.5 50007050 0.7.5 0.7.5
0.7.6 0.7.6 50007060 0.7.6 0.7.6
None 0.8.0_test1 300800001 0.8.0.b1 0.8.0.b1
0.8.0 build 2 0.8.0 build 2 300800002 0.8.0.b2 0.8.0.b2
0.8.0 build 3 0.8.0 build 3 300800003 0.8.0.b3 0.8.0.b3
0.8.0 build 4 0.8.0 build 4 300800004 0.8.0.b4 0.8.0.b4
0.8.0 build 5 0.8.0 build 5 300800005 0.8.0.b5 0.8.0.b5
0.8.0 build 6 0.8.0 build 6 300800006 0.8.0.b6 0.8.0.b6
0.8.0 build 7 0.8.0 build 7 300800007 0.8.0.b7 0.8.0.b7
0.8.0 build 8 0.8.0 build 8 300800008 0.8.0.b8 0.8.0.b8
0.8.0 0.8.0 500800010 0.8.0 0.8.0
0.8.1 0.8.1 500801011 0.8.1 0.8.1
0.9.0 build 1 0.9.0 500900000 0.9.0.b1 0.9.0.b1
0.9.0 build 2 0.9.0 500900001 0.9.0.b2 0.9.0.b2
0.9.0 build 3 0.9.0 500900002 0.9.0.b3 0.9.0.b3
0.9.0 build 4 0.9.0 500900003 0.9.0.b4 0.9.0.b4
0.9.0 build 5 0.9.0 500900004 0.9.0.b5 0.9.0.b5
0.9.0 build 6 0.9.0 500900005 0.9.0.b6 0.9.0.b6
0.9.0 build 7 0.9.0 500900006 0.9.0.b7 0.9.0.b7
0.9.0 build 8 0.9.0 500900007 0.9.0.b8 0.9.0.b8
0.9.0 build 9 0.9.0 500900008 0.9.0.b9 0.9.0.b9
0.9.0 build 10 0.9.0 500900009 0.9.0.b10 0.9.0.b10
0.9.0 build 11 0.9.0 500900010 0.9.0.b11 0.9.0.b11
0.9.0 build 12 0.9.0 500900011 0.9.0.b12 0.9.0.b12
0.9.0 0.9.0 500900012 0.9.0 0.9.0
0.9.1 0.9.1 500901000 0.9.1 0.9.1
0.9.2 0.9.2 500902000 0.9.2 0.9.2
0.9.3 0.9.3 500903000 0.9.3 0.9.3
0.9.4 0.9.4 500904000 0.9.4 0.9.4
0.9.5 0.9.5 500905000 0.9.5 0.9.5
None 0.9.5 500905001 0.9.5_Rev2 0.9.5_Rev2
0.10.0 build 1 0.10.0 740100000 0.10.0.b1 0.10.0.b1
0.10.0 build 2 0.10.0 740100001 0.10.0.b2 0.10.0.b2
0.10.0 build 3 0.10.0 740100002 0.10.0.b3 0.10.0.b3
0.10.0 build 4 0.10.0 740100003 0.10.0.b4 0.10.0.b4
0.10.0 build 5 0.10.0 740100004 0.10.0.b5 0.10.0.b5
0.10.0 build 6 0.10.0 740100005 0.10.0.b6 0.10.0.b6
0.10.0 build 7 0.10.0 740100006 0.10.0.b7 0.10.0.b7
0.10.0 build 8 0.10.0 740100007 0.10.0.b8 0.10.0.b8
0.10.0 build 9 0.10.0 740100008 0.10.0.b9 0.10.0.b9
0.10.0 0.10.0 740100009 0.10.0 0.10.0
0.10.1 0.10.1 740100100 0.10.1 0.10.1
0.10.2 0.10.2 740100200 0.10.2 0.10.2
0.10.3 0.10.3 740100300 0.10.3 0.10.3
0.10.4 0.10.4 740100400 0.10.4 0.10.4
0.10.5 0.10.5 740100501 0.10.5 0.10.5
0.11.0 build 1 0.11.0 740110001 0.11.0.b1 0.11.0.b1
0.11.0 build 2 0.11.0 740110002 0.11.0.b2 0.11.0.b2
0.11.0 build 3 0.11.0 740110003 0.11.0.b3 0.11.0.b3
0.11.0 build 4 0.11.0.b4 740110004 0.11.0.b4 0.11.0.b4
0.11.0 build 5 0.11.0.b5 740110005 0.11.0.b5 0.11.0.b5
0.11.0 build 6 0.11.0.b6 740110006 0.11.0.b6 0.11.0.b6
0.11.0 build 7 0.11.0.b7 740110007 0.11.0.b7 0.11.0.b7
0.11.0 build 8 0.11.0.b8 740110008 0.11.0.b8 0.11.0.b8
0.11.0 build 9 0.11.0.b9 740110009 0.11.0.b9 0.11.0.b9
0.11.0 build 10 0.11.0.b10 740110010 0.11.0.b10 0.11.0.b10
0.11.0 build 11 0.11.0.b11 740110011 0.11.0.b11 0.11.0.b11
0.11.0 build 12 0.11.0.b12 740110012 0.11.0.b12 0.11.0.b12
0.11.0 build 13 0.11.0.b13 740110013 0.11.0.b13 0.11.0.b13
0.11.0 build 14 0.11.0.b14 740110014 0.11.0.b14 0.11.0.b14
0.11.0 0.11.0 740110015 0.11.0 0.11.0
0.11.1 0.11.1 740110101 0.11.1 0.11.1
None 0.11.1 740110102 0.11.1_Rev2 0.11.1_Rev2
0.11.2 0.11.2 0.11.2 0.11.2
0.12.0 0.12.0 0.12.0 0.12.0
0.12.1 build 1 0.12.1.b1 760120101 0.12.1.b1 0.12.1.b1
0.12.1 build 2 0.12.1.b2 760120102 0.12.1.b2 0.12.1.b2
0.12.1 build 3 0.12.1.b3 760120103 0.12.1.b3 0.12.1.b3
0.12.1 build 4 0.12.1.b4 760120104 0.12.1.b4 0.12.1.b4
0.12.1 build 5 0.12.1.b5 760120105 0.12.1.b5 0.12.1.b5
0.12.1 build 6 0.12.1.b6 760120106 0.12.1.b6 0.12.1.b6
0.12.1 build 7 0.12.1.b7 760120107 0.12.1.b7 0.12.1.b7
0.12.1 build 8 0.12.1.b8 760120108 0.12.1.b8 0.12.1.b8
0.12.1 build 9 0.12.1.b9 760120109 0.12.1.b9 0.12.1.b9
0.12.1 build 10 0.12.1.b10 760120110 0.12.1.b10 0.12.1.b10
0.12.1 build 11 0.12.1.b11 760120111 0.12.1.b11 0.12.1.b11
0.12.1 build 12 0.12.1.b12 760120112 0.12.1.b12 0.12.1.b12
0.12.1 build 13 0.12.1.b13 760120113 0.12.1.b13 0.12.1.b13
0.12.1 0.12.1 760120114 0.12.1 0.12.1
0.12.2 0.12.2 760120200 0.12.2 0.12.2
0.12.3 0.12.3 760120300 0.12.3 0.12.3
0.13.0 build 1 0.13.0.b1 760130001 0.13.0.b1 0.13.0.b1
0.13.0 build 2 0.13.0.b2 760130002 0.13.0.b2 0.13.0.b2
0.13.0 build 3 0.13.0.b3 760130003 0.13.0.b3 0.13.0.b3
0.13.0 build 4 0.13.0.b4 760130004 0.13.0.b4 0.13.0.b4
0.13.0 build 5 0.13.0.b5 760130005 0.13.0.b5 0.13.0.b5
0.13.0 0.13.0 760130000 0.13.0 0.13.0
0.13.1 0.13.1 760130100 0.13.1 0.13.1
0.13.2 0.13.2 760130200 0.13.2 0.13.2
None 0.13.2 760130201 0.13.2_Rev2 0.13.2_Rev2
None 0.13.2 760130202 0.13.2_Rev3 0.13.2_Rev3
0.14.0 build 1 0.14.0.b1 760140001 0.14.0.b1 0.14.0.b1
0.14.0 build 2 0.14.0.b2 760140002 0.14.0.b2 0.14.0.b2
0.14.0 build 3 0.14.0.b3 760140003 0.14.0.b3 0.14.0.b3
0.14.0 build 4 0.14.0.b4 760140004 0.14.0.b4 0.14.0.b4
0.14.0 build 5 0.14.0.b5 760140005 0.14.0.b5 0.14.0.b5
0.14.0 build 6 0.14.0.b6 760140006 0.14.0.b6 0.14.0.b6
0.14.0 build 7 0.14.0.b7 760140007 0.14.0.b7 0.14.0.b7
0.14.0 0.14.0 760140009 0.14.0 0.14.0
0.14.1 0.14.1 760140100 0.14.1 0.14.1
0.14.2 0.14.2 760140200 0.14.2 0.14.2
0.14.3 0.14.3 760140300 0.14.3 0.14.3
None 0.14.3 760140301 0.14.3_Rev2 0.14.3_Rev2
Realms build 1 0.15.0.a2 781150002 0.15.0.a2 0.15.0.a2
Realms build 2 0.15.0.a3 781150003 0.15.0.a3 0.15.0.a3
Realms build 4 0.15.0.a4 781150004 0.15.0.a4 0.15.0.a4
0.15.0 build 1 870149900
0.15.0 build 2 870149902
0.15.0 build 3 870149903
0.15.0 870150001 0.15.0
0.15.1 build 1 870150050
0.15.1 870150102 0.15.1
0.15.2 870150201 0.15.2
0.15.3 870150302 0.15.3
0.15.4 870150400 0.15.4
0.15.6 870150600 0.15.6
0.15.7 870150702 0.15.7
0.15.8 870150800 0.15.8
None 870150801
0.15.9 870150900 0.15.9
0.15.10 870151000 0.15.10
0.16.0 build 1 870159000
0.16.0 build 2 870159001
0.16.0 build 3 870159002
0.16.0 build 4 870159007
0.16.0 build 5 870159008
0.16.0 870160005 0.16.0
0.16.1 870160100 0.16.1
0.16.2 970160202 0.16.2
alpha 870170001
alpha 870170002
alpha 871000000
alpha 871000001
alpha 871000002
alpha 871000007
1.0.0 871000016 1.0.0
1.0.1 1.0.1 1.0.1
1.0.2 871000201 1.0.2
alpha 871000300
1.0.3 871000312 1.0.3
alpha 871000400
alpha 871000401
1.0.4 871000411 1.0.4
alpha 871000500
alpha 871000503
alpha 871000511
alpha 871000513
1.0.5 871000554 1.0.5
alpha 871000600
1.0.6 871000652 1.0.6
1.0.7 871000700 1.0.7
1.0.8 871000801 1.0.8
1.0.9 871000901 1.0.9
alpha 871010000
alpha 871010001
alpha 871010003
alpha 871010004
alpha 871010005
alpha 871010008
alpha 871010009
1.1.0 871010055 1.1.0
alpha 871010100
alpha 871010101
1.1.1 871010151 1.1.1
1.1.2 871010250 1.1.2
alpha 871010300
alpha 871010301
1.1.3 871010352 1.1.3
1.1.4 871010451 1.1.4
1.1.5 871010501 1.1.5
1.1.7 1.1.7 1.1.7
beta 871020002
beta 871020007
beta 871020009
beta 871020011
beta 871020015
beta 871020018
beta 871020022
beta 871020025
beta 871020031
1.2.0 871020081 1.2.0
1.2.1 871020101 1.2.1
1.2.2 871020203 1.2.2
beta 871020303
1.2.3 871020306 1.2.3
beta 871020500
beta 871020512
beta 871020515
1.2.5 871020552 1.2.5
beta 871020602
1.2.6 871020655 1.2.6 871020660
1.2.7 841020702 1.2.7
1.2.8 871020800 1.2.8
1.2.9 871020901 1.2.9
beta 871021001
1.2.10 871021002 1.2.10
1.2.11 871021104 1.2.11
beta 871021305
beta 871021306
beta 871021308
beta 871021310
beta 871021311
beta 871021312
1.2.13 871021354 1.2.13 871021360
beta 871021402
beta 871021403
1.2.14 1.2.14 1.2.14
1.2.15 1.2.15 1.2.16
beta 871022001
beta 871022002
1.4.0 871040005 1.4.0
1.4.1 871040100 1.4.1
1.4.2 871040200 1.4.2
1.4.3 1.4.3
1.4.4 871040400 1.4.4
beta 871050000
beta 871050001
beta 871050004
beta 871050007
beta 871050010
1.5.0 871050014 1.5.0
1.5.1 871050102 1.5.1
1.5.2 871050201 1.5.2
1.5.3 871050300 1.5.3
beta 871060001
beta 871060005
beta 871060006
beta 871060008
1.6.0 871060014 1.6.0
beta 871060030
1.6.1 871060100 1.6.1
1.6.2 1.6.2 1.6.2
beta 871070002
beta 871070003
beta 871070005
beta 871070007
beta 871070009
1.7.0 871070013 1.7.0
1.7.1 1.7.1 1.7.1
1.7.3 1.7.3 1.7.3
None 871070900 1.7.9
beta 871080008
beta 871080010
beta 871080011
beta 871080013
beta 871080014
1.8.0 871080024 1.8.0
1.8.1 871080102 1.8.1
None 871080925 1.8.9
beta 871090000
beta 871090002
beta 871090003
beta 871090005
1.9.0 871090015 1.9.0
1.9.1 1.9.1 1.9.1
1.9.3 1.9.3 1.9.3
beta 871100003
beta 871100004
1.10.0 871100007 1.10.0
1.10.1 1.10.1 1.10.1
beta 871110001
beta 871110003
beta 871110004
beta 871110005
beta 871110007
beta 871110008
beta 871110009
beta 871110010
1.11.0 871110023 1.11.0
1.11.1 871110102 1.11.1
1.11.2 1.11.2
1.11.3 871110301 1.11.3
1.11.4 871110402 1.11.4
beta 871120002
beta 871120003
beta 871120004
beta 871120006
beta 871120009
beta 871120010
beta 871120011
beta 871120012
beta 871120013
beta 871120014
1.12.0 871120028 1.12.0
1.12.1 871120101 1.12.1
1.12.3 1.12.3 1.12.3
1.12.5 1.12.5 1.12.5
1.12.60 1.12.60 1.12.60
beta 871130001
beta 871130002
beta 871130004
beta 871130005
beta 871130006
beta 871130013
beta 871130015
beta 941130018
1.13.0 941130034 1.13.0
1.13.1 941130105 1.13.1
beta 941140001
beta 941140002
beta 941140003
beta 941140004
beta 941140006
1.14.0 941140009 1.14.0
beta 941140050
beta 941140051
beta 941140052
beta 941140102
beta 941140103
None 941140104 1.14.1
1.14.1 941140105
beta 941140250
beta 941140251
1.14.20 941142001 1.14.20
beta 941142501
1.14.30 941143002 1.14.30
1.14.30 283143006
beta 941143051
1.14.31 283143100 1.14.31
1.14.32 283143200 1.14.32
1.14.41 1.14.41 1.14.41
1.14.50 283145000 1.14.50
1.14.60 1.14.60
1.16.0 1.16.0
1.16.1 1.16.1
1.16.10 1.16.10
beta 943162050
beta 943162052
beta 943162053
beta 943162054
1.16.21 1.16.21
1.16.40 1.16.40
1.16.42 1.16.42 1.16.42
1.16.50 1.16.50 1.16.50
1.16.60 1.16.60 1.16.60
1.16.61 1.16.61 1.16.61
1.16.100 1.16.100
beta 953610050
beta 953610051
beta 953610052
beta 953610053
beta 953610054
beta 953610055
beta 953610057
beta 953610058
beta 953610059
beta 953610060
1.16.101 1.16.101
1.16.200 1.16.200
beta 971620051
beta 971620052
beta 971620053
beta 971620055
beta 971620056
beta 971620057
1.16.201 1.16.201
beta 971621050
beta 971621051
beta 971621053
beta 971621054
beta 971621055

--SkyE | Talk · Contributions · Logs 06:51, 17 February 2021 (UTC)

Minecraft Dungeons

This section has been created to separate Dungeons wiki related topics and proposals from the sea of other topics in this portal, mainly for my own convenience. If this is of issue then please notify me of such so that I am aware to not do so in future. 🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

Extension to Style Guide

Related discussion in Wiki Discord (2021-02-14)

As the dungeons wiki continues to expand there has become a desire and a need for a Style Guide that caters specificity to aspects that likely are not evident in general MCW pages or MC and MCE wikis. WIth MCD:Flames of the Nether and a large free update rapidly approaching bring a large quantity of new content, I believe it would be beneficial if we had something to guide Dungeons editors, including myself, to ensure consistency, convenience, and quality of pages and files.

This specific style guide can touch upon image naming schemes for dungeons equipment images (See: User:Raybeano99/MCD_EquipStyle), common page layouts for general articles, equipment articles, mission articles ect., inform about commonly used templates and appropriate scale values for using them, and probably much ,much more that I, myself, have not even thought about.
Preferably, this is to be viewed as an extension with tweaks upon the existing MCW:STYLE rather than a transcluded/duplicated page with some modifications. I have a few ideas on how this could be implemented:

Style 1 - Append onto existing MCW:STYLE page.

  • A new section could be created and enveloped within a distinctive #f4efe6 coloured box and text to ensure viewers recognise that the contained information is specific for the Dungeons WIki. Alternately, dungeons specific information are appended onto existing sections and subsections.
  • Clear that the information is an extension rather than a replacement or equivalent.
  • Centralised - Come one, come all, all ye need lies within a single page of wonderful info.
  • Most exposure to all editors of the wiki - More feedback, critique, and viewpoints from editors to ensure that the style guide is constructed up to a high standard. Also more users are likely to view it.
  • Flow, bit of a double edge - Centralised page would allow the whole MCW:STYLE to be read without trying to find other places for info. However, this may flow too well. Users may not recognise the section as dungeons specific, even with crystal clear visual elements and text, and apply the information onto non-dungeons pages, or miss/disregard the information altogether.
  • Expansion concerns - The existing style guide may become formidably long over time as the dungeons specific section expands and adds detail.

Style 2 - A subpage of MCW:STYLE.

  • A page to contain the dungeons specific information. linked by a visually-distinct hatnote on the MCW:STYLE.
  • Still clear that the information is an extension rather than a replacement or equivalent.
  • Expansion concerns are no longer a concern.
  • Flow concerns mitigated - Information not all in one place thus the distinction that the information is for dungeons specifically is more clear.
  • Moderate exposure to all editors of the wiki - Likely less exposure than style 1.
  • There must certainly be a clear negative somewhere but I am unable to think of one.
  • MCW:Style Guide/Dungeons, MCW:Style Guide/MCD perhaps?

Style 3 - A page within the Minecraft Dungeons namespace.

  • A page to contain the dungeons specific information close to home in the dungeons. linked by a visually-distinct hatnote on the MCW:STYLE.
  • Style - All the visual glory of the dungeons is applied onto the page.
  • Expansion concerns are no longer a concern.
  • Flow concerns mitigated - Information not all in one place thus the distinction that the information is for dungeons specifically is undoubtedly clear, especially with the dungeons namespace.
  • Least exposure to all editors of the wiki - Probably less exposure than style 1 or style 2.
  • Probably another negative exists but I am unable to think of one.
  • MCD:Style Guide perhaps?

I have personal preference for the dungeons style guide extension to become its own page in some form that style 2 and style 3 provides.

  • 🤔 Would this lead to further specificity for other MCW pages such as the portal, tasks and projects? Would that be a concern? Could further pages make things more cumbersome and difficult?

🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

Style 1
I don't fully agree with this approach. Pertaining to keeping different kind of information simultaneously can be difficult to navigate and may lead to some confusion. A similar problem to this is the difference of information between Java and Bedrock. So as to resolve, the community decided to use {{in}}/{{only}} whenever the provided information contain disparities. This solution should not be used in terms of information that are fundamental to the wiki, like style guides. Another solution such as adding a background color or new section wouldn't help as much. Furthermore, similar styling to background color has already been defined and it requires new knowledge for people to realize the distinction.
Style 2
I totally agree in separating the page from the main style guide. By separating the page, there will be more freedom for expansion whilst not polluting the current page with MCD guides. Regarding misdirections, they are enough to be resolved by using a hat note or message box. For page name, I would say that Minecraft_Wiki:Style_guide/Minecraft_Dungeons is good enough.
Before talking about extensions to the style guide, maybe the editors of Minecraft Dungeons articles could work harder to follow the basic style guidelines that already exist, such as not using title case in headings, not capitalizing things in text that aren't proper nouns, refraining from filling articles with indiscriminate lists of trivia (which I have worked hard to clean up), and so on. The last thing we need is new guidance that conflicts with or creates exceptions to guidelines we already have. Amatulic (talk) 02:38, 1 June 2021 (UTC)
Style 3
It would be more appropriate to put meta information in the Minecraft Wiki namespace. As for MCD:Style, I guess it can be used as a redirect to the MCW namespace for shortcut. Also I wouldn't personally be bothered with the design aspect of the page.
In addition, I feel like the sidebar could have the style guide to link specifically when you are in the MCD namespace. Thus resolving the concern of exposure of the page, especially to MCD editors. Other maintenance/community pages like community portal, projects, etc. shouldn't be a concern, at least for now. – ItsPlantseed|⟩ 11:20, 16 February 2021 (UTC)
Having a dynamic sidebar that alters to suit the namespace the user is in would be a brilliant implementation and not just for the style guide exposure. I do recall a discussion in the discord where an issue that prevents namespace dependent sidebars from functioning was mentioned. I suppose until that is resolved, we can’t poke the sidebar in a dynamic fashion. Could have Dungeons Style Guide be under Style Guide until that fix arrives.
Style 1 could certainly end up becoming messy and unclear for all members involved, I agree with your views.
Style 2 & 3 design aspect is agreeably low priority and appropriate location should have possess weight. Some design aspects can be determined by the page through the source so things can be solved on that front.
Minecraft_Wiki:Style_guide/Minecraft_Dungeons with MCD:Style and MCW:Style Dungeons as redirects perhaps? Maybe only the one redirect shortcut is required. 🍍 Raybeano99 (Talk) 14:55, 16 February 2021 (UTC)

Centralised Datapage

Related discussion in Wiki Discord (2021-02-04)

In the Dungeons namespace, there are multiple pages that duplicate the same information that must be kept updated, consistently styled, and worded correctly. For instance:

Some of these pages present the information in different styles to match the context of these pages.

To make numerous edits across multiple pages is tiring, time-consuming, introduces error, and new editors may be unaware of the different information location. A centralised place to edit this frequently used information will be immensely helpful. One edit to induce into many edits.
I am unaware on how to construct such a thing and implement it in a way that is accessible to locate, trivial to edit, future-proof, and easy to implement into pages.

Please share your thoughts on this and how such a thing could be constructed. A dedicated Sandbox page with subpages could be created for testing purposes.
🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

UPDATE: Consideration for the use of Cargo. Discussed at Wiki Discord 2021-03-2021

Wiki channel in the Official Dungeons Discord

This is a thought that has been swimming around in my mind for some time. The Dungeons wiki does not have a huge quantity of editors that are immensely experienced with the game and its internals. There is also, unfortunately, a partial community consensus that any dungeons wikis are untrustworthy and information from them is to be treated with caution. This is something we need to resolve and gain the trust in the community.
The Official Dungeons Discord hosts a large quantity (but not overwhelmingly large!) of experienced players that educate, advise, and guide others but are unfamiliar with wiki editing. I believe there to be a fiction when learning how to edit the wiki with there being a few places to learn such with huge exposure. This wiki, MediaWiki Wiki, Help Wiki and the MCW:Discord (side note: I am very glad the wiki hosts a Discord Server.) are all brilliant places to start learning how to wiki edit however, they are not frequently seen or you need to ask around and explore to find them.

As a moderator of the dungeons discord, I have been able to internally propose the idea of a wiki dedicated channel - a place for dungeons folk to comfortably discuss wiki pages and information without worrying about unintentionally misinforming other players or being disruptive to existing channels. Information and links directing to wiki rules, help wikis, frequently used templates, and some wiki editing tools (ie: the generate spreadsheet on User:Raybeano99 userpage) will be made available as a pinned message. Speculation and general chat will not be permitted in the channel and will be held to a high standard. Specialised roles have not been discussed and will be handled internally.
The internal proposition was to gain feedback and thoughts from the rest of the admins and the moderators before establishing further communications. Unfortunately, the response turnout has been unexpectedly low however, none have made an explicit deny to the channel implementation. Hence me making communications here to gain your thoughts whether ye be a passer-by, an editor, admin or above to ignite the idea again.
I am in belief that implementation would not immediately yield desired output... could be slow, could be nothing, maybe something worth the attempt. Can always be removed quicker than the time taken to make the channel. Reverting and backtracking is not a concern

  • Exposure - More people experienced with the game will be informed of the wiki's existence and can contribute! This could also increase the frequency of disruptive, defacing edits.
  • New place to learn - Another place for editors to gain assistance from other editors.
  • Communication fragmentation - This, personally, is a huge concern. Could be mitigated by instructing users to provide the discord message link of the first substantial message in a conversation in the talk page of the page in discussion.
  • 🤔 What about Wiki Discord's #dungeons-wiki channel? - Something to be considered is if the implementation of a wiki channel on the official discord would have any impact on the existing Wiki Discord.

🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

Neutral to weak oppose. Agree with the three points (except I'd say the first point is more positive than negative, rather than positive/negative to an approximately equal degree). I'd also like to add a fourth point (which is a rather major one for me). As I understand, the Dungeons server is run by Mojang, who may have a conflict of interest against the community in a number of aspects. As such, I'm not very positive about game developers controlling communities. Mojang in specific isn't a company I trust given some historical actions and additional information. --AttemptToCallNil (talk) 18:23, 8 April 2021 (UTC)

Tabbed Mob pages

Alt title: Merge “base” and “variant” mobs into a singular page.

Mobs in Minecraft Dungeons have different tiers (a term used by patch notes referring to apocalypse plus changes) that exhibit the same behaviour but with, generally, increased statistics. For example. Zombie is tier I, the dagger variant of Armored Zombie is tier II, and the sword variant of Armored Zombie is tier III.

Rather than visually appending the information upon the “base” mob (as it would encumber the page), or, what is currently the case, separate pages for Tier I and Tier II&III, a single page could implement a tabbed experience that would allow viewers to select which tier of mob they wish the page, section, or specific component to display.

Perhaps something similar to the infobox used at Terraria's Blue Slime but fashioned so it that would influence the information on the page. This could be under the page title, attached to each section, or applicable components such as tables.

Unsure on whether tabbed consolidation should include Jungle and Frozen variants of Zombie, Skeleton, and Creeper…these are tier I mobs but with additional and/or modified attacks. Could that be considered significantly altered behaviour?
Also are charged creepers considered a higher tier of creeper? Also husks and drowned? Ancients?

  • Reduction of duplicated or fragmented applicable information.
  • Makes explicit that the mobs are related
  • 🟡 Less pages for near identical mobs and thus less entries on Mob. Could possibly be beneficial?
  • Potential to decrease accessibility.
  • Likely to increase complexity of page source and hinder visual editors.

🍍 Raybeano99 (Talk) 17:34, 2 April 2021 (UTC)

Oppose, I don't think this is a useful way of using tabs. Tabs tend to cause accessibility and technical problems as you said (I'd also add that links to anchors in non-default tabs may not work). Fandom staff keep telling editors that research has shown tabs are not an effective way of conveying information as tabs other than the first will be ignored by a large portion of readers. I'm not sure about your third point, I'd say this isn't a factor at all. About the second point, is "fun related" a typo for "unrelated"? I'm not sure what "fun related" means. --AttemptToCallNil (talk) 18:29, 8 April 2021 (UTC)
Typo… not sure how fun got in there. Has been corrected.
Yeah I could envision folk not recognising the tabs as clickable and missing the information enclosed within them thinking about it more. Wondering if there are other ways that the merge could be achieved… or perhaps the standard information suffixing might not be as encumbering as initially imagined. Would love any different ideas. 🍍 Raybeano99 (Talk) 18:54, 8 April 2021 (UTC)

User page problem.

For any user page but mine it always says "This user has not filled out their profile page yet." I can tell this is a problem as while looking at the abuse filter, examining individual changes, when I go to a user page that the person edited and added stuff, it says this, and it says this in the for the page history too. Gameking1happy (talk) 19:15, 16 February 2021 (UTC)

Yes, it is showing, this is to prevent other people from editing their userpage. --TreeIsLife (talk) 19:18, 16 February 2021 (UTC)
That is nonesense. See my comment below. Dhranios (talk) (Join the wiki videos project!) 19:18, 16 February 2021 (UTC)
If correct, that was the reason --TreeIsLife (talk) 09:06, 18 March 2021 (UTC)
Known fandom problem, they're looking into it; you can still view the pages if you use visual editor. Dhranios (talk) (Join the wiki videos project!) 19:18, 16 February 2021 (UTC)
Yes, doesn't make sense why they would prevent others from viewing your userpage. I would get preventing editing, but viewing is obviously has no harm and is most likely a glitch on Fandom's part. James Haydon (talk) 19:20, 16 February 2021 (UTC)

Reinstate Tutorials/Obtaining discontinued blocks and items

Currently, Tutorials/Obtaining discontinued blocks and items is a page with no text other than a soft redirect to a Miraheze about discontinued blocks and items.

I am in favour of reinstating this page because it is useful, and has all the information needed on one page. Many players find it neat and challenging to grab all of these discontinued items and show them off to their friends. The page before it’s update was very helpful and detailed all of the blocks, plus a nice roadmap for gaining all of the blocks through their versions. The Miraheze page has all of the items on separate pages, no roadmap, and full of fluff that can be made into a short paragraph if rewritten. John502 (talk) 03:32, 18 February 2021 (UTC)

The reason why the migrate it is because maybe they feel it as an official wiki for obtaining discontinued blocks and items. TheGreatSpring (talk) 03:51, 18 February 2021 (UTC)
"All of the items on separate pages" because it's a wiki, "no roadmap" that's just not true, "and full of fluff that can be made into a short paragraph" no not at all, it says as much info as it can. Tho I may be biased because I made and own the bedrock edition version of that wiki --Gtbot2007 (talk) 15:26, 18 February 2021 (UTC)

"all the information needed on one page" seriously? What existed on those pages was a tiny fraction of what has been obtainable throughout the game's history. - User-12316399 (talk) 19:38, 18 February 2021 (UTC)

Why are there no quotes?

The wandering trader used to have quote from "Meet the Wandering Trader", but that is no more. The same applies to other pages. Why?--Olivia Capucine Elisabet (talk) 16:13, 21 February 2021 (UTC)

Because there was a community decision about a year ago to scrap these, as they hogged page space while providing little to no useful information to the article. - User-12316399 (talk) 16:56, 21 February 2021 (UTC)
Yes I do think that having quotes on every page is stupid, especially if they aren't related to said thing but only mention it. The only exception is on pages for items and locations in Minecraft Dungeons since they have these quotes in-game rather than in a YouTube video. James Haydon (talk) 17:03, 21 February 2021 (UTC)

Apperance sections

Should we have them or not?--Olivia Capucine Elisabet (talk) 17:44, 21 February 2021 (UTC)

I also have seen the occasional need for an Appearance section, particularly where something listed in a trivia section would be better suited for the article body, but there isn't already a section for it. Overall, the vast majority of articles don't need such a section. It would have to be judged on a case-by-case basis. Amatulic (talk) 02:57, 1 June 2021 (UTC)


I'm not sure if this is related to UCP but several signatures are resetting including mine, TheGreatSpring's, and Madminecrafter12. Is their any fix to this, is it related to UCP?Humiebeetalk contribs 01:43, 22 February 2021 (UTC)

Hey Humie! I'd imagine it is related to UCP, since your userpage isn't showing up for me either, which is a "known bug" with UCP (this roll out is going great, huh?)
For what it's worth, I can see your sig right now.-- DigiDuncan (talk) 02:18, 22 February 2021 (UTC)
Don't call me humie I recently changed my signature to attempt to reverse the bug. This bug also happened before the user page bug.Humiebeetalk contribs 03:04, 22 February 2021 (UTC)
Sorry, didn't know about the name thing 😅 Wish I had more info, all I know is that this UCP rollout has messed up a lot, including my own personal Wiki and account, and many features of the platform. -- DigiDuncan (talk) 03:49, 22 February 2021 (UTC)

Old 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) 01:31, 30 April 2021 (UTC)

Securly for Chromebooks blocks part of content.

Screenshot 2021-02-24 at 12.50.15 (DELL Chromebook 11 3189 MW Com. portal with Securly for Chromebooks).png Securly for Chromebooks blocks part of content (right for Useful pages). I reached 400 edits! Android 1123581321 (talk) 12:55, 24 February 2021 (UTC)

Remove Securly if possible (I am assuming you can't).  Comment What is being blocked is Widget:Discord. It just seems like your school doesn't like Discord, and Widget:Discord uses discord's servers, and Securly blocks anything from discord's servers. You can also, if possible, use Tor(I am pretty sure Gamepedia unblocked it, I'll check it), a VPN, a proxy, or another computer. Blockofnetherite Talk Contributions 16:42, 24 February 2021 (UTC)
Can you take a screenshot of Widget:Discord with Securly disabled? I reached 400 edits! Android 1123581321 (talk) 09:17, 25 February 2021 (UTC)
I'm surprised that Gamepedia isn't (completely) blacklisted on Securly. Fadyblok240 (talk) 02:24, 26 February 2021 (UTC)

Page patrolling?!

I was looking at my wiki achievements and saw a whole group of achievements called "Page Patrolling," what does that mean? --Gameking1happy (talk) 19:57, 25 February 2021 (UTC)

It means that you go an edit and mark it as patrolled, which can be done by viewing the difference. Only admins and patrollers (myself included) have this ability, which is why you most likely don't know about it. James Haydon (talk) 20:59, 25 February 2021 (UTC)

Help with sorting my userboxes

On my page which has my userboxes, the boxes are randomly sorted, how could I make it in a scroll box where each box is on top of each other (no boxes to the right or left of each other)? Also, can I easily put it on my user page or do I have to do something, and is there a way I can put the distinguish template (to not have people confuse it for User:Gameking1happy/Userboxes) without it showing the template on my user page? --Gameking1happy (talk) 22:59, 27 February 2021 (UTC)

This is good now. --Gameking1happy (talk) 13:15, 28 February 2021 (UTC)

Need help with 2 things with my talk page and a "template" (which is a page to show userboxes).

Hello, can someone tell me how to: A, have my userboxes from the "template" (User:Gameking1happy/My Boxes) be on the right side, next to the part which shows subpages, and B, have it NOT show the {{Distinguish}} template that is on the My Boxes page. Also am asking this on my talk page. --Gameking1happy (talk) 13:41, 28 February 2021 (UTC)

I found out about <noinclude>, now all I need is to get the template to the right side, is there something like the center template but instead of the going to the center it goes to the right?

Schematics don't display properly on Safari on iOS. I'm not sure this is the right place to put this... Please advise/edit/etc. Thanks! Grundlesalad (talk) 17:02, 28 February 2021 (UTC)

You forgot to make a section, when you are going to add a new topic press add section, don't press edit source and just add what you will say to the bottom of the page. --Gameking1happy (talk) 17:14, 28 February 2021 (UTC)

Want to know how to do something I saw people do.

I want to not need to use <small> in my whole signature to make it at a reasonable size (as now the <sub> text is a bit too small, but at normal size is too big), but need a HTML tag, what HTML tag allows you to put text on text, as I saw someone do this in their signature once. --GK1H (PF/T/C/A/S/UB made/UB on UP/PJ) 13:45, 1 March 2021 (UTC)

I don't think it is a template as a few days ago I was looking for a template for something. --GK1H (PF/T/C/A/S/UB made/UB on UP/PJ) 13:46, 1 March 2021 (UTC)
Refer to MCW:TALK again, your signature should not contain templates unless substituted. In other words, even if such a template existed, you are left with the same complex HTML after signing so might as well start with that. Plus, while you can make it visually shorter with different HTML tags, remember that markup length is a problem too, having to scroll past several lines of text for your signature is not ideal. Wikipedia limits to 255 characters. We don't have a strict limit, but I'd advise using close to 255 characters. KnightMiner (t/c) 15:42, 1 March 2021 (UTC)
Ok, I changed it to this as my made userboxes and sandbox can be found on my user page, in the subpages section, my userboxes and projects I am in can be found in other sections, and achievements can be found on my user profile and it isn't really necessary. --GK1H (P/T/C) 16:14, 1 March 2021 (UTC)

Release date for versions

Now TheGreatSpring (talkcontribslogs) changed the Planned versions page to include that the release date of be 1.16.210 to 2021. This was because of consistancy and because 1.17.0 releases after 1.16.210, therefore 1.16.210 releases in 2021. Personally, I don't like these odd release dates as they provide little info and are broad. Also, putting it as present day - June 2021 seems a little odd. I looked at the version histories for edition articles with no mentioned (but obvious) release date and the version history for planned versions. I noticed that there was an inconsistancy - one said no release date while the other said the obvious year. I  Oppose the broad release dates. Any thoughts? Humiebeetalk contribs 03:14, 3 March 2021 (UTC).

Yeah, I wouldn't oppose getting rid of 1.16.210's listed release date at all. Listing 2021 as a release date because 1.16.210 will release before 1.17 is already kinda speculation anyways, and not providing a source for it just encourages further speculation – JEC talk 03:44, 3 March 2021 (UTC)

Break row (or break line or whatever it is called) in visual editor.

How do I do <br> in the visual editor? --GK1H (P/T/C) 15:05, 3 March 2021 (UTC)

Never mind, found out it just makes formatting confusing as hell, I'll use the source editor for formatting in the visual editor section of my userbox testing page then. --GK1H (P/T/C) 15:22, 3 March 2021 (UTC)

Better moderation

on one of the talk pages on this wiki, i commented about an invalid template and how it should be removed, but then it got deleted.--Geniusrobot1 (talk) 17:47, 5 March 2021 (UTC)

Which talk page? What invalid template? Who removed it? Give some details, I see no record of such a comment in your contributions. KnightMiner (t/c) 17:52, 5 March 2021 (UTC)

Enabling discussions on the wiki

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The Fandom Minecraft Wiki got archived as part of Project Crossover, but Fandom discussions won't be enabled on this wiki.

We discussed some details of upcoming Minecraft Wiki Crossover (which is between Fandom and Gamepedia), and we came to a topic of enabling discussions on this wiki.

If you did not know what discussions are, they are forum-like social space where community members can talk about the wiki's topic as well as the wiki itself. However, those are built on a different engine, than normal wikis are, so they don't support wikitext. Here are some PROs and CONs of it:

  • A forum-like place
  • Categories
  • Ability to report (for all users)
  • They may attract many people to the wiki
  • You don't need to add a signature
  • You can add images to the post and on the comments.
  • It may hurt the wiki's reputation (because it would be much more active, than wiki itself)
  • Hard to moderate (unless there will be Special:SocialActivity)
    • There may be need to hire new moderators (which may not be a problem)
  • We would need to have discussion rules (we can use Fandom's one)
  • IPs can't comment there, only accounts.

Discussions may help to have better crossover, with more people for crossover. What do you think? Do you support it, or not? --TreeIsLife (talk) 19:10, 5 March 2021 (UTC)

For an example of what Discussions looks like, see https://minecraft.fandom.com/f . For the guidelines that TreeIsLife mentioned, you can find a link at the top or on the side, which will take you to https://minecraft.fandom.com/d/g . Finally, if you want some general information on Discussions, check out Help:Discussions on Community Central. SLScool 19:20, 5 March 2021 (UTC)
On the Minecraft Wiki Crossover Discord the consensus was generally in favor of enabling discussions on the Gamepedia wiki. This allows the users of this feature to find their new home on the Gamepedia wiki as well, once the Fandom wiki gets locked. If the wider community consensus here agrees to enabling discussions as well, the planned timeline would be to enable discussions after the domain migration (this possibility is currently being looked into by staff, might have to wait with enabling discussions until the unified skin) and finish the Crossover with that, locking the Fandom wiki. --MarkusRost (talk) 19:46, 5 March 2021 (UTC)
Support section
I  Weak support (or maybe  Neutral, because of the arguments below) this as it was already decided on the Crossover Discord. While wikitext is useful to show templates and things like that, actually we don't do that frequently, and an advantage of the discussions system is that you can share images on the comments, which is really useful to show what we should do on specific situations. That means that there will be more vandalizers. However, it will be easy to set a group of discussion moderators to prevent such things. Thejoaqui777 (talk) 21:40, 5 March 2021 (UTC)
I  Support as I would like a place for discussion, and the cons don't seem too bad. --GK1H (P/T/C) 21:50, 5 March 2021 (UTC)
 Support because I want a way to easily communicate with other wiki editors (i dont have discord).Humiebeetalk contribs 22:15, 5 March 2021 (UTC)
 Support solely to unblock Crossover. The technology itself is not to the standards I'd consider required of any wiki technology (full histories, logs, no permanent deletion, moderator identity disclosure), so if it wasn't plausibly needed for Crossover, and if I had reasons to believe Fandom would refrain from forcing this technology on the wiki no matter its state, I would have opposed. --AttemptToCallNil (talk) 00:02, 6 March 2021 (UTC)
 Support Just for unblocking migration. We can't risk crossover would fail even with this wiki, after the MCSM one. Many people will want this, may attract new editors, especially those, who are getting here from Minecraft Forums. On the other side, i understand people against this. --TreeIsLife (talk) 19:57, 6 March 2021 (UTC)
 Weak support Discussion technology is ok, often overused as a chat platform rather than a forum which creates this weird environment since the technology itself is clearly not made with that in mind (show more button appearing every few posts). I generally don't expect a lot of meaningful discussion happening over there, I fully expect quizzes in type of "what is your favorite block" which is not something I'm interested in. That said, discussions could potentially be a good place for community to communicate with each other, I don't believe it's as good as current communication platform we use (Discord server) but it could be an option for those who don't want to use it. I think discussions present a better way to announce various changes on the wiki, with notification integration and nice formatting. The site notice is quite... Archaic and not pretty. As mc-pl admin I'm interested in turning Discussions on to see how it goes. Perhaps something similar could be suggested in here? Do a trial and see if that's something you'd like? Frisk (talk) 00:59, 7 March 2021 (UTC)
Oppose section
I  Oppose. I believe talk pages are already sufficient and they allow anonymous contributors to chip in, even if it were to be only one. Discussions would hamper this. Furthermore, I am of the school of thought where on-wiki discussions should only be about the wiki itself (or the page in question; hence talk pages), not some chit-chat about the wiki's topic (in our case, Minecraft) even if guidelines or rules exist. Purpose-built forum websites (like the Minecraft Forums or r/Minecraft) and chat programs (like Discord) serve that purpose better. A wiki's speciality is to serve user-generated content about the wiki's topic in question, not to be a catch-all for whatever one may feel like posting. DarkShadowTNT (talk) 23:21, 5 March 2021 (UTC)
 Oppose per DarkShadowTNT. BDJP (t|c) 23:29, 5 March 2021 (UTC)
 Oppose What's the point? If you want to discuss an article, you to the talk page; if you want to discuss the wiki, you come here. What would this add? It seems like a bunch of extra work for admins for no benefit at all. Looking at the link provided, 🤢🤮 this is not what a wiki is for.  Nixinova T  C   23:37, 5 March 2021 (UTC)
 Strong oppose Talk pages have served the wiki just fine for the past over a decade, so there's absolutely nothing to benefit from switching over to this. Not to mention the proposed discussion feature simply looks far less professional and oversimplified. A no from me. - User-12316399 (talk) 00:10, 6 March 2021 (UTC)
 Oppose – My main concern is how this would affect the wiki's reputation if we allow non-wiki discussion like the Fandom wiki currently does. While I don't mind the idea of social aspects within the wiki community, the Discord fills that purpose already and most of the active members there are editors; whereas with Discussions, there may be a substantial amount of people who are only active there and don't edit the wiki and vice versa (which seems to be the case on MCW Fandom). IMO, having two separate communities on the same site makes it harder to manage.
I am also not a fan of its general layout (e.g. lack of search-ability, displaying every post/comment on a single page), although UCP phase 2 may make some changes. I should also mention that a few Fandom wiki admins expressed support in the Crossover Discord for merging even if we decided against enabling discussions, so it might not be a blocking factor. –Sonicwave talk 01:50, 6 March 2021 (UTC)
 Weak oppose per above comments. TheGreatSpring (talk | contribs) (Tagalog translation) 02:24, 6 March 2021 (UTC)
 Oppose Discussions doesn't belong in a wiki-like environment. Compared to talk page, it's not well-structured and also not archivable. It's poorly designed and doesn't give much to the wiki. It shouldn't ever be used for in-wiki discussions, because the lack of navigation and reliability. There are other places for general people to talk about the game like Minecraft Forums. So I don't see any "actual benefit" for us from having it here; just going to add more burden to moderation. – ItsPlantseed|⟩ 05:35, 6 March 2021 (UTC)
I  Strong oppose, it's disorganised and messy, we are too much! MetalManiac at your service fellow human! (talk) 08:31, 6 March 2021 (UTC)
Changed to  Weak oppose per above (I guess I just have to get discord).Humiebeetalk contribs 15:38, 6 March 2021 (UTC)
 Oppose. I don't see the need to add DIscusions--Eduaddad (talk) pt.Wiki Administrator Helper 14:38, 7 March 2021 (UTC)
 Oppose. When I look at the current discussions on the current Minecraft wikia, I don't think this is something that a wiki needs. That type of content fits way better on Reddit. Most of the things there don't even have anything to do with the wiki at all, they're just shitposts about Minecraft. | violine1101 (talk) 15:55, 10 March 2021 (UTC)


I saw some people with argument against discussions, that was similar to - "Basically discussions are talk pages".

So, as i described, they are forum-like. But people said they are basically talk pages. Well now, i see people voting oppose will be even more mad, but discussions can be also named as - well- Minecraft Forum. They have some Wiki things, but other topics are allowed, such as creations, memes,... - based on wiki admins choice. Fandom's Wiki has sections like: "General, Poll, Creations, News (on Minecraft), Q&A or Minecraft Wiki.--TreeIsLife (talk) 20:16, 6 March 2021 (UTC)

I have changed my vote from  Support to  Weak oppose to  Neutral. I understand that it you want it to be a forum but i'm not exactly sure if we need this. All of this is usually documented on reddit OR MCW discord. I really think memes are not nessicary at ALL in this wiki. Creations might be helpful for tutorials and feedback could also be helpful so i'm  Neutral Humiebeetalk contribs 20:29, 6 March 2021 (UTC)
Well, this discussion/vote was suggested by Markus, and the inclusion of Discussions was by Fandom users.--TreeIsLife (talk) 20:49, 6 March 2021 (UTC)
Even still, I do not believe a wiki should be hosting things like memes, polls and creations (unless relevant for an article and placed only there where it's relevant). Like Humiebee said above and I in my vote, there are places already for this which serve such purposes better than a wiki could. If this would block the crossover, then so be it. I would still stand by my vote. Going by Sonicwave, not having Discussions might not be a blocking factor anyway. DarkShadowTNT (talk) 20:59, 6 March 2021 (UTC)
There is a lot of opposition to Discussions on the basis that non-wiki conversations are an integral part of the system and it's impossible to only have wiki-related posts. However, this is not actually the case. The rules can very easily be written to only allow wiki-related posts. For example: suppose this wiki allowed everyone to freely discuss the games on talk pages. You would see a lot of users using talk pages to discuss the game without editing articles/templates/whatever else; you would also see a lot of users editing articles et al. without using talk pages to discuss the game (which is what we currently have). However, this wiki does not allow that, so this only happens very rarely if ever. Similarly, if the rules on Discussions say that users can only discuss the wiki, you would see a lot of users discussing the wiki there without many users discussing the games themselves. While the design of Discussions might make it more likely for people to use Discussions for the wrong purpose than to use talk pages for the wrong purpose, it's still the same principle: whether or not users are allowed to discuss non-wiki matters is a choice that is entirely up to the wiki, regardless of whether it's in Discussions or on talk pages or in some other location. There are still other reasons to oppose discussions, but wiki-related vs. non-wiki-related shouldn't be. SLScool 23:59, 6 March 2021 (UTC)
If we only allowed wiki discussion posts, I don't think Discussions would be worth it over talk pages due to layout issues mentioned above. While they are more intuitive especially for new users, comments take up more space and you have to click multiple times to view all the comments on a long thread, it doesn't support "multi-level replies" like talk pages (or Reddit comments), and it's not searchable so decisions made there would be lost. The ability to add polls may lead people to use that for decision making, instead of forming a consensus as should be done on here. Plus, the very existence of another communication medium fragments wiki discussion further. It may work if we have a rule that important discussions should be taken to wiki talk pages (like with the Discord), but there wouldn't be much point in having it then. –Sonicwave talk 05:05, 7 March 2021 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

All Wiki Tags on Main Page

All wiki tags are not listed on this wiki's main page. SpeedoThreeSixty (talk) 18:28, 12 March 2021 (UTC)

Mechanics/Redstone problem

The following discussion of a proposal to move several redstone-related pages was closed. Please do not modify it. Make subsequent comments below this or make a new topic.
 Done. Pages were moved per this discussion. Thejoaqui777 (talk) 19:34, 6 April 2021 (UTC)

Currently, Mechanics/Redstone acts as a page that works like a short version of Mechanics/Redstone/Circuit and a list of Mechanics/Redstone/Components. The page needs to be rewritten to be transformed into a general article about all the redstone mechanics.

While Mechanics itself can be converted into an index page to list related articles, that isn't the actual problem. The problem is with the name of the page itself: Mechanics/Redstone and its subpages. Mechanics is a redirect to Tutorials/Mechanisms, meaning that we have subpages of a redirect. This means that the way of classifying them became more confusing and disorganized over time.

My proposal at Talk:Mechanics/Redstone is that it should be renamed to Redstone mechanics to be its own main article.

Now, adressing the discussion about Mechanics/Redstone/Circuit, it has been proposed to rename the page to Redstone circuits on its talk page. However, I don't think that is the only possible solution to this. Instead, I've proposed to rename it to Redstone mechanics/Circuit. It would still be a subpage, but a subpage of a complete article.

There is also an inconvenient: There exist pages like Mechanics/Redstone/Clock circuit, which use "circuit" on their names, and even have a lot of subpages. These ones should be renamed to Redstone mechanics/Circuit/Clock as an example.

Now, I'll show a table showing what we should do to solve this:

Proposal 1
Original name New name Reason
Mechanics Mechanics It should become an index page like Tutorials/Redstone, to list related articles about mechanics. (Change already made, though it needs improvements)
Mechanics/Redstone Redstone mechanics It should be a general page for all redstone mechanics.
Mechanics/Redstone/Components Redstone mechanics/Component To become a subpage of the new name.
Mechanics/Redstone/Circuit Redstone mechanics/Circuit To become a subpage of the new name, as circuits are part of the mechanics.
Mechanics/Redstone/Clock circuit
Mechanics/Redstone/Pulse circuit
Mechanics/Redstone/Transmission circuit
Mechanics/Redstone/Memory circuit
Mechanics/Redstone/Piston circuits
Redstone mechanics/Circuit/Clock
Redstone mechanics/Circuit/Pulse
Redstone mechanics/Circuit/Transmission
Redstone mechanics/Circuit/Memory
Redstone mechanics/Circuit/Piston
As they are specific circuits, it doesn't make sense to keep them separated as their own pages and not as subpages of the main article.
Example: Mechanics/Redstone/Clock circuit/Clock multiplier Example: Redstone mechanics/Circuit/Clock/Clock multiplier The subpages of the last ones should be converted to the new naming.

What do you think of it? I think it solves the problem. Thejoaqui777 (talk) 02:05, 18 March 2021 (UTC)

Since subpages are inaccessible from Special:RandomRootPage, which is used by "Random page" in the sidebar, renaming the articles without using subpages might make them more visible to readers, which might help in improving the articles. Fadyblok240 (talk) 02:35, 18 March 2021 (UTC)
That's also why Redstone mechanics should have links to all its subpages, and the same for Redstone mechanics/Circuit. Thejoaqui777 (talk) 02:40, 18 March 2021 (UTC)
As I said on my own page, the information currently at Mechanics/Redstone is certainly needed, no matter what name it's accessed by. It's not an abbreviated version of the Redstone Circuits page, it's explicitly the extraction of the mechanics info from that page. I purposely copied an abbreviated subset of that info back to the Circuit page, in the interests of readability/comprehension.
  • Turning Mechanics into an index page is a reasonable idea, and would go well with turning Mechanics/Redstone into a top-level page.
  • IMHO promoting the Redstone/Circuit page to a top-level "Redstone circuits" page would be better than making it a subpage of the new "Redstone mechanics" page -- it is a major topic in its own right, and the circuits already fit awkwardly under Mechanics. (They're equivocally "mechanical", but they're not really about game mechanics.) Note that the general "Circuit" page already has links to the type pages; the Circuit page itself briefly explains the types and offers general info about making redstone circuits.
    • Regardless, the circuit-type pages should stay as become subpages to the "Circuit" page's new location. I think all the internal links within the subtrees are already relative, but if any aren't we can fix them easily enough. Note that the type pages have more levels, notably the schematic breakout pages! (Those do need to be broken out of their respective "main" pages, due to the overhead and limits of the schematic system.)
  • It's also worth noting the index page Tutorials/Redstone, which mostly links to subpages of Tutorials/, but also has a few links into the Mechanics/Redstone tree.
--MentalMouse42 (talk) 03:20, 18 March 2021 (UTC)
That would make the proposal change from the original to this:
Proposal 2
Original name New name Reason
Mechanics Mechanics It should become an index page like Tutorials/Redstone, to list related articles about mechanics. (Change already made, though it needs improvements)
Mechanics/Redstone Redstone mechanics It should be a general page for all redstone mechanics.
Mechanics/Redstone/Components Redstone components To become an article to list all the posssible components, being rewritten for better readability.
Mechanics/Redstone/Circuit Redstone circuits To become its own article, as it is really big to be just a subpage.
Mechanics/Redstone/Clock circuit
Mechanics/Redstone/Pulse circuit
Mechanics/Redstone/Transmission circuit
Mechanics/Redstone/Memory circuit
Mechanics/Redstone/Piston circuits
Redstone circuits/Clock
Redstone circuits/Pulse
Redstone circuits/Transmission
Redstone circuits/Memory
Redstone circuits/Piston
As they are specific circuits, it doesn't make sense to keep them separated as their own pages and not as subpages of the main article.
Example: Mechanics/Redstone/Clock circuit/Clock multiplier Example: Redstone circuits/Clock/Clock multiplier The subpages of the last ones should be converted to the new naming.
That would be another proposal. Which do you think it is better? Proposal 1 or proposal 2? For me, the 2 actually may work better, but it is still worth keeping the 1. Thejoaqui777 (talk) 04:22, 18 March 2021 (UTC)
 Support for Proposal 2. The circuit type pages already have top-level redirects, those should be kept for indexing/search purposes. --MentalMouse42 (talk) 04:37, 18 March 2021 (UTC)
 Strong Support for Proposal 2. --TreeIsLife (talk) 08:20, 18 March 2021 (UTC)
 Strong support for Proposal 2 based on my comments from #The problem with subpages.Humiebeetalk contribs 00:56, 19 March 2021 (UTC)
 Support proposal 2. We do need consistency in naming. We have anvil mechanics already, and the redstone stuff should have the same hierarchy under Mechanics once that is changed from a redirect into its own page. Amatulic (talk) 18:16, 21 March 2021 (UTC)

Inconsistancy between Nether Update and Caves & Cliffs

In the page Nether Update, the Notable features section only contained the notable features. In Caves & Cliffs though, it shows every single feature. It also shows changes as well as having a much higher image rate (not in gallery). What style should be adopt, Nether Update or Caves & Cliffs?Humiebeetalk contribs 14:24, 20 March 2021 (UTC)

I'd say the newer page is just getting more attention as the game and wiki get bigger. I have no trouble with listing all the features, but it might be worth prepending a summary. --MentalMouse42 (talk) 16:17, 20 March 2021 (UTC)
As i said at least twice, Notable features should show notable features, not every feature. So Nether Update style should be adopted (for now).--TreeIsLife (talk) 07:52, 21 March 2021 (UTC)
I  Support the usage of Nether Update's style to write general articles about updates, while Java Edition 1.17 and Bedrock Edition 1.17.0 should be the specific articles to document the information as it is, like with Java Edition 1.16 and Bedrock Edition 1.16.0. Thejoaqui777 (talk) 19:44, 21 March 2021 (UTC)
Fair enough.  Support summary articles for "named updates", detailed articles for specific version numbers. --MentalMouse42 (talk) 19:18, 22 March 2021 (UTC)
Huge  Support for the idea of named articles for summaries and version articles for full changelogs. --DigiDuncan (talk) 21:14, 22 March 2021 (UTC)
 Comment @MentalMouse42: I would agree with that, as the wiki has been extremely active lately in the past few months, way more than it was when the Nether Update was being developed. James Haydon (talk) 21:13, 22 March 2021 (UTC)

New Developementcategory.png

I think that the developement icon is kind of outdated. So I did a Roboto Mono version of it.– Unsigned comment added by Gugalcrom123 (talkcontribs) at 10:37, 31 March 2021‎ (UTC). Sign comments with ~~~~

User talk:Mr.Ymnik

User:Mr.Ymnik created 2 images (File:Vestnik08.jpg, File:Bandicam 2021-03-10 16-16-40-217.jpg) for the purpose of creating a story that breaks Wiki Rule 4 (use an online translator if you can't read Russian). Although articles in the "User" namespace are exempt from rules 4, this is in the talk page and does not contribute to any wiki discussion. Should the talk page and the associated images be deleted? ~DΦC (talk) 19:43, 19 April 2021 (UTC)

Maybe move the page to a subpage of User:Mr.Ymnik? Also, pages in user space should never be referred to as articles. Fadyblok240 (talk) 22:48, 19 April 2021 (UTC)
Gotcha. So, I move the page to something like User:Mr.Ymnik/Vestnik Error? ~DΦC (talk) 22:52, 19 April 2021 (UTC)

SVG files for blocks

User:Arrran-gpuser created a number of svg files for block renders back in 2018. Should these remain on the wiki or be deleted? They don't currently serve any purpose and the files are ~10x the size of their png counterparts, but they don't get pixelated. ~DΦC (talk) 01:29, 23 April 2021 (UTC)


We have pages for Minecraft edu items/blocks, so what about items/blocks from ComputerCraftedu a mod not made nor owned by Mojang but that was also part of Minecraftedu. Like it would be strange if we had ComputerCraftedu info on this wiki but it would be more staring to have Minecraftedu info but not ComputerCraftedu info.– Unsigned comment added by Lego Starwars Timeline (talkcontribs) at 00:03, 29 April 2021 (UTC). Sign comments with ~~~~