Minecraft Wiki talk:Community portal

From Minecraft Wiki
Jump to: navigation, search

This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.


Change Windows icon?[edit]

I feel like the Windows icon should be changed to one that is used for Windows 10; instead of keeping the XP-7 icon. Jarl penguin (talk) 14:10, 22 November 2018 (UTC)

 Yeah. It should be the iconic icon of Windows 10, but I'm afraid other editors will argue that readers will be confused between Minecraft: Windows 10 edition and Minecraft: Java edition. If you think it is right, you can propose it in the main page's editcopy. Lê Duy Quang (Make some words | Contributions) at 12h53:20 | 1/12/2018 (UTC)
 Strong Oppose – Would cause confusion with both the Bedrock Edition and the aforementioned Windows 10 Edition. -BDJP (t|c) 20:48, 15 May 2019 (UTC)
While I agree the icon should not be that of windows XP anymore, the icon for Windows 10 is not suitable either. The edition that the icon represents, and the one the icon is clashing with, Java Edition and Bedrock Edition for Windows 10, need to be differentiated. To use distinct icons. Because the icons should be representing the edition, and not the platform it runs on. I have ideas on how to do that, but in no way can I myself because I have no graphics software to do it. But somebody should fix this once and for all, I keep seeing the two parties colliding on which icon should be used and if a new icon could be made that fits both arguments (different icon but not the old logo), both parties should be able to agree. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 20:49, 15 May 2019 (UTC)
No, it should represent platform instead of edition. Along with macOS, linux, etc. Cause I don't remember there is actually "Minecraft: Java Edition macOS Edition". – ItsPlantseed|⟩ 20:54, 15 May 2019 (UTC)
Then come up with a different solution, instead of saying "no you're wrong". – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 20:56, 15 May 2019 (UTC)
Everyone should be aware that there is no "Minecraft: Windows 10 Edition". It doesn't exist, there are only three or four that are considered as edition, instead it got replaced by Bedrock Edition. Thus, the icon on main page should refer to platforms instead of editions, since Bedrock and Java are also available in Windows. Windows 10 has been out for years. Using two distinct Windows logos will make other people believe that Windows 10 is representing edition in the long term, believing that the edition is still exist. I don't come up with a solution since I don't think it needed a change. – ItsPlantseed|⟩ 21:09, 15 May 2019 (UTC)
They should both be windows 10 as it's about the platform not the edition of the game. Both Java and bedrock can be played on Windows 10, so the logo should be the same. – Nixinova Nixinova sig1.png Nixinova sig2.png 21:08, 15 May 2019 (UTC)
But Java can also be played on Windows XP and higher; that’s why the confusion regarding the logo should be avoided. -BDJP (t|c) 21:16, 15 May 2019 (UTC)
If Windows version was the problem, instead of diffirentiating Windows 10 Edition with Java Edition, adding "or lower" under the Windows logo should help just fine. – ItsPlantseed|⟩ 21:28, 15 May 2019 (UTC)
This being discussed before, twice, (even though those discussions were for Windows 8 only, the logo hasn't changed), and is has been pointed out that there is another problem with the post-W7 logo: it is uniformly blue, thus less visible on the wiki's light blue background, and on lower resolutions, like 20px in infoboxes, it may not be sufficiently recognizable even if contrast is sufficient.
It may not be the best comparison, but I thought of comparing the issue of the "old" Windows logo with using floppy disks as icons for "Save"-like actions in software. --AttemptToCallNil (report bug, view backtrace) 22:03, 15 May 2019 (UTC)
The main page will use the blue on yellow/red, so that point is not that relevant, and the windows 8 logo is still easily recognisable in low resolution. – Nixinova Nixinova sig1.png Nixinova sig2.png 22:49, 15 May 2019 (UTC)
This discussion is completely superfluous and needs to be speedily closed with no changes. Why would we need to change the icon to Windows 10 in full when the following completely counters this change;
  1. Java Edition is not just available for Windows 10; minimum requirements show that it works on Windows 7 or later. Heck, Java Edition isn’t even sold through the Microsoft Store.
  2. Story Mode and it’s sequel already have a Windows 10 icon already to signify that the game is also available through the Microsoft Store as well as Steam; there is no need for two Windows 10 icons on those pages.
  3. It has already been confirmed that Dungeons will be playable through the Java Edition launcher, so no icon change is necessary.
Think about this, why change the icon when all of the information 100% counters it? -BDJP (t|c) 09:55, 19 June 2019 (UTC)
Side note; even Majr disagrees.-BDJP (t|c) 09:58, 19 June 2019 (UTC)
There's a difference between {{OS|win}}: Windows and {{OS|win10}}: Windows 10, the former refers to all Windows version in general (which is currently using the latest Windows version logo) while the latter only refers to that of Windows 10 (used for a software that isn't compatible with all Windows but ten, same for {{OS|win7}} it is used for a software that only compatible with seven). You can easily tell this difference by hovering the cursor over them, and honestly we shouldn't bother all the Windows version below 7, they are already long gone by now. If the current logo is not clear enough, we can use this file for the former which indicates Windows in general as the file description says. – ItsPlantseed|⟩ 11:23, 19 June 2019 (UTC)
No difference from what I can see. It’s literally the same logo, which is what needs to be prevented, and the template should never have been changed in the first place. I also  Oppose using any derivative of the Windows 10 logo. -BDJP (t|c) 11:39, 19 June 2019 (UTC)
They indeed have the same logo, but the title and the link of {{OS|win}} is different than {{OS|win10}} or {{OS|win7}}, you can literally see this by hovering over them. The logo for the general Windows version is currently using the latest Windows version logo, clearly you opposed for this because of the logo being the same, now you are opposing for the logo to change. Why should we use the Windows 7 logo for the general logo of Windows? Even the page of Microsoft Windows on Wikipedia is using the Windows 10 logo since it's the latest and the most recognizable logo. Reverting the logo of {{OS|win}} to Windows 7 doesn't help either, since it'll be using the same logo as Windows 7. – ItsPlantseed|⟩ 12:00, 19 June 2019 (UTC)
Side note: hovering doesn't exist on mobile devices. --AttemptToCallNil (report bug, view backtrace) 12:06, 19 June 2019 (UTC)
Reverting the logo to Windows 7 will help tremendously because it will avoid confusion with the Bedrock Edition and the Microsoft Store. Many visitors to the site aren’t going to hover over a logo to figure out what the platform is, but when they see two of the same logo (e.g. Minecraft: Story Mode), they’ll definitely be confused. Visitors are catered far more than editors, and I am speaking on behalf of the wiki visitors that having two of the same logo will indeed cause confusion, and may imply that it’s only available on the Microsoft Store on Windows, of which the Java Edition and Minecraft Dungeons definitely aren’t. Story Mode is different in the fact that it’s both on Steam and the Microsoft Store, but having two of the same logo there will make visitors confused.
In addition, I’m surprised that the editors have decided to act on changing the logo with one person in support, all prior to this discussion taking place. Just complete bull. -BDJP (t|c) 12:09, 19 June 2019 (UTC)
Now tell me, how will reverting the logo to Windows 7 help people differentiate between the Windows 7 and Windows in general? Even if there's no other Windows 7 logo on the page other than {{OS|win}}? You can't just assume that people will consider the Windows 7 logo as the universal Windows version, so to prevent this it's best to just change the logo to other versions that are different both from the Windows 7 and Windows 10 logos, if you are only opposing the derivative from Windows 10 logo, what about this, is this any better than the previous? – ItsPlantseed|⟩ 12:27, 19 June 2019 (UTC)


”Now tell me, how will reverting the logo to Windows 7 help people differentiate between the Windows 7 and Windows in general? Even if there's no other Windows 7 logo on the page other than {{OS|win}}?”
Look at the infobox in this revision; it clearly shows why the Windows 7 logo needs to be used.
And yes, I am fine with the commons logo you just showed. Windows 10 in terms of aesthetic, but Windows 7 in terms of look and design. 👍 -BDJP (t|c) 12:40, 19 June 2019 (UTC)
Personally I think that the infobox on the page you referenced should've just used one logo, the Windows in general. Since the row itself says the platforms it runs on, not the place where it's on sale (such like Windows 10 logo as Windows 10 store). I still think that it should be changed to a version that uniquely represent all the Windows versions (for instance like stacking Windows logos), but I've no further suggestions as for now. – ItsPlantseed|⟩ 12:50, 19 June 2019 (UTC)
This ^ . The infobox is showing which operating systems the game runs on. For both Bedrock and Java, it runs on Windows. Use the generic current Windows logo.
If we were a soft drink wiki and were saying something about Pepsi being available at a specific ballpark, let's say, we wouldn't use an old logo, we'd use the current one representing the Pepsi company / product in general - the visual brand that's seen as current by the company and by the public. To use an older logo is out of sync with what ballpark visitors or wiki site visitors are familiar with in most every other current context (for Pepsi or Windows or whatever). Just as the beverage site wouldn't say "Ballpark X serves Pepsi (2014-2019)" but rather "They serve Pepsi," so too should we say "This game runs on Windows."
Unless we're documenting something that only runs on older versions of an operating system, it makes no sense to me to differentiate specific iterations of that operating system. So I  Oppose the original proposal but support replacing the logo in the infobox with the current generic Windows logo and doing away with release-specific operating system logos (i.e., Windows 10) unless there's a need to identify a particular op-sys. This has nothing to do with differentiating versions / editions of Minecraft, as far as I can see. That's a separate issue. Memetics talk | edits 04:09, 20 June 2019 (UTC)
Just throwing the idea out there, why not use the "current" logo and add the text "7 or above"? FVbico (talk) 11:20, 20 June 2019 (UTC)
 Oppose; not the logo for Windows 7, and the text would be too small. -BDJP (t|c) 11:31, 20 June 2019 (UTC)
Who said I meant in the image itself? Also that it's not windows 7 is the point, it's not 7 exclusive, it's just the latest logo of the OS, as Memetics explained in the comment chain above. FVbico (talk) 11:33, 20 June 2019 (UTC)
“it’s not 7 exclusive”
The feeling of exclusivity is what I’m trying to avoid by having the old logo. If the Windows 10 logo is used, then visitors will assume that it’s only for Windows 10. -BDJP (t|c) 12:09, 20 June 2019 (UTC)
Maybe use this logo instead? [1] Modern logo geometry with the old logo color scheme. --AttemptToCallNil (report bug, view backtrace) 12:22, 20 June 2019 (UTC)
Was already shown in a reply above (I opposed to that one but supported this one). -BDJP (t|c) 12:31, 20 June 2019 (UTC)
The thing is, when we're trying to represent windows as a whole, we should not use any existing windows logo that is used for a specific version of the OS. Because that will always mislead the reader to think it is exclusive to that version, whichever version that may be, even if it is for the newest version. I'm not sure if there is a non-version specific logo for windows, but if there is, try that one. That is the whole point of this discussion, to find a logo that is not version specific. I don't know whether any of the above suggestions are used for a specific version or not, I'm just describing what we're looking for. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 13:53, 20 June 2019 (UTC)
No; using the Windows 7 logo will show to visitors that its for all Windows versions (we've never had any issues with it up until now), while using the Windows 10 logo will show to visitors that its exclusive to Windows 10 only. -BDJP (t|c) 14:33, 20 June 2019 (UTC)
I've made a mockup of what I had in mind some time ago here: File:Jack McKalling icons.png. I post this here and immediately retire from this discussion. You guys will have to solve this problem yourselves, I tired out. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 16:50, 20 June 2019 (UTC)
 Oppose per BDJP. 14:23, 24 June 2019 (UTC)
 Strong Oppose as having the Windows 10 logo will cause massive confusion among readers in pages such as Story Mode and Dungeons. I regularly view these pages from time to time and when I saw that the logo was changed, I was already confused as to whether the games were exclusive to Windows 10 or not, in which I had to literally search it someplace else to know that they were not exclusive to Win10. 19:57, 24 June 2019 (UTC)
How is that confusion any different than if a Win7 logo is used? Microsoft uses the Win10 logo to denote "Windows" in general; using a random old logo doesn't show that it runs on most computers. Win10 is the recommended system requirement of all these games; it's just supported on older platforms. – Nixinova Nixinova sig1.png Nixinova sig2.png 20:11, 24 June 2019 (UTC)
For the main page, I would support keeping the updated Windows logo (Windows.svg) in the Java Edition launcher section; for the Bedrock and Education edition sections, perhaps the icon could be similar to File:Windows 10 Mobile icon.svg (where the Windows logo is displayed with the text "Windows 10" or "Win 10" under it). –Sonicwave talk 00:16, 25 June 2019 (UTC)

Proposed compromise[edit]

For a start, I’m not really good at compromises, but this honestly just popped into my head right before I started typing.

The proposed compromise is as follows:

  1. The logo stays as the Windows 7 logo for as long as possible on all Java Edition related pages / sections. If and when Windows 7 is no longer supported as a minimum requirement for Java Edition is when the logo should be changed immediately to the Windows 10 logo or some other derivative (e.g. Windows 8).
  2. The logo stays as the Windows 7 logo for both Story Mode pages indefinitely. This is because the system requirements for both Story Mode games mention Windows versions older than 10, and also for the fact that Windows 10 versions of these games have been released separately.
  3. The logo stays as the Windows 10 logo for Dungeons until system requirements for the game are released. If the system requirements show that the game will support Windows 7 and later, then the logo should be changed to said logo (and also for the fact a Windows 10 version might be released separately).

-BDJP (t|c) 05:16, 25 June 2019 (UTC)

That's not a compromise, and I see you trying to sneak this change into the main page recently. Windows 7 is such an old system now that people hardly recognise it as representing "Windows" itself. Microsoft has pushed Win10 so hard and the Win10 logo is everywhere, and is the official logo for the Windows brand. There's no reason to confuse people by listing old supported versions.  Nixinova T  C  01:39, 6 November 2019 (UTC)
Yeah, like Nixinova said, this isn't a compromise. This is just what you want. The Win10 logo should be used everywhere where Win10 can be used, only using older logos when Win10 is actually not supported. Using a logo that was deprecated in 2012 makes no sense. And even aside from it being directly linked to Win10, that logo has come to represent the Windows brand as a whole, not just the specific version.
BDJP has been the only strong voice of opposition aside from a couple IPs. Everyone else who's disagreed has at least wanted to use the new logo in some capacity. I think it's time we close this discussion, and, if needed, open up a separate discussion on how we what variation of the Win10 logo to use (subtitle, colors, etc.). -PancakeIdentity (talk) 06:14, 15 November 2019 (UTC)

Is "NBT tag" redundant?[edit]

FVbico and I disagreed on Discord about whether the phrase "NBT tag" is redundant because "NBT" is an initialism for "Named Binary Tag". FVBico suggested making edits to change the phrasing so that it's grammatically correct when you substitute the expanded name in the sentence, and opined that we should do so globally on the wiki. I think that's unnecessary and even harmful in some cases. We agreed to bring the discussion to the community.

In my opinion, NBT is an initialism that has become a word with its own denotation, something that popular initialisms do frequently (often even losing their original association with a phrase, as happened to "snafu" and "radar"). When we read such an initialism, we don't ordinarily translate it into the expanded phrase, but rather conceive of it as an independent thing. It functions as a noun in a sentence (even when the original wasn't a noun phrase, e.g. "snafu"), and therefore it shouldn't be judged grammatically as if the expanded phrase were substituted for it. In the specific case of NBT, we conceive it as referring to a method of coding, not to an individual tag as the expanded phrase would suggest. I leave it to FVBico to present his point of view, obviously. – Auldrick (talk · contribs) 17:31, 11 January 2019 (UTC)
 Yes, it is redundant; it's an instance of RAS syndrome like "ATM machine". Both of these should be avoided IMO, because of the redundant expansion. --Pokechu22 (talk) 17:35, 11 January 2019 (UTC)
I would point out that the cited Wikipedia article contains a refutation by author Bill Bryson, who says "only the ultra-finicky would deplore them". – Auldrick (talk · contribs) 17:46, 11 January 2019 (UTC)
I agree with Auldrick. Yes, it's redundant, but  No, it's not necessarily a bad form of redundancy. --AttemptToCallNil (report bug, view backtrace) 17:48, 11 January 2019 (UTC)
My opinion on the matter is that "NBT" could be seen as a short form of "NBT Format" which is a short form of "Named Binary Tag Format". In "NBT tag", the "NBT" doesn't mean the tag itself, but the format in which the tag is saved. (At least that's my interpretation of that.) I think using "NBT" instead of "NBT Tag" everywhere will make it more difficult to understand what's actually meant. Then again, you could just use "tag" instead of "NBT tag", but there are so many tags in Minecraft that this could get confusing as well. That's the reason why there's the "NBT" in front of it, so that you actually know what kind of tag it is.
TL;DR: my opinion would be  No | violine1101(Talk) 20:05, 11 January 2019 (UTC)
Just elaborating here, as already stated, "NBT tag" is a form of RAS syndrome, and the term is not short for NBT Format, but actually just "Named Binary Tag", as stated on the wiki as well. The "NBT tag" when referring to the name of a variable can easily be changed to use "key" instead, as string NBT (as in when used in commands) is actually derived from JSON format, which is key: value pairs, which is exactly the same in NBT, even block states are adressed this way, key=value pairs; when referring to the whole key:value pair, it can simply be called "the NBT". So any mention of "NBT tag" can actually easily be changed to not have RAS syndrome, while not making it hard to understand, and naming it "NBT tag" is bad grammar. FVbico (talk) 20:50, 11 January 2019 (UTC)
So you think we should say things like "NBT key" and "NBT value"? --AttemptToCallNil (report bug, view backtrace) 20:53, 11 January 2019 (UTC)
It would be equally clear, if not even more clear, and be grammatically correct. FVbico (talk) 20:58, 11 January 2019 (UTC)
Clarifying, I did not say that "NBT" is short for what Violine calls "NBT Format", but that it denotes it. The difference is important. Furthermore, redundancy isn't a grammatical issue, it's a style issue. Grammar is concerned with structure, not meaning. Grammatically, "NBT tag" is an ordinary attributive noun phrase. – Auldrick (talk · contribs) 21:18, 11 January 2019 (UTC)
Being a non native English speaker I still feel "NBT tag" is a little redundant, and that just using "NBT" is not precise enough. I would opt for doing "NBT data" or "NBT key/value", as it feels correct without loosing its meaning if expanded. Holroy talkcontribs 23:38, 11 January 2019 (UTC)
I was thinking of that exact solution as well. Fully agreed. – Jack McKalling [ Talk Contrib ] 09:17, 13 January 2019 (UTC)
But without disagreeing with Holroy here, I wanted to add/clarify that "NBT" isn't an accurate acronym for what it actually means. It stands for something what the format contains many instances of, which isn't a really good name for a format. However, using the acronym as an adjective to any noun like in "NBT tag", will have the same meaning as if you were just calling it a "Mojang tag", as it has nothing to do with what the acronym stands for but is just a plain adjective trying to differentiate what kind of tag this is. So there is an ambiguous meaning here to begin with. Although I feel this "tag" differentiation is more important than it is meaningfully common for someone to actually know what the acronym stands for, because of the many, many different kinds of "tags" that are there already, a different phrasing altogether would be best. – Jack McKalling [ Talk Contrib ] 00:13, 15 January 2019 (UTC)
Any further opinions? If not, this discussion kind of hit a dead end with support and opposes being balanced out.
To everyone who opposed, what do you think about replacing it with "NBT key/value" when referring to the tag name or value, and "the NBT" when referring to the full pair? FVbico (talk) 13:33, 7 March 2019 (UTC)
Although I, too, find the redundancy slightly annoying (similar to "PIN number"), I feel that this is an instance of needing to honor and record the term that the Minecraft community commonly uses, rather than risk creating confusion by trying to change it. Let it remain QWERTYed into the lexicon. Memetics talk | edits 10:41, 28 April 2019 (UTC)
I support "NBT key" and "NBT value", but not "the NBT" because I think that's more confusing. Given you propose to use this to refer to a full pair, I propose using "NBT pair" instead. However, I'm not that proficient with Minecraft technical terminology, so this term may be inaccurate. --AttemptToCallNil (report bug, view backtrace) 20:29, 20 May 2019 (UTC)
I can agree to that. FVbico (talk) 20:40, 20 May 2019 (UTC)
NBT tag is redundant, however, I think it has been used to such extend now, that this form of RAS syndrome has literally been petrified. Changing it now to something different would, in my opinion, raise eyebrows. This does not take away that I'd support NBT key for the tag's name and NBT value for the tag's value and NBT data for a set of NBT tags (or should I say a set of NBT key/value pairs? {so lengthy...}).
In short, NBT tag is a form of redundancy, however,   this expression has become petrified and thus I no longer consider it a redundancy. If you want to use other expressions than NBT tag, be my guest, but don't be surprised some eyebrows are raised. —DarkShadowTNT (t ♦ c) 20:54, 20 May 2019 (UTC)
Oh yeah, "petrified". 🙃 --AttemptToCallNil (report bug, view backtrace) 21:17, 20 May 2019 (UTC)
Giving 1 more bumb.
I'd like to see the title of this discussion changed to match more what I actually suggest to be done (avoid it, rather than declare it redundant).
Just stating again what I'd prefer: NBT key, NBT value, NBT pair and NBT data for the tag name, tag value, key and value, and the total set of all NBT resprectively. This to avoid NBT tag, as it is used to refer to all but the last one. FVbico (talk) 10:08, 2 October 2019 (UTC)
I like and  Support this suggestion. -PancakeIdentity (talk) 23:36, 16 November 2019 (UTC)
 Support using "NBT value", as this distinguishes a single value from, for example, the entire NBT data of a block entity. We can use "NBT data" when referring to multiple values (e.g., an entity's NBT data) which we currently label as "NBT tags". The BlobsPaper.png 01:05, 17 November 2019 (UTC)

User pages[edit]

On the topic of cleaning up the wiki: it seems a lot of pages belonging to inactive users link to either a lot of relatively useless and outdated redirects, or straight up redlinks and missing files. Could we have the option to outright blank inactive userpages (I'd say before January 1, 2017 would be a reasonable cutoff date), removing these redlinks in the process, and possibly including a template on the page stating the action taken (similar to the box placed on inactive user talk pages)? Of course, if the user ends up returning, they can revert this blanking at will, hopefully fixing up their page in the process as well.

The only main concern I have regarding this is userpage images; removing these from the page would result in them possibly being linked to from nowhere, and would likely result in their deletion, which may be undesirable. Might be prudent to keep such images linked somehow, for example in a gallery, for their preservation, although this might not be the most visually desirable option. - User-12316399 (talk) 11:55, 29 January 2019 (UTC)

 Support, and the gallery could be wrapped in a display: none div which will render it invisible, but keep the images "used" from the engine's perspective. --AttemptToCallNil (report bug, view backtrace) 12:03, 29 January 2019 (UTC)
I've went ahead and created Template:InactiveUserpage. I might pop it on a few of the more notorious pages later on. - User-12316399 (talk) 08:59, 30 January 2019 (UTC)
I don't see any reason to avoid performing basic maintenance on userpages such as updating/removing links to pages that have been renamed or deleted. I have no objections to simply blanking old userpages when the user hasn't edited for some time (I do it myself on another wiki I edit regularly), but I do think it should be left to the discretion of the editor performing the cleanup whether they want to just blank the page, or take the time to actually fix the issues with it (though on the gripping hand, I'd be surprised if many people chose not to blank, since blanking is much easier and faster). ディノ千?!☎ Dinoguy1000 11:18, 30 January 2019 (UTC)

Considering changing the cutoff date to August 1, 2018 (from January 1, 2017); this will cover all userpages created before the Update Aquatic and therefore before the removal of numeric IDs. Any objections? - User-12316399 (talk) 22:33, 14 May 2019 (UTC)

Not sure if this is still relevant but seems good,  Support. -PancakeIdentity (talk) 02:12, 22 November 2019 (UTC)

Clock circuit, Logic circuit, Pulse circuit, Memory circuit, Transmission circuit[edit]

Should these pages really be at the location they're currently at? The scope of these pages makes me feel as though these would all be much better as subpages of Tutorials, rather than as top-level mainspace articles. - User-12316399 (talk) 12:30, 12 March 2019 (UTC)

 Weak oppose. According to MCW:NOTABILITY, "Gameplay strategies, guides, how-to's, etc., should be subarticles of Tutorials." The redstone articles are more like a encyclopedia than most tutorial pages. Tutorial pages are usually aimed more at readers wanting to construct something rather than to learn about something. That doesn't necessarily mean they couldn't go under tutorials though. jahunsbe (talk) 13:30, 12 March 2019 (UTC)
 Oppose. But I agree at the same time, that they're not right in their current state. These pages are not tutorials in the same sense of the word like the other tutorials. They are indeed more about documenting something rather than guiding you through something. These pages are documenting game mechanics, and are using a completely different tone than any other "tutorial". Similar to enchantment mechanics, which has been (in my opinion) erroneously moved to a subpage of Tutorials. I bet there are more examples of this, like anvil mechanics, village mechanics. You can see the pattern here. In my opinion we should rather be looking for a new top level page, like Mechanics (for game mechanics, redstone mechanics, anything about not specifically one particular game object), next to the tutorial one, and then move all these pages as a subpage of that instead. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:57, 12 March 2019 (UTC)


So I propose the following page structure. There may be more pages that should belong in here but I just listed some examples, you may add more if you know of any. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:01, 26 April 2019 (UTC)

If what Jack's suggesting is that Mechanics is its own section, not part of Tutorials but on the same level as Tutorials, then I  Support . Memetics talk | edits 05:58, 27 April 2019 (UTC)
Yes that is what I'm suggesting. Currently the Mechanics page redirects to a really old and outdated subpage of Tutorials, and is not the kind of page I was thinking about. I didn't link it for the reason that I'm thinking of a completely new page, similar to Java Edition guides. That one, this new Mechanics page, as well as the Tutorials page, in this proposal, would all be top level pages that provide a neat overview of all their subpages. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:20, 28 April 2019 (UTC)
 SupportNixinova Nixinova sig1.png Nixinova sig2.png 06:26, 27 April 2019 (UTC)
 Looks fine to me - when will we be getting round to doing this? - User-12316399 (talk) 08:47, 1 October 2019 (UTC)
If nobody complains I'll start moving these pages to their proposed destinations in around four hours. - User-12316399 (talk) 09:13, 8 October 2019 (UTC)
I've went ahead and moved most of them. Should Tutorials/Piston circuits also move? I'll see if there's any others that could potentially be moved and list them here. - User-12316399 (talk) 13:20, 8 October 2019 (UTC)
Yes, definitely also move Mechanics/Redstone/Piston circuit. There are some tutorial subpages that might be a better candidate for Mechanics too, but in all those cases they would need to be rewritten so lets leave those where they are for now. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:33, 10 October 2019 (UTC)

Continuing with the process of rearranging the pages in favour of the "Mechanisms" umbrella subject, I've marked the current "main" Mechanisms page as requiring attention. Namely, it is currently a redirect to a sort of unrelated tutorial page, however the redirect page should in my opinion be repurposed to displaying an overview of all kinds of mechanisms that are now subpages of it, with possibly a section for somewhat related tutorial links. This way the subpages would make sense, as their top level page shouldn't be redirecting. Also, I've similarly marked the Dyeing page for requiring attention, seeing it currently cannot be moved yet due to the above linked discussion for it. Lastly, the Redstone subpage hasn't been made yet, eventhough we've subpaged it with all the circuit pages. It would be a good idea to add some overview content to that sub-main page as well. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:49, 10 October 2019 (UTC)

Reversion of the proposal[edit]

Besides the wiki's consistent insistence on mistreating tutorials (by rejecting both a custom content namespace or, if at all possible, placing them in the main namespace with no prefix), I strongly believe this proposal is similar, has no merit and must be reverted.

At no point is ever any substantial reason for tutorial grouping is provided (policy is not an argument as it is the thing being questioned).

No strong arguments (i. e. beyond opinion and personal preference) have been provided in favour of the mechanics proposal. Arguments against such grouping are problems with searchability (no search bar suggestions, potentially SEO issues as well) and overcomplication of page structure. You have categories for technical and queryable grouping, you have the ability to create a hub page which is not a superpage, and you have the ability to request custom namespaces to be created if nothing else serves your means.

You will definitely have to create mainspace redirects to tutorials and mechanics pages in this structure to avoid searchability issues (but potentially incur new issues with search engines - not an expert, but from what I know their page scoring algorithms are rather unpredictable and often counterintuitive). At this point you might as well put articles there.

Why not group blocks, items and mobs? While with tutorials you had the irrelevant excuse that they do not describe game content, alleging to a defined (in reality, unspecified) aim of the main namespace, mechanics are actual description pages.

P. S. Proponents' insistence on that my arguments must not be considered because I allegedly had half a year to "find" this discussion and participate in it are disgusting. --AttemptToCallNil (report bug, view backtrace) 20:32, 13 October 2019 (UTC)

I oppose the current proposal, but I would support moving them to something like Villages/Mechanics (for example). It keeps these pages better tied to their parents, is much more clear, and could help with the accessibility issues by having them clearly linked on their main pages. One problem with the current proposal is that simple redirects don't work. You can't just have Village redirect to Mechanics/Village, as the main village page is still used. -PancakeIdentity (talk) 20:40, 13 October 2019 (UTC)
Thanks for you guys' imput. Sad it was late, sorry that this caused frustration, but better late than never. This is yet another case where the com portal's function failed. Please understand your feedback is and will always be welcome, regardless of frustrated reactions. Anyway, I too am not an expert in SEO/searchability/redirects. I should have provided arguments for my proposal though. I've participated in the tutorials discussion too, and because you and others opposed to namespaces, I didn't again suggest it here. However these pages do share similarities with the tutorials, and I wanted to address that. Although I didn't start the discussion, I did have the very same idea before and had clear ideals. I'd gladly hear any other proposals, because my main point is and will be, these pages aren't following the proposed article structure as suggested by the style guide, and this has to be addressed in some way. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 21:06, 13 October 2019 (UTC)
I think you had the right idea, but I disagree with the details. I'd propose moving the mechanics to pages like Village/Mechanics, Trading/Mechanics, etc. I would also propose moving the redstone circuits to something like Redstone/Circuits/X. –Preceding unsigned comment was added by PancakeIdentity (talkcontribs) at 22:52, 13 October 2019 (UTC). Please sign your posts with ~~~~
I would actually support that far more than "Mechanics/Village", etc. I believe it is more meaningful to have the mechanics pages be structurally/logically dependent on the thing mechanics of which are described than on the concept of mechanics. I might actually support the same with tutorials, like mob farming and combat tactics as subpages of corresponding mobs, and e. g. "Cactus/Farming". --AttemptToCallNil (report bug, view backtrace) 23:50, 13 October 2019 (UTC)
This proposal of PancakeIdentity & ATCN makes sense to me; I support that scheme. Memetics talk | edits 07:30, 26 October 2019 (UTC)
Here's the fact. Tutorials are community-made guides that guides you in the game. They are never official guides by Mojang or in the game. Logic gates, redstone circuits are all community-made concepts, they're not coded into the game. Mechanics in the other hand such as enchantment mechanics are mechanics that are coded in the game. I can't think of a good proposal, but I'll  Support PancakeIdentity because it makes much more sense.--skylord_wars (talk) 16:36, 28 October 2019 (UTC)
I would also support making them subpages when available.  Nixinova T  C  01:45, 6 November 2019 (UTC)
Great, I also like this proposal better than mine. It's good to have consistency, and giving each article that has specific mechanics its own /mechanics subpage makes sense and keeps these related and close together. I agree that is better than keeping all mechanics subpages together instead. Now that I've seen the latter in action in page titles and links, it doesn't even look right after all anyway. For readers it makes more sense to go from for instance "village" to "village/mechanics" than to "mechanics/village", because it's a completely separate top level page. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 15:15, 11 November 2019 (UTC)
 Support moving pages to Mechanics/x and having redstone circuits as tutorials, per the arguments described above. I am wondering if, for example, the Village page should transclude its mechanics page using {{LoadPage}}. The BlobsPaper.png 23:06, 5 January 2020 (UTC)
 Support moving mechanics pages to the Village/Mechanics format for reasons given above. I'm not sure about tutorials though, since there are some tutorial topics that don't have a clear root article (e.g. Tutorials/Tips and tricks) and they tend to contain more subjective information than regular articles. We could add a template to the top of all tutorial-style articles to inform readers that the article is a tutorial or has community-made content. –Sonicwave talk 01:35, 5 February 2020 (UTC)
I've gone ahead and  Moved the village, enchanting, and anvil pages to the format "X/Mechanics" because I feel like there's a pretty clear consensus to do so.
I'm not clear on what needs to be changed about Trading and Dyeing, because if these two pages were moved as is, neither would have a base page. For trading, are we suggesting that it should be moved to Trading/Mechanics and have Trading redirect there? If so, that seems unnecessary and by that logic, the enchanting, brewing, and smelting redirects should exist only as redirects to their mechanics subpages. And for Dyeing, dye is actually a collection of items in the game so moving that makes even less sense; is the suggestion to split the dye page into one article about the items themselves and another about the mechanic?
I haven't moved the redstone pages yet because I don't think it's clear yet from this discussion whether they should be mechanics subpages of Redstone or tutorial pages.--Madminecrafter12 (Talk to me | View what I've done) 15:22, 5 February 2020 (UTC)
I see no reason to enforce a pointless redirect scheme for the sake of ensuring page relation consistency. If the mechanics are not descendants of a base something, they are a base something. Support leaving the above as is (without any moves or redirects). --AttemptToCallNil (report bug, view backtrace) 15:33, 5 February 2020 (UTC)
Yeah, that's what I was thinking.--Madminecrafter12 (Talk to me | View what I've done) 23:35, 5 February 2020 (UTC)
Re:dye; I think that was the idea. I would support just having a "Dyeing" page and no mechanics subpage. -PancakeIdentity (talk) 05:08, 6 February 2020 (UTC)
About the redstone pages, I  Support having them be subpages of redstone rather than tutorial pages. Putting them under redstone keeps them all better organized in one place. It would, however, probably be helpful to have links to the pages in Tutorials and maybe Template:Tutorials. I think the "Redstone/Circuits/X" format mentioned above would work well with Circuits having a list of subpages. jahunsbe (talk) 15:11, 10 February 2020 (UTC)

"Raw materials" and "manufactured" classifications on item pages[edit]

The concept of "raw materials" is mentioned at Template:Items, Item#Raw_materials, and Category:Raw materials; however it doesn't appear to be a distinction made in-game. Each page also categorizes items differently (Template:Items lists glass bottles and sticks as raw materials, while the Items page puts them under manufactured).

The Items page has "Raw materials are used for crafting, brewing, and smelting other items and blocks.", but that can include anything that's used in a recipe, such as bows being used to craft dispensers. The category page says "Raw resources in Minecraft used to create other resources", which is also somewhat vague.

In my opinion, the "raw materials" classification should be defined better if we decide to keep them in the first place. I'm thinking something like "Items and blocks used for crafting, brewing, and smelting other items and blocks, and are not themselves craftable or smeltable", which would exclude things like bows. However I'm not sure if "raw materials" or "manufactured" is necessary in the first place. Many other items that fit into either category (e.g. green dye or arrows) are placed in more specific categories instead, leaving only 10-20 items in the "manufactured" category. There could simply be a "miscellaneous" category instead, which might be less confusing. –Sonicwave talk 22:20, 4 April 2019 (UTC)

Support removing the concept of "raw materials". Doesn't make much sense given a lot of very different things can become "raw materials", and the common definition for the class seems arbitrary and useless: what really depends on whether an item is a "raw material" or not? --AttemptToCallNil (report bug, view backtrace) 19:56, 5 April 2019 (UTC)
 Support Several months ago, I proposed replacing several of the item classifications, including raw materials and manufactured, and with a simple list of all items. I think they are unnecessary and have vague definitions. So I would support just about anything that involves removing item classifications. an_awsome_person (talk) 00:54, 6 April 2019 (UTC)
 Support removal of both raw materials and manfuactured classifications. -BDJP (t|c) 03:51, 9 April 2019 (UTC)
The method we should go with is automatic categorisation based off values in the infobox, e.g. add [[Category:{{{type|}}}]] to {{Items}}. That would be easy to deal with and less vague. – Nixinova Nixinova sig1.png Nixinova sig2.png 04:02, 9 April 2019 (UTC)

There does not seem to be any reason we can't go ahead with disbanding that category. No objections and no arguments against, with substantial arguments for it. Anyone up for the task? --AttemptToCallNil (report bug, view backtrace) 21:55, 8 April 2019 (UTC)

Could also get rid of passive/neutral/hostile mobs classification while we're at it... --AttemptToCallNil (report bug, view backtrace) 22:11, 8 April 2019 (UTC)
Can we remove block classifications (plants, mechanisms, utility, etc.), too? an_awsome_person (talk) 15:36, 20 April 2019 (UTC)
 Support - and I support replacement of hostile/neutral/passive with expanded overview text instead. Also block classifications, unless someone has good reasons why they should be kept. Memetics talk | edits 11:22, 28 April 2019 (UTC)
I don't think I can edit the infobox templates, but can I remove the classifications on the block and item pages? I want to replace them with a table of all blocks or all items, like what I have on my user page right now. an_awsome_person (talk) 17:35, 28 April 2019 (UTC)

Since the parameter is now removed, could a bot be made to remove it from all of the pages that it still currently exists on (as well as other deprecated parameters, namely gravity=, dirt=, and sunlight=)? - User-12316399 (talk) 09:22, 8 October 2019 (UTC)

Voiced over pages[edit]

Bit of an odd proposal, but what if we added voice overs for pages? Wikipedia has something similar to this with the "listen to this article" feature, and I'd figure it be good for accessibility reasons. (if it's already added, feel free to let me know) ggtylerr (talk) 11:17, 17 April 2019 (UTC)

