Talk: Community portal

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?

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 [ ] 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 [ ] 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   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   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}}: and {{OS|win10}}: , 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 [ ] 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 [ ] 16:50, 20 June 2019 (UTC)

 Oppose per BDJP. 174.255.8.180 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. 64.134.162.93 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   20:11, 24 June 2019 (UTC)

For the main page, I would support keeping the updated Windows logo () 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

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?

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. -- psl85 (talk • contribs) 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.-- Madminecrafter12^{Talk to me} 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 [ ] 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 [ ] 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.-- Madminecrafter12^{Talk to me} 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. -- psl85 (talk • contribs) 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.-- Madminecrafter12^{Talk to me} 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 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

• Ag001bot (talk • contribs • logs • block log)

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

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

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 ^{talk◆contribs} 23:38, 11 January 2019 (UTC)

I was thinking of that exact solution as well. Fully agreed. – Jack McKalling [ ] 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 [ ] 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?

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 (talk • contribs) 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

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?

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

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 [ ] 14:57, 12 March 2019 (UTC)

Proposal

• Tutorials ("player guides on how to use or do things")
• Mechanics ("regular articles about game mechanics")
  • Mechanics/Anvil
  • Mechanics/Dyeing (also see this discussion)
  • Mechanics/Enchanting
  • Mechanics/Redstone
    • Mechanics/Redstone/Circuits
    • Mechanics/Redstone/Components
    • Mechanics/Redstone/Clock circuit
    • Mechanics/Redstone/Logic circuit
    • Mechanics/Redstone/Pulse circuit
    • Mechanics/Redstone/Memory circuit
    • Mechanics/Redstone/Transmission circuit
  • Mechanics/Trading
  • Mechanics/Village (although now contains a ton of outdated pre-1.14 content)

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 [ ] 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 [ ] 07:20, 28 April 2019 (UTC)

 Support – Nixinova   06:26, 27 April 2019 (UTC)

"Raw materials" and "manufactured" classifications on item pages

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

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

I'm not against it, but I don't really see how it's valuable. The corresponding wikipedia project is neat, but for accessibility at least I don't think it matters too much since screen readers (e.g. the narrator thing built into windows) exist and we don't use much in the way of special characters that it might break. IMO, the old video overviews of article content are more useful, just because they could also illustrate what's going on. (Of course, I myself just really prefer text to speak, since I can skim over text much faster. So I'm biased.) --Pokechu22 (talk)

It's my understanding that modern text-to-speech readers also benefit from the use of multi-level headings, which enables the user to navigate the page (the reader reads aloud the index of headings). Without headings, the person has to listen to the entire page to find what they're looking for. Much better to skim through the headings first. —Memetics ^{talk | edits} 11:25, 28 April 2019 (UTC)

Screen readers are in no way superior than anyone who would devote their time into making a decent voiceover of an article. Artificial intelligence as of now canʼt understand the articleʼs topic and structure and will inevitably make errors. Also, some info best presented as text will have to be changed to fit for audibility. Iʼm not against the idea, but may it be worth the effort? Might be worth a try though. — BabylonAS ru.Wiki Admin 06:51, 3 August 2019 (UTC)

How about more updated/accurate videos? :3 Marinah (talk) 17:27, 17 April 2019 (UTC)

Thatʼs a way harder thing and surely not worth the effort. Updating voiceovers is much easier if organized properly. — BabylonAS ru.Wiki Admin 06:51, 3 August 2019 (UTC)

InvSprite is out of memory again

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 [ ] 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. –Majr ᐸ Talk
Contribs 06:23, 27 April 2019 (UTC)

To-do

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

See also: MCW:Projects/Version cleanup

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

Is there a difference between Pokechu's and Memetic's example and mine? Anyway, there is now a project that includes this work amongst other stuff, see new hatnote. – Jack McKalling [ ] 08:28, 14 July 2019 (UTC)

Categorize images of generated structures and other images?

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 (talk • contribs) 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

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 [ ] 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.   MarkusRost (talk) 15:31, 29 April 2019 (UTC)

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

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 (talk • contribs) 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 (talk • contribs) 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 [ ] 21:09, 6 May 2019 (UTC)

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

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 [ ] 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   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. –Majr ᐸ Talk
Contribs 07:31, 25 May 2019 (UTC)

Hovering over the image area of an infobox will pause all animations in it now (and you can define any element with animations in it as the container for pausing by adding the animated-container class to it). As for implementing changing the image on hovering an inventory icon, that still needs a viable solution to link related images and inventory images together. –Majr ᐸ Talk
Contribs 07:09, 1 July 2019 (UTC)

Move translation pages out of mainspace

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

It's better to have the translation pages hidden from regular English users as it leads to a lot of confusion. I agree with having a list of translations of a page shown at the top of the English article. What mediawiki does isn't really relevant here, and if you are visiting mediawiki you will have a general idea of how wikis work: on mcw we get average readers so will be confused at why these non-English articles are appearing in their search bars. – Nixinova   00:25, 30 June 2019 (UTC)

Make pages from old major releases accessible.

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

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 [ ] 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

(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. –Majr ᐸ Talk
Contribs 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

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. –Majr ᐸ Talk
Contribs 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   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 [ ] 11:08, 9 June 2019 (UTC)

Great idea!  Support. —Memetics ^{talk | edits} 05:58, 13 June 2019 (UTC)

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

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

Oh, yes! That looks amazing; I'd say definitely do that for all infobox images! FVbico (talk) 09:18, 1 July 2019 (UTC)

I would fully  Support using this format on all renders. – Nixinova   02:54, 2 July 2019 (UTC)

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

Aim of the wiki and other titles in the franchise

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   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   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 [ ] 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 [ ] 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 (talk • contribs) at 20:10, 12 June 2019‎ (UTC). Please sign your posts with ~~~~

I would  Support this method. – Nixinova   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 (talk • contribs) at 02:40, 14 June 2019‎ (UTC). Please sign your posts with ~~~~

AttemptToCallNil's proposed resolution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BDJP007301's proposed resolution

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

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

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

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

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

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

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

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

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

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

“

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

„

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

In other words, here are the key points of this topic:

1. Story Mode (SM) and Dungeons (D) are completely different games than Minecraft, and therefore must be described separately.
2. Having any sort of SM/D information on this wiki (implicitly – regardless of arrangement) will be excessively confusing to readers.
3. This wiki will not be able to maintain SM/D articles, and they will be abandoned (implicitly – as opposed to if they were hosted on another wiki, where they would be better off).
   1. Evidence of that imminent abandonment is mods.
4. Maintaining SM/D articles will divide the attention of existing editors (implicitly – as opposed to if the articles were hosted on another wiki), which will harm main game coverage.
5. This wiki is only about the sandbox games.

All the points presented above are refutable, and thus so is this entire proposal.

Point 1. No logical link. Once again, I must refer to Fallout and Elder Scrolls, where there is no evidence of decisions that games outside their typical RPG form must have separate wikis. TES: Blades and Fallout Shelter, I believe, are described on the same wikis as other games in the Minecraft universe, which both SM and D are explicitly stated to be part of. A factor weakening my position may be absence of a base series of games in the same universe prior to the release of dissimilar titles, though, 1) sandbox games rarely get sandbox sequels due to the nature of the genre, and 2) other points remain unaffected by this.

