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)

Should we move all Tutorials pages to a own namespace?[edit]

Should we move all Tutorials/ pages to a separate namespace, because all tutorial pages should have a own namespace instead of in the main space, and there could be a new Tutorials: namespace and a Tutorials talk: namespace could be new namespaces to make tutorials in and if we make it, we would have a Tutorials link to the Tutorials: namespace in the sidebar and also link to the pages on the Main page and we could have the main page as Tutorials:Main Page or Tutorials:Index and redirect the current Tutorials page to the main page to the new namespace. The new tutorial pages could be located by a search box on the "Main Page" of Tutorials and all pages could have the prefix "Tutorials:Example" (where Example is the tutorial page of the current Tutorials/Example tutorial page. -- Wikipedia-logo.png psl85 (talkcontribs) 19:55, 5 December 2018 (UTC)

 Support, nothing else to add. FVbico (talk) 20:04, 5 December 2018 (UTC) The arguments from other people below actually convinced me, so it's become a  No for me. FVbico (talk) 15:01, 29 January 2019 (UTC)
 Support, but I don't think Tutorials:Main Page would be the right place to put an index. I like Tutorials:Index better, similar to how Help:Contents works on wikipedia (n.b. Help:Main Page redirects there too). --Pokechu22 (talk) 20:15, 5 December 2018 (UTC)
 Support and Comment There is at least one subpage of Tutorials that is linked to directly from a main page, I think using a {{main}} template. (Sorry, off the top of my head I can't remember exactly which page it is. Maybe Enchanting? But there could be others, too.) If this gains consensus, I hope we can make a split between them. – Auldrick (talk · contribs) 21:16, 5 December 2018 (UTC)
There are actually a large amount of "normal" mainspace pages that are linked to Tutorials subpages, such as Carrot.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:58, 11 December 2018 (UTC)
 Support "Tutorial" and "Tutorial talk" namespaces (singular, in line with the others). Also, redirect Tutorials to Tutorial:index or Tutorial:contents, instead of to "Tutorial:Main Page". It will be an exhaustive overview of contents (an "index"), more than a regular page describing the content of the namespace as a "main page" would. All current tutorial pages would have to be redirected to the new namespace, not just the top level "Tutorials" page. I don't think we need a second search box though, the one we have will be just fine this way. – Jack McKalling [ Talk Contrib ] 22:16, 5 December 2018 (UTC)
 Strong oppose The proposal uses only cyclic argumentation (we should do it because it should be done) for support. I ever heard only one solid reason to move tutorials outside the main namespace (not even its current subpage pseudo-namespace) was that they were of poor quality, and people shouldn't see such poorly written pages when they click "Random page", but this is an argument for improving the tutorials rather than putting them somewhere where they're even less likely to be found. Are there any real reasons we should do this? --AttemptToCallNil (report bug, view backtrace) 09:10, 6 December 2018 (UTC)
Because the tutorials do not describe the game. They describe suggestions from player to player, and aren't really articlespace worthy within the vision of the wiki, in my opinion. They have a different tone, different set of editors, different audience and different intentions. – Jack McKalling [ Talk Contrib ] 09:24, 6 December 2018 (UTC)
Do we have a standard definition for what exactly the main namespace is for? --AttemptToCallNil (report bug, view backtrace) 09:36, 6 December 2018 (UTC)
 Neutral Don't really have a strong opinion on this, although I would prefer "Tutorial:" over "Tutorials:" and "Tutorial:Index" or "Contents" over "Main Page" (for reasons stated by Pokechu22 and Jack McKalling). Just as a general note though, there are currently 351 content pages and 273 redirects beginning with "Tutorials/", although around 50 of them are /video subpages. –Sonicwave talk 21:21, 6 December 2018 (UTC)
 Weak oppose Meh, I don't really see a good reason for this. One disadvantage is that if we do this, the pages will not show in the search bar because namespaces don't. The article namespace is for content relating to the game, which tutorials are, and I can't think of a reason why we need to go to the trouble to move these all to a new namespace and just complicate things.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:41, 11 December 2018 (UTC)
 Comment If we move the pages to a new namespace, we could make in the LocalSettings.php so these could show up by default in the search bar. --Wikipedia-logo.png psl85 (talkcontribs) 18:53, 11 December 2018 (UTC)
Oh, I didn't realize that was configurable; thanks for the enlightenment. However, again, I still don't see a good reason to do this and it would create quite a bit of extra work.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:55, 11 December 2018 (UTC)
 Support Per the above reasons and I would like to be able to block seeing these pages on recent changes. Also the namespace should be singular (Tutorial:) – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 03:46, 17 December 2018 (UTC)
 Strong oppose It is specifically because the tutorial pages need fixing that they shouldn't be moved to a new namespace. Moving them to a different name-space doesn't fix tutorial pages, it just tries to hide them. Though the Minecraft Wiki is meant to explain factual data about the game, it cannot fully do that without the tutorial pages. Things such as redstone circuits, general farms, game quirks, functions, and information about the game's UIs all are stored within the tutorials. This is factual evidence that can only really be given in a tutorial format. I agree that the tutorial pages on this wiki are terrible, but the wiki needs tutorial pages, so instead of hiding them where they'll get edited less, the pages should be kept in the open so they're more likely to be maintained or fixed. -SuperDyl19 (talk) 06:29, 18 December 2018 (UTC)
 Weak oppose According to this page, the only reason I found to use a custom namespace is that it can be used to hold content that should not be shown on the search results page. Though most wikis use custom namespace so that only users that require additional privilege(s) can edit. For this case, tutorial pages does not require special privileges to edit and is not restricted. --skylord_wars (talk) 17:10, 31 December 2018 (UTC)
 Support - The aim of the mainspace is for information on the game (and, by extension, Mojang) to be documented. Tutorials do not fall within the scope of what the mainspace should document, and as such should not be kept in the same namespace. It's also worth noting that other Gamepedia wikis such as the Terraria Wiki already have namespaces dedicated to tutorials. - User-12316399 (talk) 12:59, 12 March 2019 (UTC)
 Oppose - but only for part of the tutorials.
I'm persuaded both by Skylord wars' and SuperDyl19's reasoning. As SuperDy119 points out, the tutorial sections often are critical for users' understanding of how the game works, particularly for new users who might not have a good grasp of features like redstone mechanics or minecart functionality. As a new player, I referred to the redstone tutorials many times and still do on occasion, and I play with other experienced players who also will turn to the tutorial information to look up some specific kind of redstone circuit when needed. Not all of the tutorials are this kind of information, however, so maybe some of it should be organized separately, such as the "suggestions from player to player" information that has less to do with advanced or nuanced game mechanics and more to do with game strategy ideas.
As a rough analogy, moving or striking the tutorial section as being "not valid information about the game" would be like having a computer programming textbook that defines what variables and procedures are but that does not include any examples of actual working procedures. Many new programmers would find it difficult to understand how to write procedures and make them work within a program without seeing those examples. Such examples are definitely important to illustrate a particular core feature of the language.
Yes, the tutorial pages are in need of significant improvement in various ways (last I checked), and they may need to be reorganized to distinguish ones that are more fundamental to understanding how the game works from ones that merely offer suggested play strategies, but I'd argue that the former at least need to be kept as part of the main wiki space. Memetics talk | edits 18:53, 27 April 2019 (UTC)

Bot's task request[edit]

This bot will be used on:

  • Cosmetic changes
  • Repair interwiki links
  • Text replacement
  • Automatically welcome new users (Use with {{subst:Welcome}})
  • Automatically clean Sandbox
  • Automatically archive

--Angrydog001 (talk) 06:03, 3 January 2019 (UTC)

Bump and . – Nixinova Nixinova sig1.png Nixinova sig2.png 04:11, 9 April 2019 (UTC)
Bots making purely cosmetic edits to page wikitext are controversial, I wouldn't recommend that task. Automatically welcoming new users with a bot is very often perceived as annoying, defeats the purpose of welcoming, and disruptive users may be welcomed (vandals, spammers, users with unacceptable usernames). --AttemptToCallNil (report bug, view backtrace) 08:21, 9 April 2019 (UTC)
I agree with ATCN about welcoming new users with a bot; the software already gives you notifications for making your first/10th/100th edit if I'm not mistaken. Cleaning the sandbox might be useful, but it doesn't get edited that frequently and it isn't much trouble to clean it by hand. Repairing interwiki links would be useful, and for text replacement it would depend on what text is being replaced (large scale text replacements should probably be discussed first). –Sonicwave talk 23:00, 10 April 2019 (UTC)

Minigames page?[edit]

I propose a generic minigames page, where, like mods, people can create subpages explaining a certain minigame. Minigames are more relavant to the Minecraft than mods since they can be played in vanilla or semi-vanilla so I reckon they have more of a place on this wiki. Also, they aren't going to get quickly outdated since they don't necessarily apply to just one version of Minecraft. – Nixinova Nixinova sig1.png Nixinova sig2.png 05:11, 7 January 2019 (UTC)

I like the page, but I think it would be beneficial to clarify on both the minigames page and on the specific pages (such as Spleef) that they are not in any way official features, and are more player-made concepts or something similar. It's implied currently, but yeah. -PancakeIdentity (talk) 05:27, 26 May 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)

Should we make a "farmable" section on item pages?[edit]

It isnt exactly the same as "renewable", but it can be an extra option for it. What I'm reffering to here is if it can be renewed without player interaction. Just a suggestion.–Preceding unsigned comment was added by AFellowEditorLikeYou (talkcontribs) at 1:47, 14 January 2019 (UTC). Please sign your posts with ~~~~

I don't really understand this. Can you give examples of "farmable" items and items that are renewable but not "farmable"? an_awsome_person (talk) 16:43, 27 January 2019 (UTC)
Items renewable only through trading would not be farmable.
 Oppose I don't really see a use for this. I understand the difference, but it gets muddy with the inclusion of redstone and such. Are logs just renewable because saplings need to be planted by the player, or farmable because they can be broken and gathered without player interaction? Renewable works perfectly fine imo. -PancakeIdentity (talk) 05:30, 26 May 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)

Use official Mojang trailers over slicedlime videos?[edit]

Would it be better to use official Mojang trailers on 1.x updates instead of slicedlime's fill coverage? A short video in my opinion would be better as all the other information is already found above. Maybe even have both? – Nixinova Nixinova sig1.png Nixinova sig2.png 06:42, 31 January 2019 (UTC)

 Support for both only, not for removing slicedlime's. FVbico (talk) 20:27, 20 February 2019 (UTC)
Same:  Support allowing both. – Sealbudsman talk | contribs 21:59, 11 May 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)

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

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)
How about more updated/accurate videos? :3 Marinah (talk) 17:27, 17 April 2019 (UTC)