I'm not against it, but I don't really see how it's valuable. The corresponding wikipedia project is neat, but for accessibility at least I don't think it matters too much since screen readers (e.g. the narrator thing built into windows) exist and we don't use much in the way of special characters that it might break. IMO, the old video overviews of article content are more useful, just because they could also illustrate what's going on. (Of course, I myself just really prefer text to speak, since I can skim over text much faster. So I'm biased.) --Pokechu22 (talk)
It's my understanding that modern text-to-speech readers also benefit from the use of multi-level headings, which enables the user to navigate the page (the reader reads aloud the index of headings). Without headings, the person has to listen to the entire page to find what they're looking for. Much better to skim through the headings first. Memetics talk | edits 11:25, 28 April 2019 (UTC)
Screen readers are in no way superior than anyone who would devote their time into making a decent voiceover of an article. Artificial intelligence as of now canʼt understand the articleʼs topic and structure and will inevitably make errors. Also, some info best presented as text will have to be changed to fit for audibility. Iʼm not against the idea, but may it be worth the effort? Might be worth a try though. — BabylonAS ru.Wiki Admin 06:51, 3 August 2019 (UTC)
How about more updated/accurate videos? :3 Marinah (talk) 17:27, 17 April 2019 (UTC)
Thatʼs a way harder thing and surely not worth the effort. Updating voiceovers is much easier if organized properly. — BabylonAS ru.Wiki Admin 06:51, 3 August 2019 (UTC)

Present or past tense in lead section of a version release?[edit]

Recently the Java Edition 1.14 and other versions' pages were modified to switch the tense of the lead section to the past. But I don't agree with this. I'm convinced the text about what the update does should be present simple perspective, and just the release date part of it in the past. Because only the release of an update lies in the past, everything else about the update is present. Anyone can choose any version of the game to play at anytime they want, using launcher profiles, so it doesn't make sense to force the contents of an update to reside in the "past", it will confuse the perspective even if it is supposedly in a player's present or even future. Present simple is the default for this. For example, in my opinion it should be phrased like:

1.14, the first release of Village & Pillage, is a major update to Java Edition that was released on April 23, 2019. It focuses mainly on villages, adds (...)

Just because the update happened in the past, doesn't mean its content is as well. It is a product that is still available right now, and so is its content. Like a car, it may have been designed in the past, but it can still be bought right now. Pinging Nixinova, as you were involved in this edit (series). – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:31, 25 April 2019 (UTC)

Present tense for me. The argument that it shouldn't use present after it released is wrong, since it should be in future tense until it releases ("will add", "will focus", etc) if not present. Past tense just seems silly. --Pokechu22 (talk) 15:51, 25 April 2019 (UTC)
Present if the version of the game is currently accessible and playable (e.g. through the launcher). If we're talking about a future update, then we use future tense, and if the version is lost/unavailable, past tense. - User-12316399 (talk) 16:00, 25 April 2019 (UTC)
Do you both then also agree that the part about the release date should always be past tense though, unless of course it hasn't happened yet? – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 16:02, 25 April 2019 (UTC)
"1.14 is an update to Java Edition that was released in 2019." That does make sense, so it should be past tense if is/was is present and referring to a past date. - User-12316399 (talk) 16:28, 25 April 2019 (UTC)
Yeah, the release date should be in past tense, "was released", and anything directly related to the release probably should be too; however attributes of the update itself should be present IMO. The closest example elsewhere I can think of is television episodes — pulling up a random one from wikipedia (Gridlock (Doctor Who)), with present tense in blue and past tense in red:

"Gridlock" is the third episode of the third series of the British science fiction television series Doctor Who, which was first broadcast on BBC One on 14 April 2007. It was written by Russell T Davies and directed by Richard Clark.

The episode is set five billion years in the future on the planet New Earth, a planet humanity settled on following the destruction of the Earth in the 2005 episode "The End of the World". In the episode, alien time traveller The Doctor (David Tennant) and his new travelling companion Martha Jones (Freema Agyeman) discover the remainder of humanity on the planet live in perpetual gridlock within the Motorway, a highway system beneath the city state of New New York. When Martha is kidnapped, the Doctor races to find her before she enters the dangerous "fast lane".

Wikipedia on Gridlock (Doctor Who)
I think the same style makes perfect sense here as well. --Pokechu22 (talk) 19:10, 25 April 2019 (UTC)
Present per Pokechu22. -BDJP (t|c) 16:05, 25 April 2019 (UTC)
Past. The update is in past tense—the version isn't being "updated" anymore—but if you then say "1.7 is a version of Java Edition" that is fine. It also doesn't make sense to have one word in present tense while the rest of the paragraph is in past. "1.x was an update to Java Edition released on x y z that added a b c d and e" reads better than "1.x is an update released". – Nixinova Nixinova sig1.png Nixinova sig2.png 19:51, 25 April 2019 (UTC)
The difference between version and "update" is irelevant in my opinion here, as we're documenting the version of the game anyway. How it works, how it looks, what it has, what it does, and what it thinks, if that were a thing. In other words, the page is describing the product, not the event. For the reason that readers will be reading and interpreting it as a version of the game, and not as a point in time when stuff happened. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 19:58, 25 April 2019 (UTC)
present per Pokechu's example, as that's exactly how I understand the tense of iteratively released content which remains available. – Sealbudsman talk | contribs 22:09, 11 May 2019 (UTC)
Why haven't we reached consensus yet about this? Nixinova, you're the only one so far who wants to put everything in past tense. In my example above, I'm using past tense for the date-related aspect of the update, and put the content it contains in present tense. This is what I think is the best way, and all others who have replied to this discussion so far. Do you have any argument against this suggestion other than your preference? – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:57, 1 June 2019 (UTC)
I still prefer past tense. 1.4.2 was a major update to Minecraft (Java Edition) released on October 25, 2013, which added a number of new mobs... reads much better than 1.4.2 is a major update to Minecraft (Java Edition) that was released on October 25, 2013, which adds a number of new mobs.... When you say "update" you think of something new – this update occured many years ago, and as such using past tense sounds better. – Nixinova Nixinova sig1.png Nixinova sig2.png 08:04, 1 June 2019 (UTC)
How about we don't call it "update" but just "version"? Would you then agree on the tense used in my suggestion above? You're completely ignoring the argument that the content of a release is not exclusive to the past, but is still available. Keeping all content described as happened in past tense is confusing some people and we need to address that. Your argument is purely your own preference, and I can't think of a different way to address that too. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:22, 1 June 2019 (UTC)
Grammatically, the correct construction was illustrated by Pokechu22 in the Doctor Who example, which shows the use of past tense for things that happened as an event at a point in the past but are not still happening in the present, and present tense for things that still exist in the present (exactly as the grammar of this sentence you're reading demonstrates). So it just depends on what we're saying. It works in both contexts for a specific version of Minecraft: The version was released at a specific point in the past, and it is a playable version of the game in the present. The game was designed in a specific way, and it is fun to play.
To take Jack's example specifically: To say "1.14, the first release of Village & Pillage, was a major update to Java Edition that was released on April 23, 2019. It focused mainly on villages, [...]" grammatically means that it no longer is a major update to Java edition and that it no longer focuses mainly on villages (etc.), neither of which is true.
Using the correct tense is a matter of accuracy of expression, therefore, as well as of following the conventions of formal written English, so I don't think this can be considered an opinion-based discussion (unless we're of the opinion that we should make inaccurate statements or violate general linguistic conventions for some specific purpose). Memetics talk | edits 07:17, 13 June 2019 (UTC)
That's not my example, you switched it around. Are you saying what I wrote was the correct one, seeing it follows the same construct as the Gridlock example? I'm confused. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:25, 13 June 2019 (UTC)
I was not saying what you wrote was correct; I believe I was using your example as the starting point but applying past and present tenses to illustrate how the incorrect tense causes problems and to show which tense is grammatically and factually accurate in the various contexts. Thought I explained this sufficiently in the previous post; sorry if the wording in how I introduced those examples was confusing. Memetics talk | edits 07:27, 26 October 2019 (UTC)
I'd say this topic reached a pretty good consensus. We really only have one person opposing this. Do we have the go-ahead to change pages to reflect the same the present tense style (per Pokechu22 and Memetics's examples)? -PancakeIdentity (talk) 02:45, 21 June 2019 (UTC)
Is there a difference between Pokechu's and Memetic's example and mine? Anyway, there is now a project that includes this work amongst other stuff, see new hatnote. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:28, 14 July 2019 (UTC)

RfC: when possible, control infobox image animations by using associated invslots as radio buttons[edit]

Just a thought. For an example, take Wool. Can we have the infobox display the white wool render by default (static), then have it switch to whatever render is associated with the invslot the user clicks? Such as if the red wool invslot is clicked, display the red wool render as the main image, and the same for all other variants.

I think this is better than having an unstoppable and uncontrollable animation of 16 images. --AttemptToCallNil (report bug, view backtrace) 21:34, 8 May 2019 (UTC)

