Minecraft Wiki talk:Community portal/Archive 32

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

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)
 * 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."
 * 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? 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 Revision 1.png Because I do. --Ninji2701 13:50, 27 December 2020 (UTC)

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

This is just a stepping stone. I am open to any additional input regarding any further changes to this. BDJP (t 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 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 keeping all pages which have enough content and  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 .) For birth dates, I really don't see any harm if they posted it on  or some other social media thing. Also I wish to  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 01:02, 9 February 2021 (UTC)
 * I 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 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, 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, 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)
 * , 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)
 * PS4 is part of LCE, no reason to split its history.  Nixinova   T   C   19:29, 7 January 2021 (UTC)
 * 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 </b>  T </b>  C </b></b>  21:27, 10 January 2021 (UTC)
 * True, they only spanned 1.14, or 1.8.0 - 1.13.0.Humiebeetalk contribs 21:30, 10 January 2021 (UTC)
 * 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. 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. 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/Yes 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 players use Java Edition 1.16.4 than .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: However, this is the history section for goats: 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 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 </b>  T </b>  C </b></b>  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
Hi

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)


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


 * . 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)
 * , I agree with, 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 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)
 * 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)

Minicraft?
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)
 * this wiki is about Minecraft. TheGreatSpring (talk) 23:04, 13 February 2021 (UTC)
 * 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)
 * 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)
 * 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
 * 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 --172.58.228.82 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. 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  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 1.1.3.52. 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 1.16.210.59" 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 1.16.210.59" 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 and  of version nav also need to be changed. Do you think it's necessary?--  |  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 </b>  T </b>  C </b></b>  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 1.16.210.59", most people would say "1.16.210.59" 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 1.16.210.59" but input "Bedrock Edition v1.16.210.59" or "Bedrock Edition 1.16.210.59"). If you ask "Why not use the search function?", if the title is changed to "Bedrock Edition 1.16.210.59", wouldn't the search function still be useful? Without various prefixes and suffixes, wouldn't the search efficiency be higher?--  |  Talk · Contributions · Logs  13:24, 16 February 2021 (UTC)
 * Word "alpha" was not shown since 0.14, can we recognize that versions from 0.14 to 0.16 belong the Alpha development stage? -- Lxazl5770 zh.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 1.2.13.60 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 1.2.13.60 and released a version. This version didn't compile for iOS. Then Mojang changed the version number to 1.2.16.3, 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,  and   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 1.2.6.1 should be "Bedrock Edition 1.2.6.60". In Google Play changelog and Mojira's this page], Mojang said it's 1.2.6.1, but in game it displays 1.2.6. In source code and on Mojira it's 1.2.6.60. The full version no. of Bedrock Edition 1.2.6 is 1.2.6.55. 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 1.2.6.60". There was an argument about this on the talk page.
 * Nixinova@undefined 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. 1.14.1.4). If you want, we can provide the original apk files. We made a table to show this:

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.
 * ,   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.
 * 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.

🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)
 * 🤔 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?


 * 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.
 * with  and   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.
 * MCD:Enchanting, MCD:Weapon, MCD:Armor, and MCD:Artifact share the same information with the main pages for the individual pages of the specified thing (ie: MCD:Burning, MCD:Sword, MCD:Crossbow, MCD:Grim Armor) and, with respect to equipment, MCD:Drops, MCD:Daily Trials, the main page for a individual location (ie: MCD:Creeper Woods) and, in future, MCD:Difficulty to an extent.

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

🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)
 * 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.
 * 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 $$ have different tiers (a term used by 1.8.0.0 patch notes referring to apocalypse plus changes) that exhibit the same behaviour but with, generally, increased statistics. For example. is tier I, the dagger variant of is tier II, and the sword variant of  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 . 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 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)

Signatures
I'm not sure if this is related to UCP but several signatures are resetting including mine, 's, and. 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)