InvSprite is out of memory again[edit]

Image. The last time this happened, the solution was performance improvements. But I think this is obvious now we can't just optimize sprites forever, and a more conceptual rework is needed to support the ever-growing sprites. I have no idea what the solution to this might be (except maybe generating the image list at runtime using JS). Splitting away some of the sprites could also work, but it seems to me this will have a lot of drawbacks. --AttemptToCallNil (report bug, view backtrace) 18:51, 20 April 2019 (UTC)

I thought we're indeed going to split the template, hence the Template:InvSpriteTextureUpdate. I proposed this in an old discussion, but everytime I asked about this nobody seems to care. – ItsPlantseed|⟩ 19:04, 20 April 2019 (UTC)
Surey we could relocate the banner textures to another file entirely, given how much space they take up? - User-12316399 (talk) 22:49, 20 April 2019 (UTC)
The best idea I can think of is to split away some of the sprites to a separate template (not to single files). The banners take up a lot (there appears to be over 1000 over them, in fact), so as 12316399 suggested, separating them might be a good start.--Madminecrafter12 (Talk to me | View what I've done) 13:36, 21 April 2019 (UTC)
How are we going to use the split-off sprites in inventory slots? Our slot and UI modules aren't designed to handle multi-page InvSprites. --AttemptToCallNil (report bug, view backtrace) 13:40, 21 April 2019 (UTC)
They aren't? Hmm, that's too bad. How difficult would it be to allow multi-page InvSprites?--Madminecrafter12 (Talk to me | View what I've done) 13:41, 21 April 2019 (UTC)
A system of completely multi-page sprites would also have other limitations. For example, it would be difficult to move sprites between pages. There would not be a centralized location to edit all sprites.
The real issue is the pre-generated sprite list. There is no other significant limitation to sprites: we're over 2000 (probably over 3000 now!) sprites for InvSprite, and the file size isn't a quarter of the 8 MB maximum (plus, I almost don't doubt this maximum can be doubled upon request).
Whatever the new system of sprites will be, it needs to:
1) allow as easy sprite sheet editing as the current one, both using the sprite editor and manually (given translating the sprite is easier manually especially if external Lua scripts are used to assist with translation);
2) not be much harder to maintain than the current one (meaning the restructuring of sprite data, like addition of a new field for IDs, should not require extensive rewrites to complex JS);
3) not be too complex to translate;
4) not be prohibitively difficult to develop.
Any system where sprites are split would be relatively easy to develop, but difficult to maintain and difficult to modify.
Any other system I can think of requires runtime-generation of the sprite list, which either complicates manual editing or requires implementing a Lua parser in JavaScript.
Does anyone have any ideas? --AttemptToCallNil (report bug, view backtrace) 14:50, 21 April 2019 (UTC)
From my experience, I don't think that centralized sprite edit will be efficient in any way. Long documentation is a pain to deal with, I'd think by downloading the old sprites and uploading them afterwards into a separate not-so-long-list of sprites is a lot easier than moving them one by one to their section respectively on the same page. So with separate pages, you don't have to scroll through the long documentation to move the old sprites. And of course this would only make sense if we are going to split pages between the olds and the up-to-date ones. (P.S. I can only think of splitting them, not sure if I can come up with one with less drawbacks) – ItsPlantseed|⟩ 15:48, 21 April 2019 (UTC)
How about keeping all invsprites in one definition file like they are right now, but split them into categories, such as "current", "old revision", "colour states" etc, and document these separate categories on different pages? I don't know much about lua or sprites, but just an idea. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:06, 22 April 2019 (UTC)
I say that while we are not at a limit of the sprite sheet, its a lot more effort than its worth to split into multiple docs. The issue comes down to what do you logically split at so it remains in space for the sprite editor.
Personally, I say just move all the legacy stuff to another sheet once 1.14 releases, as by that point none of the main pages would still need them. I honestly cannot think of a good reason to keep every single old version on the main sheet anyways, it not like the crafting templates specifically call for the old textures ever. KnightMiner · (t) 19:37, 22 April 2019 (UTC)