I like the idea, though accessibility is a concern (though equally, invslot has accessibility issues which I brought up on a module talk page that nobody seems to have noticed). But, ignoring that, maybe it'd be best to have the animation automatically cycle, but clicking an individual image would set it to that one and stop the cycling? --Pokechu22 (talk) 22:23, 8 May 2019 (UTC)
Since you've brought it up, I do remember that when I was a reader of the MCW who knew nothing about how it worked from the technical side, I found it annoying that some block images were replaced by others before I could take a good look at them. I'd definitely support fixing this, but I'm not sure how. I'm a bit skeptical of having only one image appear unless the reader clicks an InvSlot; something like Pokechu's idea might work better, though if we replaced the left-clicking an image functionality with stopping the cycling, that wouldn't allow the easy maneuver to the file's own page, which could be problematic.--Madminecrafter12 (Talk to me | View what I've done) 22:33, 8 May 2019 (UTC)
What if on hover of the invslots and the infobox image itself, the animation stops indefinitely, but immediately resumes again when moused out (or alternatively, the animation automatically resumes again after a longer interval than currently)? And then on click of the infobox image it of course opens its file page, and onclick of the invslots it switches out the infobox image as the original suggestion. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 22:52, 8 May 2019 (UTC)
Nice idea, Jack, that solves all of my concerns.  Support!--Madminecrafter12 (Talk to me | View what I've done) 23:46, 8 May 2019 (UTC)
I like this and I think it'd be more obvious behavior-wise, but I'm not sure about accessibility. Would it make sense to have clicking on the images in the invslot simply open the file itself, the same way as the one in the infobox works? Granted I'm not sure if it's too big a deal, and people have been able to live with the current inaccessible version this long. --Pokechu22 (talk) 23:51, 8 May 2019 (UTC)
 Support original proposal if this is possible to do. – Nixinova Nixinova sig1.png Nixinova sig2.png 23:40, 8 May 2019 (UTC)
 Support Jack's idea or original proposal. This is one of the most annoying aspects of the wiki, imo. Some kind of fix is desirable! Memetics talk | edits 07:35, 9 May 2019 (UTC)
 Support Jack's idea or original proposal. Although what about entities like Wolf or Cat? – Sealbudsman talk | contribs 05:27, 10 May 2019 (UTC)
 Support Jack’s idea or original proposal. -BDJP (t|c) 07:24, 10 May 2019 (UTC)
Looks like Jack's idea (22:52, 8 May 2019) gets implemented? Presuming someone knows how to code that. Memetics talk | edits 23:08, 20 May 2019 (UTC)
We can pretty much reuse the code that pauses animations for crafting recipes on hover, for other animations (I'm thinking a generic class to apply to any container that should pause animations when hovered). Having the image change based on the invslot however is not so easy. The naive approach of just showing frame 1 for invslot 1 would be very simple and work for many cases. But many wouldn't. Wood has two rows of invslots and images, so it would have to only change the image 1 for row 1 and image 2 for row 2. Potion has a bunch of rows, but only one image. Bell has a multiple frames and images rows, but only one invslot. Bed has a whole set of invslots for BE that are only different in the inventory, not the world so there's no different image to show. In other words, you'd need a way to assign specific slot(s) to specific image(s), and handle cases where there's slots without corresponding images, and images where there aren't corresponding slots. It'd be a nice feature to have, but it's just not simple to set up properly. MajrTalk
07:31, 25 May 2019 (UTC)
Hovering over the image area of an infobox will pause all animations in it now (and you can define any element with animations in it as the container for pausing by adding the animated-container class to it). As for implementing changing the image on hovering an inventory icon, that still needs a viable solution to link related images and inventory images together. MajrTalk
07:09, 1 July 2019 (UTC)

Stop overwriting renders and upload new images instead[edit]

The result of the discussion was to implement the suggested change.

The texture update highlighted a long-standing issue caused by our current method of updating textures, where we upload over a render with the new version, then reupload the old version somewhere else (seem to be using "Revision X" currently, but the naming scheme is irrelevant right now). This is great for updating all the places the image is used in most cases, but when it comes to historical places such as history sections, removed feature pages, and the texture update page itself, this actually causes a problem as we should've kept the original image. Someone now needs to find all those locations and update them to use the newly uploaded revision file, so it goes back to the correct version. This issue was a real big problem on the texture update page, where it was using the current render for the "old" column and a TextureUpdate version for the "updated" column, which then all broke when the original files were overwritten with the texture update versions, and required changing all the "old" column to revision files, and the TextureUpdate files in the "updated" column are now all duplicates of the original file, which should be removed.

As such, I propose we move all current renders to whatever name we would've used for the current version had the texture been changed (don't bikeshed about the naming scheme here, we can decide that elsewhere if people aren't happy with whatever we're using now), and leave the original name as a redirect. When a texture is changed, we just upload a new revision file, and update the redirect to point to the new revision. That way all pages that want the latest version will get it via the redirect, and historical places will keep using the revision file directly.

For example: we would move Grass Block.png to Grass Block Revision 6.png, leaving a redirect and continue using Grass Block.png in places it should update, but use Grass Block Revision 6.png in the history entries about the texture update, so those won't break in the future. If the texture is changed again, we'd upload Grass Block Revision 7.png and update the Grass Block.png redirect to point to it.

I would also recommend we standardise on linking all the different revisions of a texture on each file page, so you can navigate them easily, and add a note (on the redirect page too) about using e.g.: [[File:Grass.png]] when you want a file that updates with the game, and [[File:Grass Revision X.png]] when you want the file to stay the same.

The only issue I see with this is I'm assuming redirects don't work for shared repositories, so language wikis relying on these images will be missing them until they create redirects themselves or upload the images locally. That being said, while the shared repo is a useful crutch for new language wikis first starting up so they don't need to duplicate all the files, it is not something that should be relied on long-term as it's prone to being broken due to our files being modified to work for our own articles, as it's not practical to check in with every wiki to see if a file can be modified. MajrTalk
15:20, 8 June 2019 (UTC)

A big part of this project has been changing history sections to be correct as well. I honestly don't see what's wrong with the current system as long as we're vigilant about updating things, and your way just seems like the current way but more complicated. And it doesn't even make sense. If you move a page, the redirect redirects there, not an old version of the page. In my opinion, the file named "grass block" or whatever should always have the most recent version of the texture on it, and the current system seems like a good way to do that. If you (or anyone else) sees an incorrect history page, fix it! That's the beauty of a publicly editable wiki. -PancakeIdentity (talk) 18:54, 8 June 2019 (UTC)
So you mean Grass Block.png would redirect to Revision 6?  Strong support. This would be a much better method than having all these duplicated files. – Nixinova Nixinova sig1.png Nixinova sig2.png 19:18, 8 June 2019 (UTC)
My problem is that I feel that people should be able to link Grass Block.png and always have it show the latest texture. I might be missing something here though. -PancakeIdentity (talk) 19:32, 8 June 2019 (UTC)
The proposal says redirect the non-revision version to the latest revision, so you'd be able to do that. FVbico (talk) 20:16, 8 June 2019 (UTC)
Oh alright, I see. Thank you!  Support -PancakeIdentity (talk) 20:35, 8 June 2019 (UTC)
 Support. FVbico (talk) 20:16, 8 June 2019 (UTC)
Interesting idea, the author deserves praise for creatively solving technical challenges.  Support. --AttemptToCallNil (report bug, view backtrace) 21:08, 8 June 2019 (UTC)
Full  Support. Complete solution to a troublesome problem, no counter-arguments. Also thanks for the clear examples, that cleared up a bit of misunderstanding, as "just upload a new revision file" was ambiguous for me, and I understand now that you're talking about texture revision, not a revision of the file's page. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:08, 9 June 2019 (UTC)
Great idea!  Support. Memetics talk | edits 05:58, 13 June 2019 (UTC)

I have moved File:Grass Block.png, put the text explaining the redirect with a table of all revisions on the redirect and revision pages (this would obviously need to be made into templates), and updated the relevant history section, as an example of how it would work. If an update made a change to how the grass block looked, you would upload File:Grass Block Revision 7.png, update the redirect at File:Grass Block.png to point to the new file, and add the new file to the table (kept on the first revision file page, as you can't transclude the content of a redirect page). All pages using the redirect would update to the latest revision as usual, but you don't need to update any history sections as they will keep using the previous revision file directly. If this looks good we can convert the text and table into templates and start moving files. MajrTalk
06:58, 1 July 2019 (UTC)

Also: incredibly, redirects work over a shared repo (e.g.: cs:File:Grass Block.png), so that's not a concern any more. MajrTalk
07:18, 1 July 2019 (UTC)

Oh, yes! That looks amazing; I'd say definitely do that for all infobox images! FVbico (talk) 09:18, 1 July 2019 (UTC)
I would fully  Support using this format on all renders. – Nixinova Nixinova sig1.png Nixinova sig2.png 02:54, 2 July 2019 (UTC)

Let's get this done! FVbico (talk) 20:11, 12 August 2019 (UTC)

Aim of the wiki and other titles in the franchise[edit]

This Discord message is the reason I'm posting this here. Since the introduction of an entirely separate game, Story Mode, questions have been raised about whether we need to provide detailed coverage of other Minecraft titles, or delegate this task to other wikis and settle for brief descriptions instead. Given the upcoming release of Minecraft: Dungeons, it would be better if this question was finally answered.

The aim of the wiki was implicitly and informally defined too long ago, when what is now Java Edition was the sole work titled Minecraft. As such, it cannot be said that we document Minecraft and therefore only the main game. This statement could be made broader, to the point that since what we call Bedrock Edition is the sole work officially named "Minecraft" without any other words in the title, we could say that this wiki should only document Bedrock Edition and delegate coverage of other editions to other wikis. While such an approach isn't going to be taken because of substantial similarity between Minecraft editions, something not true for completely independent titles in the franchise, it underlines the main issue with this argument: "Minecraft" in "we document Minecraft" isn't defined. And I have started this very topic specifically to help the community determine what definition is appropriate.

I support documenting other titles on this wiki. Content pages for these titles could be placed in subpages or separate namespaces (like UESP does). --AttemptToCallNil (report bug, view backtrace) 14:51, 11 June 2019 (UTC)

 Support franchise as a whole, as I already stated on discord. I'd prefer just subpages, rather than separate namespaces though, so they can be found better with the search then. FVbico (talk) 15:12, 11 June 2019 (UTC)
UESP definitely supports search suggestions for other content namespaces. There are server configuration options for enabling them as content namespaces and as namespaces to be searched by default. --AttemptToCallNil (report bug, view backtrace) 15:42, 11 June 2019 (UTC)
Uninvited, seriously I want to comment on this topic. I thought carefully about new community, the independent community is more new and dynamic, knowing how to running with scissors, like today Singapore and Japan. Singapore's approach gives a community the opportunity to develop independently, the new community is more focused on the gameplay writing of this new game.
A point of view made against AttemptToCallNil: A new game released by Mojang must have much gameplay in the future, if it is not advisable to take many subpages, the reader will only be busy looking for the subtitle page, rather than a complete wiki. Looking at the previous Minecraft Wiki and not preparing any subpage for Minecraft:Story Mode, it is obviously not appropriate to outline the entire page with a whole game.
I quote words from Gamepedia suggesting wiki interface:

At Gamepedia, our goal is to provide the #1 wiki resource for gamers spanning all genres and platforms. Whether you are starting a brand new wiki or moving an existing one over, gamepedia will provide your community with all the necessary tools to create a great wiki. Please answer the following questions to give us a better understanding of your preferred involvement.

FANDOM has the same wiki: https://minecraftdungeons.fandom.com . Why couldn't set up a new wiki on Gamepedia by interfering with the right of others to establish a wiki freedom?
So my opinion is given  Oppose, sorry. All in all, we need to listen Gamepedia wiki managers and project creator's (Awesomeninja886) suggstion. --Angrydog001議(Talk)/誌(Logs)/勛(Contribs) 17:41, 11 June 2019 (UTC)
I'm sorry, but I can't understand this post. I'm unable to see links between its parts, and sorry for being blunt, but it doesn't sound coherent enough. --AttemptToCallNil (report bug, view backtrace)
^That being the case, we reserved our respective views. Besides, what BD saying is what I thinking. --Angrydog001議(Talk)/誌(Logs)/勛(Contribs) 02:45, 12 June 2019 (UTC)
 Conditional support. If Minecraft Dungeons has a lot of content that differs than the main game, and will receive constant updates, then it may be better to have a separate wiki for it. If the game is similar to the main game then it should be on here, as a subpages of Minecraft: Dungeons. We didn't have this discussion about story mode because it didn't add enough content but now with 2 new games on the horizon this is quite different. – Nixinova Nixinova sig1.png Nixinova sig2.png 19:22, 11 June 2019‎ (UTC).
How much is too much? Given this question is not answerable, this topic is not about whether to make a new wiki for MC: Dungeons, but about the scope of this wiki, and thus whether titles like Story Mode or Dungeons should be documented here in detail. --AttemptToCallNil (report bug, view backtrace) 20:07, 11 June 2019 (UTC)
I think this will should be more about the franchise as a whole, but I'm not sure of the extent we should document other games on here. I think subpages are the best idea at the moment for eg Dungeons exclusives. Story Mode can be easily described in one page. Though, what is technically the difference between bedrock, console, java, and dungeons? All are completely different games that just have similar content. To answer the main question... "probably". – Nixinova Nixinova sig1.png Nixinova sig2.png 21:07, 11 June 2019 (UTC)
I think I can't formally answer this question. Because first, I'd like to know how we could even document other games in the first place, and make it fit on the wiki. But seeing we're still stuck on the wiki-wide refactoring of edition-specific information already, I'm not seeing how we're going to get consensus on how to document an even wider scope. So generally speaking, it's my opinion we should discuss at least how we could achieve this, before deciding whether we should do it. But for what it's worth, depending on whether it could be done with a clear distinction between each game, I'd be leaning towards the whole franchise. Because although they might not be the same game, if they are part of the same franchise, they essentially are still "Minecraft"-y. But I'm heavily concerned about the implementation of this. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 21:27, 11 June 2019 (UTC)
Whether it is implementable is definitely not a problematic question. Documenting substantially different titles requires even less integration with main-game articles than edition refactoring. A custom content namespace or a subpage system (I'd prefer the former, I guess?) is not impossible, and integration into main game articles could be achieved with a dedicated section (such as "In other titles"), which briefly describes the subject's involvement in titles like Dungeons or Story Mode (also, why wouldn't we document books as well?) and links to more detailed dedicated articles. --AttemptToCallNil (report bug, view backtrace) 21:42, 11 June 2019 (UTC)
 Strong oppose. Having too many articles dedicated to a particular game (Dungeons) or series of games (Story Mode) will basically make this wiki a huge mess. When I first began making the Story Mode article back in 2014, I had felt like that it would be best if information about the game was kept to that article, with the exception of trivia or pictures pertaining to the game in other articles.
Its simply unnecessary for numerous articles that are basically part of spin-offs to be included in this wiki. It would be better off if any additional information (e.g. locations / characters in Story Mode or items/armor/potions in Dungeons) be kept completely separate from this one. -BDJP (t|c) 23:26, 11 June 2019 (UTC)
 Oppose. Story Mode is a standalone game created by another company, Telltale. They only acquired the rights to use Minecraft franchise for their game. Aside from that, Story Mode is a linear progression storytelling or basically just a point and click game, it's not worth documenting each character in the first place. As for Minecraft Dungeons even though it's a Mojang game, it's not suitable for this wiki. Every items, mobs, and mechanics will conflict with the base game. Sure we can utilize namespaces as the solution, but Minecraft Dungeons has a very different genre, it'll be 100% better to just separate the wiki, more efficient and maintained separately.
Back to the topic, yes this wiki documents the Minecraft franchise as a whole, hence why we have Minecraft Dungeons and Minecraft Story Mode articles. But this wiki isn't suitable to document all the contents and gameplay of another game, we should keep this wiki to only document the main game and only the titles of another game. – ItsPlantseed|⟩ 05:24, 12 June 2019 (UTC)
 Oppose. Unlike Story Mode, I think Minecraft: Dungeons is actually an indie game with enough new content that it's likely to contain a lot of diffenent content information. Even if it is the same thing as the vanilla, it must contain different information from the vanilla one. Putting them in subpages means there will be tons of subpages and subpages of subpages, so why not make it a standalone wiki? — SagvinXC  讨论(Talk)/贡献(Contribs) 02:40, 13 June 2019 (UTC)

Once again, the question of this topic has no relation to specific titles whatsoever! The question is the scope of the wiki. All conversation in this topic is basically people pushing incoherent, unexplained, and often false reasons why this wiki should not have extensive coverage.
Since the question is the scope of the wiki, nothing about non-primary titles matters: their number, their content, nothing. The only thing that matters is to what extent we should document, for the purposes of this discussion, an unknowable number of titles with unknowable content, of which the only thing known is that they're part of the Minecraft franchise.
For an example similar to non-primary titles, take mods. If not for the aggressive vanilla-elitist position of the community and disturbingly poor admin strategies during this wiki's first few years, this wiki could have become the source of information not only on vanilla Minecraft, but on a wide variety of mods as well. This has irrecoverably failed, and people are now pretending like mods were never within the scope of the wiki to begin with.
Technological limitations are most definitely not a problem with documenting many titles. Neither is "creating a mess", content organization is solvable. What's not easy to solve is involved editors.
I'd rather not resort to pointing out specific titles, but we may as well have lost our chance to provide due coverage of Story Mode – it's too late now for multiple reasons.
So the question is, what exactly is this wiki about? --AttemptToCallNil (report bug, view backtrace) 09:02, 12 June 2019 (UTC)

What the wiki is about? Ultimately, to have people cooperate together. This conversation isn't a very good example of that. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:31, 12 June 2019 (UTC)
As I just said above, this wiki serves no purpose for documenting the contents of another titles. Other titles should have their own wiki separately if they don't share the same gameplay and genre. That's it, this wiki should only document the main vanilla sandbox game, Minecraft. And clearly unofficial community-made stuffs don't belong here, none of them are supported by the official nor the wiki. Mod pages only cover some parts of the community, some are taken care by an individual and most of them are abandoned just to fall into despair. But then again it's just my own opinion and I'm not fully opposing this, there are some of my concerns regarding this move among others:
  • What belongs in the mainspace?
  • The searchability and accessibility of specific titles.
    • If we were about to include namespaces for specific titles, the search bar functionality should refer to the title that people desire (one solution I can think of is to add a dropdown menu that search a specific namespace). – ItsPlantseed|⟩ 11:16, 12 June 2019 (UTC)
I personally  Wouldn't be opposed to opening it up.
  • I'm imagining keeping mainspace for the java/bedrock/etc game, and opening new namespaces for each of the other game series: one for Earth and whatever sequels, one for Dungeons and whatever sequels, one for the Story Mode series, and so on.
  • From mainspace articles like Pig, you could have sections at the bottom, near the History / References area, titled "In Minecraft Earth", "In Minecraft Dungeons", and so on. These could have see-also links to Earth:Pig and Dungeons:Pig, as well as short summaries perhaps. And then you'd have a nice, clean Earth:Pig with content only from that game.
I like this organization because it separates the peripheral content from the main-game content. Peripheral game info won't be sprinkled throughout the page, so when the main java/bedrock/etc game gets its many many updates, editors won't have to gingerly step over all this other content. And those other namespaces won't have to deal with the constant update churn from java/bedrock/etc that's irrelevant to their games. –Preceding unsigned comment was added by Sealbudsman (talkcontribs) at 20:10, 12 June 2019‎ (UTC). Please sign your posts with ~~~~
I would  Support this method. – Nixinova Nixinova sig1.png Nixinova sig2.png 20:15, 12 June 2019 (UTC)
I appreciate this discussion, and I thank AttemptToCallNil for raising it. The question of the purpose and scope of this wiki is at once a philosophical one and a matter of history, preference, and practicality.
First, the Ship of Theseus comes to mind - What exactly defines Minecraft the game, and at what point does Minecraft the game become something other than itself? Are Java Minecraft and Bedrock Minecraft the same game? Well, yes and no. How I see it is that essentially they are the same - a player's experience with the game involves mostly the same kinds of adventures and interaction with the game interface in both versions, despite that there are minor (and sometimes not so minor) differences. Should they have separate wikis? Probably not. I liken this to how I may act somewhat differently in different social contexts, such as at work, with family, among friends, on this wiki, etc. Am I a sufficiently different person in each context to be called a different me? No, I don't think so. (YMMV.)
I have a brother, and he's a lot like me but also very much his own man. I see Minecraft and Minecraft: Dungeons (etc.) in this light: Part of the same family, but not the same individual. So then, when people are seeking information about Memetics, are they looking for information about only one kind of me, about the various "me"s, or about me and other members of my family? I guess it depends on the seeker. I personally only really care about finding information here on the core game we call Minecraft. But sometimes I might look elsewhere for information on tutorials, on mods, on related games in the franchise, on Minecraft stories (official books), on toys, and so on. Why should I have to look elsewhere for this information, I wonder? Why can't I find it all here, on the official Minecraft wiki?
And here's where I arrive at my position of  Support. To the extent that we can be a comprehensive and most-useful information source for all things Minecraft, I think we should be. I believe we can and should stay focused primarily on the core game but that we also can be so much more. I believe we can solve the technical challenges that this change will pose (and by "we," I mean "you, all you people with better technical ability than me," though I'll pitch in my $0.02 here and there). And I believe that this expansion of focus will help us to attract a much broader cadre of dedicated editors, which in my view can only serve to make this place a healthier and more vibrant community with more long-term staying power. Memetics talk | edits 06:35, 13 June 2019 (UTC)
 Conditional oppose I oppose this idea if the wiki continues in its current state. I've mentioned before that I think the wiki can already be extremely messy due to 5+ versions of Minecraft that have been, or are being, developed. However, if we do eventually find a good way to represent these differences without making these extremely messy pages, I would be more likely to support this. The wiki just doesn't need more mess, but if we can do it well, I'll support. –Preceding unsigned comment was added by PancakeIdentity (talkcontribs) at 02:40, 14 June 2019‎ (UTC). Please sign your posts with ~~~~

AttemptToCallNil's proposed resolution[edit]

I believe there is one most significant argument of those who opposed covering other Minecraft titles on this wiki in detail, and it is great difficulty in manage articles if they had to include other titles' information.

It does not seem to be a real challenge, however. I believe this to be even easier than managing editions of a single base game. Separate articles can be created and referenced from the main game article in a short section.

For organizing the separate articles, we could create subpages (not good for search) or use disambiguation in parentheses (this may have other issues), and we also have the option of a separate custom namespace. I do not believe there is substantial difficulty for wiki managers in configuring a separate namespace for each title, which are not expected to appear in significant numbers. Wikis which have to manage content from multiple titles use both namespaces and parentheses to various degree of success.

For examples of such coverage, I provide the Fallout wiki on Gamepedia (known as The Vault), Unofficial Elder Scrolls Pages (UESP), and its Fandom counterpart (Gamepedia does not have a general TES wiki).

For the Vault, a single weapon type, a 10mm pistol, has many different implementations in the many titles of the Fallout franchise. There is even a common article for all those variations, which provides links to articles about such items in specific games.

One example from UESP is the Azura's Star, an artifact which makes appearances in four major titles. There is a lore page for it, a subsection for Daggerfall, and three articles for Morrowind, Oblivion, and Skyrim.

A second example from UESP is the Light Armor skill. It also appears in four titles (but not the same four titles) and has a separate article for each of them: Morrowind, Oblivion, Skyrim, TES Online.

The Fandom Elder Scrolls Wiki uses a more conventional parenthesized disambiguation. Azura's Star has a disambiguation page, and separate pages for Daggerfall, Morrowind, Oblivion, and Skyrim. An identical approach is used for light armor: a disambiguation page and articles for Morrowind, Oblivion, Skyrim, and TES Online.

These examples indicate it is possible to manage such content without creating a huge mess.

In particular regarding Dungeons, there is a reason I would strongly prefer not creating a separate wiki. A separate wiki would mean reduced interactions between base game and Dungeons editors, reducing flow of users from one wiki community to another, and creating possibilities for a greater split in the general Minecraft community. In this case, there would be a blank wiki with little to no established policies and a new administration team (much more reliance on GRASP for recent changes patrolling, less effective admin tools use – there has even been a concern than a certain non-English editor has a non-constructive approach to opening a Dungeons wiki in their language).

Since Fandom acquired Gamepedia and later announced Project Crossover (referred to by some people as "Project Gelatinous Cube"), which involves potential merges of same-subject wikis between the two wiki farms, the possibility of integrating the existing Minecraft community on Fandom (which is smaller and lacks the advantage of being official) into the one on Gamepedia has been discussed. In light of this possibility, proposing a further split of the Minecraft community seems counterproductive to me.

Another issue is caused by existence of non-English Minecraft wikis (but please don't joke about having them deleted, it's inappropriate). If a separate wiki is created for English coverage of Dungeons, it will be implicit encouragement for other wikis to delegate Dungeons coverage to separate Dungeons wikis, which may have undesired effects on their communities. Even if a non-English wiki defies this encouragement (which could even be named borderline denial of agency) and covers Dungeons on their wikis, a separate Dungeons wiki in that language could be opened, thus creating an ineffective system of content duplication (once again, something against the aims of projects like Crossover) and splitting the community.

I propose detailed coverage about Dungeons, and likely Story Mode as well, to be provided on this wiki, in separate custom namespaces.

Please note I would strongly not appreciate unargumented opposition – you're basically saying "your reasoning is faulty, and I won't tell you why". Also I ask you to avoid repetition of arguments provided above (that coverage here would be a mess – I have provided evidence to the contrary, or something among the lines of "there should be no coverage because there should be no coverage" – this is even worse than no argumentation because it's lack of reasoning that doesn't necessarily look invalid). --AttemptToCallNil (report bug, view backtrace) 21:29, 24 June 2019 (UTC)

 Strong oppose to the resolution provided per my resolution as stated below. -BDJP (t|c) 04:53, 30 June 2019 (UTC)

BDJP007301's proposed resolution[edit]

The aim of this wiki for far too long has been about the similar editions of Minecraft that have been released on everything at this point. Computers, tablets, smart phones, game consoles; you name it. Then, out of nowhere, we get Story Mode (heck, it was revealed in a "game" released on Mojang's website), and the same with Dungeons and Earth; both are basically revealed without any proper tease or information beforehand. They are also revealed to be coming to basically the same devices, but how the games play out are completely different.

Both Story Mode and its sequel are not sandbox games, but instead are point-and-click and driven by a narrative. While they do have a similar visual style, they are completely different at their core, with stuff that is not possible in the sandbox game, such as animated facial expressions, fluid movement, a third-person camera constantly following the player at various angles, voice acting, etc. Also, as stated by ItsPlantseed, characters / mobs from a game other than the sandbox game are not suitable for this wiki (heck, there is already a separate wiki that we can move over to Gamepedia).

As for Dungeons, it is also not a sandbox game, but an action-adventure RPG. Again, while it does have a similar visual style to the sandbox game, it is completely different at its core, with stuff that is not possible in the sandbox game, such as a top-down camera, in-game currency that is used throughout the game as a whole (not just the Marketplace in the sandbox game), completely different weapons / items / mobs, powerups, etc.

As for Earth , it is also not a sandbox game (per se), but an augmented-reality game. Again, while it does have a similar visual style to the sandbox game, it ends up becoming different at its core. First and foremost, unlike the previous two, this is exclusive to iOS and Android. Secondly, while the gameplay is similar to the sandbox game, it is impossible in the sandbox game for there to be a 360 degree camera without the need for virtual reality (sorry, Bedrock Edition on Gear VR doesn't count), or for real people to be implemented into the world.

Simply put, Story Mode, Dungeons and Earth do not share the same gameplay or genre with the sandbox game, and as such, are completely different, and therefore must be completely separate from this one. For the fact that both Dungeons and Earth have separate Twitter accounts as well is something of note.

Managing articles to include information different from the sandbox game (which is what this particular wiki covers) will cause massive confusion among visitors. Having articles / subpages for Dungeons, Earth, and Story Mode will make this wiki more focused on editors than visitors, be much more difficult to maintain, and said articles may eventually become abandoned and suffer from all kinds of internet rot (I'm looking at all the mod pages that have been made and then eventually deleted because of being left abandoned). It will especially become difficult when, exaggeratingly speaking, that a major update for Dungeons, Earth and the sandbox game are all released on the same day, meaning that it could take days, let alone weeks, for all the information to be updated (instead of it currently taking around a day or less for us to update the articles with the major updates to the sandbox game).

As for Dungeons in particular, keeping the information separate will help tremendously as it'll avoid editing conflicts with this wiki as a whole, will make this wiki easier to maintain, and avoid internet rot (I'll be happy to help set up the Dungeons wiki if need be).

While I was not able to provide good examples of information being separate (as some wikis I have been looking up haven't been updated in 2+ years, and also for the fact we aren't Wikipedia), it will be easier to have the information completely separate overall for the reasons as stated above.

I vehemently oppose any coverage about Dungeons, Story Mode, or Earth on this wiki, with the exception of one article having a brief explanation about each game. This wiki is meant to be about the sandbox game, not the Minecraft universe as a whole.

I end with this quote from Jasper Boerstra (this one and this one):

Minecraft Dungeons is an entirely different game with different textures and items. Blocks and props were specifically made for the levels and will most likely not be in Vanilla. There is a small chance a few blocks might make it to Vanilla, but not all of them. It's an entirely different game in terms of game design.. But set in the same universe as Minecraft.

-BDJP (t|c) 04:53, 30 June 2019 (UTC)

In other words, here are the key points of this topic:
  1. Story Mode (SM) and Dungeons (D) are completely different games than Minecraft, and therefore must be described separately.
  2. Having any sort of SM/D information on this wiki (implicitly – regardless of arrangement) will be excessively confusing to readers.
  3. This wiki will not be able to maintain SM/D articles, and they will be abandoned (implicitly – as opposed to if they were hosted on another wiki, where they would be better off).
    1. Evidence of that imminent abandonment is mods.
  4. Maintaining SM/D articles will divide the attention of existing editors (implicitly – as opposed to if the articles were hosted on another wiki), which will harm main game coverage.
  5. This wiki is only about the sandbox games.
All the points presented above are refutable, and thus so is this entire proposal.
Point 1. No logical link. Once again, I must refer to Fallout and Elder Scrolls, where there is no evidence of decisions that games outside their typical RPG form must have separate wikis. TES: Blades and Fallout Shelter, I believe, are described on the same wikis as other games in the Minecraft universe, which both SM and D are explicitly stated to be part of. A factor weakening my position may be absence of a base series of games in the same universe prior to the release of dissimilar titles, though, 1) sandbox games rarely get sandbox sequels due to the nature of the genre, and 2) other points remain unaffected by this.
Point 2. That "implicitly" part in my point is key. I have presented _two_ arrangements in my proposal which are demonstrably not disastrous for readers. One point, however, I have not covered, is searchability of SM/D content (think SEO). Since it should be expected that people will initially come to SM/D articles from search engines, how close to #1 will the wiki be will determine whether it remains functional. I am not remotely knowledgeable on SEO, so this is just my relatively-layman hypothesis: being associated with an active wiki is likely to be a positive factor, but so may be having a separate subdomain, and/or association with Gamepedia. I will ask for expert advice.
Point 3. The "implicitly" part is again key; even if you have not said this, your argument – that a separate wiki is better – is automatically invalid without it. Having SM/D articles on this wiki is likely to improve the chance of current visitors, whether editors or readers, finding them, thus helping these articles to stay alive. The searchablility factor is still applicable.
Point 3.1. There have been many contributing factors to mods becoming unused here. Their less-searchable arrangement (as opposed to, say, a custom namespace). The core community's negative attitude towards unofficial content (including the popular non-sequitur "we're the official wiki and therefore can't cover unofficial content"), to the point they were effectively subject to unstated exemptions from all rules (then-admin Kanegasi told me that in 2013). The presence of separate, official mod and mod pack wikis, including the FTB Wiki (which would make this wiki just a secondary source of information). Probably other factors as well.
The Russian wiki had a different situation for all the listed factors. There are still mod articles being developed, and even though they aren't updated very well, neither is base game information. This is, however, not necessarily applicable to the English wiki for one of the factors I listed: managing a non-English language project or a wiki is something almost no single mod wiki does at all, much less something they do effectively.
A more important analogy to see with content rot is, yes, non-English language projects (typically referred to with terms which imply their derived, dependent status on the English wiki, a despicable trend of marginalizing people who don't speak English; I deliberately avoid such terms as "translation project" or "language wikis"). Why did so many translations on this wiki become inactive and had to be purged? Because they didn't have enough editors. There are, once again, many reasons for that, and not being a separate wiki isn't necessarily among these reasons. Some translation projects did get their wikis, even recently. Are they more active now? Some may be, but definitely not all. Could we have done things better for them? Yes. For one, listing non-English versions on top of each page would have contributed to influx of a new editors.
Point 4. That's a mostly flawed model of editors. Typically, wiki editors, especially on relatively large wikis, have areas in which they work. They may not have or like all the games or editions, they may do something that few other can, or they may be bad at something people are often good at. If an editor is focused on updating command documentation, writing change logs, or editing tutorials, they will be mostly unaffected by there being a separate namespace.
I said "mostly". The editors whose attention will be divided are those metapedically focused: tracking discussions, managing templates, clearing backlogs (yet most of those isn't the work which greatly peaks with updates, that would be content writing). What would happen if there was a separate wiki? They'd need a metapedic setup: people who can create and revise rules, guidelines, policies, templates, content layout... and where will they take these people from? Who will they ask for assistance? Will there be a "they" even? Capable wiki maintainers are much less common than your average article creators, and we have quite a bit here. The topic of dividing the community was one I covered in my proposal.
Point 5. That's just what the dragon left for his treat. Because it's simple: figuring out what this wiki's about is the aim of this discussion. This hasn't been decided yet.
 I cannot agree with a proposal I can only respond to with a wall of text debunking its key points. We have screwed up with mod coverage, we have screwed up with translation projects, we have screwed up with Story Mode. I believe proposals like this can lead us to screwing up with Dungeons, Earth, and whatever comes next as well. I have nothing left in my life than these few communities online I still believe I can help, and it seems to me people are pushing, in good faith, for something that is likely to deal irrepairable harm to these very communities. --AttemptToCallNil (report bug, view backtrace) 22:52, 1 July 2019 (UTC)
I think non-core-MC content (SM, Earth, Dungeons) shouldn't really be documented fully in this wiki, but wouldn't mind if they were. Also, these massive 6KB text walls aren't really encouraging discussion here. – Nixinova Nixinova sig1.png Nixinova sig2.png 02:51, 2 July 2019 (UTC)
Trying to stay on a discussion of scope of the wiki: I think the wiki would be better, and more of something to take communal pride in, with more of the official franchise in it.
Imagine: you'd look at a page like Sheep, and you're not just reading about how it works in the core sandbox game, instead you have access to sections about the other games right there, and you can get a glimpse how the Sheep plays its part across all Minecraft worlds. That's lore, that's interesting stuff fans would love. And that goes for Dungeons readers too! They get to know the Sheep as it was in the original game. It's a much richer page.
And then we look back on that a few years later and can be proud we made that transition and made it all that much richer.
I read BDJP's piece, and while I don't really feel much of it actually discourages me from supporting opening the project up, I think his point about internet rot is an interesting one to consider. Ultimately with that though, you can never predict beforehand what editors will come. We've had times when we wished we had more Bedrock and Console editors, but over time they did come. I'm optimistic about Earth and Dungeons editors; we had a fantastic Story Mode editor after all ; ) – Sealbudsman talk | contribs 01:49, 18 July 2019 (UTC)
I've added a few bits of trivia to pages such as pig and mooshroom saying that muddy pigs and mooblooms exist; since Earth runs in Bedrock there's not any exclusive functionality afaik so no need for any sections or anything. – Nixinova Nixinova sig1.png Nixinova sig2.png 02:17, 18 July 2019 (UTC)
This is a tough issue with no easy answer. Both (all) sides have persuasive points. I'm comfortable with us being "Minecraft-the-sandbox-game documentation," a comprehensive user manual with text and pictures. I'm also comfortable with that being just one facet of a wiki that covers the entire Minecraft universe, because I am convinced that we can manage successfully the complexity of such a wiki with our current leadership at the helm.
So since a choice is required, I'll keep my original stance. I like the idea of us being the comprehensive, go-to wiki for all things Minecraft. I think we ought to be more than just a fancy user manual for the core game. I concur with Sealbudsman (18 July) and lean toward the solution AttemptToCallNil has proposed, with separate namespaces. I think that needs to be accompanied by a distinct page style for each namespace, if possible; the pages' look and feel - i.e., color scheme, head banner, maybe page structure - will help people tell at a glance which specific Minecraft "species" (sandbox game, interactive story, novel, toy, whatever) the particular page is about. This should be accompanied by clear infoboxes or whatever identifying the "species" at the top of each page.
As long as we continue to document the ever-evolving core game(s) effectively, I believe (as I said before) that expanding our scope will result in a larger, healthier community of editors and, if managed properly, will not result in the confusion we wish to avoid. I even asked my nine-year-old daughter about this issue and read her the various opinions here. She said at first that it might be confusing to have the expanded scope, but then she brightened and declared with enthusiasm that she thinks it will be fine because we can label the information to make it clear which Minecraft thing the information is about. She even mentioned a wiki for another game where this is done. So if she can distinguish such information without confusion (and with enthusiasm, even), then I am confident that the vast majority of our readers will have a similar experience.
Also worthy of note: We must make this decision based on reason and evidence if we want to make the best decision. However, we have to acknowledge, I think, the emotion behind this: Our feelings of what scope is best are tied up with our involvement and history with the game(s), and with the wiki, and with the various communities involved. Whatever decision we make, we are going to feel uncomfortable with it to some degree, and some people will be affected more than others, no matter what we decide. We have to acknowledge that that's a normal and expected part of the process of change here and to be prepared for that. We have to do our best to proceed with patience and empathy, and with a degree of compromise, regardless of the outcome. Having said that, we can only make a good decision here by doing our best to acknowledge and then set aside our emotional associations with Minecraft and engage in the rational basis for what our scope ought to be. What is best for the wiki and for its user community?
Whatever the wiki's scope, I think we'd generally agree that readers of the wiki usually arrive here because they're seeking information about Minecraft. They want to learn. To best inform and educate readers, then, the wiki needs to have content that is clear, accurate, current, complete, and easily accessible. Some of the arguments laid out so far raise concerns that expanding our scope would make achieving those goals more difficult. But I'm more persuaded by the arguments that if we organize the information carefully and systematically, the potential problems will be minimized and that we will gain more in the benefits, which would include a more active, healthy community of editors, some of whom would focus on parts of the wiki more narrowly and some of whom would be more broadly involved.
Therefore, the reasoning and evidence overall say to me that we ought to go ahead with expanding our scope to cover the whole franchise: the Minecraft universe (or the whole Minecraft Tree of Life, if you will, not just one branch). We need to evolve just as Minecraft evolves. It won't be easy, but it promises to be worth the effort. Memetics talk | edits 15:40, 18 July 2019 (UTC)


(New section to differentiate from the text walls above)

Minecraft Earth is now out and since it runs on Bedrock, all Bedrock features apply to Earth. There are a couple of exclusive features - mooblooms and muddy pigs - but otherwise features are the same. I think it would be fine to have info about mooblooms and muddy pigs documented on their respective parent pages (pig and mooshroom), since there isn't that much (Muddy Pigs jump in Mud and Mooblooms plant dandelions when they walk), and for a page on Mud to be created. – Nixinova Nixinova sig1.png Nixinova sig2.png 22:34, 19 July 2019 (UTC)

At first thought, I'd be fine with documenting those here. However, it's the gameplay that really separates Earth. Do we document how to get each type of block, if there's chances or only specific locations? What about combat? Monster spawning, if it happens? And for small stuff like the two new mobs, Earth is in a closed beta right now. It could receive lots of new features by release or in future updates. Etc, etc. It just opens up a big can of worms that we *really* aren't ready to deal with, at least not until we figure out how we're gonna deal with the already varied versions of the base game. So,  Oppose, at least until we figure some more stuff out. -PancakeIdentity (talk) 00:06, 20 July 2019 (UTC)
Pages for Mud and Mob of Me have been created while this discussion has fizzled out; should these be kept, and other Earth exclusives be documented? Since Earth runs on Bedrock there won't be many more of these new pages created.  Nixinova T  C  05:54, 29 August 2019 (UTC)

The de facto consensus at the moment (based on the fact no-one seems to have said anything about the recent pages) seems to be to create pages on Earth info but not to incorporate it into main-game pages, which seems to be working. For Earth-exclusive information about main-game features I think we should add a "In Minecraft Earth" section to avoid the confusion already created by {{only}} sometimes. This discussion needs to have some sort of conclusion by now since the game is already out.  Nixinova T  C  07:26, 30 August 2019 (UTC)

The discussion above, a summary (to the best effort)[edit]

Reactions to full-franchise coverage[edit]


  1. AttemptToCallNil – supports as the writer of the proposal (diff)
  2. FVbico – support (diff)
  3. Nixinova – conditional support (diff)
  4. Sealbudsman – "wouldn't be opposed" (diff)
  5. Memetics – support (diff)


  1. Angrydog001 – oppose (diff)
  2. BDJP007301 – strong oppose (diff)
  3. ItsPlantseed – oppose (diff)
  4. SagvinXC – oppose (diff)
  5. PancakeIdentity – conditional oppose (diff)


  1. Jack McKalling – could not answer the core question (diff)

Points made[edit]

For coverage of other titles on other wikis:

  1. It is too difficult to manage articles about similar content on one wiki when it appears in different titles with major differences.
  2. Other titles may have, or are known to have, radically different gameplay requiring similarly different wiki coverage, and this may be confusing to readers.
  3. Covering other titles will require a new set of templates for every such game/series, which is about the same as making a whole new wiki.

For full-franchise coverage on this wiki:

  1. It is possible to cover substantially different implementations of the same entity in different titles on the same wiki (provided examples: parenthesized disambiguations on the TES Fandom wiki and the Fallout wiki, custom content namespaces on UESP) – refutes opponents' point 1
  2. Having all titles under the same wiki-roof is likely to bring the community together (as opposed to potentially causing a split). There will be easier access to experienced users: those who monitor recent changes and revert bad edits, and to those who can help with wiki/technical things if needed.

Further discussion[edit]

Assuming we still want to discuss this further. --AttemptToCallNil (report bug, view backtrace) 21:09, 27 October 2019 (UTC)

I'd be less opposed to covering everything on this wiki if we didn't try to Frankenstein like 5 different games' version of a mob/block/whatever on to one page. It's already messy enough covering Java and Bedrock on the same page in some cases, and they're essentially the same game. I think it could work much better if we keep everything separate (even if still on this wiki) by creating separate pages (or sections on pages). If we did put everything on this wiki, I'd say we should put other games under their own namespace, like Minecraft Earth/Cluckshroom or whatever. Documenting things on the same page can be slippery. Sure, some new Minecraft Earth mobs might be similar to existing mobs, but this might not also be the case in the future. Also, there's vastly different gameplay mechanics, like obtaining blocks. I think more separation is, in this case, better than less. Not saying completely different wikis, but yeah.
Also, I'm much more open to have Earth on this wiki than something like Story Mode or Dungeons. Earth at least uses the Bedrock engine and has similar(ish) gameplay. Story Mode and Dungeons are much different games that are better described as using Minecraft as a setting rather than being Minecraft. -PancakeIdentity (talk) 21:36, 27 October 2019 (UTC)
Sectioning is definitely a good idea if we go down the route of documenting everything on this wiki and will avoid the "in Java and Bedrock editions../..‌[PlayStation 4 and Education editions only]" spam we have currently.  Nixinova T  C  21:43, 27 October 2019 (UTC)
Of course; can't speak for other supporters, but I never meant for base game articles to provide spin-off coverage, hence the TES/Fallout examples. Though a mention of the separate article would be useful, I think. --AttemptToCallNil (report bug, view backtrace) 21:42, 27 October 2019 (UTC)
Earth and Dungeons seem to be completely different games; the gameplay at MINECON Live had pretty different gameplay from standard Minecraft. Perhaps they should have their own wikis, once we learn more about them. We could still mention them in Trivia sections, similar to Story Mode. The BlobsPaper.png 22:50, 27 October 2019 (UTC)

Mass deletion of mcspotlights videos[edit]

I hope this is the correct venue for this topic.

I've noticed a rather aggressive effort on the part of PancakeIdentity (talkcontribslogsblock log) to delete those helpful little 1-minute summary videos created by mcspotlights. They mostly appeared in many of our articles about individual blocks. I've reverted a few of these deletions (for example, this removal of the planks video, and this removal in sugar cane) because the content of the video is still valid and true, not out of date, but possibly incomplete due to software updates.

PancakeIdentity and I have engaged in a bit of discussion about this on my comment board but I thought this should be discussed in a wider community.

My position is this:

  • If the information in the video is valid and true, then it should be kept.
  • The fact that information is incomplete isn't a good reason to remove it, unless the missing information is so significant that viewers may be misled by watching the video.
  • If the information in the video is misleading, it should be removed.

My viewpoint is based on my personal experiences with my child, who had difficulty reading these pages when he started playing Minecraft, but could use a browser and watch videos. These little 1-minute summary videos were extremely helpful to him. Even now that he can read better, when he looks something up on this wiki, the first thing he does is scroll down to see if the article has a video by mcspotlights.

We may all be adults creating content here, but young children use this Wiki also. Information that is still useful to them should be kept.

What say others? ~ Amatulic (talk) 18:16, 13 June 2019 (UTC)

I guess I personally don't see their use if they're incomplete. It doesn't provide a good overview of the item/block/whatever then. The videos are kinda weird for the wiki, and feel very out of place imo, tbh I'd support removing them entirely but I really don't see them happening. When I watched the first one, it struck me as extremely out of place, maybe better fit for some type of tutorial page. If we are insistent on providing video overviews, I'd say we should find/create completely updated videos. Otherwise, I'd say they're not really too useful and should be removed.
I will say though, I do think floor/ceiling placement for item frames is important enough for the video to be considered outdated.
I would also like to clarify, I have been watching all the videos without outdated notices and have kept the accurate and up to date ones On the pages. -PancakeIdentity (talk) 19:01, 13 June 2019 (UTC)
Going in on "If we are insistent on providing video overviews, I'd say we should find/create completely updated videos.", I suggested this recently in the discord:
"Since so many videos are outdated (and now removed), should we try to make new videos altogether, and try to keep them updated? I'm open to try, but I've never actually video edited anything."
Since I posted that, ItsPlantseed pointed out we should alter Minecraft Wiki:Wiki rules/Video policy first.
The wiki admins would be in charge of the video process then, though editors would be able to help by providing scripts for the videos or alike. FVbico (talk) 19:11, 13 June 2019 (UTC)
It's just weird to me that Curse videos are exempt from the typical video policy. Also, how are the overview videos serving a business purpose? I'd be more supportive of overview videos if they were done professionally and essentially rehashed the wiki page's content. -PancakeIdentity (talk) 19:25, 13 June 2019 (UTC)
The videos being deleted seem professionally-enough done to me. They are nice and concise overviews of the main points in an article. Little details that are missing, like the ability to place item frames on floors, are easily discovered by player themselves and don't detract from the educational value, particularly for kids like mine who want to see them. That's rather the whole point of a concise overview; you can't include all details and still be concise. They don't need to be comprehensive, just informative.
We may as well argue that a video has no value because it was made with Java Edition while Bedrock has the larger installed base. I don't buy that line of reasoning (and by the way, I and my child play Bedrock and we still found those videos helpful), and I don't buy the reasoning that a perfectly valid video should be removed because more details became available in a software update. I'd rather keep them, adding a notation about changes, and delete only the ones that are now completely wrong (such as villages needing doors). ~ Amatulic (talk) 19:49, 13 June 2019 (UTC)
I mean, I would argue that, although not for the same reason. That's not what we're talking about though so I won't bother. From my understanding, we as a community had reached a consensus to remove out of date videos (See above topic). Even if I disagree, I do see your argument about keeping incomplete videos. More of the community would have to chime in. In addition, "completely wrong" is too strict a criteria for removal imo. The wiki should not promote any out of date information whenever possible, unless the page is dedicated to an older version (such as the new Trading before Village and Pillage page). Like I already said, I think the best solution to make the most people happy is creating up to date videos and removing outdated or incomplete videos (even if I personally still dislike the current videos). Incomplete videos are incompetent as overviews, especially in the case of something like item frames, where the missing information is pretty essential to the current function of the item. We're gonna have to undo most of my edits if we decide to promote videos that don't showcase basic functions of an item. I've stated my opinion, and I think we need more community input before moving any further. -PancakeIdentity (talk) 00:44, 14 June 2019 (UTC)
I had just restored the video in chest and then I saw this reply. OK, I'll stop restoring them for now, if no more get removed.
My choice of words "completely wrong" was poor. I'm in favor of removing videos that have obsolete information (that is, information that is now wrong because things have changed, such as beds now defining villages instead of doors), but if the content is still all correct, it serves as a concise overview.
We disagree that a new capability to put an item frame on the floor is a critical feature. It wasn't before, and it isn't now, it's just an enhancement that isn't necessary for a concise overview video.
Ultimately, we disagree about what constitutes "out of date". My position is, if the content of the video is still valid and correct, and it covers most of what a young player needs to know, it isn't out of date yet, it's a keeper. ~ Amatulic (talk) 02:16, 14 June 2019 (UTC)
I'm really glad the videos helped your child, but I'm just not sure we should specifically cater towards that audience. Maybe we should instead focus on increasing the wiki's readability? I know a lot of articles could really use it. Maybe as a separate project, but I digress. I don't know, the videos just feel very out of place to me, especially when missing good amounts of information. I really hope some other people chime in.
I also wanna say, I got the impression from the videos that they mostly focused on how to obtain the item and how to use the item in gameplay. It's when that information is missing is especially when I feel they should be removed. Especially since I would say most provide a good, solid overview for when they were released, whereas now, they can be missing info that I feel the creators wouldn't have left out if making them today.-PancakeIdentity (talk) 02:35, 14 June 2019 (UTC)
Having watched many of these with my son, I can say confidently that they (at least the ones by the mcspotlights team) are concise yet thorough overviews, covering one specific block or item: what it is, how to obtain/craft it, the primary things you can do with it, and other considerations if there's any time left (these videos seem to be disciplined about running less than 90 seconds). Basically they give a new player all the basic information they need to know in far less time than it takes to read the article. This isn't about catering to children who have difficulty reading (but why not do so? Minecraft appeals to a wider age range than any other game). It's about providing information choices. For the comprehensive details, you read the article, which covers everything known about a topic. If you just want to get a quick understanding, those videos are extremely useful. They're professionally-done, well-scripted overviews. Overviews don't cover all information, by definition. And in many cases the videos aren't out of date. ~ Amatulic (talk) 15:24, 14 June 2019 (UTC)
I see both sides and at first blush fall somewhat in the middle. When I first started using this wiki, I absolutely loved those little video overviews, as did my daughter (we had an experience similar to Amatulic's). But lately, it has become somewhat disheartening to see the frequency of tags identifying videos as out of date. It makes the pages with videos feel out of place.
The rub of the problem seems to be this: If the videos are a core part of the wiki, i.e., an expected element of the basic content and structure of key pages, then most pages should feature current, accurate overview videos - at least the pages about the basic elements of the game, as the videos seem intended for bringing beginners up to speed. If the videos are not a core part of the wiki, then they should not be embedded in the pages at all, as having them on some pages sets up an expectation that they will be present on most pages. This expectation is reinforced by the way the current videos refer to other videos in the series: they present a comprehensive structure of video content about current basic game elements and mechanics, a structure that simply doesn't exist anymore now that so many of the video "nodes" in that structure are out of date.
And that to me seems like the bigger problem: Taken as a whole, the set of mcspotlights videos is no longer about the current game. As a whole, it's historical content, individual remaining videos notwithstanding. The old scheme for how our wiki pages were structured, including overview video content near the end, is no longer viable. As much as still I like the videos and appreciate their professionalism and consistency, I reluctantly have to conclude that it's time to pull them all until we have an active project creating a comprehensive set of up-to-date videos. Meanwhile, we can work on making the rest of the page content as accessible and user-friendly as possible. (Honestly, it seems as though the video content should be its own living project with an active maintenance team, one to which the wiki can point; otherwise, as the game is under constant development, we'll run into this issue of stale videos over and over again.)
If the community's consensus is to keep videos that are still accurate (even if incomplete), then I wouldn't oppose that, though I think the larger issue of the wiki's overall stylistic consistency would still need to be addressed. Memetics talk | edits 11:56, 18 July 2019 (UTC)
I completely agree with you. Having a continuing project for creating updated videos would be great, but if it doesn't happen, I'd rather just remove them altogether. -PancakeIdentity (talk) 23:27, 18 July 2019 (UTC)
I guess we could try to launch such project then, as I stated in the above comment thread early on, I actually suggested doing it, but it kinda stopped there.
If we were to make videos, I suggest making scrips for videos a subpage of the project (eg Videos/Stone for the video about the Stone page).
I'd gladly record it, but I suck at making scripts and never video edited anything, so this will need a collaborative effort nonetheless. FVbico (talk) 23:38, 18 July 2019 (UTC)

Usage of "you" vs "the player" in tutorial pages[edit]

The result of the discussion was to amend the style guide to allow second-person in tutorial articles.

I've noticed that there has been a relatively recent effort (i.e. within the last year) to remove "you" from Tutorial pages and replace such instances with "they" or "the player". While I do think that normal feature pages should not use second person point of view, I disagree that using second person on tutorial pages is harmful. The whole point of a tutorial page is to instruct the reader how to do something, so using third person does not make much sense to me. As I've briefly looked around tutorial pages, I've noticed weirdly-worded sentences quite commonly and I can't come up with good ways to rewrite them. Here are two examples from Tutorials/Your first 10 minutes:

"It is best to create a temporary landmark to indicate your spawn location before the player moves at all". This sentence is addressed directly to the player at the beginning of the sentence, but then refers to the player in third person, causing inconsistency. It could be changed to "It is best for the player to create a temporary landmark to indicate their spawn location before they move at all", but again, it doesn't seem right to be constantly referring to the player in third person when the whole point of a tutorial is to teach the reader how to do something.
"If the player still does not see trees, then start collecting sand (as much as they can get) for 20 seconds, then move on". Same circumstance as above, inconsistent POV usage. Could be changed to "If the player still does not see trees, then they should start collecting sand", but again the whole point of such a sentence is to instruct the reader themselves to do something, so why would it be in third person?

I'd be happy to see what other users think about this. I understand that a lot of users may not end up agreeing with me. But I do want to make sure that if we do end up deciding that despite tutorials being addressed to the reader they should always be in third person, we clear all tutorial pages of structural and grammatical mistakes in articles (e.g. "Keep the player's eyes and ears open for animals in the "First 10 minutes" tutorial), as well as change commands such as "Punch wood from a nearby tree" to "The player should punch wood from a nearby tree". Currently, there is a large amount of inconsistency in POV amongst tutorial pages which really needs to be fixed. Thanks, --Madminecrafter12 (Talk to me | View what I've done) 15:50, 16 June 2019 (UTC)

Noting that if we do end up deciding that "you" is preferred over "the player" in tutorial pages, we need to clarify that in the style guide, which currently says "Articles in the main namespace should always be written in the third-person perspective and without terms referential to the reader".--Madminecrafter12 (Talk to me | View what I've done) 15:52, 16 June 2019 (UTC)
 Support changing tutorials to second person and adding this as a style guideline. I have no objections against the provided argumentation on the purpose of tutorials. (To future posters: please note that whether tutorials should be moved somewhere else is off-topic and should not be discussed here.) --AttemptToCallNil (report bug, view backtrace) 17:57, 16 June 2019 (UTC)
Support usage of second person ("you") in tutorials, but not articles. I oppose being strict about this, however. There are times when "a player" is preferable to "you" even in tutorials, depending on the context. ~ Amatulic (talk) 05:32, 17 June 2019 (UTC)
Yeah, to clarify, I'm not saying tutorials should never use "the player", but it generally should be and there should definitely be consistency in the same sentence (unless, of course, the tutorial is talking about something regarding other players or similar scenarios).--Madminecrafter12 (Talk to me | View what I've done) 13:18, 17 June 2019 (UTC)
 Support "you" on tutorial pages. I suggest to amend the existing style guideline to phrase Tutorials as just an exception to the rule. We don't know how to make Tutorials exclusively use either one or the other style, so just state that it's not exclusive there like it is on regular articles. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:56, 17 June 2019 (UTC)
If this proposal does end up passing, how about adding the following sentence to the second paragraph of the style guide?
"The exception to this is tutorial pages, where in most cases "you" is the most appropriate pronoun to use when referring to the player."
Improvement suggestions are welcome.--Madminecrafter12 (Talk to me | View what I've done) 13:23, 17 June 2019 (UTC)
That sounds perfect to me. ~ Amatulic (talk) 13:49, 17 June 2019 (UTC)
Good, that's what I meant exactly. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 13:58, 17 June 2019 (UTC)
If no one objects soon, I'll add the sentence to the style guide and start changing the pronouns on tutorial pages.--Madminecrafter12 (Talk to me | View what I've done) 13:52, 25 June 2019 (UTC)
Late  Support on being lax on nth-person grammar in tutorials. – Nixinova Nixinova sig1.png Nixinova sig2.png 00:28, 30 June 2019 (UTC)
Thanks, added to the style guide.--Madminecrafter12 (Talk to me | View what I've done) 01:23, 30 June 2019 (UTC)
Also late to the party, but I  Support consistency here over which grammatical person to be consistent with. (Violations of parallel structure and shifts in person make me cringe as a reader.) We should go with whatever person makes sense for each specific tutorial page. Memetics talk | edits 11:12, 18 July 2019 (UTC)
 50 – 50:
 Agree on consistency of using only one perspective.
 Disagree on using second-person perspective. Information on this site are for everyone, there is a pretty great chance that someone looks the wiki up to supply information to another person, thus the looking up one is obviously should not be referred as "you".
Lê Duy Quang (Make some words | Contributions) at 13h54:53 | 4/9/2019 (UTC)
If someone is reading the tutorial to help someone else, they will usually refer to the other person as "you". Writing tutorials this way will match what the readers would say. The BlobsPaper.png 14:18, 4 September 2019 (UTC)

Request for Comment: Enhanced page creation regulation for new users and IPs?[edit]

The result of the discussion was prevent IPs from creating non-talk pages and disable the page creation abuse filter.

It has been proposed that our current system of filtering out undesired new pages, which allows IPs to create redirects (and this has been abused several times recently) and sometimes incorrectly prohibits new users from creating pages, is replaced with a simpler one:

All additional page creation restrictions from new users are removed. IPs are completely disallowed to create any pages.

In addition, this far simpler system can be implemented as a group right change. While this would require wiki manager access, IPs will automatically be told that they can't create pages, and abuse filter logs will be less flooded with nonsense.

This system has been implemented as a group right change on Terraria Wiki and as an abuse filter on Minecraft Wiki (Russian), in neither case causing any significant problems.

Since this is a group right change or an abuse filter equivalent, it would not be inappropriate to let the community comment on this suggestion. --AttemptToCallNil (report bug, view backtrace) 18:04, 17 June 2019 (UTC)

 Support This current system doesn't really work. The admin noticeboard has many false positives and special:log/delete has many of those redirect pages. – Nixinova Nixinova sig1.png Nixinova sig2.png 19:30, 17 June 2019 (UTC)
 This does make sense, but I think there should also be a way for IPs to propose new pages that they themselves have created without having to request them on talk pages. - User-12316399 (talk) 19:33, 17 June 2019 (UTC)
We could have something like Wikipedia:WP:Requested articles. ~ Amatulic (talk) 23:03, 18 June 2019 (UTC)
 Support the creation of Minecraft Wiki:Requested articles. A page like that would be very useful for IPs to propose new pages. 07:26, 24 June 2019 (UTC)
 Oppose the creation of that page. Would be hardly used (this is Minecraft, with limited topic coverage, not Wikipedia which covers everything) and if an IP really wants a page made they can just make an account. – Nixinova Nixinova sig1.png Nixinova sig2.png 07:46, 24 June 2019 (UTC)
 Oppose per Nixinova. -BDJP (t|c) 14:00, 24 June 2019 (UTC)
 Support I would already have signed up if you could just register in Minecraft Wiki. But you have to sign up to Gamepedia, which ask you to sign up to... Twitch. Seriously. I have principles. Hence I want "Requested articles" to be created. 09:32, 20 October 2019 (UTC)
 Support although I prefer to see the English Wikipedia's additional restriction of not allowing page creations for users who aren't confirmed. Auto-confirmation (a group right) seems to happen here immediately after creating an account. On en-wiki, you are confirmed (and can create pages) after your account is at least 4 days old and you have made at least 10 edits. Here, we could do 2 days and 5 edits. A positive side effect is that a new user can still create a new page in his/her sandbox (on en-wiki a new user can also create pages in Draft space). By the time the page is ready, the user will have enough time and edits built up to move the sandbox article to main space. ~ Amatulic (talk) 23:02, 18 June 2019 (UTC)
As far as I know, autoconfirmation cannot be configured on Gamepedia due to the authentication mechanism used. --AttemptToCallNil (report bug, view backtrace) 08:38, 19 June 2019 (UTC)
@AttemptToCallNil: I have run across pages on this wiki that requires autoconfirmation status. So I thought if the protection level is available, and it's a configurable user right, I figured it was something that could be set up. ~ Amatulic (talk) 14:45, 6 July 2019 (UTC)
By that I meant the following: Gamepedia's auth system makes it so that all logged-in users are autoconfirmed, and no additional restrictions (like 4 days since registration and 10 edits) can be imposed. --AttemptToCallNil (report bug, view backtrace) 15:00, 6 July 2019 (UTC)
 Support per above. -BDJP (t|c) 14:00, 24 June 2019 (UTC)
 Support; if implemented as a group right change, this would be clearer for IPs than the current abuse filter system. (I assume this would apply to all non-talk namespaces and not talk pages.) –Sonicwave talk 23:35, 24 June 2019 (UTC)
 Support, assuming this doesn't apply to talk pages. If we have spam issues, a simpler filter to add in addition would be just preventing a user's first edit being a page creation, as I'd assume most spambots won't bother trying to make an edit before making a spam page. MajrTalk
05:56, 1 July 2019 (UTC)
 Support original proposal. I don't think we need Minecraft Wiki:Requested articles, though. Memetics talk | edits 11:01, 18 July 2019 (UTC)
The permission change would be fine by me. It would prevent IPs from creating non-talk pages. Talk pages can still be created by IPs normally.   HorseFace.png Gamepedia icon.png MarkusRost (talk) 23:34, 6 September 2019 (UTC)
 Done, IPs can no longer create non-talk pages.   HorseFace.png Gamepedia icon.png MarkusRost (talk) 20:44, 11 September 2019 (UTC)

Page view statistics[edit]

The result of the discussion was the questions were answered. The topic-starter got the information they needed to perform the desired task. --AttemptToCallNil (report bug, view backtrace) 18:29, 6 November 2019 (UTC)

Is there a tool like the Wikipedia page view stats for this Minecraft Wiki?

I thought I'd look at the top-viewed pages to see if they need cleanup. One thing I've been doing is changing future tense to present tense, as has been discussed. Today I finished doing that for Villager and a few other articles I thought might be highly visible. ~ Amatulic (talk) 23:50, 28 June 2019 (UTC)

Unfortunately, there is no such tool for Gamepedia wikis available publicly. The only tool that allows to access views per page is the administrator tool showing statistics about the wiki. And from it it could be gathered that the most viewed pages in last 30 days are to no surprise Villager, Enchanting, Brewing, Blast Furnace, Conduit, Java Edition 1.14, Composter and so on. Frisk (Talk page) 08:16, 29 June 2019 (UTC)
There used to be a special page for the most viewed pages, but it was improved and added to a ton, and got admin-only. Somewhere within the last 7 years. It's now indeed called Statistics, I've noticed this change myself too on my own wiki. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:18, 29 June 2019 (UTC)
@Frisk: Thanks. That short list you provided is good enough for now. I figured Villager was near the top, but I'm surprised Blast Furnace is in the top 10.
@Jack McKalling: Special:Statistics doesn't show page views but it does show other interesting information. ~ Amatulic (talk) 00:34, 30 June 2019 (UTC)
Oh woops, I meant Special:Analytics, not statistics. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:11, 1 July 2019 (UTC)
Ah. Yes, that page isn't visible to me. Anyway, I've corrected the verb tense in all the articles in the short list you provided, as well as others. ~ Amatulic (talk) 03:59, 2 July 2019 (UTC)

To what extent should we fix bug report titles?[edit]

The result of the discussion was the user was provided with relevant information.

Bug reports often have spelling or grammatical errors in them, or in other ways just don't comply with the general style of wiki writing. I've seen many bug reports that have been changed on version pages to fit the style guide and others that haven't. To what extent should we fix errors in these titles? -PancakeIdentity (talk) 05:42, 5 July 2019 (UTC)

This has been discussed before and basically the titles can be freely edited to match the style guide. – Nixinova Nixinova sig1.png Nixinova sig2.png 05:45, 5 July 2019 (UTC)
As long as it doesn't completely change the meaning of course. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:17, 6 July 2019 (UTC)

New village blueprints - templates broken[edit]

The result of the discussion was the issue was addressed. The pages were changed to use the JS-based page loader and no longer display Lua errors. --AttemptToCallNil (report bug, view backtrace) 18:31, 6 November 2019 (UTC)

The New Village Blueprints page is broken, and I'm trying to determine the correct/best way to fix it. It seems the page has reached some threshold where the wiki won't process templates anymore. Most of the page is fine, but the last several blueprints on the page just show the template name instead of actually rendering the BlockSprite or other templates correctly. When previewing individual sections instead of viewing the whole page at once, the templates work fine. My instinct would be to either make each village type loadable on demand the way the blueprints currently are, or split each village into its own page (plains village page, desert village page, etc). However, I was hoping to get a bit of guidance before making a large-scale change like that. -Aronson 1 (talk) 15:41, 6 July 2019 (UTC)

I'd make all blueprints load on demand as only some of the blueprints are now. --AttemptToCallNil (report bug, view backtrace) 17:11, 6 July 2019 (UTC)
Yes that's a good start. There aren't that many blueprints directly on the page and there are still a good number of Taiga and Snowy buildings left to add (which have their own material tables) so I'm worried we'll run into this again, but I suppose we can deal with that if/when it happens. --Aronson 1 (talk) 18:35, 6 July 2019 (UTC)
Minecraft Wiki:Projects/Structure Blueprints/Underwater Ruins seems to suffer from the same problem, with most of the blueprints just reading "#invoke: layered blueprint" instead of displaying the actual template. 06:38, 7 July 2019 (UTC)
It seems to show up fine in the edit window but not when on the page itself. Weird. – Nixinova Nixinova sig1.png Nixinova sig2.png 06:44, 7 July 2019 (UTC)
The blueprint template is very expensive. It shouldn't be "spammed" on one page that often like that. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:16, 7 July 2019 (UTC)

Edition Problem[edit]

I'm aware that there is already a project started for changing how different versions are discussed on the wiki. However, as far as I know, the project hasn't really gotten anywhere, and I want to bring attention to it again. We really need to focus on that, and in the meantime, decide what information to include. Minecraft currently has 6 different editions (JE, BE, LCE, PS4, EE, 3DS), all in some way different from one another. This gets even more difficult as LCE and 3DS have been discontinued, and different versions of LCE were discontinued at different times. In addition, we have stuff like the Apple TV edition which was PE edition that stopped being updated before Bedrock replaced it. I'm sure active editors have also noticed how different pages will include different versions and exclude others with no consistent rule. And, on pages such as Trading, it can get messy as we essentially have 2 different pages due to the massive differences between version.

This is a hugely complicated mess and we really need to finally decide what to do. The page is here: MCW:Projects/Refactoring edition specific information. Please contribute if you can. -PancakeIdentity (talk) 04:58, 18 July 2019 (UTC)

Interwiki files[edit]

Hello everyone! I come from the Portuguese Minecraft Wiki. Should we can use the file from other Minecraft Wiki in our Minecraft Wiki? For example: by using [[:pt:File:exemplo.png]] on English Wiki, will show the exemplo.png file from the Portuguese Wiki. I don't know if you understand me, but is like MediaWiki Commons is related with (every) Wikipedia. It'll be awesome for minor Minecraft Wikis. Thank you! --Dr03ramos (talk) 14:50, 30 July 2019 (UTC)

This wiki is a shared repository for language wikis, so other wikis can use images from here but not vice versa. – Nixinova Nixinova sig1.png Nixinova sig2.png 05:29, 1 August 2019 (UTC)
Yes, but is still necessary make re-uploads in the other wikis. seria melhor sem uploads, como no wikimedia commons. --Dr03ramos (talk) 15:48, 26 August 2019 (UTC)


(See Also: User:Blobs2/Renewable resources#Quasi-Renewable Resources)

Many pages have recipes involving elements or compounds because of {{crafting usage}}. However, this implies that the player can obtain these items, which is not true since the chemistry GUI blocks are not legitimately obtainable (they can only be obtained in Creative or with commands, and the player must be in a world with “Education Edition” enabled). We should have a template that explains this, which would be used to describe methods of obtaining certain blocks and items, including when {{crafting}} is used. It could look like this:

{{{1}}} cannot be obtained in Survival without commands and can only be obtained in Education Edition, or in Bedrock Edition worlds with “Education Edition” enabled. Therefore, the same rules apply to {{{2}}}.

I have written a similar paragraph on the Element page, but I would want to extend it to all chemistry pages. The BlobsPaper.png 15:19, 3 August 2019 (UTC)

 Support this as the chemistry blocks are not renewable. —HaydenBobMutthew (talk, contribs) 04:43, 19 August 2019 (UTC)

Pages for blocks/items that are only textures?[edit]

What do you guys think of the pages about blocks/items that are limited to only having textures in the game's files getting pages? Something about it seems wrong to me, like its super speculative or something. I personally think these pages shouldn't be made and the texture references put somewhere else. -EatingSilencerforBreakfast (talk) 00:22, 23 August 2019 (UTC)

I am also opposed to such pages. They should just be sections in the unused features pages. The BlobsPaper.png 01:19, 23 August 2019 (UTC)
I have turned those pages into redirects while retaining the page content so that it can be quickly fixed when they are implemented.  Nixinova T  C  07:40, 23 August 2019 (UTC)

Create and update new videos like how mcspotlights did[edit]

The result of the discussion was proposal approved. Further discussion can be done at the video project page or in the #wiki-videos Discord channel. –Sonicwave talk 00:25, 18 February 2020 (UTC)

I know, hear me out first.

I propose we create new videos for all pages that cover certain topics, and update them if new things need to be mentioned/changed.

The videos would have to be voiced by active members, or administrators/directors on the wiki (preferably the latter) in order to keep it in a similar line with other videos.

Editors on the wiki would be able to assist with the creation of the videos (unlike with mcspotlights) by providing scripts and or note things that definitely need to be shown/talked about.

Speaking of scripts, we could save them on a semi-protected subpage for confirmed editors to assist with (eg Creeper/video_script). These pages would need to follow a format to be consistent, but that's up for discussion.

The videos would need to be uploaded to a wiki youtube channel, and not a personal one; all admins should have access to this channel, as well as a few select editors.

Who here thinks this is a good idea and would like to assist with it?

People willing to help out
Voice recording
Video recording
Video editing
Script providing
Subtitle Translator

If you like to help out, please add yourself to the sections above. FVbico (talk) 15:50, 24 August 2019 (UTC)

EDIT: some clairifications after internal discussions:

  • Not only admins would have power over the channel, trusted regular editors would be asked as well.
  • The channel would not be limited to only english videos explaining game content, but also other languages (if they chose to do so) and other wiki related videos (such as talking about upcoming changes to the wiki, or recent changes to, eg, the style guide).
  • Subtitles would be able to be suggested by anyone, but would need to be checked by the people who have power over the channel, either by someone who knows the language, or someone who puts it through a translator to see if it pretty much matches with what's said.
  • We will not take an existing channel, but instead create one depending on the outcome of this discussion.

I hope this clears things a bit up, and I'll extend this list of small decisions/clairifications as the topic gets discussed. FVbico (talk) 16:51, 28 August 2019 (UTC)

Note that these videos are likely to end up mostly useless for non-English readers, and non-English editors may be unable to record their own versions as this requires very substantial effort. I believe the German wiki is the only other one which will ever be able to create something similar. --AttemptToCallNil (report bug, view backtrace) 15:58, 24 August 2019 (UTC)
(Thanks for the spelling fix, missed that one.) True, but youtube videos support subtitles, which can be suggested by anyone as well; so other language wiki admins/editors could suggest subtitles. FVbico (talk) 16:21, 24 August 2019 (UTC)
Subtitles are a very interesting idea. That means I no longer have substantial objections against videos. Just wondering, what does providing scripts involve? --AttemptToCallNil (report bug, view backtrace) 16:39, 24 August 2019 (UTC)
The scripts would be the text which'd be spoken in the video, along with notes on what to show, where to put emphasise on, etc. It wouldn't be the same as the article itself, which'd go in much more detail. FVbico (talk) 17:08, 24 August 2019 (UTC)
I'm willing to edit videos. Perhaps I could make a script once in a blue moon, but I'm not quite sure about that yet (which is why I put my username in small font in that section). —DarkShadowTNT (t ♦ c) 23:12, 24 August 2019 (UTC)

I also suggest adding subtitles in another language (in my Portuguese case that I can translate)--Eduaddad (talk) pt.Wiki Administrator 16:42, 25 August 2019 (UTC)

In my opinion subtitles should be translated by administrators of their respective Minecraft Wiki languages ​​and subtitles should not be available for translation on YouTube --Eduaddad (talk) pt.Wiki Administrator 17:21, 25 August 2019 (UTC)

Good point, or at least constructive wiki members. FVbico (talk) 17:23, 25 August 2019 (UTC)
We need to establish a subtitle submission method (for example: Discord Channel, Google Drive Folder, Minecraft Wiki Page) --Eduaddad (talk) pt.Wiki Administrator 17:32, 25 August 2019 (UTC)
Youtube has a function for the community to support with translation. just need to enable it. --Dr03ramos (talk) 15:42, 26 August 2019 (UTC)

If approved, this can become a project --Dr03ramos (talk) 15:42, 26 August 2019 (UTC)

I personally don't think we should include history information within the videos, since it isn't included anywhere in the main article outside of the History section. Also, will we have to make new videos for everything once an update hits? - User-12316399 (talk) 19:06, 28 August 2019 (UTC)

It wouldn't, as that's not relevant to the viewers anymore, also "and update them if new things need to be mentioned/changed". FVbico (talk) 21:56, 28 August 2019 (UTC)
I'd be up for captioning videos in English UK if I can figure out how the youtube caption system actually works. - User-12316399 (talk) 14:43, 5 October 2019 (UTC)
It's a bit quiet here, perhaps an example should be made to better get responses? An easy to cover one is the parity issue list.
If anyone has anything else to say about this that's not uncertain depending on how the videos would turn out, you can already say it. FVbico (talk) 22:23, 27 October 2019 (UTC)
Let's start finding out why we can't really make anything like that making videos, no? I can help with writing scripts and Russian subtitles (both with big maybe). --AttemptToCallNil (report bug, view backtrace) 22:38, 27 October 2019 (UTC)
Bear in mind that the channel's name is pretty important such as " Minecraft Wiki". Since the videos are not supervised by Mojang, we should be pretty careful on the name chosen.--skylord_wars (talk) 01:25, 29 October 2019 (UTC)
Created a project page for it now: Minecraft Wiki:Projects/Wiki videos. FVbico (talk) 19:07, 6 November 2019 (UTC)
I think it's best not to recycle an existing account, and instead make a new one. FVbico (talk) 17:08, 24 August 2019 (UTC)
(Split off discussion) What do others think, recycle that channel, or create a new one? FVbico (talk) 17:49, 24 August 2019 (UTC)
I propose creating a new channel. First, there is the matter of ownership, which I believe would need to be transferred to a more involved wiki participant (like what happened with the Discord server). Additionally (and I believe this to be more important), I find it weird that this channel has no content and over 72 thousand subscribers. If this is a result of some manipulation, it could open the channel to sanctions in the future, which would be completely unacceptable if the channel hosts our videos. --AttemptToCallNil (report bug, view backtrace) 18:41, 24 August 2019 (UTC)
I suggest a new channel like "MinecraftWiki". This generic name would open up the channel for more than one purpose, promote itself for the wiki specifically, it would be recognisable and official, and I agree it needs to be owned by an involved wiki editor/ranked editor. It would be nice if we could share ownership of it though, within the/a group of video-creators on the wiki. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:25, 25 August 2019 (UTC)
I'd also prefer if we started a new channel; it would probably seem strange to readers for the channel to already have 72,000+ subscribers with only a few recently uploaded videos. The current subscribers of that channel might not be expecting (English) Minecraft content, depending on what type of videos (if any) used to be uploaded there. –Sonicwave talk 00:03, 26 August 2019 (UTC)
I also think it. --Dr03ramos (talk) 15:42, 26 August 2019 (UTC)
If we have more support/people willing to help out, I'll make the channel then, but until such time, it's best to wait, as this proposal might not launch still. FVbico (talk) 06:33, 26 August 2019 (UTC)

Sound file attribution[edit]

This was discussed before in this archived thread, but didn't get very far. Samuel Åberg's twitter ("slamp0000") describes him as the lead sound designer for Minecraft; however most sounds on this wiki have {{License C418}} slapped on them. In addition, this minecraft.net attribution page shows that some sounds were taken from Freesound.org, though likely edited afterwards. Since it's not clear which sounds were created by C418 or slamp0000, perhaps all non-music sounds (not taken from Freesound) should simply be tagged with {{License Mojang}}; the sounds listed on the "Sound attributions" page would instead be tagged with the license listed there. –Sonicwave talk 19:03, 27 August 2019 (UTC)

Not a licensing expert, but I agree with this proposal. --AttemptToCallNil (report bug, view backtrace) 19:05, 27 August 2019 (UTC)
I might go ahead and begin slowly changing the non-music sound descriptions to use {{License Mojang}} instead of {{License C418}}. I'm not sure how to figure out which sounds are from Freesound without listening to everything on the attribution page and seeing what sounds familiar, since the files don't have attribution info in their metadata (unless I looked in the wrong place).
Also, License C418 says "In agreement with C418, Minecraft sounds are allowed to be hosted on the wiki. All music must be shortened to the first 30 seconds"; is this agreement publicly viewable or was it made through something like a private IRC channel? –Sonicwave talk 06:11, 5 October 2019 (UTC)

Minecraft PE[edit]

Please make the "codes" for Minecraft PE. I'm having trouble understanding because I play on PE. -Person with no name (I made it like this) 03:33, 14 September 2019 (UTC)

The block and item IDs (both numerical IDs and namespaced IDs) can be found here. If I misunderstood your question, please clarify. The BlobsPaper.png 04:12, 14 September 2019 (UTC)

About screenshots with old textures: opinions[edit]

Since Java Edition 1.14, the textures are changed and many screenshots got outdated. I hope people can upload the new versions with new textures. Opinions about support this or keep the original images (don't update the screenshots), or just being optional? I have make a category "Screenshots with old textures" to reflect this as a part of the Screenshot Fixing Project. --HaydenBobMutthew (talk, contribs) 12:37, 17 September 2019 (UTC)

 Support Like other screenshot fixes, this should be a long-term goal. We may want to leave some screenshots to show how the old textures appeared in-game. The BlobsPaper.png 13:21, 17 September 2019 (UTC)
 Support where it makes sense. - User-12316399 (talk) 14:43, 17 September 2019 (UTC)
 Support from me Oakar567 (talk) 15:48, 17 September 2019 (UTC)
 Support setting screenshot updating as a long-term goal. --AttemptToCallNil (report bug, view backtrace) 16:14, 17 September 2019 (UTC)
 Support. I had already been doing this myself.  Nixinova T  C  20:27, 17 September 2019 (UTC)

We need to talk about the Texture Update[edit]

It's been five months and yet the wiki is still a complete mess due to the texture update, with files labelled "Texture Update" remaining in infoboxes and many older revisions of blocks missing from history sections, as well as new textures being passed off as old due to funkiness with file moving. Not to mention that history sections are, in many cases, outrageously incomplete; for many of them, early revisions from the resource pack releases of the Texture Update are completely omitted, which isn't good at all. We need to get this sorted out sooner rather than later.

I propose the following:

  • Check through infoboxes to make sure Texture Update files aren't being used in the infoboxes
  • Make sure all non-historical renders are up to date
  • Check through the histories of Texture Update files and upload to new filenames any prior revisions of blocks, items and mobs that aren't yet noted in the history sections
  • Check through all the official Texture Update resource packs for any textures that may not have been uploaded here in the first place, and (render then) upload them
  • Maybe use a script to check through those resource packs (and old releases of Java Edition, just to be sure)?

There will probably be a few other steps required to get us out of this mess, so I'd rather get the to-do list finalised so we can get all of this finally cleaned up. - User-12316399 (talk) 15:13, 18 September 2019 (UTC)

It'd been worked on for a while, not sure what happened to it. I'll pick up the project again. -PancakeIdentity (talk) 18:08, 21 September 2019 (UTC)
Just made a project, Minecraft_Wiki:Projects/Texture_Update_Cleanup. -PancakeIdentity (talk) 23:19, 29 September 2019 (UTC)

Some changes I've made to infoboxes[edit]

I've done some stuff to infoboxes today and felt like I should check in here and ask for other peoples' thoughts on the matter before I proceed further.


I've decided to create a new infobox to split off fluids into. This might be a bit excessive, since there's technically only three fluids in the entire franchise, but they do behave considerably differently from other blocks, and it's worth noting that they probably won't even be considered blocks anymore with the planned fluid split (assuming that actually ends up going through, of course). I've equipped this template with its own set of parameters specific to liquids, and it seems to hold together relatively well. See Water, Lava and Mud for examples.

Biome colorations in Template:Biome

I added some fields to the Biome infobox that record biome-specific plant, water, sky and fog colour codes. A test case can be seen at Badlands#Badlands (I haven't filled in the details on any other infoboxes, though). While they fulfil their job I feel as though they take up quite a big chunk of vertical space, which I feel could potentially be alleviated by compressing all of these values into some sort of "Biome colors" title, collapsed by default but expandable, like what can be seen here. Are there any other thing whose colours/appearances vary by biome (I think fog is one, or at least it will be in 1.16), and should I even continue with this in the first place?

Splitting sounds and drops into their own sections

This is another thing I've considered doing for a while. I decided to give it a shot (see Anvil#Sounds and Barrel#Sounds) and want feedback on this way of setting it out. I thought that sounds took up a bit much space on some of the infoboxes, and also believed that there was much more that could be said about them in a dedicated section (i.e. their internal IDs, their subtitles, volumes, pitch ranges, and the sound type category thing you specify in playsound).

Drops is another thing I'm not really happy with being inside the infobox, since again, there's a lot more that could be elaborated upon that would end up clogging up the template were it kept in it, such as how many of each item it could drop with Fortune, different drops depending on tools, and other conditional stuff. A dedicated section for drops, roughly equivalent to the Obtaining section, seems like a better move. Granted, this may result in lots of trivial repeated information (Breaking a barrel with any tool drops a barrel.), but this shouldn't be too much of an issue. On the topic of drops and obtaining, I think we should try reformatting the Obtaining section to more closely resemble the French wiki's obtaining sections, since monotonous paragraphs of text are boring, harder to digest and retrieve information from, and are generally less pleasing to the eye.

Any thoughts on these? - User-12316399 (talk) 19:36, 30 September 2019 (UTC)

I've now split off all block and enchantment sounds into respective sections and removed the Sounds parameter from the infobox template. Eventually I'll complete items and then mobs as well. - User-12316399 (talk) 07:46, 3 October 2019 (UTC)

...and some changes I want to make[edit]

Removing the Drops and Experience fields

I've detailed in the section below my proposals for how these would be documented. With those moved into that new section, these fields would become redundant and could be removed.

Removing data values

I'm not sure these (numerical IDs, at least) should be documented within the infobox, since the plan appears to be to remove them and perform a flattening across Bedrock Edition for parity reasons. We could probably keep the namespaced IDs there, though, since those will be official for as far as we can see going forward. Numeric IDs will still be kept in their own section. I'm also not sure about tags, these could probably also be relocated to a more technical section lower down.

Flammability values

Certain blocks are more flammable than others, should the values for them be documented in the Flammable row?

Removing the tool fields

These are already documented in the very first section of most blocks, so do they really need to be documented in the infobox? (I do feel as though the section in question is rather incomplete in itself, and could do with more info such as the effects of Haste, Efficiency, and different tool types, as only listing unenchanted tool times feels very incomplete.)

Add more parameters

Now that we've relocated a bunch of block info to dedicated sections where they can be described in further detail, is there anything we could replace them with in the infobox that doesn't need much further elaboration? Two that come to mind are how much they slow entities passing through them (the value we'd show here would be the number they multiply entity movement by), and how slippery the block is (this only applies to a small set of blocks, though).

Any thoughts on these ones? - User-12316399 (talk) 09:36, 1 October 2019 (UTC)

We should keep numerical IDs until the flattening. The BlobsPaper.png 13:59, 1 October 2019 (UTC)
Should they be marked as Bedrock Edition exclusive as to not cause confusion? - User-12316399 (talk) 14:37, 1 October 2019 (UTC)
I'd support that. Make sure to use the short=1 tag. -PancakeIdentity (talk) 01:45, 13 October 2019 (UTC)


I feel like you should have copied the templates into your sandbox and made changes to them to see if they really work and fit. "Editing in production" has a risk of ruining pages. Lê Duy Quang (Make some words | Contributions) at 9h58:44 | 1/10/2019 (UTC)

Regarding sounds, what would go under "Pitch, Volume, and Min. volume"? The default sounds.json file does specify volume and pitch for some of the sounds, but all of the sounds already have different pitches and volumes anyway, so in my opinion this wouldn't make much sense for a casual reader. I can see the "source" column being useful (though it would be better renamed "category", "type" or "volume setting"), though that would require reading decompiled code since categories are no longer specified in sounds.json since 1.9.

Also, we should probably amend Minecraft Wiki:Style guide/Features to specify where the sounds section should be placed within the article. –Sonicwave talk 05:48, 5 October 2019 (UTC)

Those parameters are pretty much completely ripped off from the playsound command with no real knowledge of how they work. However, it's definitely possible to see that pitch is definitely one worth noting - glass breaking sounds and piston sounds are always lower pitched than their default values from the command, and some sound sources have variable pitches, such as sheep (and don't forget that baby animals are affected).
As for where to put these, I've just been putting them before Data values or Achievements, whatever comes first. - User-12316399 (talk) 20:52, 5 October 2019 (UTC)

The biome colors definitely need to be listed somewhere. Any chance we could display what these colors actually look like? Also, I'm not sure about removing them from infoboxes, but I definitely support expanding the breaking time table/template to include Haste and Efficiency. -PancakeIdentity (talk) 01:45, 13 October 2019 (UTC)

I would  Support to have colors inside infoboxes.--skylord_wars (talk) 08:19, 2 December 2019 (UTC)
I am not sure about including Haste or Efficiency in breaking rows, ad it would make them too complicated. Even if we only show Efficiency for diamond tools and only show Haste for diamond tools with Efficiency V, that is 13 scenarios instead of the current 6. The Breaking page does a good job of explaining the times in these situations. The BlobsPaper.png 14:46, 2 December 2019 (UTC)

Handling loot tables on the wiki: a proposal[edit]

Currently the information on the wiki regarding obtaining blocks and items from entities and the like is a complete mess. It's pretty spread out and not consolidated into standardised sections like crafting and smelting information is. I propose that we fix this by having loot be handled much like recipes currently are.

Firstly, the Obtaining section would be split into up to four sections: recipes (for when the time is obtained through crafting, smelting and the like), loot (for when the item is obtained as a drop, from chests, fishing), trading (for when obtaining the item via trading), and other usage (filling and emptying buckets, filling and emptying bottles, filling bowls via milking and eating foods in bowls).

A proposal for how blocks would work: we should handle the "this block drops" and "obtaining this through drops" sections like we currently handle "usage of this as a crafting ingredient" and "obtaining this through crafting" sections:

  • on the block's page, the Usage#Drops section contains a small one-row table describing what the block drops under the following conditions: silk touch, unenchanted correct tool, fortune I, fortune II, fortune III, no tool or too low tier tool, correct tool II (if applicable e.g. shears on cobwebs)
  • on the desired block or item's page, the Obtaining#Loot section contains a template that calls for all blocks that drop this specific item when mined. it then displays that table in this section, including the entries that don't drop the desired item.

For example, here's how it would work with coal ore and coal:

  • Coal ore's drops are listed in the Drops section of the coal ore page in a table like this:

Block Silk Touch Correct tool Fortune I Fortune II Fortune III Incorrect tool
Coal Ore 1 (100%) 1 (100%) 1 (66%)
2 (33%)
1 (50%)
2 (25%)
3 (25%)
1 (40%)
2 (20%)
3 (20%)
4 (20%)
Nothing (100%)
  • The coal page calls for all blocks that drop coal, and lists coal ore's table entry, showing players that mining with the correct tool will drop coal, and advising them not to use ineffective tools or Silk Touch as these do not yield coal.

Now I think entity drops should be handled in much the same way, but the problem with this is that entities have a lot more weird conditions where they can drop different stuff depending on how they were killed. We'd need to consider death while on fire, skeleton arrow kills, charged creeper kills, among other things, and there's even cases where mobs drop things without even dying, such as chicken egg laying, turtle scutes, cat and villager gifts, and we could go yet further with the yet more weird cases such as shearing. (In fact, this even extends to blocks somewhat, with berry bushes, pumpkin shearing and also the advent of beekeeping.) Naturally-spawned equipment on mobs throws yet one more spanner in these theoretical works, and I think these should be kept on a separate table from the rest.

Chest loot and fishing loot probably shouldn't be as difficult to do, but should be also put into a table format like the other obtaining methods.

There's a few more things I want to mention on this matter:

  • We could also move experience drops into this section, since they almost universally accompany all types of loot except chest loot.
  • Don't forget that mobs are also a thing that can be dropped as a type of "loot" (see infested blocks, turtle eggs, splitting of slimes), which could also be integrated into the table somehow.
  • If we include experience drops and mob spawning as parts of these tables, could we also have drops sections for projectiles? Thrown bottles o enchanting drop experience, thrown chicken eggs can drop chickens, and thrown ender pearls can occasionally drop endermites, so it might just fit in well, but this might be getting out of the scope of "loot". We could even consider explosions as a type of loot, but that's probably another step too far.
  • We should address blocks more or less informally when describing what they drop. For example, we wouldn't distinguish between what a torch drops and what a wall_torch drops, since in casual gameplay those are the exact same thing despite having different block IDs. We would distinguish on different block states if they make a difference, such as wheat that's fully grown as opposed to wheat that's not.
  • As I addressed above, mobs can drop items without having to be killed first. Should we have separate tables for "mob loot from killing it" and "mob gifts from the living thing", or should they be merged together? If these are to be made separate, should we also have block interactions such as berry harvesting kept separate as well?
  • The template should be designed to merge a source block or entity if it can drop multiple different items, similarly to how consecutive identical major versions are merged by the History template. Here's an (incomplete) example table:
Block Correct tool
Oak Leaves 1
  • We'd have trivial self-referential cases, such as a section on the Block of Redstone page saying that breaking a Block of Redstone drops a Block of Redstone, and another section on the same page saying that a Block of Redstone can be obtained by breaking a Block of Redstone. I really don't think that's anything worth worrying about though.
  • Blocks and entities that don't drop anything should still have a drops section to be consistent with the rest, since most of the time (at least in the case of entities) they do still drop experience.

Any thoughts on this system? - User-12316399 (talk) 08:14, 1 October 2019 (UTC)

I sorta agree with the "Fortune" table, but it can be more visualized by generating a small graph in each cell (I will try to create a preview of this using HTML and CSS later).
For conditional loot, another type of table can be created:
Loot type Dropped when...

Drop conditions

Gold ingot Killed by a player.

5% chance.

Trident Killed by a player.

1,25% chance.

... ...
If a condition is repetited multiple times, I think we can use color codes and a legend table.
If the chance involves Looting, we can embed a sub-table like the Fortune table.
About "entities" as "drops", from my point of view, I don't consider silverfish, small slimes,... as loot, they are special functions of the block/entity when triggered, thus they should be addressed as "special behaviors" or something similar.
Lê Duy Quang (Make some words | Contributions) at 8h29:26 | 1/10/2019 (UTC)

Here is the table I attempted:
Loot table proposal – Mining.png
Lê Duy Quang (Make some words | Contributions) at 9h48:08 | 1/10/2019 (UTC)
I would prefer to keep the non-enchanted versus enchanted options closer together, so if you switch Silk Touch with Incorrect Tool, that should be better. In your example Le Duy Quang, you're using percentage heights for each cell to represent their values. I don't know if I'd like that, as this technique is not used elsewhere on the wiki and would be inconsistent design. Not saying it shouldn't be used, but if not, it would look like this (please excuse resolution, I just messed around):
Loot table proposal2 – Mining.png
Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:36, 1 October 2019 (UTC)
As we're on the topic of percentages for each item count, I think this is a point worth considering. - User-12316399 (talk) 11:46, 1 October 2019 (UTC)
The behavior of the lowermost cell filling the rest of the column is just ugly and illogical in my opinion. At least in each column, distribute the height of each cell. Lê Duy Quang (Make some words | Contributions) at 14h05:35 | 1/10/2019 (UTC)
Here is the updated version of the table using my new template In-cell graph:
Block Incorrect tool Silk touch Correct tool Fortune 1 Fortune 2 Fortune 3
Coal Ore
Nothing (100%)
1 (100%)
1 (100%)
1 (67%)
2 (33%)
1 (50%)
2 (25%)
3 (25%)
1 (40%)
2 (20%)
3 (20%)
4 (20%)
Lê Duy Quang (Make some words | Contributions) at 14h02:55 | 1/10/2019 (UTC)
 Support something like this. It looks nice, is informative, and gets across much more than the current single sentences we currently use in most situations. -PancakeIdentity (talk) 02:00, 12 October 2019 (UTC)
 Support For complex pages like this, it is much advisable to use graphs or diagrams. But for others that's fine. We should draw a clear boundary whether to use tables or not.--skylord_wars (talk) 06:47, 29 October 2019 (UTC)
Perhaps we could still have a table like that, but hidden by default, and a more simplified version displayed so the full information can still be accessed without cluttering the page up too much? Or would this just complicate the code even further? - User-12316399 (talk) 09:28, 29 October 2019 (UTC)

So how exactly will we sort the Obtaining section once this is implemented? I'm thinking something like this (although named differently):

  • Obtaining
    • Loot
      • Blocks (this section itself contains stuff like ready composters, ready berry bushes, and shearing pumpkins)
        • Block drops
          • Contained items
      • Non-mob entities
        • Non-mob entity drops
          • Contained items
      • Mobs (this section itself contains stuff like cat and villager gifts, laid eggs, shearing, etc.)
        • Mob drops
          • Mob equipment
          • Contained items
      • Fishing
      • Loot chests
    • Recipes
      • Crafting
      • Smelting
      • Blasting
      • Smoking
      • Campfire
      • Stonecutting
      • Brewing
      • Loom
      • Enchanting
    • Trading
    • World (items that can be obtained by changing an existing item, such as filling bottles and milking cows)

Are there any other notable categories I missed? - User-12316399 (talk) 12:00, 6 October 2019 (UTC)

I've transferred all smelting and mining experience drops from blocks and items into the main text of articles and removed the Experience field from the blocks infobox, in line with this Obtaining reform. I've requested a change to the Smelting template to better incorporate this information into the article (4 years ago, funnily enough). Would anyone be willing to implement this change (and also the newer one noted beneath it)? - User-12316399 (talk) 14:29, 9 October 2019 (UTC)

I might try setting up a couple of examples on images soon, but I don't have much knowledge about scripting so the pages for the items they drop won't be able to automatically read and display the information. Also, would people be okay with me removing the experience parameter from the entity template and moving said information to the drops section? - User-12316399 (talk) 13:26, 18 November 2019 (UTC)

Some examples can be seen on Coal Ore#Loot, Diamond Ore#Loot, Grass Block#Loot, Gravel#Loot and Hay Bale#Loot. The template seems to be acting up a bit, though, since the values are clipping into cells below. - User-12316399 (talk) 15:58, 18 November 2019 (UTC)
I'm not sure if we need every column on pages like Hay Bale. Could we do something else for cases like that? -PancakeIdentity (talk) 03:46, 19 November 2019 (UTC)
The """fix""" for the hay bale page is still awful. I don't think we even need a table in that case. The tables should just be used for blocks that can have different drops. -PancakeIdentity (talk) 04:49, 20 November 2019 (UTC)
Replaced with two relatively short sentences. Header renamed to "Drops": I believe "loot" would typically apply to defeated mobs or treasure containers, not broken blocks. --AttemptToCallNil (report bug, view backtrace) 08:03, 20 November 2019 (UTC)
 Veto the usage of {{ICG}} as it breaks completely on mobile. Something like the first table example is good though. Adding colours also isn't really necessary.  Nixinova T  C  23:16, 20 November 2019 (UTC)

February 2020[edit]

I've went ahead and created a new template, Template:Experience, which should be better than the previous method for transcluding experience drops. Sooner or later I plan on moving all Experience and Drops information from infoboxes into their dedicated sections in the respective pages, and then ripping out the Drops and Experience parameters from the infoboxes themselves, so if anyone wants to comment on that do it sooner rather than later. After this is done all the information will be in their respective sections and will be ready to be organised into the new table format when we've all come to an agreement on that.

A lot of people seem to be taking issue with blocks that drop themselves having dedicated tables. I did mention this before, but nobody seemed to have any problems with it with it until the trial implementation. I do think they should still have dedicated tables in articles - they do have their own loot tables, after all - but for these trivial cases they should be collapsed by default as to not take up a lot of space with this bland information. Blocks that do have non-standard drops would be open by default. Of course, this would mean that we'd make the table template collapsible and expandable, which doesn't seem like much of a challenge.

Otherwise, everything looks to be just about fine, and it shouldn't be much of a problem to take the newly added netherite tools into consideration for these templates. Is anyone else willing to contribute anything? - User-12316399 (talk) 10:14, 17 February 2020 (UTC)

Ginormous maintenance categories[edit]

Have a butcher's at these things:

These maintenance categories have grown to contain hundreds of pages needing attention. Yet, despite this, it seems as though few people are actually trying to fix the issues with these pages. I'd think that the sheer size of these categories for one is one of the main contributing factors to how these have grown out of control - why bother with fixing these pages when there's absolutely hundreds of them and it would take hours of arduous effort?

I think this calls for a split of these categories. I'm not sure how to do Information needed, Verify and Stub, but Unknown version history seems rather basic; splitting by edition and then by development period would probably dice it up into manageable chunks. Of course, it's no secret that the history template itself has a fair share of other issues that need working out, so maybe this category splitting thing could be done en route. Does anyone have any ideas as to how the other three (and any other problematic categories) could be divided up into bite sized chunks? - User-12316399 (talk) 09:02, 8 October 2019 (UTC)

I don't know information needed or verify either, but at least stub could be gone through and split on a case by case basis by adding an additional argument into the template call, such as a particular type of page (like content, project, person, version, etc). Of course it can already be split between full-page and section-specific, by detecting whether or not that argument was specified. Good idea to start with these categories before any big history template overhaul, because missing information always makes things like this difficult. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:09, 8 October 2019 (UTC)
  • Every so often I scroll through Category:Verify and fix what I can. I do agree that it should be split more since I just deal with modern Java when I go through the list. There should be a {{verify|historical=yes}} or something to exclude history verifications, and unknown v.h. should definitely be split by edition; that doesn't seem difficult to do.  Nixinova T  C  00:38, 9 October 2019 (UTC)
Since {{history}} already checks which edition is being referred to, it should not be difficult to have categories for "Unknown Bedrock Edition version history", "Unknown Java Edition version history", etc. The BlobsPaper.png 01:22, 9 October 2019 (UTC)
Category:Testing needed and Category:when are out there, too. – Sealbudsman talk | contribs 01:43, 9 October 2019 (UTC)

I've done a kind of sloppy split of the missing version history category, which does seem to work. There might be some formatting edge cases screwing it up somewhat that I haven't accounted for yet though. - User-12316399 (talk) 10:35, 9 October 2019 (UTC)

I think we should also somehow distinguish between things that we don't know but can currently test, and stuff we can't currently test due to reasons (e.g. the version a change happened in not being archived). This should be easy to do for templates like verify. I'm not sure how we'd deal with this in the history template. If anything we should start a discussion of revamping the history template sooner rather than later. - User-12316399 (talk) 09:30, 29 October 2019 (UTC)

I have an idea to further split unknown version history. We have already proposed to distinguish editions, but we could also distinguish releases from development versions. If we know which release a change was made in, but not which development version, that is better that a completely unknown version history. The BlobsPaper.png 00:14, 3 November 2019 (UTC)
One category per release version then? - User-12316399 (talk) 09:32, 3 November 2019 (UTC)
Yes. We would have Unknown Bedrock Release, Unknown Bedrock Beta, Unknown Java Release, Unknown Java Snapshot, Unknown Education Version, and Unknown Legacy History (for Legacy Console, and New Nintendo 3DS). The BlobsPaper.png 14:50, 3 November 2019 (UTC)

Longer introduction text and quotes[edit]

The first section of an article, before any headings, is called the lede or introduction. As this is a reader's (and a search engine's) first introduction to an article, it should contain one to two paragraphs of the summary of an article. An article should always have a lede. A lede is a good place for the article's primary infobox, but it is not a great place for quotes or navigation elements. Block quotes, when used in a relevant way to the page's topic, provide an discoverability boost to articles; however, for user experience and SEO purposes, it is preferred to place these lower in a section before they become part of the lede snippet in search results.

Article best practices

While the blog is not specifically written for Gamepedia, we can still get useful information from it. We could use this part to improve our introduction sections. I would like to suggest changes to these two points:

    We have a lot of quotes at the beginning of articles, and as the blog explained, that's not really ideal for SEO and they don't have much value for the reader who is looking for information. Because of that I would like to suggest moving the quotes to other, more fitting sections or removing them completely (case by case basis).
  2. Introduction text
    The introduction text is what search engines like Google as well as the reader see first and is therefor very important. And while the English wiki doesn't need to worry that much about SEO because of it's size, the language variants, which often just directly translate from the English wiki, need to, as they also compete against the English wiki. So it's a good idea to start with improvements on the English wiki to help both.
    Our current introduction text is often just something like "Shears are a tool" which is obviously not great. Ideally the introduction text is a summary of the article, giving the reader an overall view about the topic. A good way to do this would be to ask yourself if a new player would understand what the topic is, just from the introduction text. Examples:
    "Zombies are common undead hostile mobs."
    "Zombies are undead hostile mobs that attack villagers as well as the player. They appear in different types and burn to death during the day."
    "Shears are a tool used primarily to shear sheep and mine a few types of blocks."
    "Shears are a tool made of iron ingots that is used to shear sheep. They can also be used to collect honeycombs from bee hives."
    While the second version is still not perfect, it's already way better than the current texts. A good example for an introduction text we have would be Creeper.

To make the point about both more clear, I would like you to take a look at the results for google:shears minecraft and google:creeper minecraft. The shears article shows up with part of the quote as description, which is not helpful for anyone at all, while the creeper article starts with an informative introduction text.   HorseFace.png Gamepedia icon.png MarkusRost (talk) 13:06, 8 October 2019 (UTC)

I've noticed this before, I'll be working on it since I agree itsMatyh (talk) 00:16, 9 October 2019 (UTC)
  • I agree. When you look at the page the useless quotes are the first thing you see. I've been lengthening the intro text on version pages (MCW:VC) and occasionally do it to some other articles when I'm editing the top section. I agree with the examples chosen, and on newer pages they tend to be like that, but should definitely be made a policy.  Nixinova T  C  00:35, 9 October 2019 (UTC)
I'm all for the nuking of page top quotes. 9 times out of 10 they're redundant useless bloat which duplicate information later on in the article (and can even be outright wrong as in the Leaves case a while ago), and the other 1 time out of 10 they could easily be moved to the history section in a far less obnoxious and space-hogging form. - User-12316399 (talk) 10:02, 9 October 2019 (UTC)
 Support removing top of the page quotes unless they do actually have some use. Also  Support making intro sections longer. -PancakeIdentity (talk) 02:13, 7 November 2019 (UTC)
 Support removing top quotes and longer intro sections. --AttemptToCallNil (report bug, view backtrace) 04:11, 9 December 2019 (UTC)
 Support. I'm all for expanding the introduction texts, and I wouldn't mind removing/relocating the quotes (especially the ones from minecraft.net articles; maybe we could replace those with a link to the article in the "External Links" section). –Sonicwave talk 04:12, 9 December 2019 (UTC)
 Support, let's do this, the quotes lack historical significance and don't belong at the top. There was a project for adding quotes, which was a way of adding flavor to pages. I don't know what you want to say about that ... but as someone who installed a lot of those quotes up there in the first place I say yeah, take em down. – Sealbudsman talk | contribs 07:10, 9 December 2019 (UTC)
I think most quotes should go to External Links sections, to extend what Sonicwave32 said. The BlobsPaper.png 14:51, 9 December 2019 (UTC)

Module/database thing for infobox values[edit]

Currently, blast resistance values are added to infoboxes via being loaded from a module Module:Blast resistance values, while all other block-related values are specified manually on the page. On discord yesterday I proposed that this concept could be expanded to other values related to blocks (and, by extension, items, entities and other stuff), and it raised a head or so. Would this be useful at all?

The values we'd need to implement into this new module table thing of doom:

  • Blast resistance (number) (already done)
  • Hardness (number) (already done, but in a different way that isn't inherently called by the infobox)
  • Luminance (number)
  • Flammability (number)
  • Fire encouragement (number) (not yet in infoboxes)
  • Catches fire from lava or not (boolean)
  • Slipperiness (number) (not yet in infoboxes)
  • Entity movement multiplier (one or two numbers, as some blocks like cobwebs can have different y and xz movement speed modifiers) (not yet in infoboxes)

For items (and blocks that exist as items):

  • Renewability (boolean)
  • Stackability (number)

Other stuff, like the needed tool and the IDs, would probably still be specified manually, and yet other stuff, like drops and experience, will probably be deprecated as I've mentioned here before. Are there any other notable values that we could add? - User-12316399 (talk) 12:01, 10 October 2019 (UTC)

Why does the word "Cargo" come to mind? --AttemptToCallNil (report bug, view backtrace) 14:54, 10 October 2019 (UTC)
I definitely support the new parameters, such as movement speed and slipperiness. The hardness and blast resistance values are used outside of infoboxes, but not all parameters are. I would support having a module in this case so we get the same value across pages. I would not support a module for renewability because the Renewable resource and Non-renewable resource pages would still need to list the items manually. The BlobsPaper.png 23:51, 10 October 2019 (UTC)


There are quite a few blocks in the game as of right now. Ever since the flattening, most of them have gained unique IDs on the Java Edition, however they still share pages (likely due to the flattening not having been performed on the Bedrock Edition). I'm personally not too chuffed with most of the current page sharing that's going on, and believe that doing a large-scale splitting of these block and item pages would be beneficial.


  • The refactoring of obtaining sections, as mentioned above, would likely be made a lot easier; you wouldn't have to specify that for example only this specific type of flower can be dropped from this mob, but no other flower can, etc.
  • Crafting sections would also get a lot shorter/have much less of a need for cycling images - the stone bricks page wouldn't need three crafting recipes listed one after another for each craftable variant of stone bricks, and we'd also get rid of the smelting section as well, and the prismarine page wouldn't have the crafting grids cycling through different blocks for recipes for each stair variant.
  • More specific history for each block. Refer to the Cobblestone page, which had Mossy Cobblestone merged into it (my fault) and the markedly different histories are mashed into each other as a result.
  • Infoboxes currently note differences in properties between described blocks which can cause some minor chaos behind the scenes. For example, see Andesite, which states that polished andesite is renewable but andesite is not, causing the page to be added to Resources with invalid renewability. Granted a fix for this could be performed by editing the infobox to account for these, but splitting pages gets you a shorter infobox due to not having to specify one being renewable while the other isn't, gets rid of the error category, makes formatting more consistent across pages, among all these other benefits.
  • Data values sections would get shorter as well - the Coral Fan data values section is pretty long since it has to account for all 20 unique block IDs in Java Edition. Via splitting per species we cut this down to 4 java data values per page, and if we split this further into dead and not dead we halve it into 2. In the best case scenario,we could scrap the Data values section entirely for many pages and just have everything documented within the infobox.
  • Some blocks and items that share pages have subtle behavioural differences (e.g. breeding with dandelions) that could be documented on only the subject block/item's page and not the other ones it shares it with.


  • This will likely cause a large amount of information to be duplicated across articles, since many blocks likely share a ton in common with other blocks outside of texture, recipe and IDs.
  • Bedrock Edition doesn't have the Flattening yet, so matters could become confusing for certain blocks.

There's blocks which I'm less sure should be split than others, here's a rough list of them.

Definitely split:

  • Smooth, cut, polished, cracked, mossy, chiseled and pillar variants of blocks e.g. cobblestone, sandstone, stone bricks, quartz blocks
  • Flowers, grass/ferns, coral in all six forms
  • Non-dye colour variants of things i.e. sand and red sand, sandstone and red sandstone
  • Pumpkins and carved pumpkins
  • Heads
  • Bee nests and hives

Not sure about splitting:

  • Dyed blocks - these seem a bit too similar to be split, especially into 16/17 per block
  • Wood variants - many things come in different wood types now, and do we really want 24 new pages for each species, strippedness and logness combo of wood blocks?
  • Slabs, stairs and walls - there's a lot of them
  • Tools with tiers, armor pieces
  • Grass and tall grass, ferns and large ferns

Definitely don't split:

  • Block ID differences which are blatantly the same block and done to prevent redundant ID combinations e.g. wall signs, wall heads, attached stems
  • Block state variations (at least as far as Java Edition is concerned)
  • Damage states of anvils
  • Sponge and wet sponge

I doubt this will gain much traction at all, but this is something we've been talking about on discord recently and that has been at the back of my head for a while, so I figured putting it here might spark some kind of constructive discussion relating to it. - User-12316399 (talk) 12:38, 10 October 2019 (UTC)

If there are a lot of similarities, we do not need to split. For example, bee nests and bee hives behave almost exactly the same; they are just obtained differently. I think the zombie, skeleton, and creeper heads are very similar, so there is no reason to split.
I would support splitting smooth stone and mossy cobblestone from stone and cobblestone, respectively, but in general, I would think hard about splitting. The BlobsPaper.png 13:41, 10 October 2019 (UTC)
I'd support those two splits, as well as maybe pumpkins/carved pumpkins, but most things can probably be kept together. -PancakeIdentity (talk) 02:01, 30 October 2019 (UTC)
I  Massively oppose basically all of this, the content that shares pages is basically the exact same objects, with just a different name, look, and how to get. Flowers, all except the wither rose have the EXACT same properties; Pumpkins are the exact same except for golem creation and enchanting/wearability; Heads, exactly the same except for some recipe usages; Tool tiers, only durability and the ores it can mine. Grass, does this even need mentioning?; Beehives, exactly the same behavior, just creation process/where to find is different. Smooth, cut, polished, cracked, mossy, chiseled and pillar variants of blocks, ALL of them use the exact same properties.; Coral fans, OK, by now this is just a big joke...
This will not "cause a large amount of information to be duplicated", this will cause all those pages to be the EXACT SAME information.
As for your obtaining section rewrite: Simply say Poppies: <obtaining methods>, Azure bluets: <obtaining methords>; this is a super minor thing that really doesn't matter.
Just because 1 of it's minor properties is not shared with the rest of a group, doesn't warrant a whole new page.
I also massively oppose your previous all of the sudden crop-seed split, which had little to no discussion on ANY of their pages. FVbico (talk) 10:35, 29 October 2019 (UTC)
 Strongly Oppose. It's just much easier to have blocks that are essentially the exact same on the same page, both for us and the average reader. To help alleviate some issues, I suggest putting both the item and block texture in the infobox on pages like string and any crop/seed pages. -PancakeIdentity (talk) 02:01, 30 October 2019 (UTC)
 Strongly oppose, mostly per FVbico. --AttemptToCallNil (report bug, view backtrace) 18:39, 6 November 2019 (UTC)

About transparency and documentation of its behaviors[edit]

The behavior of transparent blocks is extremely complex and there's not different "categories" like the wiki likes to say they are. Almost every block is unique in some way. I've been documenting placement behaviors (placing transparent blocks that require support on other transparent blocks) at Opacity/Placement. This page currently only covers Java Edition. The problem with this page is that the tables are very large, and it could very quickly get out of control if new blocks are added or the Bedrock information is included. In addition, the page is kind of hidden away. I'd propose some sort of on-page documentation for each transparent block's transparency behavior. This could also cover stuff like mob spawning, light levels, etc. However, I'm not sure the best way to go about this. I'd love some discussion, as the current way we deal with this is not very good. Thoughts? -PancakeIdentity (talk) 01:57, 12 October 2019 (UTC)

I agree that documenting a block's behavior on its article is the better way. Should we pick some articles to experiment with adding that information to them? --AttemptToCallNil (report bug, view backtrace) 07:39, 12 October 2019 (UTC)
It looks like Torch has a decent table on it. Maybe something like that? We could also probably just copy the shulker box/piston sections on Opacity/Placement to the shulker box and piston pages. -PancakeIdentity (talk) 17:03, 12 October 2019 (UTC)
Yes, something like the table on Torch – and with your improvements (good work on that) I'd even say exactly like that. Also agree on shulker boxes and pistons, I think this information should be on their articles. --AttemptToCallNil (report bug, view backtrace) 17:28, 12 October 2019 (UTC)
The other thing I was wondering is how to document how a free-standing block's transparency works (such as Spawner, Glass, Brewing Stand, etc). Right now, most just have something in the infobox, but this doesn't provide a lot of information. For example, glass and spawners being listed as being partially transparent leads to misconceptions about placement behaviors, spawning, etc. Should we make a new section on the pages dedicated to this? Maybe a "Transparency" section? I'm not sure. This could help trim down these placement sections, as if we say that all blocks can be placed on spawners on the Spawners page, it doesn't need to be documented everywhere else.-PancakeIdentity (talk) 17:44, 12 October 2019 (UTC)
I would support a transparency section. I am not sure why so many different properties of blocks are categorized as transparency, so we definitely need more information. For example, ice is transparent but polar bears can spawn. This means that ice would need to be considered opaque in mob spawning, at least according to the Bedrock Edition algorithm. The BlobsPaper.png 18:04, 12 October 2019 (UTC)
Yeah, the behavior is pretty complicated. Ice seems to act as an opaque block (aside from rendering), like glass and light sources. It just has a hard-coded behavior to not allow snow on it to keep ice environments clean. -PancakeIdentity (talk) 18:09, 12 October 2019 (UTC)
I've always found the non-light-related definitions of "transparent blocks" to be unintuitive (suffocates mobs, allows spawning, block placement etc.), so I would support documenting these behaviors separately. I might even support changing "transparency" to something like "light-blocking", since many "transparent" blocks aren't visually transparent (like chests). The table on Torch#Placement seems good, although I'm not sure if it would be better to have top and side placement in separate columns. –Sonicwave talk 18:48, 12 October 2019 (UTC)
I agree, it seems like an outdated community term. I think it's time we try to move away from it. And I'll try to split the top/side placement and see how it goes. -PancakeIdentity (talk) 19:24, 12 October 2019 (UTC)
 Agree. They should be different infobox params instead of being shoved into a footnote.  Nixinova T  C  19:42, 12 October 2019 (UTC)
I think we should split it into rendering, light blocking, and mob spawning. Then the placement rules can be detailed elsewhere and not attached to any of these three. -PancakeIdentity (talk) 23:22, 12 October 2019 (UTC)
Those properties plus placement are not an exhaustive list. We would need information about chest opening, water currents, etc. This is more information than belongs in an infobox. I propose that we reserve the infoboxes for the properties that will affect the most players, and document the rest in a "Behavior" section. The BlobsPaper.png 00:07, 13 October 2019 (UTC)
I agree. However, with the chest example specifically, I think that fits better on the chest page and not each block's page. -PancakeIdentity (talk) 01:38, 13 October 2019 (UTC)
 Agree. Visual transparency should be moved to model as that page fits better.--skylord_wars (talk) 08:30, 2 December 2019 (UTC)

From Discord: Proper game rules and predicates regarding block placement[edit]

Summarizing a discussion that occurred just now on the Discord server in the #wiki channel.

Discord server member tryashtar provided us with rather useful information regarding block placement. This clearly invalidates "transparency"-based descriptions of placement rules. (Note that this relates to JE exclusively.) Quoting tryashtar:

- pressure plates require the block below to have a rim (e.g. hopper) or center point on top (e.g. glass pane)
- rails require the block below to have a rim
- banners and cakes require the supporting block to be a solid material (materials should probably be documented somewhere)
- bells and levers require the supporting face to be "full"
- carpet just needs to be above anything but air
- lanterns need a center point on top (if place on top) or below (if placed below) -- for example a lantern can hang below a down-pointing hopper but can't be placed on top
- redstone dust requires a full face below, but is also hardcoded to allow hoppers

The "rim" and "center point on top" are apparently well-defined in-game predicates; for example, the center point is a 2x2 center square on the hitbox (not visual box) assuming the surface is a 16x16 square grid. Quoting tryashtar on the "rim", "It's a predicate that is created specifically by removing the entire center section from a full cube, leaving only the, well, rim".

In references to other placement quirks (by tryashtar):

Sea pickles just check if the below block has a non-empty upward face
Not a block but item frames are really interesting, they can be placed anywhere that doesn't intersect with their hitbox (and support block material must be solid (or a repeater/comparator))

By the same person, on leaves' exceptional behavior:

Leaves are considered to have faces that are "full" but not "sturdy"

This rule-based system would probably be far better than exhaustive lists of compatible blocks. In addition, 3D wireframes have been proposed to be made for the predicates mentioned. --AttemptToCallNil (report bug, view backtrace) 21:33, 12 October 2019 (UTC)

The purpose of the Gallery section[edit]

The result of the discussion was the issue was addressed. Part of this had already been covered in the style guide by the time of this post, and the other part is now implemented as a change to the style guide. Player builds of any kind are now explicitly stated to be inappropriate in article galleries. --AttemptToCallNil (report bug, view backtrace) 18:45, 6 November 2019 (UTC)

I think it's time to clarify the use of the gallery section. I looked back a couple years in the archives for this page and couldn't find something, so I hope I'm not bringing up an old decision. In my opinion, the gallery should be used to demonstrate/showcase things about the page's subject. Like the villager professions on Villagers. Examples of full villages on Village. These images should be informative and useful but not really something that fits better elsewhere in the page as an image on the side. Images released by developers during development could also go here. However, I commonly see the gallery section used for images of builds, user creations, weird generation, etc. Should these types of images be allowed in the gallery section, or should we restrict them to the purely informative images? (Also sorry for starting two topics so quickly, both have been on my mind for a while) -PancakeIdentity (talk) 02:32, 12 October 2019 (UTC)

Just curious, can you give an example of a page where the gallery has images with user builds? Otherwise, I'd agree that galleries should be mainly about informative images. -EatingSilencerforBreakfast (talk) 02:49, 12 October 2019 (UTC)
Ice is what reminded me to make this section, but I've seen it a lot of other places as well. I've been editing out egregious examples that have bad screenshots, but I'd love to finally clarify it here. There's also a lot of images such as on Ore and Clay that are basically "look I found some of X item", and add nothing to the page. Cactus has a ton of images, such as multiple pictures of the underside, lots of tall cacti, cactus farms, etc. Just to name a few examples. -PancakeIdentity (talk) 02:57, 12 October 2019 (UTC)
I support screenshots of odd generation for the same reason we have "Trivia" sections. For example, I am not sure how else to show a village generating in multiple biomes.
While it is reasonable to show the underside cactus texture, we do not need more than one. In general, each screenshot should serve a unique purpose. The BlobsPaper.png 03:19, 12 October 2019 (UTC)
I should clarify, I'm not wholly against those types of things. I was more speaking to the excessive amounts of pictures, and how it plays into the larger idea that a lot of users view it is a place to upload their random screenshots. -PancakeIdentity (talk) 03:21, 12 October 2019 (UTC)
Also, I wanted to add that I think Banner is a really good case study for this. The top section is good. It displays images released by developers and shows some visual information, such as gradient progression or rotation. The commands section is good to showcase the two images there, however, any more is unneeded. The problem section is Example Designs, which is almost completely unnecessary imo.
I agree with Blobs2 about screenshots serving unique purposes and leaving images of odd generation. I do agree images of user builds should be minimal. For example, those farm screenshots in the Cactus article are rather off-topic.
The question of limiting the growth of galleries has been on my mind as well. In particular regarding the article Banner, specifically the Example designs gallery subsection.
In other words, the two main problems with article galleries I see now are player build images and several images of the same phenomenon. Would there be any negative implications if both were to be disallowed? --AttemptToCallNil (report bug, view backtrace) 07:53, 12 October 2019 (UTC)
I can't think of anything. They both seem to belong more on user pages and/or tutorial pages. -PancakeIdentity (talk) 16:58, 12 October 2019 (UTC)
 Comment - Though we haven't reached a definitive conclusion yet, I'd propose putting the results of this discussion on the style guide page. -PancakeIdentity (talk) 17:36, 12 October 2019 (UTC)
The no duplicates guideline is already in the style guide (see MCW:IMAGES). I opened a new topic regarding player builds. --AttemptToCallNil (report bug, view backtrace) 18:30, 12 October 2019 (UTC)

Sandbox on the sidebar?[edit]

The result of the discussion was the proposal was implemented.

Should Minecraft Wiki:Sandbox be linked from the MediaWiki sidebar? This would make it much easier to get there to test things. --AttemptToCallNil (report bug, view backtrace) 18:02, 12 October 2019 (UTC)

 Support Many anonymous users do test edits on mainspace pages, which is often disruptive. By having a link to the sandbox in the sidebar, more people would know about the sandbox, so more people would use it. The BlobsPaper.png 18:07, 12 October 2019 (UTC)
Sure, it's not obvious to find since it's only linked from user warning templates and Help:Contents (not including talk page posts). –Sonicwave talk 18:17, 12 October 2019 (UTC)
 Support -PancakeIdentity (talk) 18:19, 12 October 2019 (UTC)
I assume this would be added under the generic category? If so, I'm kind of thinking to put it directly under "Style guide", as it makes sense to have it at the end of the "small grouping of useful MCW namespace pages" (projects, wiki rules, style guide). I'm open to other suggestions, however.--Madminecrafter12 (Talk to me | View what I've done) 17:37, 15 October 2019 (UTC)
Seems like a reasonable location to me. The BlobsPaper.png 19:41, 15 October 2019 (UTC)
 Done. Added the link in the place I mentioned above.--Madminecrafter12 (Talk to me | View what I've done) 14:28, 18 October 2019 (UTC)

Prioritize Bedrock Edition over Java[edit]

Currently, the wiki is formatted as though Java were the main edition. This made sense when Pocket Edition lacked a lot of features, but this is no longer the case. In fact, there are reasons that Bedrock should be considered the main edition:

  • A lot more people play Bedrock Edition than Java, so information about Bedrock will benefit more readers.
  • Bedrock Edition is just called Minecraft, implying that Mojang thinks of it as the main Edition. (FVbico, could you verify this?)

Since Bedrock is the true "main edition", we need to make certain changes:

  • Describe Bedrock Edition before Java when they are described separately; for example, in history sections.
  • Some Java-specific pages, such as Level format and Custom servers, should be moved so that "Java Edition" is in the title, similar to their respective Bedrock pages.
  • Some features that were mentioned for Minecraft (not specifically Java Edition) are currently on the Java Edition mentioned features page. We should transfer these to a generic "Mentioned features" page instead, since almost all mentions after the Better Together Update apply to both editions.
  • In infoboxes, when information is different between editions, the Bedrock information should be given (with {{only|bedrock}}). For example, the renewability of netherrack should say "Yes (BE only)" instead of "No (JE only)".
  • The tutorials covering features that are different between editions, such as redstone, need more Bedrock Edition information.
  • Once Bedrock Edition receives a flattening, pages should be moved to the Bedrock titles, should any discrepancies remain.

Please let me know what you think. The BlobsPaper.png 19:46, 15 October 2019 (UTC)

Mojang has stated time and time again, there's no priority over one or the other, so they don't see it as a "main" edition. As it stands now, java has more streamlined and more new namings for objects in the game though, so it's best to follow those. FVbico (talk) 20:21, 15 October 2019 (UTC)
Since Mojang considers neither one the "main" edition, that factor is irrelevant. Bedrock is the more widely played edition, so we should consider that. The BlobsPaper.png 21:04, 15 October 2019 (UTC)
Mojang has said multiple times that Java is, at least in terms of features and technical stuff, the more complete and accurate version. It's why we use JE names for pages and such. -PancakeIdentity (talk) 22:56, 18 October 2019 (UTC)
I'd support moving mentioned features to the non edition-specific mentioned features page (see also my comment on Talk:Mentioned features). –Sonicwave talk 01:47, 16 October 2019 (UTC)
  • "Since Bedrock is the true 'main edition' "—false, there is no "main edition". On your other points: 1) I think the History section should be ordered in the same order as the feature was added to the game in (eg stonecutter has bedrock first); 2) Agree; 3) That's probably better; 4) We should instead list both (Yes‌[BE only] No‌[JE only] etc) or "Only in Java Edition"; 5) Ok, whatever, not something a policy can do; 6) Java still has the "correct" names.  Nixinova T  C  02:47, 16 October 2019 (UTC)
 Oppose to your 1st point : history would get very messy (and it is already a bit) 10:02, 20 October 2019 (UTC)
 Support all of this except  Oppose the first bit, as per IPs comment. -PancakeIdentity (talk) 04:03, 19 November 2019 (UTC)
 Strong Oppose from me in terms of rearranging everything to put Bedrock first. For the second half, I agree with what Nixinova said. As mentioned above, there is no "main" version, Mojang considers Java to be the more "correct" at least in terms of features and technical stuff. -PancakeIdentity (talk) 22:56, 18 October 2019 (UTC)
 Strong Oppose to prioritize Bedrock Edition over Java. Minecraft does not have an official "main edition". Minecraft is historically Java Edition. Also good luck for finding technical stuff on Bedrock Edition. Finally this would need a LOT of work that could be used for other things. 10:02, 20 October 2019 (UTC)

Having old sprite textures on, for e.g, snapshot pages[edit]

Hello, should we use old sprites textures for old content like snapshots before Texture Update ?

Thank you, 10:04, 20 October 2019 (UTC)

All visual content such as screenshots and renders should have up to date textures whenever possible. The only exception is when displaying content that is exclusive to an older version. -PancakeIdentity (talk) 17:21, 20 October 2019 (UTC)
OK then, I will take in charge some snapshots. 12:34, 21 October 2019 (UTC)
 Agree Up-to-date content should be used on non-historical pages/sections. Version pages are historical pages, and therefore it would make a lot of sense for images to remain accurate to that version, which can be more easily done with images being separately versioned now. MajrTalk
08:22, 4 November 2019 (UTC)

Definition of "Partially Implemented"[edit]

The Bedrock Edition mentioned features page defines partially implemented as features that "had been shown by a Mojang staff member, but either had no further development or were canceled shortly after". (I think the Java page uses a similar definition). This is not intuitive to readers. In fact, it is contradicted by saying that Java Edition 1.9 combat mechanic have been partially implemented with shields and the off-hand slot.

I think the meaning the phrase "partially implemented" is obvious enough to most readers if it refers to combat mechanics and similar features. What we should do instead is rename the "Partially Implemented" sections. Since these features were "added" shortly after being mentioned, I propose the term "Mentioned with partial implementation". However, feel free to give other suggestions. The BlobsPaper.png 04:21, 23 October 2019 (UTC)

I think the best option will be in section "Deleted features" --Rychlik (disc) 12:17, 23 October 2019 (UTC)
 Oppose Many readers would confuse that with removed features. The BlobsPaper.png 13:44, 23 October 2019 (UTC)

File names when textures differ between JE and BE[edit]

Currently, the naming system for block/item/entity/whatever renders is "[X] Revision 1", "[X] Revision 2", etc. If there's a different texture in Bedrock, the file name is usually "[X] BE". However, this can get messy in certain cases such as Coral Fans, where Bedrock has had multiple version-exclusive textures. How should we name files in this case?

I would personally say to adopt the Revision naming system in this case as well, just adding "[X] BE Revision [N]", removing the BE if/when the textures become the same as Java. I'd be hesitant to renumber Revisions to reflect Bedrock as it seems a lot of version-exclusive textures are being changed to be the same as Java's. Opinions? Thoughts? Ideas? -PancakeIdentity (talk) 23:45, 23 October 2019 (UTC)

Trying to think of all possible combinations of different texture evolution across editions made me reach only one conclusion: it's an absolute mess.
Some scenarios that made me reach that conclusion (note that all different texture IDs mean different texture contents):
  1. Edition X (XE) has texture T1 for the item, then switches to texture T2, then switches back to T1. Should a duplicate of T1 be uploaded as Revision 3? In general, trying to think of handling reversion to previously used textures makes my mind a cobweb.
  2. Editions X (XE) and Y (YE) started out with the same texture (T1). At some point, XE changes to texture T2x, and YE changes to texture T2y. Then YE changes to T3y, and later both XE and YE change to T4. Is it a problem that T4 is the third revision from XE's perspective (i. e. it jumps from "XE Revision 2" to "Revision 4")? Is it a problem that there is "XE Revision 2" but no "XE Revision 1"? What if after T4, XE changes to T5x? Do we have a jump from "XE Revision 2" to "XE Revision 5"?
  3. I started thinking of just numbering revisions by introduction date, but then what if XE and YE release simultaneously with different textures? This could be solved by replacing numeric revision IDs with introduction dates (i. e. "XE revision 2019-10-24" and "YE revision 2019-10-24" for simultaneous releases and the same with no mention of editions in other cases). Yes, that would mean file names would be unpredictable, but this is already present to a lesser degree with edition specification.
I apologize for being unable to present this information in a more comprehensible manner.
P. S. I believe since neither BE nor JE is a main edition (AFAIK, this is Mojang's current official stance), in case of texture divergence, texture file naming should not favour either edition by omitting edition mentions in file names. --AttemptToCallNil (report bug, view backtrace) 00:29, 24 October 2019 (UTC)
I think we should include the appropriate numbers from both editions. For example, cobblestone would be Cobblestone BE3 JE6.png, since it is revision 3 on Bedrock and 6 on Java. For texture revisions that have only ever existed on one edition, we should still specify the edition (e.g., Structure Block Save JE1.png). The BlobsPaper.png 00:37, 24 October 2019 (UTC)
I like this solution. Kinda janky but this whole thing is a mess, especially since we still haven't done anything about this project. -PancakeIdentity (talk) 00:42, 24 October 2019 (UTC)
Interesting idea. Agree about the extent of this being a mess. --AttemptToCallNil (report bug, view backtrace) 00:45, 24 October 2019 (UTC)
Unless anyone has any opposition, I'll probably start using this system within the next few days. I'll need help moving files as well. -PancakeIdentity (talk) 01:29, 25 October 2019 (UTC)
Don't. Give people the chance to reply, a few days is far from enough. Give at least 1 month. FVbico (talk) 04:34, 25 October 2019 (UTC)
There's not been much discussion, does anyone have anything to add? Support? Opposition? Other proposals? The files are super messy right now and I'd love to be able to work on it finally. -PancakeIdentity (talk) 02:17, 7 November 2019 (UTC)
I have a proposal. Redirects could be created for Bedrock Edition textures that are identical to Java Edition (for example, "File:Cobblestone BE Revision 1.png" could redirect to "File:Cobblestone Revision 3.png"). This would avoid long file names like the previous suggestion. In addition, the Java Edition file name could be changed (e.g. "File:Cobblestone JE Revision 6.png"). Bedrock Edition files that are edition-exclusive could use a similar naming system to Java Edition (such as "File:Nether Bricks BE.png" being renamed to "File:Nether Bricks BE Revision 2.png"). Thoughts? 07:47, 11 November 2019 (UTC)
 Oppose If we only mention the Java version number, that would imply Java is the main edition, and Mojang does not consider either edition to be the main one. The BlobsPaper.png 04:48, 12 November 2019 (UTC)
 Oppose this variation of the solution as it focuses too heavily on Java. File names shouldn't be too long if we use "BE1" instead of "Bedrock Edition Revision 1" or whatever. -PancakeIdentity (talk) 01:45, 15 November 2019 (UTC)
I see the problem with my solution, so I am fine with the use of the previous proposal instead. On the discussion of file parity, however, I think that this change would require the reorganization of the revision tables on certain files, as they only show the Java Edition revisions currently. 02:04, 15 November 2019 (UTC)
This should be mostly possible with merging. -PancakeIdentity (talk) 02:11, 22 November 2019 (UTC)


File names will follow the format [Thing] JE[X] BE[Y]. X is the revision number of the texture in Java, while Y is the revision number of the version in Bedrock. For example, Cobblestone would be "Cobblestone JE6 BE3". This would go for all textures, including ones with only a single revision. "Cobblestone", "Cobblestone JE6", and "Cobblestone BE3" could all redirect to it.

Textures that are exclusive to one version will only include that version, but will still include it. For example, the nether reactor core would be "Nether Reactor Core BE2".

In cases where current textures differ, I'd propose that the basic file name without any version numbers/editions would redirect to the latest Java revision. This is just due to Bedrock typically receiving Java's textures and rarely vice-versa.

This isn't any different from Blobs2's proposal above, just a bit more in-depth.

Thoughts? -PancakeIdentity (talk) 05:14, 15 November 2019 (UTC)

This seems all right. The only downside I can find is that when a texture is first introduced in a second edition, the file has to be moved, but the proposal would require a redirect from its original title anyway. --AttemptToCallNil (report bug, view backtrace) 04:07, 19 November 2019 (UTC)
This discussion has been open for a month. Considering this is a minor change for the average editor/reader, and that there's been no opposition or other proposals, I think we can go ahead with this. It should also get added to the style guide. -PancakeIdentity (talk) 02:08, 22 November 2019 (UTC)

Java Edition guides expand[edit]

In last 2 months (September - October) we created 7 new guides, but now there are only 2 guides to compleate Full Release guides, so it will be good idea to add new sections for Alpha and Beta Java Edition Guides. Now, I need only your support. Thanks. --Rychlik (disc) 13:50, 24 October 2019 (UTC)

Discussion management: existing measures aren't working[edit]

Since the hot discussions list on the community portal and the #talk-highlights channel in Discord don't get much attention, an idea was proposed to have a dedicated page on the sidebar.

Draft: User:FVbico/Open discussions.

My feedback is that we should probably not overcomplicate the classification (so maybe no minor/average/major) and rename "Moderation" to "Policies and guidelines".

Any other comments? --AttemptToCallNil (report bug, view backtrace) 15:17, 28 October 2019 (UTC)

Just for info, I added the minor, major average as in how much it would affect the wiki; changing NBT tag is much less significant than refactoring edition specific info. FVbico (talk) 16:09, 28 October 2019 (UTC)
How would one determine the scale of changes some discussion involves, if they want to know which of the three categories to put an entry into? Or what if someone decides to dispute the categorization as minor/etc? --AttemptToCallNil (report bug, view backtrace) 16:27, 28 October 2019 (UTC)
"How much would this affect the wiki as a whole?", the answer eould be the section to put it in. You got a point though, but I thought it'd help keep the focus with the biggest things. FVbico (talk) 22:53, 28 October 2019 (UTC)
First, a more indepth explanation for each of the categories could be phrased in the lead section, and second, you could also rename them in a more concrete way, such as wiki-wide, page, template. Or use multiple choice labels instead of single-parent categories. Just some tips for this page. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 23:09, 28 October 2019 (UTC)
I like the idea of having summaries of important discussions. Some time ago I proposed (on Discord) to occasionally add links to important discussions to the top of recent changes, although I'm not if that would be considered too intrusive. –Sonicwave talk 05:34, 3 November 2019 (UTC)

Re-merge crops and seeds[edit]

This was done without any real discussion on ANY of the pages.

To the average player, seeds and the crops they place are one and the same, and that's the main, if not only purpose of the seeds.

Split without real discussion:

Split before, for no clear reason:

Just because the ID is different doesn't warrant a new page. The only seeds which have another use action besides placing the crop are Potato, Carrot and Sweet Berries, which can easily just have a seperate mention in the usage section.

The only reason these pages got split is because User-12316399 is not happy with anything sharing a page.

The "pros" of the "MEGA SPLIT" section above do not at all apply to ANY of these, except shorter data values section, which is a no-concern point, as they're already really small for most pages. Additionally, only people who actually want to know those things read those sections, not the average userFVbico (talk) 10:44, 29 October 2019 (UTC)

I agree that the crops should be re-merged with their seeds. The main usage of the seeds is to plant the crops, and the main way to obtain the seeds is by harvesting crops. There is probably a lot of duplication in these sections, especially since crops cannot actually be obtained without inventory editing or add-ons. The BlobsPaper.png 13:53, 29 October 2019 (UTC)
Even though for some reason I wanna keep them split, I can't think of a logical reason to do so. Right now is messy and the page titles are confusing, and many old links are broken.  Support re-merging. I'd also suggest having both the item and block textures in the infoboxes. -PancakeIdentity (talk) 02:06, 30 October 2019 (UTC)
 Support having both the item and block render (or entity for minecarts, boats, painting, item frames, armor and armor stand) in the infobox --Capopanzone (talk | contribs) 10:31, 30 October 2019 (UTC)
 Support merging them back together. --Capopanzone (talk | contribs) 10:31, 30 October 2019 (UTC)
Also  Support remerging since they're just the block form of an item, and the page titles are confusing (Nether Wart (block)??).  Nixinova T  C  19:36, 30 October 2019 (UTC)
Any opposition? How about merging Cocoa Beans/Cocoa and Sweet Berries/Sweet Berry Bush? FVbico (talk) 19:16, 6 November 2019 (UTC)
I'd support that as long as both were in the infobox. -PancakeIdentity (talk) 02:07, 7 November 2019 (UTC)
I am not sure about sweet berries, since the bush itself has specific entity movement properties. However, if someone could create an example page, we would see how this plays out. The BlobsPaper.png 02:40, 7 November 2019 (UTC)
I have created an example page here, and it looks fine. If no one objects, I will port it to the Sweet Berries page. The BlobsPaper.png 04:58, 7 November 2019 (UTC)
Looks good! I'd  Support the merge. -PancakeIdentity (talk) 23:54, 7 November 2019 (UTC)
 Support also merging cocoa beans/cocoa and sweet berries/sweet berry bush --Capopanzone (talk | contribs) 10:19, 11 November 2019 (UTC)
 Support merging them back together, as long as the block and the item are in the infobox. For normal players the seeds and the crops are not that different. --LakeJason (TalkContribs) 15:47, 9 November 2019 (UTC)
I have merged sweet berries. We can start the other merges. The BlobsPaper.png 05:50, 13 November 2019 (UTC)
While I still can -  Oppose.
While these items and blocks are definitely closely related objects, they're not one and the same. You can't breed chickens with planted wheat crops, walking through berries doesn't damage the player, and there's no way to make potato crops directly produce eating sounds. With them merged, these sections end up becoming larger and mixing up relatively unrelated information, notably in the History section.
With them split, these sections can be kept shorter and the differences between the associated blocks and items can be more clearly defined without having to specify what does what in the text, which obviously improves readability.
The assumption that the mega split's benefits do not apply here at all is also completely false - alongside the shorter data values sections, the item pages would have no need for a drops section at all, and the block pages would be free from having a drops from section. Also, the history section, and other stuff...
Anyway, no. Having these pages be merged provides little to no readability benefits, mixes up lots of information, and generally isn't that helpful. If we're merging these pages, we may as well merge Sapling into Tree since they're just different growth stages of each other. Keeping these pages apart is definitely the better way to go. - User-12316399 (talk) 13:24, 18 November 2019 (UTC)
The pages before you split them (with absolutely no discussion) had no issues at all, it was clear when it was referred to as the block, and when it was referred to as the item. Additionally, as stated on discord, the seed and block ARE the same thing, the block implements the seed as the corresponding "block item", it just provides a different ID.
Plus, it's logical that item entities have no effect on the player, and the blocks don't exist in the inventory...
And I haven't even pulled out the argument of the HORRIBLE name you gave to nether wart...
This whole mess is caused just by your mindset of sharing page = bad, and as made clear in the mega split discussion, it's completely absurt to want to split all pages, including seeds from their crops.
Lastly, so far you're the only one to have stated to oppose both here and in discord, so I think consensus is clear... FVbico (talk) 13:33, 18 November 2019 (UTC)
@User-12316399: Lots of blocks are separate from their item forms; see this page. There is no logical reason to have separate pages for standing signs and wall signs, even though they are technically different blocks. The BlobsPaper.png 04:08, 19 November 2019 (UTC)
Almost unanimous agreement over multiple discussions and it's been done for a couple pages with no opposition. Let's re-merge the rest of these pages. -PancakeIdentity (talk)
 Strong support. Separated was confused. --dr03ramos Piston.gif (talk) Admin wiki[pt] 22:00, 1 January 2020 (UTC)

Obviously the re-merging can be strongly supported by the discussion so far. If there's no more objection, the pages mentioned above would be reverted to the last version before the split with new changes included, and the extra pages would be redirected to the matching main pages. If necessary, the re-merging will be performed in Sandbox before applying to the pages. Please reply to the topic if there are any more suggestions. --Hatsuki kiriT〕 08:22, 3 January 2020 (UTC)

Most of the work has been done. Please inform me if there's still something important lost. --Hatsuki kiriT〕 02:30, 4 January 2020 (UTC)

On sounds[edit]

All sounds should now be split into a dedicated section which provides much more information than was given for them in the infobox. There's a few things that need cleaning up now:

File names[edit]

File names for sounds don't seem to be standardised like many images tend to be. Is there a standard for sound naming, and if not, what should it be?

Missing sounds[edit]

The splitting of sound sections has helped to highlight what sounds are missing from pages, organised into a maintenance category Category:Pages with missing sounds. This should give a better idea of what needs uploading than the table on the associated wiki project.


For sounds which are always played in-game with a different pitch than their actual sound file, should we only upload the original sound file and let the table's pitch parameter do the talking, or should we upload an artificially pitched up/down version of the sound instead?

I've brought up the idea of sounds being artificially pitched up or down using a script, would anyone else agree with this? - User-12316399 (talk) 09:27, 21 November 2019 (UTC)

Block sounds[edit]

Sounds for the placement, breaking, destruction, walking on and falling of blocks should be next up to be uploaded (except for slime blocks, which are already sorted). These can be found at Category:Pages with missing sounds/Blocks. I've only added tables to one page per material type so that it doesn't become a particularly gigantic maintenance task, as the table with filled in sounds can then be pasted onto other pages. So if anyone's willing to upload these sounds I'd be more than happy.

Block sounds are pretty much done now - the only ones remaining are a few edge cases which will need more investigation, as well as jumping sounds exclusive to Bedrock Edition, with the discussion of how Bedrock Edition sounds will be represented still underway; see section below. - User-12316399 (talk) 09:27, 21 November 2019 (UTC)


The tables I've added are based solely on information from Java Edition. If we're also to document Bedrock Edition sound related information where differences exist, how should we represent it? Should we create separate tables for Java and Bedrock Edition values, or mix them into the same table?

We should put them in the same table. I assume most, but not all, of the sounds match, so having them as separate tables would result in a lot of duplication. The BlobsPaper.png 13:57, 30 October 2019 (UTC)
I believe that Bedrock uses completely different sound IDs (mob.drowned.say instead of entity.drowned.ambient, for example). We could make another column for it (making the table wider than it already is), or put the JE and BE IDs on different lines, which would probably lead to lots of [only] tags. –Sonicwave talk 05:59, 3 November 2019 (UTC)

The more I think about it, the more having two separate tables becomes the more appealing option. Given that there's still some new types of columns I want to add to the tables, having all the info being mashed into a single table does not sound useful. - User-12316399 (talk) 19:48, 13 November 2019 (UTC)

I've added an example section to Stone#Sounds which utilises separate tables for Java Edition and Bedrock Edition. I'm going with this since sound events seem to be always naked differently across versions, as well as the fact that certain sounds are version-exclusive (such as the jump and land sounds shown), that Bedrock Edition doesn't have subtitles, pitch and volume values being different across versions as well in some cases (usually being ridiculously long and precise in Bedrock) and that the attenuation distance parameter also seems to be Java Edition exclusive. If people would still rather have them be mixed into the same table then say so, but it's not what I think we should go with. - User-12316399 (talk) 08:57, 19 November 2019 (UTC)

Historical sounds[edit]

There's also plenty of cases of sounds which have changed throughout the game's history, such as skeleton sounds, and there are also sound differences between the history of the editions, such as breaking blocks in the alpha versions of Java, iOS and Android. These should also be uploaded eventually.

Created Category:Pages needing sounds/Historical sounds, which should cover most of the stuff (the block sound differences seem to be merely pitch based). - User-12316399 (talk) 09:27, 21 November 2019 (UTC)

Anyway, that should be about it for sound-related topics. If anyone wants to start work on any of these or comment on them then please do. - User-12316399 (talk) 08:53, 30 October 2019 (UTC)

The "Min. Volume" column should be removed, since it's not a field in sounds.json (at least for Java Edition) and only applies to the playsound command, not sounds played by the game by default. Sounds that play at different pitches in-game than the sound file should follow the in-game pitch, since that's what people would expect to hear (and some of them can quite different and hard to "derive", such as the zombie pigman's angering sound).
I'm still not sure about the "Pitch" and "Volume" columns; they specify the sound's ingame pitch/volume relative to the sound file, instead of relative to other sounds (which one might expect). There should at least be a tooltip explaining what they specify. –Sonicwave talk 05:48, 3 November 2019 (UTC)

Add item icons to infoboxes where the item has a different texture than the block[edit]

Should we add item textures to infoboxes where the blocks/items have different textures? Pages like string, crops, campfire, bell, etc. I would also like to do this for entities, like boats and armor stands. It seems there was support for doing this with crops in above talk sections, and I personally would  Support doing this for all items.

The main argument against this that I'm predicting is that there's an invsprite in the infobox showing the item textures. While this is true, item-only pages, such as diamond, have both the large icon and the invsprite. -PancakeIdentity (talk) 00:28, 10 November 2019 (UTC)

 Support FVbico (talk) 00:30, 10 November 2019 (UTC)
 Support as the full-sized images are quite useful for people quickly wanting to download texture files.  Nixinova T  C  06:20, 10 November 2019 (UTC)
 Oppose - the only reason that items display large versions of their texture files in the infobox is because that's the image that describes the item the best and there's no better image. Having a massive item texture there alongside the existing 3D render would just clutter the page and add nothing of value. - User-12316399 (talk) 13:56, 10 November 2019 (UTC)
"Would just clutter the page and add nothing of value" – This has never seemed to stop you before.  Nixinova T  C  04:48, 12 December 2019 (UTC)
 Support for both blocks and entities. --Capopanzone (talk | contribs) 10:21, 11 November 2019 (UTC)

How do we use files from the English wiki in foreign language wikis?[edit]

I am interested in "List foreign uses." See this. --Rascal97 (talk) 05:30, 10 November 2019 (UTC)

Exactly the same way you'd use them on this wiki; just type [[File:Whatever]] on a different language wiki and it'll work.  Nixinova T  C  06:19, 10 November 2019 (UTC)
I believe some non-English wikis don't use the English wiki as a shared file repository. On those wikis, you won't be able to use files from the English wiki without reuploading them locally. --AttemptToCallNil (report bug, view backtrace) 17:39, 10 November 2019 (UTC)
You are right, Chinese wiki is an example, but it is really inconvenient to maintain this files. --Dianliang233 talkcon 23:54, 16 November 2019 (UTC)
You'll have to enable transclude for English mcwiki at Special:Interwiki so that you can cite content on the English side including pics.  CuervoTalk 14:02, 22 November 2019 (UTC)

Proposed logo update[edit]

See the file on the Russian wiki: the change is making the "Minecraft" text gradient-coloured as opposed to the current flat grey. Another note is that maybe we should also update the grass block texture/model to the Texture Update version. --AttemptToCallNil (report bug, view backtrace) 14:33, 12 November 2019 (UTC)

Update: the Polish wiki already has an updated logo. --AttemptToCallNil (report bug, view backtrace) 15:21, 12 November 2019 (UTC)
 Support adapting the Polish wiki's logo. The gradient, while small, looks nice. And it just makes sense to use the Texture Update's grass block texture. -PancakeIdentity (talk) 02:55, 13 November 2019 (UTC)
 Support per PancakeIdentity. The BlobsPaper.png 03:55, 13 November 2019 (UTC)
 Support using the Polish logo. –Capopanzone (talk | contribs) 20:14, 18 November 2019 (UTC)
 Support Marcelah (talk) 23:57, 19 December 2019 (UTC)
 Support - seems like consensus says to update it. - User-12316399 (talk) 09:53, 17 February 2020 (UTC)

Removing information regarding discontinued versions from pages (excluding history sections)[edit]

I brought this up earlier and it was shot down, but I've heard rumblings of renewed interest so I thought I'd bring it up again.

I propose that we finally bite the bullet and remove all information regarding discontinued versions from the main sections of block/item/entity/mechanics/etc articles only. Their spots in history sections would be kept. This would mostly apply to the non-PS4 LCEs, but there's also remnants of versions such as 3DS in some articles. There are a few reasons behind this:

  1. Consistency. We don't document discontinued versions like Apple TV edition or pre-Bedrock LCEs or PEs.
  2. Readability. Articles can already be fairly messy documenting Java, Bedrock (+Education), and PS4 editions. Documenting discontinued versions adds to this mess way more. At least Java, Bedrock, and PS4 are all receiving updates, so their contents should be fairly similar. Discontinued versions are frozen where they are, and the already vast disparities are only going to get larger as other versions receive updates. Documenting these huge differences is going to create messy pages with information that, frankly, most readers won't care about.
  3. Accuracy. As time goes on and these versions get smaller player bases and become more of a pain to access, it'll be harder to confirm that information about these versions is accurate if the need arises.

Counter arguments:

  1. Readers who still play LCE may come to the wiki looking for information. I don't think this argument holds water. Readers playing any other discontinued versions may come here looking for information, but they won't find it. Additionally. we don't document old versions (i.e. 1.12) on the wiki, despite there being players who play 1.12.
  2. [Worries about PS4 as it is technically LCE.] The wiki already documents PS4 separately from LCE, so I don't think this should be an issue.
  3. LCE is the biggest discontinued version, so we should at least keep that one. While it is the largest discontinued version, I'm not sure this is a reason to support it. The only platforms (other than PS4) that have LCE but not Bedrock are discontinued platforms themselves, meaning the player base for LCE is going to shrink more and more as players move away from this.

The overall idea is that discontinued versions are going to continue to get more difficult to document on the wiki and the usefulness of this documentation is only going to decrease.

To clarify, I am only referring to removing information from the main sections of block/item/entity/mechanics/etc pages, NOT from history sections or removing version articles.

Thoughts? Opinions? (At the very least, can we decide to not document 3DS?) -PancakeIdentity (talk) 23:09, 15 November 2019 (UTC)

 Support Some pages, such as Sweet Berries, say that the feature is exclusive to the Bedrock, Java, and PlayStation4 editions. This would confuse many readers, as this essentially says it is exclusive to all editions if Minecraft. Some other pages say that the feature is exclusive to Bedrock and Java Editions. Again, this will be redundant once Bedrock becomes available on PlayStation 4. The BlobsPaper.png 00:38, 16 November 2019 (UTC)
 Support no longer documenting 3DS and LCE, definitely. – Sealbudsman talk | contribs 01:22, 16 November 2019 (UTC)
. I thought this had already been done, though all instances of ‌[Legacy Console Edition only],etc should be replaced with ‌[PlayStation 4 Edition only], etc.  Nixinova T  C  02:20, 16 November 2019 (UTC)
It's been happening, but I still see LCE-only info left on a lot of pages and I thought we should officially discuss it. -PancakeIdentity (talk) 23:34, 16 November 2019 (UTC)
 SupportCapopanzone (talk | contribs) 20:13, 18 November 2019 (UTC)
On a related note, why did we decide to get rid of Pi Edition stuff from history sections? It's historical info, so it, like Console Edition, should be kept there. I think we should really get around to redesigning the history template first though. - User-12316399 (talk) 23:41, 16 November 2019 (UTC)
Good point, not sure. Make another topic if you wanna discuss Pi Edition though. -PancakeIdentity (talk) 23:46, 16 November 2019 (UTC)
With Bedrock's PS4 release, this'll be a great time to get this all done. -Pancakeidentibot (talk) 21:52, 9 December 2019 (UTC)
The achievements list is cluttered with discontinued versions. I propose that the {{achievements}} template remove this parameter entirely. Those achievements exclusive to Legacy Console Edition should be moved to a "Removed achievements" section. I also proposed on the grass talk page to split shrubs and mark them as a removed feature. The BlobsPaper.png 14:42, 10 December 2019 (UTC)
Opened a new talk section specifically for shrubs. -PancakeIdentity (talk) 23:23, 10 December 2019 (UTC)

Replace isometric renders with interactive 3D models[edit]

The result of the discussion was Do not replace.

A thought that crossed my mind recently would be the replacement of the current widely-used isometric renders with actual three-dimensional models of said objects that can be moved around by the user, like the one that can be seen on this page.


  • Would allow the player to see things from angles otherwise inaccessible from a pure still image
  • Certain objects, such as bee models and certain model changes in History sections, require that the camera position for rendering be rotated in the first place so the difference can be seen - with models, the previews would look more consistent and the viewer would rotate to see the changes


  • Hardware and software support - png support is basically universal, so if we go with these then certain devices might not be able to view anything in the worst case, or just not be able to interact with it well in the best case. Could be worked around by adding links in infoboxes to view original images.
  • Replacing all the renders with these would be a pretty massive undertaking.

Is this a good idea at all? - User-12316399 (talk) 13:32, 23 November 2019 (UTC)

 Strongly oppose. I don't think there is a huge need to do this, plus it would bring a large quantity of work that we can just avoid. It IS a good idea though; It's just way too complicated to do this kind of work by SVG. --LakeJason (TalkContribs) 16:33, 23 November 2019 (UTC)
 Weak support. Seems like a huge undertaking and I'm not sure if it'd be worth the effort. It would be nice to be able to see all sides of things, such as Cartography Tables, or see changes outside the usual view. -PancakeIdentity (talk) 17:34, 23 November 2019 (UTC)
I agree. The only problem is that I don't know any kinds of things that are out-of-box to render the block online (if there is let me know) and it would be much more complicated if we are going to make an interactive SVG. Maybe it's not that complicated if we can just write a JavaScript or something, and when that just doesn't work we can fallback on the png files. --LakeJason (TalkContribs) 18:02, 23 November 2019 (UTC)
 Oppose now. Seems like too much work and the downsides outweigh the benefits. Just creat addition renders like normal if needed. -PancakeIdentity (talk) 00:26, 28 November 2019 (UTC)
This video shows lots of underside textures that players do not normally see (Note: It was created 3 years ago in Legacy Console Edition, but the information is probably still true). The main thing that isometric renders would do is show these "hidden textures", which should probably be documented using the raw texture files (currently, only a few pages show these, but we could change that). The BlobsPaper.png 18:39, 23 November 2019 (UTC)
  •  Strong oppose – Unnecessary and not mobile friendly. Also, people always get images directly from the wiki pages and will be confused as to why their image doesn't function like an image.  Nixinova T  C  06:07, 27 November 2019 (UTC)
 Oppose per above. -BDJP (t|c) 00:34, 28 November 2019 (UTC)

Articles on Mojang staff and related persons - do we really need them?[edit]

Except for perhaps the most notable people, do we really need articles that get almost no editor attention and rarely exceed a couple short sentences? I don't see how most of them are even relevant. Even spin-off titles like Story Mode or Dungeons are more relevant, I think. --AttemptToCallNil (report bug, view backtrace) 18:56, 23 November 2019 (UTC)

I feel like, at best, we should try to expand the articles as much as possible, much like how Wikipedia does it with their policy on biographies of living persons, making sure that information about them is backed up be reliable sources. I do recall mentioning back in 2015 that we could possibly use LinkedIn profiles as a source for reliable information, though discussion never went anywhere beyond that. -BDJP (t|c) 21:30, 23 November 2019 (UTC)
We mention devs pretty often in history sections, and it might be useful to have these pages in those cases. Especially when they commonly go by nicknames (i.e. Jeb or Dinnerbone). Other than that, I don't know. I would like to see the general staff page updated though. -PancakeIdentity (talk) 04:41, 27 November 2019 (UTC)
Other than the obvious ones I think there should just be an "employees" page that lists mainly job-related info; this also avoids the BLP issues we've had in the past.  Nixinova T  C  06:03, 27 November 2019 (UTC)

Official Minecraft wiki[edit]

So, if you visit the minecraft.net Community page https://www.minecraft.net/en-us/community and scroll nearly to the bottom, above Discussions & Help, there is a link to the "Unofficial Wiki"... which goes to this wiki.

I did a little search of the wiki here and found no mention of this unofficial link.


Sorry for being lazy and not creating an account. 13:40, 30 November 2019 (UTC)

User:FVbico mentioned on the wiki Discord that he contacted User:HelenAngel (the community manager) about this, as she has previously stated in a Discord private message that "the wiki is official and officially endorsed". While most of the content here is written by community members and Mojang doesn't take part in day-to-day editing activities, they do maintain some official documentation pages. –Sonicwave talk 18:19, 30 November 2019 (UTC)
Okay, I asked about it, and minecraft.net is right; the web team was told that since Mojang doesn't own the wiki, it cannot be called official. FVbico (talk) 16:42, 3 December 2019 (UTC)
Interesting. What does that mean for the opening... Welcome to the Official Minecraft Wiki on the homepage? --Thefakesheep (talk) 23:03, 3 December 2019 (UTC) (OP here)
While it is not technically an official wiki, it is probably the most credible Minecraft wiki, since the developers have acknowledged (and even created) the necessary pages. The BlobsPaper.png 04:10, 4 December 2019 (UTC)
This somewhat implies that they consider what is official, and there is a possibility Mojang will have their own "official" wiki/resources. It will be otherwise if they don't care about the wiki being the official nor non-official. – ItsPlantseed|⟩ 07:51, 4 December 2019 (UTC)

Cannot do the ScreenShoot Licence Project[edit]

The file MediaWiki:Msu-comment cannot be edited and I would like to licence it with "free art". --Andrew36903690 Diamond Pickaxe.png (talk) 08:59, 11 December 2019 (UTC)

That would change the default license for every file uploaded using msupload, which we can't be sure about the correct license. You will need to edit the file pages manually after the upload add the license or use Special:Upload.   HorseFace.png Gamepedia icon.png MarkusRost (talk) 09:42, 11 December 2019 (UTC)

Make templates for common NBT practices.[edit]

NBT have several basic tags, and there are many common practices in Minecraft: Java Edition based on those tags. Mojang does use some functions to parse these practices accordingly, I showed three of them here using yarn's mappings:

  • Boolean-like TAG_Bytes: Parsed by net/minecraft/nbt/CompoundTag#readBoolean. They are technically TAG_Bytes. They use 0 to represent false, and all the other possible values to represent true. e.g. NoGravity tag for entities. I've made a possible template User:SPGoding/Sandbox/Nbt practice/boolean for them:
    {{:User:SPGoding/Sandbox/Nbt practice/boolean|NoGravity|if true, the entity does not fall if in the air.}}
      •  NoGravity: 1 or 0 (true/false) - if true, the entity does not fall if in the air.
  • UUID TAG_Longs: Parsed by net/minecraft/nbt/CompoundTag#getUuid. Two TAG_Longs named KeyMost and KeyLeast which represent the most significant bits and least significant bits of an UUID. e.g. UUIDMost and UUIDLeast tag for all entities. I've made a possible template User:SPGoding/Sandbox/Nbt practice/uuid_longs for them:
    {{:User:SPGoding/Sandbox/Nbt practice/uuid_longs|UUID|this entity|indent=*:**}}
  • Block state TAG_Compounds: Parsed by net/minecraft/nbt/NbtHelper#toBlockState. A TAG_Compound with a TAG_String named Name and a TAG_Compound named Properties with all the block properties stored. e.g. carriedBlockState tag for enderman entities.

Currently we have Template:Nbt inherit for inheriting NBTs from a parent, but we don't have similar things for those common practices, which leads to copy-pasting similar texts for many times. Thus, I propose to make templates for these practices. --SPGoding [Talk] 19:34, 21 December 2019 (UTC)

How they function may be similar, but this would result in complicating the NBT providing even more (it's already complicated for people unfamiliar with the wiki to provide or correct NBT info). Additionally, UUID tags are extremely invonsistent in java, it's one {l:,m:}, another time Least:,Most: and another time UUID:""; you cannot template that.
In short, it'd complicate the most complicated part of the wiki even more, needlessly. FVbico (talk) 20:17, 21 December 2019 (UTC)
Thanks for your quick reply. However, I don't think this template would complicate things too much, to the contrary, it would make changing similar stuff easier. For instance, the function Mojang used to get a BlockState has been called for 5 times. Let's see how many times they have been changed on this Wiki:
There are still two pages (Sand/BE and Enderman/ED) with the similar situation, but I believe there's no need to put them here anymore. I'm sure everyone can find where the problem is: people have to update the 5 pages individually if they want to improve the content of the BlockState structure. I believe this is much more complex than simply updating one universal template, and I believe you are more aware of this than anybody else because all these awesome changes are just made by you. Moreover, the function used to read boolean-like TAG_Bytes has been called 84 times, which means if anyone want to update the current description of it, they have to change tons of pages seperately. However, if we had a template for those common cases, this would no longer be a problem.
Here is all my opinion, I really appreciate for your patience. Merry Christmas! --SPGoding (Talk) 23:10, 21 December 2019 (UTC)
 Support. I think it's the right idea, and if you can solve FVBico's objection to UUIDs where "you can't template that", then I feel it's got no major problems. Yes, doing the nbt templates is complicated, but I don't see this adding significantly to that, relative to the benefit. – Sealbudsman talk | contribs 15:47, 4 January 2020 (UTC)

Trading information on pages[edit]

Hello! My suggestion is make a template to automatically insert trading informations on the page from a database, like {{LootChestItem}} already do. For example:

Leather page
== Usage ==
=== Trading ===
{{Trading information|Leather}}

I hope you got it. This would make it a lot easier when adding new blocks and items or even in a new makeover in the trading system.(Mojang is unpredictable)

Thank you! --dr03ramos Piston.gif (talk) Admin wiki[pt] 21:51, 1 January 2020 (UTC)

Not sure how we'd make those, but  Support FVbico (talk) 21:54, 1 January 2020 (UTC)
that would be really useful so  Support -Hanzepic (talkcontribs) 14:53, 4 January 2020 (UTC)
 Support If you can do it, that would be great, yes – Sealbudsman talk | contribs 15:37, 4 January 2020 (UTC)
 Support though I'd much prefer a dedicated template for trading like with crafting. - User-12316399 (talk) 16:05, 4 January 2020 (UTC)
 Support If you can get someone willing to do it, this would be very helpful. -PancakeIdentity (talk) 00:16, 5 January 2020 (UTC)

Color disambiguation pages[edit]

The result of the discussion was delete.

I propose that such disambiguation pages are deleted because:

  1. They are, in most part, template-like collections of color variants of dyeing-related objects.
  2. They claim to be lists of objects having a certain color, apparently only applying to an explicit connection with the said color (so for the purposes of such pages, bedrock is not black, lapis lazuli blocks are not blue, and prismarine has no color). If the pages would also list blocks having primarily some color, this may create controversies regarding ambiguous color classification. (Note that I don't believe it's meaningful to involve resource packs as a means to refute this point, as resource packs may not have the dyeing/color system in a form similar to the original game.)
  3. In most part, they represent an artificially constructed category with little value to players. If we wished to provide an easy way for players to e. g. select objects for their color during construction or similar purposes, a page (tutorial?) on in-game color design could be useful; I don't believe simple disambiguation lists are helpful for this purpose.

Any feedback on this? --AttemptToCallNil (report bug, view backtrace) 08:22, 4 January 2020 (UTC)

 Strong support. -BDJP (t|c) 08:27, 4 January 2020 (UTC)
 Support. A tutorial would be much better. --Hatsuki kiriT〕 08:41, 4 January 2020 (UTC)
 Support. I actually got confused when I knew their existance.-- LakeJasonFace.png Lakejason0 (TalkContribs) 08:48, 4 January 2020 (UTC)
 Support removing them. They seem kinda useless. The page names could also re-redirect to dyes. -PancakeIdentity (talk) 08:59, 4 January 2020 (UTC)
 Support Recommended removtal. This kind of meaningless and controversial disambiguation page is better not to appear. --HlDorəmonWf(TAlK · C0NTR1BZ) 09:03, 4 January 2020 (UTC)
 Support For example, the Red page lists all red-dyed features, which is already documented on the Dye and Red Dye pages. There is no point redirecting because if a user searches Red, the Red Dye page will show up. With the Village and Pillage dyes, this holds for all 16 colors. The BlobsPaper.png 14:21, 4 January 2020 (UTC)
 Support: the search function does a better job of getting you pages about Red (and so forth), but automatically. – Sealbudsman talk | contribs 15:39, 4 January 2020 (UTC)
 Support Useless pages –Capopanzone (talk | contribs) 00:39, 7 January 2020 (UTC)
We can almost certainly re-redirect/delete these pages at this point. -PancakeIdentity (talk) 01:07, 9 January 2020 (UTC)

Template AutoUnsigned[edit]

So, as you may have noticed, {{AutoUnsigned}} no longer works as of a recent MediaWiki update. I was using a (somewhat hacky) approach to fetch the last user to edit the page, and now that approach has been "patched" to return the current user making the edit.

Since it appears it is no longer possible to make that template work using wikitext, I implemented an alternative using JavaScript at User:KnightMiner/autosign.js. The script adds a button to the editing toolbar under Advanced > Insert to insert a filled out {{Unsigned}}. It works fine in my testing so far, but I would like additional testing; if well received, I would like to make it into a gadget then delete {{AutoUnsigned}}. So, does anyone support or oppose this as a gadget?

As a couple notes on the script, the first thing is it does not currently support the classic toolbar. I would have added support, but I cannot find the option to switch to that toolbar to test it. The second note is it would be possible by changing the script to autosign comments from older revisions than the latest, though not sure if we can add a good enough interface to that to make it worth it. KnightMiner · (t) 20:25, 6 January 2020 (UTC)

 Support The template was very useful because I would not need to keep checking the IP address and timestamp. The BlobsPaper.png 23:25, 6 January 2020 (UTC)
  •  Comment: The template still works if you subst it, go into "Show changes", and copy-paste the added text.  Nixinova T  C  23:47, 6 January 2020 (UTC)
I haven't been able to get the button to show up after adding the import line to my common.js; the Advanced > Insert section just shows the gallery, redirect and table buttons. I tried changing the Editing > "Enable the editing toolbar" and Gadgets > "Show extra buttons on the classic toolbar" options in preferences, but neither of them seem to have an effect on the toolbar. –Sonicwave talk 06:12, 9 January 2020 (UTC)
The existing gadget is unrelated. It appears the javascript function importScript no longer exists. Majr can you shed any light on if that is intentional?
You should be able to fix this using mw.loader.load, of if you are lazy you can copy the localLoad function and use that in place of importScript. KnightMiner · (t) 05:25, 10 January 2020 (UTC)
Fixed, it seems to work when testing it in Special:Diff/1485234 and Special:Diff/1485236. I would support this as a gadget; for the idea of signing older comments, maybe clicking the button could show a popup window where you'd input the diff ID of the unsigned comment. –Sonicwave talk 07:13, 10 January 2020 (UTC)
That would certainly be possible, but I feel like if you can copy and paste the diff ID, it would be just as easy to copy and paste the username and timestamp. I guess timezones would be a bit annoying, so maybe we should add a timezome parameter to {{unsigned2}} so it can automatically convert to UTC. KnightMiner · (t) 18:54, 11 January 2020 (UTC)
I tried to add this as a gadget at MediaWiki:Gadget-autosign.js, but it's not working. The actual gadget definition works fine for me (e.g. the gadget appears in the preferences), but when I enable it the autosign option doesn't appear in the toolbar. It worked fine when I directly imported your user script, so I'm probably making some dumb error that's simply due to me being a newbie to JavaScript.--Madminecrafter12 (Talk to me | View what I've done) 02:15, 10 February 2020 (UTC)
Removed for now.--Madminecrafter12 (Talk to me | View what I've done) 02:28, 10 February 2020 (UTC)
I fixed it, seems MediaWiki supports Javascript ES6 in user scripts, but not in Gadget scripts. We should probably delete the old template at this time since its broken. KnightMiner · (t) 06:30, 11 February 2020 (UTC)
Thanks, and done.--Madminecrafter12 (Talk to me | View what I've done) 15:01, 11 February 2020 (UTC)

Gravatar machine broke[edit]

Is it just me, or is my icon still blank? I have my Gravatar set up (and have for a very long time), and yet my user icon is still the default grey person. -- Invicon Command Block.gif DigiDuncan! (talk) 01:45, 16 January 2020 (UTC)

Yeah, it took a long time to finally work for me. Not sure how I fixed it tbh. -PancakeIdentity (talk) 04:42, 16 January 2020 (UTC)

Version of the {{in}} template for {{upcoming}}?[edit]

Should we make a version of the {{in}} template for {{upcoming}}? Right now, we always have to add it onto the end of sentences. This can make things confusing or hard to read in certain cases. A version of the {{in}} template would allow us to preface a sentence with the information that something is upcoming, leading to clean sentences and easier reading. -PancakeIdentity (talk) 05:24, 7 February 2020 (UTC)

So are you suggesting an "In Java Edition 1.16" format? I would  Support this. The BlobsPaper.png 15:09, 7 February 2020 (UTC)
I'm not so sure about this. It's just a small patch to a very large and wide problem on the wiki. How is the RESI project going? I'd be neutral to this suggestion, but I'd rather like to see larger solutions or more progress on the overall project. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:03, 9 February 2020 (UTC)

Addition of experience amount in furnace recipes[edit]

There is a request dating back from... 11/2015 that the amount of experience is added to the smelting recipe UI. Only almost 40 months later has this been implemented by me and Pneuma01 as per lordmuzik848#0191's taunt. Stuff is currently residing in Smelting, Recipe table and UI modules' respective edit copies.

The modification is nothing more than the addition of a third argument. Below are some previews:

I bring this here to receive potential feedback and if everything is fine, merge the changes into production. Lê Duy Quang (Make some words | Contributions) at 3h02:14 – 3 | 18/2/2020 (UTC)
Name Ingredients Smelting recipe
Steak Raw Beef +
Any fuel

Mineral Any raw ore + Any fuel

 0.1 0.7 0.2 1 0.7 1 1 0.2 2