Minecraft Wiki 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 forums.

Autoconfirmed permission on all pages
Note: Some of the text seen below has been intentionally copied from an eariler discussion regarding anonymous users creating pages, seen here.

Can we just disable anonymous users editing pages? Sure, I have seen some "useful" contributions by anonymous users (mostly just grammar fixes), but most of the edits by anonymous users are just blatant vandalism, spam and advertising. We should still let them edit talk pages, but require making an account to edit pages, as if a user cares enough about the wiki to make an account, they are that much more likely to care about our policies.

I know a change like this has to be made by Curse, but I figure the community should decide before I suggest it. BDJP (t 17:01, 8 July 2015 (UTC)


 * This is very unlikely to happen. You underestimate the value added by drive-by fixes from anon editors. Why do you think Wikipedia allows it, when they are such a huge target for vandalism?
 * Small wikis which can't keep up are the only cases where I could see this happening, of which we are not. This is better handled by better abuse filters, rather than preventing editing entirely. –Majr ᐸ Talk Contribs 17:24, 8 July 2015 (UTC)

Curse requests
Please direct requests requiring Curse's attention (such as configuration changes) to me first to assess, and I will then pass them on. Thanks! –Majr ᐸ Talk Contribs 17:14, 8 July 2015 (UTC)


 * Accepted, although I may still prefer contacting Game widow directly. Make sure to add her talk page into the watchlist if needed. — Agent NickTheRed37 (talk) 17:28, 8 July 2015 (UTC)


 * Notified Russian users. — Agent NickTheRed37 (talk) 17:39, 8 July 2015 (UTC)


 * Ouh, and does it apply to other wikis (like Terraria one) by chance? — Agent NickTheRed37 (talk) 17:42, 8 July 2015 (UTC)


 * Nope, only here. –Majr ᐸ Talk Contribs 15:54, 11 July 2015 (UTC)


 * Nick, this has nothing to do with your preferences. Majr is an employee of Curse, and, presumably in that role, has stated that requests for Curse need to go through him. Unless he or another Curse employee clarifies otherwise, this means all requests need to go through him, regardless of your feelings on the matter. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 02:34, 9 July 2015 (UTC)


 * FYI, the reason that I should be contacted is I know the community better, so I am in a better position to vet the requests before passing them on. –Majr ᐸ Talk Contribs 15:54, 11 July 2015 (UTC)


 * I will keep that in mind. Sorry if I overstepped a bit with contacting Game widow directly. – KnightMiner  · (t) 03:48, 9 July 2015 (UTC)


 * No problem. I hadn't formed a strong opinion on the subject yet, so I hadn't replied, and so you didn't know. –Majr ᐸ Talk Contribs 15:54, 11 July 2015 (UTC)

Sprite editor ready for testing
I have finally gotten this project in a state ready for testing. A page is available here, which you can feel free to play with. To get started hit the "Edit sprite" tab.

My main areas of interest are browser compatibility and bugs, but comments on performance and usability are useful too. I have created a repository here to keep track of bugs and feature improvements, which you may report to directly if you wish.

I haven't created any documentation on how to use it yet, as I'd like to first see if it is easy enough for people to figure most things out without requiring a manual. :)

–Majr ᐸ Talk Contribs 16:48, 11 July 2015 (UTC)


 * Firefox 39.0. Works fine when editing, but nothing seems to happen when the Save button is clicked (except that the button changes its graphics; I have been waiting for at least 3 minutes). --GreenStone (talk) 17:20, 11 July 2015 (UTC)


 * Same browser here, unable to make it fail as you describe; can you provide steps we can follow? Maybe also hit F12, and report anything that happens in the network tab or console tab. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 18:41, 11 July 2015 (UTC)


 * All I get is sections of sprites, no editor. I use Firefox 39.0 but with a lot of things blocked. What was this supposed to run in (javascript, flash, etc.)? &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:09, 11 July 2015 (UTC)


 * If you don't see the tab at all, you have JS disabled. If you do see the tab, but clicking it doesn't load the editor, then maybe you're blocking particular scripts. –Majr ᐸ Talk Contribs 06:25, 12 July 2015 (UTC)


 * Reply to Sealbudsman: I added a new section and an entirely new sprite into that section. The sprite was loaded from a 16x16 .png image. --GreenStone (talk) 06:52, 12 July 2015 (UTC)


 * If it was an API error, a message would be displayed, so it sounds like you managed a JS error. Have your console open while editing and see if any errors come up. –Majr ᐸ Talk Contribs 06:25, 12 July 2015 (UTC)


 * Reply to Majr: This is what I get in the console when opening the page (thought you might be interested in that as well) and when saving. The first four lines appear when loading the page in View mode, nothing new appears when switching to Edit sprites mode, and the last line appears when clicking Save after performing the changes described above. --GreenStone (talk) 06:52, 12 July 2015 (UTC)


 * Ah yeah, that's a problem. Curse keeps images on a different domain, so it is impossible to load the sprite sheet due to the same origin policy. I've disabled image editing for now. Maybe if CORS was enabled, it would allow it to work. –Majr ᐸ Talk Contribs 10:05, 12 July 2015 (UTC)


 * CORS is now enabled (it was actually already enabled on the server side), so image editing should work now. –Majr ᐸ Talk Contribs 11:48, 16 July 2015 (UTC)


 * Image editing seems to work now, but I am unable to view this diff properly. This is the entire returned page. --GreenStone (talk) 12:44, 16 July 2015 (UTC)


 * That's caused by the wiki not handling large diffs well. Because you added a new section, that incremented the section number for all the below sections, causing all 774 lines to be updated with the new section number. I could fix this by using a unique ID for each section, rather than a positional number. This would also make tidier diffs when re-arranging sections, as the section number for all images in those sections wouldn't need to be updated. –Majr ᐸ Talk Contribs 17:07, 18 July 2015 (UTC)


 * If you click to edit the sprites, navigate away from the page without saving, and use your browser's back button to return to the edit sprite page, you don't return to the actual edit mode until you click "Edit sprite" again (in Chrome 45). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 22:40, 11 July 2015 (UTC)


 * Can't reproduce. Either from navigating to a different page, or fake navigating to the view page. Does the tab actually get selected, but the editor doesn't load? –Majr ᐸ Talk Contribs 06:25, 12 July 2015 (UTC)


 * It's working for me now, must've been my browser being stupid (as is its wont). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 07:54, 12 July 2015 (UTC)


 * I think it might have been due to a race condition caused be mw.Api being called before it was loaded, which is why it only happened sometimes. –Majr ᐸ Talk Contribs 10:05, 12 July 2015 (UTC)


 * Everything works fine for me on Chromium. The only issue I see is deleting sprites could be a bit more obvious, such as by having a little X button.
 * Now a question: is this ultimately intended for the sprite extension, or the sprite module? – KnightMiner  · (t) 13:10, 12 July 2015 (UTC)


 * Normally you can click on an image to bring up the option to replace/delete it, however that is removed entirely when image editing is disabled. I probably did that because I was thinking deleting an image required removing it from the sprite sheet, but that doesn't happen anyway, so I could keep that option and just disable the replace button.
 * This is intended for the module. The extension doesn't have any benefit over the module aside from slightly easier name adding (which is now solved with the editor), and is lacking in features and sane HTML to be a replacement for the module. However, there is no particular reason (with some modifications) that the editor couldn't also be compatible with the extension. –Majr ᐸ Talk Contribs 11:48, 16 July 2015 (UTC)


 * Works fine for me on Safari on iOS. The only issue that I have is that I can't see the snowfall sprite. Either its an issue with my brightness, or the background behind the sprite is too bright. :P -BDJP (t 03:13, 14 July 2015 (UTC)


 * So you were able to use it on a phone? That is quite surprising, although I highly doubt the interface was at all optimal for a touch screen, correct? –Majr ᐸ Talk Contribs 11:48, 16 July 2015 (UTC)


 * It’s working fine on my Firefox 30.0 (adding and removing (I assume) names, adding, replacing and removing images), but I still have to understand: what realization will we use in the end? I’m mostly sure the SpriteSheet wiki extension can offer more possibilities if made correctly, and it probably doesn’t use JS, which can be disallowed on one’s browser for obvious reasons or not supported altogether. — Agent NickTheRed37 (talk) 15:20, 16 July 2015 (UTC)


 * While supporting no JS for basic functionality and browsing is highly recommended, for more advanced features it is quite acceptable to require JS, especially since this is not going to be used by readers, and you still have the option to manually edit the sprite sheet and data module, just like with the VE and source editing situation. Anyway, the sprite sheet extension requires JS as well.
 * The extension just handles basic assigning of names to images in the sprite sheet. It does not handle the most difficult part of sprites, and that is the creation of the sprite sheet itself. The sprite editor is intended to handle sprites as if they were separate images, and you just assign names to those images and categorise them. Yes you could certainly develop an extension that handles constructing the sprite sheet from individual images, and I may indeed do that at some point to improve browser compatibility and performance (as well as providing a more convenient back-end for the editor to work with), but using JS was easier for me as I am more familiar with it, and I generally hate PHP. –Majr ᐸ Talk Contribs 17:07, 18 July 2015 (UTC)