While I agree legacy sprites could be moved to a separate spritesheet, this would be a difficult task, it would further complicate editing and translation, and won't fix the actual problem which will keep occurring whenever the main sheet becomes too large. Splitting the sprite sheet endlessly should be an obviously nightmarish option which will make the entire sprite system an irrecoverable mess. I understand whatever long-term solution would be very difficult to create, but at least it's more long-term and doesn't complicate regular editing. --AttemptToCallNil (report bug, view backtrace) 19:52, 22 April 2019 (UTC)

While I agree this solution will not work forever, my point is there is no reason to maintain two copies of every icon on the main template, just split off the legacy icons for now so its not broken until we can come up with a long term solution. No reason for it to be broken simply because the solution will not work forever. InvSprite is designed to use in the crafting grids and the crafting grids do not need outdated sprites; this is not a case that is about endless splitting, splitting legacy out is something I would have argued even if it did not overload the doc page as that many sprites makes normal editing painful. KnightMiner · (t) 00:45, 24 April 2019 (UTC)

Ugh no wonder it's out of memory with all the sprites being duplicated from the texture update. The texture update sprites should've gone in Template:InvSpriteTextureUpdate, which would've then replaced Template:InvSprite when the update came out, but it's too late now. Only current versions of items should be in InvSprite, as they are the only ones that need to be used hundreds of times on a page, and thus need the performance of a sprite. Old versions of items (and maybe even removed items) can just be normal files, as they are just used once in the history section. Even if you need an old item to demonstrate an old recipe, you can still use individual Invslot files in recipes by including the file extension in the item name. MajrTalk
06:23, 27 April 2019 (UTC)