Point 2. That "implicitly" part in my point is key. I have presented _two_ arrangements in my proposal which are demonstrably not disastrous for readers. One point, however, I have not covered, is searchability of SM/D content (think SEO). Since it should be expected that people will initially come to SM/D articles from search engines, how close to #1 will the wiki be will determine whether it remains functional. I am not remotely knowledgeable on SEO, so this is just my relatively-layman hypothesis: being associated with an active wiki is likely to be a positive factor, but so may be having a separate subdomain, and/or association with Gamepedia. I will ask for expert advice.

Point 3. The "implicitly" part is again key; even if you have not said this, your argument – that a separate wiki is better – is automatically invalid without it. Having SM/D articles on this wiki is likely to improve the chance of current visitors, whether editors or readers, finding them, thus helping these articles to stay alive. The searchablility factor is still applicable.

Point 3.1. There have been many contributing factors to mods becoming unused here. Their less-searchable arrangement (as opposed to, say, a custom namespace). The core community's negative attitude towards unofficial content (including the popular non-sequitur "we're the official wiki and therefore can't cover unofficial content"), to the point they were effectively subject to unstated exemptions from all rules (then-admin Kanegasi told me that in 2013). The presence of separate, official mod and mod pack wikis, including the FTB Wiki (which would make this wiki just a secondary source of information). Probably other factors as well.

The Russian wiki had a different situation for all the listed factors. There are still mod articles being developed, and even though they aren't updated very well, neither is base game information. This is, however, not necessarily applicable to the English wiki for one of the factors I listed: managing a non-English language project or a wiki is something almost no single mod wiki does at all, much less something they do effectively.