Moving transcludable metadata, video etc into their own namespaces
These transcludables (examples 1, 2) for now are named as Main article/Name, as subpages, in main namespace. It was a long time since subarticles are now counted as normal articles (note the article count jumping at around February 4–5), and as such these transcludables also go under their definition and, including but not limited to, mess up the shown amount of articles.

Thus I propose introducing new namespaces for these pages (like Metadata:, Video:) to fix all of that. I anticipate a wave of opposes due to being a huge change with probable little benefits, but anyway...

— Agent NickTheRed37 (talk) 18:16, 15 July 2015 (UTC)


 * Both methods have pros and cons. The multiple-namespace approach has been used for years on the Yu-Gi-Oh! wiki for such things as galleries and rulings, but in spite of that, I don't have much of an opinion on which I prefer. I will point out, though, that one of the cons for that approach is that renaming an article doesn't provide the option to automatically rename the related pages, since they are no longer subpages of that article, though this probably isn't a significant concern here given that pages are so infrequently renamed. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 19:06, 15 July 2015 (UTC)


 * . Even though I'm okay with it, the Video namespace is already used in Wikia. --<font face="Minecraft"><b style="color:lime">MCPEpl</b><b style="color:lime">ayer2</b> TNT.png <sup style="color:gold">Talk to me! 22:48, 15 July 2015 (UTC)


 * The Video: namespace on Wikia was deprecated a little while back and no longer works; all videos uploaded to Wikia are instead in the File: namespace (as they were originally). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:07, 16 July 2015 (UTC)


 * Keeping data pages in an alternate namespace makes some sense (though it should really be "data" rather than "metadata", mainly since shorter is usually better). The video namespace could also be helpful, especially if we set the namespace to only allow administrator edits (like "MediaWiki" does, and "Project" accidentally did for a bit.)
 * The main issue I see with this is loss of convenience: not only the moving of pages stuff, but also the convenience of transclusion. Subpage templates (or templates only used on a single page) would basically lose their purpose if they are moved into another namespace, as they no longer have a quick way to be called (thus, they might as well be in the "template" namespace).
 * I am mostly neutral on this topic, basically I am against it as it seems like a lot of work for seemingly little gain (yep, as said above), but like it for the idea of a namespace to contain all extra page data, basically to keep the main namespace for articles. Though for one last thought, if the main point of this is to fix errors with them acting as articles, wouldn't it be easier to develop a simple extension to get the root article count instead? Most related problems can be solved in a similar way, such as using something like mw:Extension:Randomrootpage to solve related issues with the random button. – KnightMiner  · (t) 04:08, 16 July 2015 (UTC)
 * There are “subarticles” that are actually articles, most notably tutorials and ones about game modifications. Oh wait, can we rather implement a __NOTAR TICLE__ “magic word”? If yes, then the idea can be scrapped in favor of that. — Agent NickTheRed37 (talk) 05:50, 16 July 2015 (UTC)


 * The tutorials have generally been considered as poor quality non-articles (I like to pretend the whole tutorial section doesn't exist), and mods are not officially supported by the wiki, so those sections not being considered "real" articles would be kind-of fitting. However, the quality of tutorials has been improving a lot, so maybe we could consider them real articles and give them their own namespace, or include our pseudo-namespace subpages in our article definition.
 * As for the magic word, it is likely the easiest solution (and an extension may already exist for it), but feels messy to me. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 17:51, 18 July 2015 (UTC)


 * I feel that sub-pages are a good way to associate data with a page, which really should be on the page itself, but only isn't to avoid duplicating the data on other pages. With single-page templates, it is just to avoid wikitext clutter in the article, so those could just be moved the template namespace. And for videos it is just for protection reasons.
 * I don't see it at all being worthwhile to lose the convenience of these pages being associated with their parent pages just for more accurate statistics. I would rather do as says and try to fix the definition of "article". –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 17:51, 18 July 2015 (UTC)

Template:Grid/Dispenser
There should be a template for the dispenser GUI. The BlobsPaper.png 15:54, 22 July 2015 (UTC)


 * Why? There's no difference between the dispenser and the player's inventory or a chest, as far as item interaction mechanics go. There's nothing that would require using a template for that that couldn't be served with a simple screenshot. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 16:47, 22 July 2015 (UTC)


 * Well, the dispenser can store LESS items than the inventory or chest. --<font face="Minecraft"><b style="color:lime">MCPEpl</b><b style="color:lime">ayer2</b> TNT.png <sup style="color:gold">Talk to me! 18:27, 22 July 2015 (UTC)


 * Okay? How does it storing less items make it be required as a template? The reason there is no chest or inventory template is it is not needed, not there are too many slots. – KnightMiner  · (t) 19:05, 22 July 2015 (UTC)


 * The purpose of the grid templates is to provide a simple, modular, and easily extendable method of displaying interfaces that interact with items, or that enable items to interact with each other, without requiring a separate image uploaded for each possible interaction. The player's inventory, chests, dispensers, and other such interfaces do not interact with items stored in them, nor do they enable those items to interact with each other; they are purely storage interfaces, distinguished from each other in the way they interact with the player and the environment rather than items. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 02:43, 23 July 2015 (UTC)
 * By using a template, it is easier to create GUI's because you don't have to upload a new image each time. The BlobsPaper.png 15:33, 23 July 2015 (UTC)


 * That doesn't say why one is needed for dispensers. What exactly are you trying to do that requires a template instead of being able to just take a screenshot? 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 18:25, 23 July 2015 (UTC)
 * I don't know, though it could be created later (if necessary) The BlobsPaper.png 18:04, 24 July 2015 (UTC)


 * This is true, but my entire argument is that it is not necessary, and no one else has been able to present an argument as to why it actually is. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 21:07, 24 July 2015 (UTC)

Splitting Windows 10 only updates into their separate pages.
I know this has been brought up a few times, and I know Win10 is MCPE, but for consistency and avoiding confusion, why can't we just create separate version pages for the Windows 10 Edition? We can just add a note saying:

This would settle down the argument about the 0.12.0/0.12.1 page order in the version Nav template. --MarioProtIV (talk) 15:55, 4 August 2015 (UTC)


 * If anything we should do the opposite and merge 0.12.0 into .1 (since that is the majority), with a note about it being released early as 0.12.0 on Windows 10. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 16:09, 4 August 2015 (UTC)
 * That seems like a good idea. --MarioProtIV (talk) 16:12, 4 August 2015 (UTC)
 * I've written up a sample in my workbench to display (see below). Opinions/suggestions are welcome.

--MarioProtIV (talk) 18:04, 4 August 2015 (UTC)
 * It's good. --<font face="Minecraft"><b style="color:lime">MCPEpl</b><b style="color:lime">ayer2</b> .png <sup style="color:gold">Talk to me! 21:51, 4 August 2015 (UTC)
 * @Goandgoo @Dinoguy1000 thoughts? Would like to know soon, so the argument on the 0.12.0/0.12.1 labeling stops (it's also being argued about on Alpha 0.11.0). --MarioProtIV (talk) 23:29, 4 August 2015 (UTC)


 * I do agree with Majr's proposal that 0.12.0 should be merged into 0.12.1. Seeing that 0.12.0 was never released for the Pocket Editions, and all the features from 0.12.0 are being implemented as part of 0.12.1, it makes sense for the 0.12.1 should be the main version. 0.12.0 was essentially 0.12.1 released early for Windows 10. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 01:52, 5 August 2015 (UTC)

Portal blocks
The result of the discussion was split respective portal blocks.

Recently a page was created for the end gateway portal block itself. The end portal and nether portal blocks were removed from the technical blocks page and made as a section of their respective page (end portal and nether portal). In the interests of consistency, I propose that the end portal and nether portal blocks themselves should have their own page at End Portal (block) and Nether Portal (block) respectively, with the existing page at End Portal (block) being moved to End Portal (frame). –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 13:16, 5 August 2015 (UTC)


 * – KnightMiner  · (t) 13:42, 5 August 2015 (UTC)


 * – Sealbudsman (Aaron) SealbudsmanFace.png T/C 14:45, 5 August 2015 (UTC)


 * , although I thought it may get better to rename to End Portal Frame, not End Portal (frame). We should really use the “rename” term alongside “move” — Agent NickTheRed37 (talk) 15:10, 5 August 2015 (UTC)


 * The problem with that however is that it is only officially called the End Portal Frame in the console edition, however the name in the PC version is simply End Portal. However, the in-game name is end_portal_frame so I'm on the fence with this one. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 11:52, 6 August 2015 (UTC)


 * The name was reported as a bug for Pocket Edition in, and subsequently confirmed and assigned by Daniel Wustenhoff. -- Illidicia ( t + c ) 14:59, 6 August 2015 (UTC)


 * . -Mikazukinoyaiba 16:47, 5 August 2015 (UTC)


 * it be any better to just merge the gateway block article into the gateway structure article, the same as was done with the nether and end portal blocks, into their structure's articles? They don't appear in gameplay independent of their structures, and their structures don't function without them, and the correlation of portalblocktype-to-structure is one-to-one.  – Sealbudsman (Aaron) SealbudsmanFace.png T/C 18:25, 5 August 2015 (UTC)


 * While the structures don't function without the blocks, the blocks do function independent of their structures. While the nether and end portal blocks simply take players to the Nether/End respectively, the gateway block can be used as a custom teleportation block, and detailing the information on the custom teleportation is completely separate to the survival function of going to the other islands. Therefore I still think there is enough content on the block themselves, which can be placed using, to have their own respective pages. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 11:52, 6 August 2015 (UTC)


 * Ah ok, fair enough. I still support the split as proposed. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 12:58, 6 August 2015 (UTC)


 * I . --<font face="Minecraft"><b style="color:lime">MCPEpl</b><b style="color:lime">ayer2</b> .png <sup style="color:gold">Talk to me! 01:15, 7 August 2015 (UTC)

Error on mobile w/ desktop view on?
Apparently I cannot view the desktop view of the entire wiki on my phone, instead, it links to the main Gamepedia page.. Is this an error/bug/data failure or something? MarioProtIV (talk) 16:44, 5 August 2015 (UTC)

I would really appreciate any response if this is a bug or not D: MarioProtIV (talk) 20:39, 5 August 2015 (UTC)

@Majr, can you try and see if this occurs on your mobile device? I'm not sure if it's just me that's having the issue. MarioProtIV (talk) 01:11, 6 August 2015 (UTC)


 * I don't have one. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 04:25, 6 August 2015 (UTC)


 * Seems to be working fine for me (Chrome on Android). -- Orthotopetalk 04:45, 6 August 2015 (UTC)


 * Works on Wikipedia (Safari on iOS). The BlobsPaper.png 22:38, 15 September 2015 (UTC)

Beta 1.9 page
I think it may be a good idea to add more info to the Beta 1.9 article to make it more consistent with the other pages. It will also include some info on why it was never released. I've written a draft here. --MarioProtIV (talk) 21:08, 7 August 2015 (UTC)


 * It was released, it was just called 1.0.0. Any other content you can add is either redundant or states that first sentence. Your draft article only proves this, with all its content either being fan nicknames (a forum thread is not a valid source for a name) or stuff that can easily be described on 1.0.0. It would also be less consistent to split it, as all other updates which changed their number are covered on the new number (for example, 1.7 on 1.7.2). – KnightMiner  · (t) 21:24, 7 August 2015 (UTC)
 * Ah ok. I'll just add a trivia note to the 1.0.0 article saying that it was originally planned to be released as Beta 1.9. --MarioProtIV (talk) 22:01, 7 August 2015 (UTC)

Module:LoadArchives
On talk pages with more than one archive, it is impractical to manually create archive boxes for each talk page. There should be a module that creates archives for you. Parameters would be stored in Module:LoadArchives/Discussions. The code would be as follows: local p={} p.archives=expandTemplate{title='Archive box',args=mw.loadData('Module:LoadArchives/Discussions')[mw.getCurrentTitle.prefinedText:gsub('/Archive %d+$','')]} return p The BlobsPaper.png 00:45, 10 August 2015 (UTC)


 * You don't need to create an archive box for each page if one is required on the archive pages, just create a subpage and transclude it (see my talk page for an example). Usually though we only add the box on the main talk page. – KnightMiner  · (t) 01:47, 10 August 2015 (UTC)

Phasing away from Mojang avatars to real life pictures + Expanding biographies on current and former employees
I feel like these are the stupidest ideas I've ever conceived, but here goes nothing... (I literally had to rethink this about 20 times before finally getting an idea)

I think that the Mojang avatars on Mojang AB need to be replaced by real life pictures of the employees (in fact, the last avatar ever made by Jnkboy was almost three years ago). A perfect example would be this picture of Daniel Wustenhoff. To me, I feel like these pictures look cleaner and more "professional" than the official avatars.

The biographies of the employees at Mojang clearly need some major expanding, and I feel like using LinkedIn would be a fine choice, as no one has even bothered to touch those pages (except for Tomas Alaeus of course) when it comes to information about where they graduated, what they graduated for, what jobs did they have before joining Mojang, etc. -BDJP (t 01:39, 10 August 2015 (UTC)


 * While I do like the Mojang avatars, I do agree the real life pictures often look better when available, though I am not so sure such pictures are required on the Mojang article anyways (if one is required, I am neutral on which to use).
 * As for LinkedIn, that seems like a pretty good source for information on the users, though I am currently having issues getting the site to display in English. (I take it the subdomain made the site think I am Swedish...). I think it looks like a reliable enough source to start adding to articles, though it couldn't hurt to make sure the profiles were made by the actual employees. – KnightMiner  · (t) 02:37, 10 August 2015 (UTC)


 * I don't have much of an opinion on using the Mojavatars versus actual photos, but would like to point out that getting new Mojavatars is a simple matter of asking Jnkboy for them (assuming he still works with Mojang); this is literally the method I used to get the last version of them.
 * Of course, now that I think about it, it would be really awesome if we could get photos of the Mojangstas all wearing shirts with their Mojavatars printed on them, though that would probably be hard as hell to have done for several reasons. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 07:10, 10 August 2015 (UTC)
 * As for expanding their articles with more details of their lives and careers, two important factors need to be kept in mind: verifiability and desire for privacy. Verifiability should be simple enough; either ask each Mojangsta for some details to flesh out their article, or ask them to confirm if a given source has it right. Desire for privacy is a bit trickier but just as important; if a given Mojangsta prefers some detail not be included in their article here, we should respect that (note we made this concession for ez). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 07:22, 10 August 2015 (UTC)


 * Welp, I just got confirmation that Jnkboy is going to get back to making Mojang avatars; didn't say when though, so that takes the phasing away part out of the picture. Don't even read the rest of the tweets I sent him. Its very hush-hush. -BDJP (t 11:58, 10 August 2015 (UTC)

Pocket Edition Alpha 0.12
Can we please decide what we're actually doing with these versions already? I've lost track of the various pagemoves and redirects by this point, and the situation doesn't seem to be getting any simpler from the perspective of the releases themselves; these are also part of what resulted in the editing restrictions currently in place on several editors.

This is my understanding of the version situation as it stands (note that I am pointedly ignoring the hot mess that is our article(s)): (If I missed anything or am mistaken in any details, please call me on it, or feel free to fix the summary directly.) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 00:16, 12 August 2015 (UTC)
 * Pocket Edition Alpha 0.12.0 was released exclusively for Windows 10, with the version number "0.12.0"
 * Pocket Edition Alpha 0.12.1 was released for mobile devices, incorporating the changes and bugfixes from 0.12.0, and adding/fixing a few more things (?)
 * Windows 10 devices received 0.12.0.1


 * Just to be clear, this is what I want out of this discussion:
 * A clear and concise summary of the version/release situation
 * A summary, with links, of any relevant statements by the developers
 * Summaries of any relevant discussions that have already taken place, with links to those discussions
 * Where necessary, harmonization of the results of those discussions, and extension of those results to cover any details that weren't already handled
 * A single, central location for any and all further discussion on this topic (meaning any currently-in-progress discussions should be summarized here and then pointers to this topic should be posted on them)
 * I don't care about the minutiae of implementing the decisions; that can be left to new discussions on the article talk pages themselves; what I want to see is a final decision on what those articles will be in the first place. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 00:27, 12 August 2015 (UTC)
 * You are correct, but 0.12.1 on mobile also adds the additions from 0.12.0. Here is my theory on what I want to do with these pages:
 * Split them into separate articles, and while I know Win10 is MCPE, it can prevent this from happening again if 0.13 happens to be 0.13.0 (then 0.13.0.1 and so on) on Win10, then 0.13.1 on mobile devices. I've also discussed how the template for MCPE versions can be sorted out here.
 * We can keep the pages as is and just add the template that I explained before.
 * --MarioProtIV (talk) 00:41, 12 August 2015 (UTC)


 * The current situation is basically Windows 10 got 0.12.0 released early, and now got a bug fix update called 0.12.0.1 (which is likely to fix incompatibilities with the new platform). The rest of the editions meanwhile are developing 0.12.1, which contains basically the same feature set.
 * As for developer statements, Tommaso says it is the same edition, and that most exclusive features are planned for the other MCPE versions, along with supporting co-op play between the two. He also stated that they will be developed together.
 * As for relevant past discussions: There is the first discussion, which was about merging the windows 10 edition article with the pocket edition article, which end undecided, leading to no action. The second discussion about splitting Windows 10 to its own articles, which ended with 0.12.0 being merged into 0.12.1. The last discussion I know of was about dealing with the later bug fix updates for the windows 10 edition, which lead to MarioProtIV moving all the articles, despite disagreeing with separating the two editions.
 * As for a final solution, I suggest the Windows 10 Edition should be treated as another platform for the Pocket Edition. This means it will share a spot in the history section, the same version articles, same navigation templates, and same features articles (mentioned, removed, etc.). We have all the other pocket editions merged already, and have merged all the console editions, so I see no reason to split the windows 10 edition. (And a response to the likely argument of "they have slightly different features", I will say so do current and next gen console when it comes to the console edition, and I do not see that split.)
 * MarioProtIV@undefined I highly doubt the developers are going to not release the same builds on Windows 10 in future update, those have proven a much more stable method of releasing updates. In any case, I don't think we should completely split everything based on an assumption of the developer's plans. If it actually happens, then I might agree to split. – KnightMiner  · (t) 20:09, 12 August 2015 (UTC)
 * For the template, this may be a good example: [snip] --MarioProtIV (talk) 20:36, 12 August 2015 (UTC)
 * @MarioProtIV I agree, except I believe the top should be like this: [snip] Note Windows 10 being under AlphaTySkyo (talk) 21:12, 12 August 2015 (UTC)


 * To quote Dinoguy above: "I don't care about the minutiae of implementing the decisions; that can be left to new discussions on the article talk pages themselves; what I want to see is a final decision on what those articles will be in the first place." This discussion is only about whether we should treat windows 10 as a separate edition. If and only if we agree to treat it as a separate version should we start discussing how we perform the split.
 * You both have already stated what you think should be done, but for the sake of a resolution, instead state why you think it should be done, give me direct reasons as to why we should split. As it stands, I still disagree with the split, and showing me another way to implement it will not change my mind. – KnightMiner  · (t) 21:44, 12 August 2015 (UTC)
 * I think they should be split because of the following:
 * Splitting would prevent a huge clutter on the version pages (this is for my sake apparently). It would also make the original 0.12.1 page more consistent with the other major update pages for the original MCPE.
 * Splitting would also make it consistent with the other editions of Minecraft, just like how Pi Edition has its versions split into separate pages, even though it is based/built of off PE Alpha 0.5.0.
 * It would create less clutter in the template as well, as listing the Windows 10 Edition versions in the original MCPE versions template, which just creates arguments/confusion.
 * Alas, if we decide not to split at all, we could do the following:
 * Pocket Edition Alpha 0.12.0 would be restored to the revision before it was merged with the 0.12.1 page.
 * Pocket Edition Alpha 0.12.1 would remain unchanged, just with the removal of the 0.12.0 release early for Win10 and the removal of the Windows 10 stuff.
 * Pocket Edition Alpha 0.12.0.1 can be recreated.
 * The template I explained above could be implemented.
 * Keep in mind if we decide to do the second option, on the 0.11.0 page (and sub-pages), it should still be necessary to have the nextparent thing link to 0.12.1 as it is the next major update to the original MCPE platform. But this is where people say "0.12.0 comes before 0.12.1 so it should be the parent version instead of 0.12.1." I have a solution for this. We can treat 0.12.0 and 0.12.0.1 as "pre-releases" (NOT OFFICIAL ONES), and we could add that to the version navbox. --MarioProtIV (talk) 22:16, 12 August 2015 (UTC)


 * As for the clutter on version pages, I think the only case of that would be on 0.12.1, which I agree should have the Windows 10 exclusive updates split from, basically as it was before 0.12.0 and 0.12.1 were merged.
 * As for the consistency part, I will point out that we have all the console editions merged, along with all the other pocket editions. The pi edition is an exception, as when it was released, it was never stated as part of the pocket edition, and did not contain all features from PE. In contrast, the console editions and all other pocket editions always received an exact or slightly better version of the relevant edition, and the Windows 10 edition is no exception.
 * With the navbox, it is not really cluttered from two exclusive versions; clutter would more likely be five to seven exclusive versions with no common releases. I would agree to split if 0.13.x/beta 1.0 keep the same format, but overall I think it would be easier to split at a later date if the update format changes, then to merge it the versions again if it does not.
 * Lastly, as a response to nextparent, it technically was an official release, but since most of the main update stuff would be covered on 0.12.1, I would agree to just linking 0.12.0 in the "next" field on 0.11.2 and calling 0.12.1 the next parent release. (I would still leave it first in the navbox though, as the parent release is already highlighted there pretty good.) – KnightMiner  · (t) 00:01, 13 August 2015 (UTC)


 * I believe that Pocket Edition and Windows 10 Edition should be seperated and considered different versions as:
 * Mojang brands the Windows 10 Edition as a separate edition from Pocket Edition unlike Android, iOS, and Windows Phone
 * They already have different versions (ex: 0.12.0.1) and separating the versions would cause less confusion for readers and editors
 * While Windows 10 Edition is basically Pocket Edition is is still different in some ways:
 * Uses a Xbox Live/Microsoft Account
 * Has Multiplayer over Xbox Live
 * Multiple control schemes (Touch, Controller, Keyboard)
 * Has a built in GameDVR
 * Has a player feedback mechanism


 * This basically means that there would be a seperate template for the Windows 10 Edition versions, seperate version pages for Pocket Edition and Windows 10 Edition(even if there are some versions that are the same, others still might differ) a seperate box for the Windows 10 Edition on the main screen ect.


 * I also think this should apply for the future HoloLens Edition as it will have some differences from Pocket Edition and Windows 10 Edition and is branded as a seperate edition like the Windows 10 Edition. Wolffillms (talk) 20:26, 13 August 2015 (UTC)
 * While this is conceiving and a good reason, I feel I need to reiterate this again: Windows 10 is Pocket Edition, because they can play with PE players in the release that co-launches with 0.12.1 on mobile. Also, this should be in the discussion above, since it regards the 0.12 issue. --MarioProtIV (talk) 21:49, 13 August 2015 (UTC)
 * I am aware the two versions are pretty much the same, but it is still branded as a different version, has some different versions, and is slightly different in some ways. Wolffillms (talk) 22:55, 13 August 2015 (UTC)


 * Please read the discussion above and direct all discussion on this topic to it. There is no point in having the same discussion in multiple places. – KnightMiner  · (t) 22:29, 13 August 2015 (UTC)


 * I have read the discussion above, however all it is, Is going back and forth if the version article 0.12.0 should be split or not. I am talking about how Pocket Edition and Windows 10 Edition should be split. Wolffillms (talk) 22:55, 13 August 2015 (UTC)


 * Then this should be added to the discussion above for precisely those reasons. No split has been decided upon, so it is pointless to add to the same controversy in a seperate section. - Illidicia ( t + c ) 03:08, 14 August 2015 (UTC)


 * I think just simply having it the way it is now, while a bit cluttered, is the best solution. Ultimately future versions are most likely to be the same as on the Pocket Edition, and I think separating out these two Windows 10 versions will lead to more confusion. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 07:28, 14 August 2015 (UTC)
 * , and those two pages (0.12.0 and 0.12.0.1) can be re-added if we go through with this. --MarioProtIV (talk) 13:07, 14 August 2015 (UTC)


 * While the major updates will probably be the same, they will probably have different bug fix/minor updates (ex: 0.12.0.1) and there is still a chance of major updates being released on different dates (ex: 0.12.0). Also all of the above still applies "it is branded as a different version, has some different versions, and is slightly different in some ways". Also I fail to see how having them separate will cause more confusion, wouldn't having it less clustered be less confusing? Wolffillms (talk) 13:45, 14 August 2015 (UTC)


 * 0.12.0 as well as 0.12.0.1 are separate updates from 0.12.1 and in the style guide it specifically says under article creation that each update gets a page. Also, this very similar to 0.11.2, and while this update was for only one platform it still got it's own page; this update is no different. Ergo, it should get it's own page.
 * Grid Spawn Shulker.png TySkyo (Talk•Contribs) 01:13, 15 August 2015 (UTC)
 * Would any other admins like to state their opinions on whether we're going through with splitting or keeping as is? --MarioProtIV (talk) 13:55, 16 August 2015 (UTC)
 * MarioProtIV@undefined Admins should approve this. Grid Spawn Shulker.png TySkyo (Talk•Contribs) 22:18, 16 August 2015 (UTC)
 * I'm gonna take a guess everyone is siding with keeping as is now, if this is the case I can re-create the PE 0.12.0/0.12.0.1 pages. Dinoguy1000@undefined is this going to be the conclusion on what we're doing with the 0.12 pages? --MarioProtIV (talk) 17:29, 17 August 2015 (UTC)

Tagalog code
The Tagalog translation project currently uses the "ph" code. As stated on the project talk page, this is a bit... strange, as the Tagalog language uses the ISO 639-1 code of "tl", which is what is used on Wikipedia as well as my wiki, the Feed The Beast Wiki. Anyway, I'm proposing Tagalog translations should be moved to reflect the ISO standard, rather then what it is currently using (there aren't many Tagalog translations, so it should be easy to patch em' up without bots). -Xbony2 (talk) 00:46, 14 August 2015 (UTC)
 * , assuming your information is correct. The BlobsPaper.png 01:35, 14 August 2015 (UTC)
 * I'm guessing whoever started the project mistakenly used the ISO 3166 country code for the Philippines, whose official language, Filipino, is basically a formalized version of Tagalog. Needless to say, I this, and honestly don't think you need to wait to make sure there's consensus for this change, since it's a purely procedural one to bring the project into line with SOP. 「 ディノ 奴  千？！ 」? · ☎ Dinoguy1000 07:01, 14 August 2015 (UTC)
 * Welp, I'll give it a day unless anyone has objections to say, and start moving stuff then. -Xbony2 (talk) 21:03, 16 August 2015 (UTC)
 * Moving complete :) I left behind the redirects, just in case- since "ph" isn't used as a language code, it shouldn't be in the way of anything. -Xbony2 (talk) 16:15, 17 August 2015 (UTC)

Thank button
Hey neat, when did we get a 'thank' button on the revision-difference page? – Sealbudsman (Aaron) T/C 19:24, 19 August 2015 (UTC)


 * requested it for the French wiki, and I also stated in that topic that I'd wanted to use it every once in a while. – KnightMiner  · (t) 20:02, 19 August 2015 (UTC)


 * Well then thanks, you two! I always liked the atmosphere of friendliness that button can foster. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 20:24, 19 August 2015 (UTC)


 * How does it even work? The BlobsPaper.png 02:17, 21 August 2015 (UTC)


 * If you see an edit that you really appreciate, simply click the "Thank" button and it will notify the user that you appreciate their edit. See mw:Extension:Thanks for more information. – KnightMiner  · (t) 02:25, 21 August 2015 (UTC)


 * I thanked Majr for this edit, it seemed appropriate. =D 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 07:36, 21 August 2015 (UTC)

Move pages to singular form titles
At the moment, the wiki is slightly inconsistent when it comes to pluralisation of page titles. The majority pages are singular (e.g. Redstone circuit, Attribute, Skin, Texture pack), however many are pluralised. I suggest changing the following: (pages with strikethrough have been moved)
 * Achievements --> Achievement
 * Languages --> Language
 * Status effects --> Status effect
 * Renewable resources --> Renewable resource
 * Chunks --> Chunk
 * Mobs --> Mob
 * Blocks --> Block
 * Items --> Item
 * Commands --> Command
 * Formatting codes --> Formatting code
 * Key codes --> Key code
 * Screenshots --> Screenshot
 * Models --> Model
 * Capes --> Cape
 * Mods --> Mod

I am currently unsure of the following:
 * Materials --> Material
 * Data values --> Data value
 * Statistics --> Statistic
 * Drops --> Drop

It would be great to get feedback and a community consensus for these changes. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs


 * I absolutely disagree. In some situations, referring to something in plural form as a whole in a title can be useful. — Agent NickTheRed37 (talk) 13:18, 21 August 2015 (UTC)


 * I understand where you're coming from, which is why there are pages in the "I'm currently unsure" category. However, the problem lies in that we have inconsistencies between certain pages being singular, and others that could equally be singular but are plural (e.g. why is attribute singular but status effects plural, why is skin singular but capes plural, etc). –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 13:24, 21 August 2015 (UTC)


 * per NickTheRed37. -BDJP (t 13:29, 21 August 2015 (UTC)


 * #1, Is there precedent for this on other wikis?
 * #2, What about the opposite: moving them all to plural? Most of the ones you suggest seem more natural to state as plural.  (personal opinion.)  Do the other ones (you say most are singular) read well as plural? – Sealbudsman <span style="-moz-transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 14:36, 21 August 2015 (UTC)


 * I vehemently oppose any general proposal to move pages to plural names; it is wholly unnecessary and leads to increased complexity in linking, due to the inevitable impulse many editors have to avoid redirects where possible (and before anyone tries to say "that won't happen here", I have seen it happen on a wiki that decided to use plural page names; it continues to happen now, and every time I see an edit making that change, I cringe). And there absolutely is precedent for using singular page names: Wikipedia calls for singular page names as the norm, not the exception. Specifically, I support moving to a singular title the following pages: Status effects, Chunks, Mobs, Blocks, Items, Screenshots, Models, Capes, Mods; I am uncertain of Drops, but I feel the rest of them fall under one of the exceptions listed on Wikipedia's naming guideline, which I see no reason for us to diverge from (though if you think you have a compelling reason, you're welcome to try to persuade me). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 18:59, 21 August 2015 (UTC)


 * What you have listed makes sense to me. Several of the plural titles just sound odd as singular, and I think the reason is because they focus on the list rather than focusing on the title topic and simply providing a list.
 * As for Drops, I also am unsure about it, and even with my above definition it could go either way. – KnightMiner  · (t) 01:41, 22 August 2015 (UTC)


 * What are the objections with moving renewable resources to its singular form? Also should particles stay plural or become singular? –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 02:56, 22 August 2015 (UTC)


 * With Renewable resources, my main issue is that the article is mainly about listing all the renewable resources, rather than describing to the player what is a renewable resource. It is sorta like a category in the end.
 * As for particles, while most of the article does contain the list of particles, its focus is describing a particle to the player, similarly to blocks. I may be getting a little nit-picky here though, as my requirement is basically me attempting to explain why one title sounds weird to me as singular and others do not, so it could use improvements... – KnightMiner  · (t) 03:57, 22 August 2015 (UTC)


 * If you read between the lines of Wikipedia's policy page, it's basically saying that nouns that are always used as plural or mass nouns should have a plural title. With that much more straightforward definition in mind, it doesn't make sense to move Particles to Particle, since they are always talked about in plural (no one ever talks about a single particle, because the game never produces one particle at a time). But that particular case is still a bit hairy, and I'm kind of expecting someone to disagree with me on it. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 05:18, 22 August 2015 (UTC)


 * Ok, seeing we are simply following wiki naming conventions, I think I can safely move those pages that you mentioned. We can continue to discuss some of the other pages which are slightly more contentious. I think drop should be singular as drop is often referred to as singular. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 07:46, 22 August 2015 (UTC)


 * I've moved the pages suggested above with the exception of Mods, because it has around 1000 subarticles which would probably be a nightmare to move. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 08:08, 22 August 2015 (UTC)


 * I should be able to get my bot to do that, but since it is such a major change (due to the thousands of articles, plus the style guide requiring mod articles as subpages of mods), I want to wait until we are sure people agree with the move, even if the move is to reflect naming conventions. As a start though, I agree with the move. – KnightMiner  · (t) 14:33, 22 August 2015 (UTC)


 * That does sound more reasonable then what I had, and I don't disagree with keeping particles under the current title. – KnightMiner  · (t) 14:33, 22 August 2015 (UTC)


 * These pages are about mechanics that have multiple types. Moving them would mislead. I think Renewable resource should be moved to Renewable resources. The BlobsPaper.png 23:03, 22 August 2015 (UTC)


 * Can you specify which proposed moves you're opposed to, or whether you're opposed to all of them? 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 00:10, 23 August 2015 (UTC)


 * All of them. The BlobsPaper.png 02:15, 25 August 2015 (UTC)


 * There honestly hasn't been any good counterarguments for these page moves. I think we should discuss whether Renewable resource should be moved to its plural title (I was unaware of it already being singular), whether we should move Mods to Mod and Drops to Drop. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 08:12, 25 August 2015 (UTC)


 * Blobs2@undefined Before you disagree with all of them, please note the style guide requires all titles to be singular, so unless you have a proposed amendment to the style guide to cover a common trait of those pages, they are just going to have to be moved to a singular title later to comply with the style guide. That being said, I think the criteria that Dinoguy proposed of "nouns that are always used as plural or mass nouns should have a plural title" sounds good.
 * Goandgoo@undefined Renewable resource and Drops both make sense as plural since they are almost always referenced in plural; you rarely see reference to a renewable resource outside of the category of renewable resources, or a drop without other drops present. And I have already stated my opinion on the mods article above. – KnightMiner  · (t) 14:20, 25 August 2015 (UTC)


 * There are some articles which refer to the item being a renewable resource, and while it may not appear often, it still does make sense when used in context. Therefore I still think Renewable resource should remain as is. Drops should definitely stay plural as it is basically always used in the plural form. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 08:30, 28 August 2015 (UTC)


 * In that case, I would agree with keeping the current renewable resource title. – KnightMiner  · (t) 14:40, 28 August 2015 (UTC)
 * Actually, I because that is how it is done with other articles (such as Spider). The BlobsPaper.png 22:01, 29 August 2015 (UTC)

Alex skin variations
Can someone please upload the variations of the Alex skin from the default skin pack onto Skin? - MinecraftPhotos4U (talk) 19:09, 2 September 2015 (UTC)
 * I'm pretty sure there's already an image called [[media:Alex.png|Alex.png]]. Also, I'm not sure what you mean by uploading a file to a page. The BlobsPaper.png 14:21, 3 September 2015 (UTC)
 * The console edition has the default skin pack, which includes seven differently dressed variants of the default skin. They've been out for a while and have not been uploaded to the wiki. If you look at the skin page and lick Show next to Default Skin Pack you'll see what I mean. - MinecraftPhotos4U (talk) 19:56, 3 September 2015 (UTC)

Catalan Wiki
Hello,

I would like to open a Minecraft Wiki in catalan language. I know this project, but if we don't have an own wiki we won't get new contributors. My question is, what I have to do or how many pages must the catalan project have on this wiki to obtain the subdomain? Cheers, --NeoMahler (talk) 11:30, 8 September 2015 (UTC) edit: When I try to create a page in catalan, it appears a message that says: An automated filter has detected that you are attempting to create a possibly unwanted page. As a new user, your action has been   disallowed. If you believe your edit was constructive, please post a message on the admin noticeboard or notify an admin directly. But I'm not doing anything wrong! --NeoMahler (talk) 11:42, 8 September 2015 (UTC)


 * There are a few requirements, but most notably is you must have a large enough community interest and create articles for redlinks from the main page and major navboxes. It is also worth mentioning that nearly all of the other languages started as a project here, and managed to get enough contributors before getting their subdomain.
 * could also likely offer a little more insight on getting a subdomain than I know.
 * As for that issue you are having, it means you are a non-autoconfirmed user adding things to a new article such as external links. After making a few edits (such as improving/updating earlier translated pages), that should stop. – KnightMiner  · (t) 14:47, 8 September 2015 (UTC)
 * Well, now I was creating the Markus Persson page in catalan with only one sentence and no links, and I couldn't make it. Anyway, I will wat until I'm 4 days old and I have 10 edits. Thenks for commenting! --NeoMahler (talk) 10:50, 9 September 2015 (UTC)
 * There's not really enough Catalan translations to go independent, but it is possible to get that point in the future like many other projects have done. You'd probably need at least one other main editor with you as well, so if you disappeared there'd still be staff around to maintain the wiki. -Xbony2 (talk) 11:38, 9 September 2015 (UTC)
 * “Staff”? There’s no “editorial staff” as such on Minecraft Wiki, Xbony2! — Agent NickTheRed37 (talk) 16:35, 9 September 2015 (UTC)
 * "Directors", "Bureaucrats", "Administrators". Btw Nick, I can confirm mentioning via does work, as debated on my user talk page on the FTB Wiki. -Xbony2 (talk) 20:54, 9 September 2015 (UTC)

Importing data from other article
Hi. I have a some problem with one of templates, but on my other wiki about other game (non-gamepedia). I ask here, because many of you have enough experience (I hope so) to help me with my problem.

I have a 'translating' template. There is a main code http://pastebin.com/WzuDenxz, where is  word to translate. Translating can be bilateral (?duplex?) (it depends on second parameter in other piece of template). Example:

This is a tree, and this is a sky. This is a drzewo, and this is a niebo.

When cursor is hover bold words, translate is show up in formatted tooltip, e.g. for tree will display "pol. drzewo", and for drzewo will display "ang. tree". Everything allright? Not exactly. To add new words, you need to edit sensitive template. One small mistake = many big troubles for almost every articles.

So my question is: how I can import phrases from external source (other template/article or optionally other website)? What addon I need install? And how I can implement it to main template? Sorry for my bad English :/  Lewandowski pl.Wiki Admin   talk  19:19, 18 September 2015 (UTC)
 * Impossible. The BlobsPaper.png 01:48, 19 September 2015 (UTC)

PE boats
There should be an image called [[media:Boats.gif|Boats.gif]]. It would be used to show the boats in Pocket Edition on the boat page. The BlobsPaper.png 17:19, 19 September 2015 (UTC)


 * An animated gif that cycles thru the boats like the crafting recipe on the boat page? – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 19:20, 19 September 2015 (UTC)


 * I mean in the infobox. The BlobsPaper.png 22:17, 19 September 2015 (UTC)


 * Infoboxes support animation of multiple images, so GIF image is not necessary, all you need is just several separate images for each kind of boat. — Agent NickTheRed37 (talk) 14:51, 20 September 2015 (UTC)


 * We don't have all the images. It would be easier to upload one image than to upload six. The BlobsPaper.png 15:05, 20 September 2015 (UTC)


 * What do you mean by “easier”? Do you mean quicker? Then we have MsUpload and patience. And, using separates can be more flexible, since when using a single GIF only, you would need to upload a separate image for a single kind of boat when it is needed. — Agent NickTheRed37 (talk) 15:16, 20 September 2015 (UTC)


 * And if another type of wood ever gets added, it is a lot harder to update as you need someone with both modeling and gif knowledge. Thus the easiest way is separate images animated like we have done almost all the other pages. – KnightMiner  · (t) 20:42, 20 September 2015 (UTC)


 * What is the MsUpload? The BlobsPaper.png 01:46, 22 September 2015 (UTC)


 * The "Drop files here" header on the editing screen. – KnightMiner  · (t) 15:30, 22 September 2015 (UTC)

How do I make a list of pages in a category that the page is in?
I want to know how to make a list of pages in a category at the end of a page. What template would do that? Kivitoe (talk) –Preceding undated comment was added at 01:49, 21 September 2015‎ (UTC). Please sign your posts with


 * –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 03:09, 21 September 2015 (UTC)

How to make a template or make a list at the end of a page?
1). How do you make a template?

2). How do you make a list of pages in a category like at the end of this page, End City? –Preceding unsigned comment was added by Kivitoe (talk • contribs) at 3:12, 30 September 2015 (UTC). Please sign your posts with


 * Writing a template can be complicated, depending on what you want it to do. wikipedia:Help:Template is a good place to start.
 * The list of categories a page belongs to is automatically added. See also wikipedia:Help:Category. -- Orthotopetalk 03:18, 30 September 2015 (UTC)

Replace Windows logo - 2012 (red).svg with WindowsPhoneLogo.png
I believe that the red Windows logo should be replaced with the purple one, as the purple logo is for the Windows Phone in general, while the red logo is for a specific model, which changes all the time and all the other OS's logos are the general image, rather that the current model/OS version. Wolffillms (talk) 22:53, 6 October 2015 (UTC)
 * Apparently, the red logo doesn't even exist. The BlobsPaper.png 20:58, 7 October 2015 (UTC)
 * Red logo was the Windows Phone 8 logo (going off of the wikipedia entry), but yes, they've retained the purple branding on the top of https://www.windowsphone.com/en-us and the bottom of https://www.microsoft.com/en-us/windows/phones – even though the current phone is the Windows 10 phone with sky blue branding. Is that where you are getting the idea for purple?  The only thing I would add is that the purple logo is at slightly the wrong angle and doesn't match the angle from Microsoft; probably a new image should be captured. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 21:42, 7 October 2015 (UTC)
 * I got the idea for the purple logo, as it is the general Windows Phone logo, rather than a specific model (red for Wondows 8 and blue for Windows 10). Also suppose a different version of the image would be better. Wolffillms (talk) 12:57, 9 October 2015 (UTC)


 * It requires Windows Phone 8.1, same as the Windows 10 edition require Windows 10. Should we change the windows 10 logo to a generic one too? –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 13:01, 9 October 2015 (UTC)


 * I believe we shouldn't change the Windows 10 Edition logo, so it is not confused with the regular Windows version. Wolffillms (talk) 19:55, 9 October 2015 (UTC)

Nether Fortress in Minecraft PE
I have been looking for a fortress in the nether for over 3 weeks. Do the fortress's exist in PE?

Thanks, Garry –Preceding unsigned comment was added by Getw (talk • contribs) at 1:35, 10 October 2015 (UTC). Please sign your posts with


 * Yes, they do. See Nether fortress. – KnightMiner  · (t) 13:50, 10 October 2015 (UTC)
 * Try going east or west. You can figure out your direction in the overworked by the sun movement. Portals in the nether face the same direction as the version in the overworld. The BlobsPaper.png 22:50, 15 October 2015 (UTC)

Recent guideline updates
I have noticed with the large amount of different pages on guidelines that there is no easy way for a user to keep track of what new guidelines are added, so I would like to propose adding a list of recent guideline changes to the community portal article. It would basically just be a brief summary of what changed, a link to the relevant discussion, a link to the guideline, and a timestamp, and it would contain the last five or so changes.

So the main thing I am wondering is if anyone would actually use this, or if this is just some random idea that isn't needed. – KnightMiner  · (t) 22:24, 25 October 2015 (UTC)


 * Personally I would appreciate it. As it stands I am not usually aware of changes. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 02:46, 26 October 2015 (UTC)


 * We can add a box for all wiki news altogether. Russian wiki has it, but it is not much used. — Agent NickTheRed37 (talk) 14:46, 27 October 2015 (UTC)

Stating historical information when a block/item is used in a new crafting recipe
Should historical information be stated for when existing blocks/items are used in a crafting recipe for a new block/item? I've noticed that the wiki is quite inconsistent in this regard, for example the iron ingot page's history table lists when iron was used to craft anvils, weighted pressure plates and iron trapdoors, but not any of the other other items/blocks listed in the Usage section. If we decide to ensure consistency, it would be a matter of looking at the Crafting ingredient subsection of Usage and ensuring that when those blocks/items received a crafting recipe, they are listed in the history table and add the relevant information to the history table. It may be worth setting up a project (just like the Rewrite for Style project) so that pages aren't missed.

I know it may seem like a minor thing, but I believe there should be consistency over the wiki's pages either way. Thoughts? Opinions? –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 01:40, 31 October 2015 (UTC)


 * I this. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 03:43, 31 October 2015 (UTC)


 * I personally see it as somewhat useful information, but mainly for crafting ingredients, and overall a lot of effort would be required to add it. So overall I just vote for a consistent approach across articles, whether it be either way. – KnightMiner  · (t) 03:11, 1 November 2015 (UTC)


 * Yeah I see you've been going to town on this. Any estimate on how far along you are?  Good job by the way. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 03:27, 1 November 2015 (UTC)


 * I've actually finished it all - I've gone through all blocks and items and it should all be up to date now. Some pages were certainly longer to do than others (e.g. wood plank, diamond, stick, redstone, iron ingot etc). But at least there's now consistency over the wiki on this though. –<b style=color:#282>Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 04:37, 1 November 2015 (UTC)


 * Applause! – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 16:42, 1 November 2015 (UTC)
 * The BlobsPaper.png 01:36, 6 November 2015 (UTC)

Quotes on snapshot pages
I was wondering what people's thoughts were on putting developer quotes on snapshot pages. For reference there's a project whose aim it is to put developer quotes on pages, and I personally like the idea. I know there was a matter of whether it was consistent or not, but I guess "consistent with what" is my question. Consistent with the status quo would lead you to remove quotes, whereas consistent with the project would lead you to add them. Depends how you look at it. I see it like the snapshot images: if there is one, put one, if not, don't put one. Same with quotes. What do you all think? – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 04:45, 31 October 2015 (UTC)


 * I like the idea, it would certainly give some more interesting content to snapshots with are only bug fixes, and can help a few articles seem less like stubs. – KnightMiner  · (t) 03:11, 1 November 2015 (UTC)


 * , makes rather boring pages more interesting. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 12:53, 2 November 2015 (UTC)

Notch videos
We have some pages, like Version_history/Classic, that use youtube videos by Notch – but apparently he's recently removed minecraft videos from his account. I saw somewhere (reddit maybe?) that some other youtube user had mirrored them. What should we do; is it fine to link to the mirrored account, if we find it? – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 20:50, 13 November 2015 (UTC)


 * While a youtube account mirroring them can be useful for the references, we have no way to guarantee that they did not change any of the footage to add false references (thus every video would have to be independently checked by those who saw the original). I really don't know what the easiest way to go about doing that is, other than finding someone we know is trustworthy who uploads some of the videos, such as MCSpotlights who uploaded the first Cave Game video as an archive. (There also is the question of video copyright). – KnightMiner  · (t) 00:57, 15 November 2015 (UTC)
 * Only use sources that are directly from Mojang (YouTube videos don't work). The BlobsPaper.png 02:47, 17 November 2015 (UTC)

Bug descriptions "controversy" Part II
Well, what a nice day for a fresh start on this topic that layed dormant for over five months.

Renewing the "controversy-that's-still-eating-away-at-me-due-to-my-condition" discussion from the twenty-sixth section in archive sixteen, I'm still to changing the bug description in any shape or form. As what Munin said six months ago, rewriting titles are heavily subject to further and further rewriting by a generation of editors to this wiki. Keeping the titles as they should be can cause less edit wars and makes referencing easier. As they are quoted from mojang.com, they are immune to the grammar rules from the style guide, and per WP:MOSQUOTE, they should be quoted precisely. Those are the reasons why I opposed any changes to the bug description six months ago, with the exception of html formatting. -BDJP (t 15:21, 14 November 2015 (UTC)


 * It is a nice day. What brings this up again? – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 15:31, 14 November 2015 (UTC)


 * 1. Bug titles are no more subject to rewriting than many other types of wiki content, such as tutorials. If we make bug titles compliant with the style guide, we will either keep the revision as a better one, revert it for reduction of quality, or, which is less likely than the other two (and less likely than in tutorials or other places), have an edit war and a discussion about whether this edit is improvement or degradation.
 * 2. Bug titles are no more official quotes than a Reddit post which is quoted by a developer when they write a reply to it. That this particular title is present as a quote on mojang.com does not mean (if we disregard implied rules) that we should use this particular spelling. Also, what if there is a bug fixed in this version but not written on mojang.com? Are you going to tell that an editor needs to figure out for each single title whether it can be rewritten?
 * 3. Since when are Wikipedia manuals and rules in effect here without explicit references from local rules and guidelines (correct me if I am wrong, but I don't recall a reference to MOSQUOTE from MCW:STYLE)?
 * Also, if it will be decided that bug titles should not be changed, how are we going to reference that from articles which include bug fix lists? --GreenStone (judge me) 15:59, 14 November 2015 (UTC)


 * See the archived discussion, particularly Munin's response.
 * You clearly didn't read WP:MOSQUOTE, didn't you?
 * This edit.
 * -BDJP (t 16:29, 14 November 2015 (UTC)


 * If we're treating the fixes as quotes, and applying WP:MOSQUOTE, that would require the use of attribution, sic for significant errors, quotation marks, "trivial spelling and typographic errors should simply be corrected without comment", and dispensing with typographical conformity – if that wiki rule is a rule we are explicitly applying in this case. MOSQUOTE doesn't seem to require as strict a character-for-character adherence as you have been advocating, if I understand you correctly, BDJP. For the record I think the standards of quoting in MOSQUOTE are better than a standard of precise quoting, as it would allow us to clean up garbage grammar, spelling, vagueness, etc. – though I'm not convinced that treating the fixes as quotes is the best idea. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 17:01, 14 November 2015 (UTC)


 * Adding to User Greenstone's first point: there is no precedent on this wiki for locking down editing on a particular type of content with the purpose of pre-emptively preventing edit wars. Our method of preventing edit wars is the same as on all wikis, as UG alluded to.
 * Adding to UG's last point, I agree that if we're going to apply a new rule to lock down titles, we ought to have a disclaimer in the page itself: "Titles and bug lists are quoted from the bugtracker which has separate editorial standards and workflow, and are not to be taken as accurate lists or descriptions of what was actually fixed in this version the game" or some such. Because as it stands, I can easily imagine that a person could put an unwarranted level of trust in what the 'fixes' section says. A person who understands to what level to trust a wiki, that it is a self-improving collection of community-edited articles, is not going to immediately understand that we have chosen to not improve this content, and there is a danger there.
 * As for referenceability, no-one is going to change the actual reference number of the bug. Problem solved.
 * As for the discussion about quotations, I think that is probably the strongest point of BDJP's in my mind, because of the lack of relevant guidelines on this wiki, though my solution would be this: Put a disclaimer at the top of the fixes section that makes it explicit that the titles are descriptions and not quotes from mojang.com. That would make it easier to add explanatory comments like, "this was partially fixed but only for birch trees" or whatever. That would be a way of getting around the 'quotes' thing: declare them as not quotes. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 16:33, 14 November 2015 (UTC)


 * Why is it bad for the wiki to be continually improved? If we lock down this, then why not just lock down the whole wiki from fixing grammar and spelling? That will really stop all those pesky edit wars we're apparently plagued with. This attitude seems generally anti-wiki.
 * Who says they're quoted from mojang.com anyway? There's no requirement to even use the issue tracker titles in the first place, they're just a good starting point and easier than writing your own. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 00:43, 15 November 2015 (UTC)


 * Apparently, Munin.
 * -BDJP (t 01:14, 15 November 2015 (UTC)
 * -BDJP (t 01:14, 15 November 2015 (UTC)
 * -BDJP (t 01:14, 15 November 2015 (UTC)


 * Well you did a good job of avoiding actually answering me. "Who says X?" is a rhetorical question. If you're going to take it as an actual question, it requires an authoritative source, of which Munin sadly isn't. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 11:34, 15 November 2015 (UTC)


 * No more than anyone else! Frankly, I assumed they were direct quotes because it boggles my mind that someone would not quote them precisely. On the other hand, while I stand by my previous argument, I don't actually care about this specific issue very much. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 21:03, 15 November 2015 (UTC)


 * Snapshot posts often have a list of fixed bugs. However, we don't leave the rest of the release notes unedited, especially when they're unclear or nonsensical. The Mojang blog posts are a good basis for version articles, but I don't see any reason to treat that text as sacrosanct and uneditable; I'd rather have the wiki be as accurate, complete, and understandable as possible. If someone wants to see the text of the original blog post, there's a link in the references. -- Orthotopetalk 01:17, 15 November 2015 (UTC)


 * The majority of the users who change the title's after their addition are either new users or IPs, basically the type who would be discouraged from editing from a revert of them correcting grammar, or don't really have plans for editing beyond that quick fix. The main edit wars I do see over this topic always start with someone reverting grammar changes, then it being reverted back, each time with summaries that make no sense to a new user as they have no idea why worse grammar is preferred.
 * Other than that and beyond echoing what Sealbudsman or Orthotope said, I only have two other things to state. Firstly, the titles don't always properly respect the issue. A great example if this is, where the title originally did not include "on smooth lighting", but was later changed as it was fixed on standard lighting. Then later it was closed in favor of separating the smooth lighting part to a separate issue, but the title never was reverted thus making it seem to a reader of the page that the smooth lighting issue was fixed.
 * Secondly, I think the titles are better off as a description than as a quote. A lot of times I read the snapshot pages wondering what was fixed, and I'd rather not have to click on every single bug report link just to understand what was actually fixed, instead just clicking on ones I want more information about. – KnightMiner  · (t) 03:36, 15 November 2015 (UTC)
 * I don't believe that fixes need to be quotes. Some users (like me) notice features while playing and do not use additional research, in which case there would be no quote. The BlobsPaper.png 02:54, 17 November 2015 (UTC)

GreenStone's analysis
As of now (15:25, 18 November 2015 (UTC)), I have analyzed the following approaches to the bug description problem:


 * 1) Disallow any modifications to bug descriptions. Mark all sections containing bug fix lists with a template which says that bug descriptions should not be edited.
 * Advantages:
 * This system requires minimal initial work for editors. Just copy the descriptions from the bug tracker or mojang.com, and mark the section with a "do not edit the descriptions" template.
 * This system allows to immediately identify any edit which modifies any descriptions as a violation of the style guide and revert it. If my understanding of the term "edit war" is correct, this will exclude edit wars as correctness of an edit can be immediately determined.
 * Disadvantages:
 * This system does not handle that bug descriptions on the bug tracker can be modified (they can be modified there, right?). Every edit which modifies descriptions must be verified by checking the bug tracker. See also: Rejected approaches, 1
 * The descriptions on the bug tracker are of various quality, ranging from perfectly fine to garbage. If we implement this approach, we'd be essentially telling editors "These titles may be garbage, but even if that is the case, you mustn't edit them anyway". How is that a good resolution to the problem? Also note that bad bug descriptions may force a visitor to read the bug tracker page in order to get an idea of what's fixed.
 * 1) Allow only minor edits to bug descriptions (such as trivial typo and spelling fixes as defined in MOSQUOTE), mark all significant errors with sic, and (probably) mark all sections containing bug fix lists with a template which says that major edits to bug descriptions should not be performed.
 * Advantages:
 * As rules of a language are not as dynamic as generations of wiki editors, this system is capable to both require a rather small amount of work while creating little opportunity for edit warring.
 * Disadvantages:
 * This still doesn't do much in cases of descriptions which are of very low quality and would in theory require major edits.
 * 1) Allow minor edits to bug descriptions, also allow major edits if and only if the description contains an insufficient amount of information useful to editors (so, for instance, "Redstone BUg" [sic] would be edited, but "1.5 Odd Mob 'Magnetized Attraction' behavior" would not be). Also probably a message template (yes, again).
 * Advantages:
 * This minimizes the number of major edits so that the edit war potential is minimal while the worst titles would be replaced.
 * Disadvantages:
 * Some rather mediocre descriptions remain and cannot be edited. Potential problems may occur when interpreting "insufficient" (and I have trouble finding words that would be less ambiguous).
 * 1) Full style guide compliance (so all minor edits are allowed and encouraged), and major edits may be performed whenever a description can be significantly improved. It may (not certain about this) be stated in the style guide that major edits are somewhat discouraged.
 * Advantages:
 * This is the approach which is closest to how the wiki generally operates. This solution also does not require any templates in the top part of bug fix sections.
 * This maximizes potential quality of bug fix descriptions.
 * Disadvantages:
 * This solution also maximizes the edit warring potential. I do not find it to be a significant problem. After all, have there been any wording edit wars on this wiki within the last 2.5 years?
 * This solution requires more work for editors than the other solutions.

My preferences are (in descending order) as follows: 4, 3, 2, 1.

Rejected approaches:
 * 1) Same as approach 1, but without updating bug descriptions. While even easier for editors, this is far less constructive in terms of "garbage that shouldn't be edited".

Please do not edit this analysis (if it needs to be edited, I will do that myself) and post your feedback below the horizontal rule.

--GreenStone (judge me) 15:25, 18 November 2015 (UTC)

This doesn’t look as good as the final analysis of the Shulker problem, but with the results. — Agent NickTheRed37 (talk) 17:13, 18 November 2015 (UTC)


 * Whether it looks as good as that discussion or not, thanks for linking it, it was enlightening and diverting. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 18:16, 18 November 2015 (UTC)

with approach 1 and approaches 2, 3 and 4. -BDJP (t 17:52, 18 November 2015 (UTC)


 * Any specific reason why you agree with 1 and disagree with all others? Is it just based on the advantages of the first and disadvantages of the rest? – KnightMiner  · (t) 23:27, 18 November 2015 (UTC)


 * "Is it just based on the advantages of the first and disadvantages of the rest?" Yes. -BDJP (t 23:56, 18 November 2015 (UTC)

Per my above comment, I with approach 4 (thus disagreeing with the rest). I see no reason the titles should be treated as quotes, as the only benefit to treating them as quotes is that they are the same as another website, of which the titles used on that site have no value as a quote (as said quotes are from members of the community just like the editors here). The titles may help slightly with identification, but that is really what the number should be used for. And yes, it is easier to start with the tracker's titles, but no one is forced to fix them when adding them, and there is no good reason to revert someone else's work if they decide to fix the titles up. This is a wiki after all, where the goal is to improve constantly. On a couple more specific points, the typos and formatting used there serve no benefit to the issue, so why keep them the same? Why preserve the mistakes? Also, the title is suppose to be a description of the bug or a summary of the issue, and if the description fails to describe the issue, what is the point of adding the title here at all? – KnightMiner  · (t) 23:27, 18 November 2015 (UTC)