1.14 is out, and since it changed all the textures, we need to modify a lot of things:

  • Move current invsprite to a separate template, to maintain the pre–Texture Update textures.
  • Change usages in the history section to point to this new template revision n files.
  • Move all images to a separate file and move the TextureUpdate files there.
    • Again, update the history section to point to these.
  • Add all texture update files to their respective pages ("Changed the texture of PAGENAME.").

Nixinova Nixinova sig1.png Nixinova sig2.png 19:56, 23 April 2019 (UTC) edited 23:09, 10 May 2019 (UTC)

I'd say we split InvSprite up a bit more, just so we don't run into memory issues. InvSprite could be split up into BannerSprite for banners, SlotSprite for slot icons as well as the "tool needed" icons the wiki uses, a template for old item sprites, and a template for old block models in the inventory. - User-12316399 (talk) 20:03, 23 April 2019 (UTC)
That would work. – Nixinova Nixinova sig1.png Nixinova sig2.png 20:26, 23 April 2019 (UTC)
Regarding InvSprite, I disagree with splitting it up just like that, after all, it solves nothing. Also, go here regarding discussing the InvSprite issue. FVbico (talk) 20:36, 23 April 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'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)

Categorize images of generated structures and other images?[edit]

Should we categorize images of etc. generated structures, such as fossils to Category:Fossils or pillager outposts to Category:Pillager outposts? Then, sub-structures could be categorized to a subcategory, such as zombie villages to Category:Zombie villages and then add "Category:Villages" to the zombie villages category, so the images of generated structures are easier to find. Any suggestions? -- psl85 (talkcontribs) 12:38, 25 April 2019 (UTC)