A more important analogy to see with content rot is, yes, non-English language projects (typically referred to with terms which imply their derived, dependent status on the English wiki, a despicable trend of marginalizing people who don't speak English; I deliberately avoid such terms as "translation project" or "language wikis"). Why did so many translations on this wiki become inactive and had to be purged? Because they didn't have enough editors. There are, once again, many reasons for that, and not being a separate wiki isn't necessarily among these reasons. Some translation projects did get their wikis, even recently. Are they more active now? Some may be, but definitely not all. Could we have done things better for them? Yes. For one, listing non-English versions on top of each page would have contributed to influx of a new editors.

Point 4. That's a mostly flawed model of editors. Typically, wiki editors, especially on relatively large wikis, have areas in which they work. They may not have or like all the games or editions, they may do something that few other can, or they may be bad at something people are often good at. If an editor is focused on updating command documentation, writing change logs, or editing tutorials, they will be mostly unaffected by there being a separate namespace.

I said "mostly". The editors whose attention will be divided are those metapedically focused: tracking discussions, managing templates, clearing backlogs (yet most of those isn't the work which greatly peaks with updates, that would be content writing). What would happen if there was a separate wiki? They'd need a metapedic setup: people who can create and revise rules, guidelines, policies, templates, content layout... and where will they take these people from? Who will they ask for assistance? Will there be a "they" even? Capable wiki maintainers are much less common than your average article creators, and we have quite a bit here. The topic of dividing the community was one I covered in my proposal.

Point 5. That's just what the dragon left for his treat. Because it's simple: figuring out what this wiki's about is the aim of this discussion. This hasn't been decided yet.

 

 I cannot agree with a proposal I can only respond to with a wall of text debunking its key points. We have screwed up with mod coverage, we have screwed up with translation projects, we have screwed up with Story Mode. I believe proposals like this can lead us to screwing up with Dungeons, Earth, and whatever comes next as well. I have nothing left in my life than these few communities online I still believe I can help, and it seems to me people are pushing, in good faith, for something that is likely to deal irrepairable harm to these very communities. --AttemptToCallNil (report bug, view backtrace) 22:52, 1 July 2019 (UTC)

I think non-core-MC content (SM, Earth, Dungeons) shouldn't really be documented fully in this wiki, but wouldn't mind if they were. Also, these massive 6KB text walls aren't really encouraging discussion here. – Nixinova   02:51, 2 July 2019 (UTC)

Trying to stay on a discussion of scope of the wiki: I think the wiki would be better, and more of something to take communal pride in, with more of the official franchise in it.

Imagine: you'd look at a page like Sheep, and you're not just reading about how it works in the core sandbox game, instead you have access to sections about the other games right there, and you can get a glimpse how the Sheep plays its part across all Minecraft worlds. That's lore, that's interesting stuff fans would love. And that goes for Dungeons readers too! They get to know the Sheep as it was in the original game. It's a much richer page.

And then we look back on that a few years later and can be proud we made that transition and made it all that much richer.

I read BDJP's piece, and while I don't really feel much of it actually discourages me from supporting opening the project up, I think his point about internet rot is an interesting one to consider. Ultimately with that though, you can never predict beforehand what editors will come. We've had times when we wished we had more Bedrock and Console editors, but over time they did come. I'm optimistic about Earth and Dungeons editors; we had a fantastic Story Mode editor after all ; ) – Sealbudsman talk | contribs 01:49, 18 July 2019 (UTC)

I've added a few bits of trivia to pages such as pig and mooshroom saying that muddy pigs and mooblooms exist; since Earth runs in Bedrock there's not any exclusive functionality afaik so no need for any sections or anything. – Nixinova   02:17, 18 July 2019 (UTC)

This is a tough issue with no easy answer. Both (all) sides have persuasive points. I'm comfortable with us being "Minecraft-the-sandbox-game documentation," a comprehensive user manual with text and pictures. I'm also comfortable with that being just one facet of a wiki that covers the entire Minecraft universe, because I am convinced that we can manage successfully the complexity of such a wiki with our current leadership at the helm.

So since a choice is required, I'll keep my original stance. I like the idea of us being the comprehensive, go-to wiki for all things Minecraft. I think we ought to be more than just a fancy user manual for the core game. I concur with Sealbudsman (18 July) and lean toward the solution AttemptToCallNil has proposed, with separate namespaces. I think that needs to be accompanied by a distinct page style for each namespace, if possible; the pages' look and feel - i.e., color scheme, head banner, maybe page structure - will help people tell at a glance which specific Minecraft "species" (sandbox game, interactive story, novel, toy, whatever) the particular page is about. This should be accompanied by clear infoboxes or whatever identifying the "species" at the top of each page.

As long as we continue to document the ever-evolving core game(s) effectively, I believe (as I said before) that expanding our scope will result in a larger, healthier community of editors and, if managed properly, will not result in the confusion we wish to avoid. I even asked my nine-year-old daughter about this issue and read her the various opinions here. She said at first that it might be confusing to have the expanded scope, but then she brightened and declared with enthusiasm that she thinks it will be fine because we can label the information to make it clear which Minecraft thing the information is about. She even mentioned a wiki for another game where this is done. So if she can distinguish such information without confusion (and with enthusiasm, even), then I am confident that the vast majority of our readers will have a similar experience.

Also worthy of note: We must make this decision based on reason and evidence if we want to make the best decision. However, we have to acknowledge, I think, the emotion behind this: Our feelings of what scope is best are tied up with our involvement and history with the game(s), and with the wiki, and with the various communities involved. Whatever decision we make, we are going to feel uncomfortable with it to some degree, and some people will be affected more than others, no matter what we decide. We have to acknowledge that that's a normal and expected part of the process of change here and to be prepared for that. We have to do our best to proceed with patience and empathy, and with a degree of compromise, regardless of the outcome. Having said that, we can only make a good decision here by doing our best to acknowledge and then set aside our emotional associations with Minecraft and engage in the rational basis for what our scope ought to be. What is best for the wiki and for its user community?

Whatever the wiki's scope, I think we'd generally agree that readers of the wiki usually arrive here because they're seeking information about Minecraft. They want to learn. To best inform and educate readers, then, the wiki needs to have content that is clear, accurate, current, complete, and easily accessible. Some of the arguments laid out so far raise concerns that expanding our scope would make achieving those goals more difficult. But I'm more persuaded by the arguments that if we organize the information carefully and systematically, the potential problems will be minimized and that we will gain more in the benefits, which would include a more active, healthy community of editors, some of whom would focus on parts of the wiki more narrowly and some of whom would be more broadly involved.

Therefore, the reasoning and evidence overall say to me that we ought to go ahead with expanding our scope to cover the whole franchise: the Minecraft universe (or the whole Minecraft Tree of Life, if you will, not just one branch). We need to evolve just as Minecraft evolves. It won't be easy, but it promises to be worth the effort. —Memetics ^{talk | edits} 15:40, 18 July 2019 (UTC)

Earth

(New section to differentiate from the text walls above)

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

At first thought, I'd be fine with documenting those here. However, it's the gameplay that really separates Earth. Do we document how to get each type of block, if there's chances or only specific locations? What about combat? Monster spawning, if it happens? And for small stuff like the two new mobs, Earth is in a closed beta right now. It could receive lots of new features by release or in future updates. Etc, etc. It just opens up a big can of worms that we *really* aren't ready to deal with, at least not until we figure out how we're gonna deal with the already varied versions of the base game. So,  Oppose, at least until we figure some more stuff out. -PancakeIdentity (talk) 00:06, 20 July 2019 (UTC)

Pages for Mud and Mob of Me have been created while this discussion has fizzled out; should these be kept, and other Earth exclusives be documented? Since Earth runs on Bedrock there won't be many more of these new pages created.  Nixinova  T  C  05:54, 29 August 2019 (UTC)

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

Mass deletion of mcspotlights videos

I hope this is the correct venue for this topic.

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

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

My position is this:

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

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

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

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

I guess I personally don't see their use if they're incomplete. It doesn't provide a good overview of the item/block/whatever then. The videos are kinda weird for the wiki, and feel very out of place imo, tbh I'd support removing them entirely but I really don't see them happening. When I watched the first one, it struck me as extremely out of place, maybe better fit for some type of tutorial page. If we are insistent on providing video overviews, I'd say we should find/create completely updated videos. Otherwise, I'd say they're not really too useful and should be removed.

I will say though, I do think floor/ceiling placement for item frames is important enough for the video to be considered outdated.

I would also like to clarify, I have been watching all the videos without outdated notices and have kept the accurate and up to date ones On the pages. -PancakeIdentity (talk) 19:01, 13 June 2019 (UTC)

Going in on "If we are insistent on providing video overviews, I'd say we should find/create completely updated videos.", I suggested this recently in the discord:

"Since so many videos are outdated (and now removed), should we try to make new videos altogether, and try to keep them updated? I'm open to try, but I've never actually video edited anything."

Since I posted that, ItsPlantseed pointed out we should alter Minecraft Wiki:Wiki rules/Video policy first.

The wiki admins would be in charge of the video process then, though editors would be able to help by providing scripts for the videos or alike. FVbico (talk) 19:11, 13 June 2019 (UTC)

It's just weird to me that Curse videos are exempt from the typical video policy. Also, how are the overview videos serving a business purpose? I'd be more supportive of overview videos if they were done professionally and essentially rehashed the wiki page's content. -PancakeIdentity (talk) 19:25, 13 June 2019 (UTC)

The videos being deleted seem professionally-enough done to me. They are nice and concise overviews of the main points in an article. Little details that are missing, like the ability to place item frames on floors, are easily discovered by player themselves and don't detract from the educational value, particularly for kids like mine who want to see them. That's rather the whole point of a concise overview; you can't include all details and still be concise. They don't need to be comprehensive, just informative.

We may as well argue that a video has no value because it was made with Java Edition while Bedrock has the larger installed base. I don't buy that line of reasoning (and by the way, I and my child play Bedrock and we still found those videos helpful), and I don't buy the reasoning that a perfectly valid video should be removed because more details became available in a software update. I'd rather keep them, adding a notation about changes, and delete only the ones that are now completely wrong (such as villages needing doors). ~ Amatulic (talk) 19:49, 13 June 2019 (UTC)

I mean, I would argue that, although not for the same reason. That's not what we're talking about though so I won't bother. From my understanding, we as a community had reached a consensus to remove out of date videos (See above topic). Even if I disagree, I do see your argument about keeping incomplete videos. More of the community would have to chime in. In addition, "completely wrong" is too strict a criteria for removal imo. The wiki should not promote any out of date information whenever possible, unless the page is dedicated to an older version (such as the new Trading before Village and Pillage page). Like I already said, I think the best solution to make the most people happy is creating up to date videos and removing outdated or incomplete videos (even if I personally still dislike the current videos). Incomplete videos are incompetent as overviews, especially in the case of something like item frames, where the missing information is pretty essential to the current function of the item. We're gonna have to undo most of my edits if we decide to promote videos that don't showcase basic functions of an item. I've stated my opinion, and I think we need more community input before moving any further. -PancakeIdentity (talk) 00:44, 14 June 2019 (UTC)

I had just restored the video in chest and then I saw this reply. OK, I'll stop restoring them for now, if no more get removed.

My choice of words "completely wrong" was poor. I'm in favor of removing videos that have obsolete information (that is, information that is now wrong because things have changed, such as beds now defining villages instead of doors), but if the content is still all correct, it serves as a concise overview.

We disagree that a new capability to put an item frame on the floor is a critical feature. It wasn't before, and it isn't now, it's just an enhancement that isn't necessary for a concise overview video.

Ultimately, we disagree about what constitutes "out of date". My position is, if the content of the video is still valid and correct, and it covers most of what a young player needs to know, it isn't out of date yet, it's a keeper. ~ Amatulic (talk) 02:16, 14 June 2019 (UTC)

I'm really glad the videos helped your child, but I'm just not sure we should specifically cater towards that audience. Maybe we should instead focus on increasing the wiki's readability? I know a lot of articles could really use it. Maybe as a separate project, but I digress. I don't know, the videos just feel very out of place to me, especially when missing good amounts of information. I really hope some other people chime in.

I also wanna say, I got the impression from the videos that they mostly focused on how to obtain the item and how to use the item in gameplay. It's when that information is missing is especially when I feel they should be removed. Especially since I would say most provide a good, solid overview for when they were released, whereas now, they can be missing info that I feel the creators wouldn't have left out if making them today.-PancakeIdentity (talk) 02:35, 14 June 2019 (UTC)

Having watched many of these with my son, I can say confidently that they (at least the ones by the mcspotlights team) are concise yet thorough overviews, covering one specific block or item: what it is, how to obtain/craft it, the primary things you can do with it, and other considerations if there's any time left (these videos seem to be disciplined about running less than 90 seconds). Basically they give a new player all the basic information they need to know in far less time than it takes to read the article. This isn't about catering to children who have difficulty reading (but why not do so? Minecraft appeals to a wider age range than any other game). It's about providing information choices. For the comprehensive details, you read the article, which covers everything known about a topic. If you just want to get a quick understanding, those videos are extremely useful. They're professionally-done, well-scripted overviews. Overviews don't cover all information, by definition. And in many cases the videos aren't out of date. ~ Amatulic (talk) 15:24, 14 June 2019 (UTC)

I see both sides and at first blush fall somewhat in the middle. When I first started using this wiki, I absolutely loved those little video overviews, as did my daughter (we had an experience similar to Amatulic's). But lately, it has become somewhat disheartening to see the frequency of tags identifying videos as out of date. It makes the pages with videos feel out of place.

The rub of the problem seems to be this: If the videos are a core part of the wiki, i.e., an expected element of the basic content and structure of key pages, then most pages should feature current, accurate overview videos - at least the pages about the basic elements of the game, as the videos seem intended for bringing beginners up to speed. If the videos are not a core part of the wiki, then they should not be embedded in the pages at all, as having them on some pages sets up an expectation that they will be present on most pages. This expectation is reinforced by the way the current videos refer to other videos in the series: they present a comprehensive structure of video content about current basic game elements and mechanics, a structure that simply doesn't exist anymore now that so many of the video "nodes" in that structure are out of date.

And that to me seems like the bigger problem: Taken as a whole, the set of mcspotlights videos is no longer about the current game. As a whole, it's historical content, individual remaining videos notwithstanding. The old scheme for how our wiki pages were structured, including overview video content near the end, is no longer viable. As much as still I like the videos and appreciate their professionalism and consistency, I reluctantly have to conclude that it's time to pull them all until we have an active project creating a comprehensive set of up-to-date videos. Meanwhile, we can work on making the rest of the page content as accessible and user-friendly as possible. (Honestly, it seems as though the video content should be its own living project with an active maintenance team, one to which the wiki can point; otherwise, as the game is under constant development, we'll run into this issue of stale videos over and over again.)

If the community's consensus is to keep videos that are still accurate (even if incomplete), then I wouldn't oppose that, though I think the larger issue of the wiki's overall stylistic consistency would still need to be addressed. —Memetics ^{talk | edits} 11:56, 18 July 2019 (UTC)

I completely agree with you. Having a continuing project for creating updated videos would be great, but if it doesn't happen, I'd rather just remove them altogether. -PancakeIdentity (talk) 23:27, 18 July 2019 (UTC)

I guess we could try to launch such project then, as I stated in the above comment thread early on, I actually suggested doing it, but it kinda stopped there.

If we were to make videos, I suggest making scrips for videos a subpage of the project (eg Videos/Stone for the video about the Stone page).

I'd gladly record it, but I suck at making scripts and never video edited anything, so this will need a collaborative effort nonetheless. FVbico (talk) 23:38, 18 July 2019 (UTC)

Usage of "you" vs "the player" in tutorial pages

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 [ ] 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 [ ] 13:58, 17 June 2019 (UTC)

If no one objects soon, I'll add the sentence to the style guide and start changing the pronouns on tutorial pages.--Madminecrafter12 ^{(Talk to me | View what I've done)} 13:52, 25 June 2019 (UTC)

Late  Support on being lax on nth-person grammar in tutorials. – Nixinova   00:28, 30 June 2019 (UTC)

Thanks, added to the style guide.--Madminecrafter12 ^{(Talk to me | View what I've done)} 01:23, 30 June 2019 (UTC)

Also late to the party, but I  Support consistency here over which grammatical person to be consistent with. (Violations of parallel structure and shifts in person make me cringe as a reader.) We should go with whatever person makes sense for each specific tutorial page. —Memetics ^{talk | edits} 11:12, 18 July 2019 (UTC)

 50 – 50:

 Agree on consistency of using only one perspective.

 Disagree on using second-person perspective. Information on this site are for everyone, there is a pretty great chance that someone looks the wiki up to supply information to another person, thus the looking up one is obviously should not be referred as "you".

Lê Duy Quang (Make some words | Contributions) at 13h54:53 | 4/9/2019 (UTC)

If someone is reading the tutorial to help someone else, they will usually refer to the other person as "you". Writing tutorials this way will match what the readers would say. The Blobs 14:18, 4 September 2019 (UTC)

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

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

@AttemptToCallNil: I have run across pages on this wiki that requires autoconfirmation status. So I thought if the protection level is available, and it's a configurable user right, I figured it was something that could be set up. ~ Amatulic (talk) 14:45, 6 July 2019 (UTC)

By that I meant the following: Gamepedia's auth system makes it so that all logged-in users are autoconfirmed, and no additional restrictions (like 4 days since registration and 10 edits) can be imposed. --AttemptToCallNil (report bug, view backtrace) 15:00, 6 July 2019 (UTC)

 Support per above. -BDJP ^(t|c) 14:00, 24 June 2019 (UTC)

 Support; if implemented as a group right change, this would be clearer for IPs than the current abuse filter system. (I assume this would apply to all non-talk namespaces and not talk pages.) –Sonicwave ^talk 23:35, 24 June 2019 (UTC)

 Support, assuming this doesn't apply to talk pages. If we have spam issues, a simpler filter to add in addition would be just preventing a user's first edit being a page creation, as I'd assume most spambots won't bother trying to make an edit before making a spam page. –Majr ᐸ Talk
Contribs 05:56, 1 July 2019 (UTC)

 Support original proposal. I don't think we need Minecraft Wiki:Requested articles, though. —Memetics ^{talk | edits} 11:01, 18 July 2019 (UTC)

The permission change would be fine by me. It would prevent IPs from creating non-talk pages. Talk pages can still be created by IPs normally.   MarkusRost (talk) 23:34, 6 September 2019 (UTC)

 Done, IPs can no longer create non-talk pages.   MarkusRost (talk) 20:44, 11 September 2019 (UTC)

Page view statistics

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

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

Unfortunately, there is no such tool for Gamepedia wikis available publicly. The only tool that allows to access views per page is the administrator tool showing statistics about the wiki. And from it it could be gathered that the most viewed pages in last 30 days are to no surprise Villager, Enchanting, Brewing, Blast Furnace, Conduit, Java Edition 1.14, Composter and so on. Frisk (Talk page) 08:16, 29 June 2019 (UTC)

There used to be a special page for the most viewed pages, but it was improved and added to a ton, and got admin-only. Somewhere within the last 7 years. It's now indeed called Statistics, I've noticed this change myself too on my own wiki. – Jack McKalling [ ] 14:18, 29 June 2019 (UTC)

@Frisk: Thanks. That short list you provided is good enough for now. I figured Villager was near the top, but I'm surprised Blast Furnace is in the top 10.

@Jack McKalling: Special:Statistics doesn't show page views but it does show other interesting information. ~ Amatulic (talk) 00:34, 30 June 2019 (UTC)

Oh woops, I meant Special:Analytics, not statistics. – Jack McKalling [ ] 09:11, 1 July 2019 (UTC)

Ah. Yes, that page isn't visible to me. Anyway, I've corrected the verb tense in all the articles in the short list you provided, as well as others. ~ Amatulic (talk) 03:59, 2 July 2019 (UTC)

To what extent should we fix bug report titles?

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

This has been discussed before and basically the titles can be freely edited to match the style guide. – Nixinova   05:45, 5 July 2019 (UTC)

As long as it doesn't completely change the meaning of course. – Jack McKalling [ ] 07:17, 6 July 2019 (UTC)

New village blueprints - templates broken

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

I'd make all blueprints load on demand as only some of the blueprints are now. --AttemptToCallNil (report bug, view backtrace) 17:11, 6 July 2019 (UTC)

Yes that's a good start. There aren't that many blueprints directly on the page and there are still a good number of Taiga and Snowy buildings left to add (which have their own material tables) so I'm worried we'll run into this again, but I suppose we can deal with that if/when it happens. --Aronson 1 (talk) 18:35, 6 July 2019 (UTC)

Minecraft Wiki:Projects/Structure Blueprints/Underwater Ruins seems to suffer from the same problem, with most of the blueprints just reading "#invoke: layered blueprint" instead of displaying the actual template. 46.132.188.41 06:38, 7 July 2019 (UTC)

It seems to show up fine in the edit window but not when on the page itself. Weird. – Nixinova   06:44, 7 July 2019 (UTC)

The blueprint template is very expensive. It shouldn't be "spammed" on one page that often like that. – Jack McKalling [ ] 07:16, 7 July 2019 (UTC)

Edition Problem

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

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

Interwiki files

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

This wiki is a shared repository for language wikis, so other wikis can use images from here but not vice versa. – Nixinova   05:29, 1 August 2019 (UTC)

Yes, but is still necessary make re-uploads in the other wikis. seria melhor sem uploads, como no wikimedia commons. --Dr03ramos (talk) 15:48, 26 August 2019 (UTC)

Chemistry

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

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

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

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

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

Pages for blocks/items that are only textures?

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

I am also opposed to such pages. They should just be sections in the unused features pages. The Blobs 01:19, 23 August 2019 (UTC)

I have turned those pages into redirects while retaining the page content so that it can be quickly fixed when they are implemented.  Nixinova  T  C  07:40, 23 August 2019 (UTC)

Create and update new videos like how mcspotlights did

I know, hear me out first.

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

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

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

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

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

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

People willing to help out

Voice recording

• FVbico

Video recording

• FVbico
• Nixinova

Video editing

• Marinah
• DarkShadowTNT
• Nixinova

Script providing

• Marinah
• DarkShadowTNT (unsure as of now)

Subtitle Translator

• Eduaddad (Portuguese)
• Dr03ramos (Portuguese)

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

EDIT: some clairifications after internal discussions:

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

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

Note that these videos are likely to end up mostly useless for non-English readers, and non-English editors may be unable to record their own versions as this requires very substantial effort. I believe the German wiki is the only other one which will ever be able to create something similar. --AttemptToCallNil (report bug, view backtrace) 15:58, 24 August 2019 (UTC)

(Thanks for the spelling fix, missed that one.) True, but youtube videos support subtitles, which can be suggested by anyone as well; so other language wiki admins/editors could suggest subtitles. FVbico (talk) 16:21, 24 August 2019 (UTC)

Subtitles are a very interesting idea. That means I no longer have substantial objections against videos. Just wondering, what does providing scripts involve? --AttemptToCallNil (report bug, view backtrace) 16:39, 24 August 2019 (UTC)

The scripts would be the text which'd be spoken in the video, along with notes on what to show, where to put emphasise on, etc. It wouldn't be the same as the article itself, which'd go in much more detail. FVbico (talk) 17:08, 24 August 2019 (UTC)

I'm willing to edit videos. Perhaps I could make a script once in a blue moon, but I'm not quite sure about that yet (which is why I put my username in small font in that section). —DarkShadowTNT (t ♦ c) 23:12, 24 August 2019 (UTC)

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

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

Good point, or at least constructive wiki members. FVbico (talk) 17:23, 25 August 2019 (UTC)

We need to establish a subtitle submission method (for example: Discord Channel, Google Drive Folder, Minecraft Wiki Page) --Eduaddad _(talk) pt.Wiki Administrator 17:32, 25 August 2019 (UTC)

Youtube has a function for the community to support with translation. just need to enable it. --Dr03ramos (talk) 15:42, 26 August 2019 (UTC)

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

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

It wouldn't, as that's not relevant to the viewers anymore, also "and update them if new things need to be mentioned/changed". FVbico (talk) 21:56, 28 August 2019 (UTC)

I think we need to communicate better, what do you think of a specific chat room? For keep the things organized :3 as soon as we make a decision. Other note: to get invited, there is a need to have a gmail. There is not a way to send invitations to other domains...

• https://support.google.com/youtube/answer/1646861?hl=en
• https://support.google.com/youtube/answer/2897336

Cheers♡ᴍᴀʀɪɴᴀʜ♡ (talk) 19:32, 30 August 2019 (UTC)

Possible channel to use

I have a channel of 72,000 subscribers, which I can give access via invitations (the channel's account is under a brand account)

• https://support.google.com/accounts/answer/7001996?co=GENIE.Platform%3DDesktop&hl=en
• https://myaccount.google.com/brandaccounts

I can make subtitles in Portuguese and Spanish ♡ᴍᴀʀɪɴᴀʜ♡ (talk) 16:58, 24 August 2019 (UTC)

I think it's best not to recycle an existing account, and instead make a new one. FVbico (talk) 17:08, 24 August 2019 (UTC)

I think that using this channel would give more excitement and motivation...It has no videos and use as a personal account, would give me a lot of headache start from 0 given that this channel is important to me and I really want to help.

I can invite others via email to have access, and provide the video's thumbnails, subtitles and other technical parts. ♡ᴍᴀʀɪɴᴀʜ♡ (talk) 17:23, 24 August 2019 (UTC)

(Split off discussion) What do others think, recycle that channel, or create a new one? FVbico (talk) 17:49, 24 August 2019 (UTC)

I propose creating a new channel. First, there is the matter of ownership, which I believe would need to be transferred to a more involved wiki participant (like what happened with the Discord server). Additionally (and I believe this to be more important), I find it weird that this channel has no content and over 72 thousand subscribers. If this is a result of some manipulation, it could open the channel to sanctions in the future, which would be completely unacceptable if the channel hosts our videos. --AttemptToCallNil (report bug, view backtrace) 18:41, 24 August 2019 (UTC)

I suggest a new channel like "MinecraftWiki". This generic name would open up the channel for more than one purpose, promote itself for the wiki specifically, it would be recognisable and official, and I agree it needs to be owned by an involved wiki editor/ranked editor. It would be nice if we could share ownership of it though, within the/a group of video-creators on the wiki. – Jack McKalling [ ] 07:25, 25 August 2019 (UTC)

I'd also prefer if we started a new channel; it would probably seem strange to readers for the channel to already have 72,000+ subscribers with only a few recently uploaded videos. The current subscribers of that channel might not be expecting (English) Minecraft content, depending on what type of videos (if any) used to be uploaded there. –Sonicwave ^talk 00:03, 26 August 2019 (UTC)

I also think it. --Dr03ramos (talk) 15:42, 26 August 2019 (UTC)

Alright :3, who would want to create it? ♡ᴍᴀʀɪɴᴀʜ♡ (talk) 02:22, 26 August 2019 (UTC)

If we have more support/people willing to help out, I'll make the channel then, but until such time, it's best to wait, as this proposal might not launch still. FVbico (talk) 06:33, 26 August 2019 (UTC)

Sound file attribution

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

Not a licensing expert, but I agree with this proposal. --AttemptToCallNil (report bug, view backtrace) 19:05, 27 August 2019 (UTC)

Minecraft PE

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

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

About screenshots with old textures: opinions

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

 Support Like other screenshot fixes, this should be a long-term goal. We may want to leave some screenshots to show how the old textures appeared in-game. The Blobs 13:21, 17 September 2019 (UTC)

 Support where it makes sense. - User-12316399 (talk) 14:43, 17 September 2019 (UTC)

 Support from me Oakar567 (talk) 15:48, 17 September 2019 (UTC)

 Support setting screenshot updating as a long-term goal. --AttemptToCallNil (report bug, view backtrace) 16:14, 17 September 2019 (UTC)

 Support. I had already been doing this myself.  Nixinova  T  C  20:27, 17 September 2019 (UTC)

We need to talk about the Texture Update

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

I propose the following:

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

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