You can already find images of generated structures on their mainspace articles. Why do you think searching in categories is easier than searching in the gallery section of a mainspace article? an_awsome_person (talk) 01:03, 7 May 2019 (UTC)

Phantom links from Template:Extension DPL[edit]

This, among other pages, appears to be linked from the page Template:Extension DPL despite no link existing and the page itself appearing to be auto-generated. These phantom links seem to be persistent and have remained on WantedPages for quite a while now. What's going on here, and can it be fixed? - User-12316399 (talk) 07:57, 29 April 2019 (UTC)

Maybe the Module:Development versions has a bug where it doesn't correctly prefix "Java Edition" to links? I don't know lua. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:51, 29 April 2019 (UTC)
Fixed it with a null edit to Template:Extension DPL. This list of pages there created the link. Why do you even have that list there? It's just the same as Special:WhatLinksHere/Template:Extension DPL. We don't do that for other templates and it just creates cached red links for deleted pages that require a null edit.   HorseFace.png GRASP logo.png MarkusRost (talk) 15:31, 29 April 2019 (UTC)

Being unable to browse here due to user scripts bug - need help[edit]

Hello! I seem to have trouble with the website today, when i load my user page (User:Psl85) the page reloads and then the browser windows becomes light blue, first I thought it was wrong with my PRO subscription, it had expired, the adblocker started blocking ads instead, also i had tracker blockers installed that I also tried to disable here but it did not work. I also tried to disable my adblocker but if i disabled it the ads started appear and I HATE ads and also I got the same screen. Then when I disabled all trackers, adblockers, etc. that still occured, it is something wrong with my scripts, the user scripts might cause this, ?safemode=yes solved the bug with my scripts on mainspace pages (with the ads) the other pages worked fine with the scripts 😛. Can someone check the bug please and help me to disable the scripts that causes pages to become blue? This causes so I cannot browse here 😠

What should I do to solve this bug? -- psl85 (talkcontribs) 16:16, 6 May 2019 (UTC)

I found a bug in your common.js. Try now. --AttemptToCallNil (report bug, view backtrace) 16:35, 6 May 2019 (UTC)
AttemptToCallNil Thank you 😛 what was the bug? -- psl85 (talkcontribs) 18:03, 6 May 2019 (UTC)
I explained it in the summary of the edit I made to your common.js. --AttemptToCallNil (report bug, view backtrace) 18:11, 6 May 2019 (UTC)
The code that Attempt commented out, caused the entire body itself of the page effectively be removed from it, in case it had the "show-ads" class. You could just try removing only the class to prevent the ads, instead of the whole element, if that effect is what you intended with that particular code. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 21:09, 6 May 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)

Move translation pages out of mainspace[edit]

Translation pages currently take the form of a subpages of it's English counterpart. There are many problems with this. They show up in the search bar, and confuse many readers who expect English pages on the English wiki but instead get an outdated foreign language page. I propose moving then to "Minecraft Wiki:language translation/pagename": this will hide it from regular readers and also keep all the pages together so they can be easily listed with something like Special:Prefixindex. – Nixinova Nixinova sig1.png Nixinova sig2.png 02:35, 11 May 2019 (UTC)

 Strong support - another thing is that they appear in the Special:AllPages page that lists mainspace articles, which I'm not much of a fan of. - User-12316399 (talk) 10:30, 11 May 2019 (UTC)
If there's no opposition to this proposal within the next week, I'll move all translation pages to this format. - User-12316399 (talk) 17:20, 20 May 2019 (UTC)
Not so fast, give people the time to notice this, and voice concerns. FVbico (talk) 22:11, 20 May 2019 (UTC)
Support, it should make moving much easier, plus articles can have the correct (translated) name already then. FVbico (talk) 22:11, 20 May 2019 (UTC)
A slight problem with the namespaced approach is that it would no longer be possible to look up translations of an English article by viewing its list of subpages (but see point 3).
With a subpage approach, listing translations in a language can be done by using categories, PrefixIndex would not be required.
I also have concerns that this move would make translations less visible, which should not be considered good. Even though this is possible with the namespaced approach as well, perhaps a form of translation navigation lists at the top of articles with translations would be beneficial?
Additionally, using the subpage approach for translations is somewhat of a convention for MediaWiki. In particular, mediawiki.org adheres to it. --AttemptToCallNil (report bug, view backtrace) 22:14, 20 May 2019 (UTC)
Does MediaWiki address similar issues as noted by Nixinova's OP? Has a similar proposal been vetted there, I wonder? Memetics talk | edits 23:12, 20 May 2019 (UTC)

Make pages from old major releases accessible.[edit]

All the wiki pages seem to be updated for 1.14, but so many mechanics have changed that when I'm playing on a 1.12 server, I have to keep digging through wiki history to find the correct info. Additionally, if I wanted to add some *new* info specific to an old version, like an explanation of a glitch, there's currently no good place for it. I would like to propose something like is done for programming documentation, where old stable versions are moved to their own pages, so you could look up, say, "Smelting" versus "Smelting (1.12)". Nupanick (talk) 13:59, 14 May 2019 (UTC)

What you're asking for is already available. The History tab lists every past version of the page. If you determine the dates that the release (e.g. 1.12) you want was current, you can simply click on a date in that range to get a historical version of the page without the interference from later changes. You can even bookmark those pages' URLs, or make yourself a private index of them in your user space. Am I missing something? – Auldrick (talk · contribs) 15:20, 14 May 2019 (UTC)
My two main points with that are 1) accessibility, and 2) editing. For 1, yeah, I could go to the version history, work out the dates, cross-reference it with the page I want, switch to Desktop view so the "history" tab appears, and find the version I need. But it seems like major versions should be easier to reach than that. Python's docs just have a drop-down to switch between v2 and v3, and its important since both still get considerable use.
Point 2), editing, I don't think can be addressed any other way. If I want to add a useful note on 1.12- villager mechanics, there's simply nowhere I can insert that into an old version of the page. Nupanick (talk) 15:56, 14 May 2019 (UTC)
You are correct. There's no easy way to improve or correct information on old versions just by history. (And, as a side note, the historical versions do experience interference from later pages, as a side effect of updated templates or images or various projects moving pages into arbitrary locations and breaking all the links. I don't complain about these things just because I'm grumpy...)
I don't know how to solve it, though. The issue with adding separate articles like that is that the number of them quickly grows, which makes maintenance painful. (If there was an old inaccuracy that was only now noticed, then it'd need to be fixed on all the forked copies of the pages). I do think that documentation of historical information is important, and at least for older mechanics it'd be useful, but copying every article with a version suffix would be too much. --Pokechu22 (talk) 17:13, 14 May 2019 (UTC)
Doesn't Bulbapedia have this exact problem? The pokemon series has several "major versions", and it's useful to be able to reference how mechanics worked in a specific version. I think they handle this problem by combining multiple versions of the mechanics into one page when it can be easily done with sections, and splitting the page into "old" and "new" versions as a last resort. So for example, we could add an extra column to the charts on the Smelting page to specify how much XP they produced in one version versus another, but the Village Mechanics page would warrant a complete split. Nupanick (talk) 23:48, 14 May 2019 (UTC)
Pokemon is very different from Minecraft. Pokemon only has 7 major updates; Minecraft has literally hundreds. – Nixinova Nixinova sig1.png Nixinova sig2.png 06:02, 15 May 2019 (UTC)
There's no viable way to do what you're asking. How far back would it go? Classic? We can't have 500 pages about the same thing. – Nixinova Nixinova sig1.png Nixinova sig2.png 01:17, 15 May 2019 (UTC)
Glitches or bugs should not be added to the page unless it is a major one. If that specific feature is only available at previous versions, like the Far Lands, it deserves it's own page. Some features also have their own page due to their uniqueness despite the feature is still available now, like Biome/Before Beta 1.8, the root page remains the same. skylord_wars (talk) 12:15, 16 May 2019 (UTC)
I agree with the others that keeping old versions of wiki pages, or old info on current pages, would be impractical. An ambitious editor (such as yourself?) might start a separate project (or a separate wiki?) devoted to a specific popular version of the game, and then copy the applicable page histories from here to there to enable editing and maintenance of that info set for that particular game version of interest.
As for the pain of looking up wiki pages for historical info, a useful workaround is to use archive.org - by starting on one of its archived pages for this wiki from a specific point in the past, one can follow the links to other archived pages in that era, without having to dig into the history here for each page separately. For example: Farmland (Minecraft 1.8). Memetics talk | edits 04:51, 21 May 2019 (UTC)

Legacy Console Edition inevitability[edit]

As Minecraft continues to update, we're going to run into a problem with the Legacy Console version as it lags behind and we have to add sections with the "Legacy Console Edition only" tag on more and more pages, taking up room for information most of the playerbase doesn't use. Especially with Update Aquatic being the last feature update, leaving this version largely unsupported, I propose that we should consider removing information pertaining only to this edition from pages. It's not a big problem right now, but I can see it becoming bigger and bigger. Maybe we could have "[page]/Legacy Console Edition" pages for these things? I don't know, but I don't think what we're doing right now is the best choice either. Thoughts? Ideas? -PancakeIdentity (talk) 05:08, 26 May 2019 (UTC)

 Oppose. Removing that information is counter-productive. At some point we will need to have that information again. There are numerous discussions about edition-specific information, a whole project even. See here: MCW:Projects/Refactoring edition specific information. On its talk page I also added a section listing more discussions and relevant templates etc. Please refer to that place regarding this subject. There is a whole ton more stuff we need to do, it is a wiki-wide mess, involving more than just the LCE edition. We need to approach the problem in the global scope, instead of patching things up left and right, missing the bigger picture. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:48, 27 May 2019 (UTC)
Didn't know about that, thank you! -PancakeIdentity (talk) 21:51, 27 May 2019 (UTC)

Old Item Overview Videos[edit]

(If this is already being talked about elsewhere, I apologize!) We need to talk about the overview videos on a lot of item/block pages. They're all extremely old and filled with inaccurate or outdated information, and most have disclaimers above them showcasing what's inaccurate. Is it worth keeping these videos? I personally don't think so. The articles already provide the information and are up to date. I propose that we remove these videos, at least the outdated ones. Thoughts? Opinions? -PancakeIdentity (talk) 23:28, 29 May 2019 (UTC)

A good idea Marinah (talk) 02:10, 8 June 2019 (UTC)
Feel free to remove outdated videos, it already had consensus for awhile. MajrTalk
14:31, 8 June 2019 (UTC)
Alright, I'll go ahead with that. Is there anywhere I can read this consensus, just out of curioisity? -PancakeIdentity (talk) 18:55, 8 June 2019 (UTC)
There are some, you can find it here, here, here, and here. – ItsPlantseed|⟩ 04:42, 9 June 2019 (UTC)
I'd love if I could get some opinions on how to move forward with this in the topic below. -PancakeIdentity (talk) 02:37, 14 June 2019 (UTC)

Stop overwriting renders and upload new images instead[edit]

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)

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

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)

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)

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

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)

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

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