Minecraft Wiki talk:Community portal/Archive 17

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 .

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.  ( 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. – ᐸ  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! – ᐸ  17:14, 8 July 2015 (UTC)


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


 * . —  17:39, 8 July 2015 (UTC)


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


 * Nope, only here. – ᐸ  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. 「」· 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. – ᐸ  15:54, 11 July 2015 (UTC)


 * I will keep that in mind. Sorry if I overstepped a bit with contacting Game widow directly. – · 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. – ᐸ  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, 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. :)

– ᐸ  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). -- 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. –   undefined/undefined 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; &middot;  &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. – ᐸ  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. -- 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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. -- 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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. -- 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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). <span class="nowrap">「」· 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? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 06:25, 12 July 2015 (UTC)


 * It's working for me now, must've been my browser being stupid (as is its wont). <span class="nowrap">「」· 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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? <span class=nowrap>– · 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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 - ( 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? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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. —  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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 17:07, 18 July 2015 (UTC)

Moving transcludable metadata, video etc into their own namespaces
These transcludables 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...

—  18:16, 15 July 2015 (UTC)


 * Both methods have pros and cons. The multiple-namespace approach has been used for years on the 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. <span class="nowrap">「」· 19:06, 15 July 2015 (UTC)


 * . Even though I'm okay with it, the Video namespace is already used in Wikia. --<font face="Minecraft">  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). <span class="nowrap">「」· 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 to solve related issues with the random button. <span class=nowrap>– ·  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. —  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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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". <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  17:51, 18 July 2015 (UTC)

Template:Grid/Dispenser
There should be a template for the GUI. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. <span class="nowrap">「」· 16:47, 22 July 2015 (UTC)


 * Well, the dispenser can store LESS items than the inventory or chest. --<font face="Minecraft">  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.<span class=nowrap>– · 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. <span class="nowrap">「」· 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. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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? <span class="nowrap">「」· 18:25, 23 July 2015 (UTC)
 * I don't know, though it could be created later (if necessary) <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. <span class="nowrap">「」· 21:07, 24 July 2015 (UTC)

Splitting Windows 10 only updates into their separate pages.
<div style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">

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. -- 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 16:09, 4 August 2015 (UTC)
 * That seems like a good idea. -- 16:12, 4 August 2015 (UTC)
 * I've written up a sample in my workbench to display (see below). Opinions/suggestions are welcome.

-- 18:04, 4 August 2015 (UTC)
 * It's good. --<font face="Minecraft">  21:51, 4 August 2015 (UTC)
 * @ @ 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 ). -- 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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  01:52, 5 August 2015 (UTC)

Portal blocks
<div style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">

The result of the discussion was split respective portal blocks.

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


 * <span class=nowrap>– · 13:42, 5 August 2015 (UTC)


 * –  undefined/undefined 14:45, 5 August 2015 (UTC)


 * , although I thought it may get better to rename to, not . We should really use the “rename” term alongside “move” —  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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  11:52, 6 August 2015 (UTC)


 * The name was reported as a bug for Pocket Edition in, and subsequently confirmed and assigned by . -- <span style='font: 6pt Zaptino'>(+) 14:59, 6 August 2015 (UTC)


 * . - 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.  –   undefined/undefined 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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  11:52, 6 August 2015 (UTC)


 * Ah ok, fair enough. I still support the split as proposed. –  undefined/undefined 12:58, 6 August 2015 (UTC)


 * I . --<font face="Minecraft">  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? 16:44, 5 August 2015 (UTC)

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

@, 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. 01:11, 6 August 2015 (UTC)


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


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


 * Works on Wikipedia (Safari on iOS). <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 22:38, 15 September 2015 (UTC)

Beta 1.9 page
I think it may be a good idea to add more info to the 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. -- 21:08, 7 August 2015 (UTC)


 * It was released, it was just called . 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 . 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, on ). <span class=nowrap>– ·  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. -- 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 <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. <span class=nowrap>– · 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 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 of course) when it comes to information about where they graduated, what they graduated for, what jobs did they have before joining Mojang, etc. - ( 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. <span class=nowrap>– · 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. <span class="nowrap">「」· 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 ). <span class="nowrap">「」· 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. - ( 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 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.) <span class="nowrap">「」· 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. <span class="nowrap">「」· 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.
 * We can keep the pages as is and just add the template that I explained before.
 * -- 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:, which was about merging the windows 10 edition article with the pocket edition article, which end undecided, leading to no action. about splitting Windows 10 to its own articles, which ended with 0.12.0 being merged into 0.12.1.  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. <span class=nowrap>– · 20:09, 12 August 2015 (UTC)
 * For the template, this may be a good example: [snip] -- 20:36, 12 August 2015 (UTC)
 * @ I agree, except I believe the top should be like this: [snip] Note Windows 10 being under Alpha  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. <span class=nowrap>– · 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 has its versions split into separate pages, even though it is based/built of off.
 * 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:
 * would be restored to the revision before it was merged with the 0.12.1 page.
 * would remain unchanged, just with the removal of the 0.12.0 release early for Win10 and the removal of the Windows 10 stuff.
 * 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. -- 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.) <span class=nowrap>– · 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.  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. -- 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.  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. <span class=nowrap>– · 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.  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. - <span style='font: 6pt Zaptino'>(+) 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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  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. -- 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?  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, 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.
 *  (•) 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? -- 13:55, 16 August 2015 (UTC)
 * MarioProtIV@undefined Admins should approve this.   (•) 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? -- 17:29, 17 August 2015 (UTC)

Tagalog code
The currently uses the "ph" code. , this is a bit... strange, as the uses the ISO 639-1 code of "tl", which is what is used on  as well as. Anyway, I'm proposing 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). 00:46, 14 August 2015 (UTC)
 * , assuming your information is correct. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 01:35, 14 August 2015 (UTC)
 * I'm guessing whoever started the project mistakenly used the country code for the Philippines, whose official language,, 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. <span class="nowrap">「」· 07:01, 14 August 2015 (UTC)
 * Welp, I'll give it a day unless anyone has objections to say, and start moving stuff then.  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.  16:15, 17 August 2015 (UTC)

Thank button
Hey neat, when did we get a 'thank' button on the revision-difference page? –  undefined/undefined 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. <span class=nowrap>– · 20:02, 19 August 2015 (UTC)


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


 * How does it even work? <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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 for more information. <span class=nowrap>– ·  02:25, 21 August 2015 (UTC)


 * I thanked Majr for this edit, it seemed appropriate. =D <span class="nowrap">「」· 07:36, 21 August 2015 (UTC)


 * Such a good idea, thanks:)-Swawesome 23:47, 27 February 2016 (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., , , ), 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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">


 * I absolutely disagree. In some situations, referring to something in plural form as a whole in a title can be useful. —  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 singular but  plural, why is  singular but  plural, etc).  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  13:24, 21 August 2015 (UTC)


 * per NickTheRed37. - ( 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? –  <span style="-moz-transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">undefined/undefined 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 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). <span class="nowrap">「」· 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, I also am unsure about it, and even with my above definition it could go either way. <span class=nowrap>– · 01:41, 22 August 2015 (UTC)


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


 * With, 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, while most of the article does contain the list of particles, its focus is describing a particle to the player, similarly to . 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... <span class=nowrap>– ·  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. =) <span class="nowrap">「」· 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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  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 ), 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. <span class=nowrap>– · 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. <span class=nowrap>– · 14:33, 22 August 2015 (UTC)


 * These pages are about mechanics that have multiple types. Moving them would mislead. I think should be moved to Renewable resources. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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? <span class="nowrap">「」· 00:10, 23 August 2015 (UTC)


 * All of them. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 02:15, 25 August 2015 (UTC)


 * There honestly hasn't been any good counterarguments for these page moves. I think we should discuss whether should be moved to its plural title (I was unaware of it already being singular), whether we should move  to  and  to .  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  08:12, 25 August 2015 (UTC)


 * Blobs2@undefined Before you disagree with all of them, please note the 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 and  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  article above. <span class=nowrap>– ·  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. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  08:30, 28 August 2015 (UTC)


 * In that case, I would agree with keeping the current renewable resource title. <span class=nowrap>– · 14:40, 28 August 2015 (UTC)
 * Actually, I because that is how it is done with other articles (such as ). <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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 ? -  19:09, 2 September 2015 (UTC)
 * I'm pretty sure there's already an image called . Also, I'm not sure what you mean by uploading a file to a page. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. -  19:56, 3 September 2015 (UTC)

Catalan Wiki
Hello,

I would like to open a Minecraft Wiki in catalan language. I know, 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, -- 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! -- 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- 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. <span class=nowrap>– · 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! -- 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.  11:38, 9 September 2015 (UTC)
 * “Staff”? There’s no “editorial staff” as such on Minecraft Wiki, ! —  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.   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 :/ pl.Wiki Admin   19:19, 18 September 2015 (UTC)
 * Impossible. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 01:48, 19 September 2015 (UTC)

PE boats
There should be an image called. It would be used to show the boats in Pocket Edition on the page. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 17:19, 19 September 2015 (UTC)


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


 * I mean in the infobox. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. —  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. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. —  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. <span class=nowrap>– · 20:42, 20 September 2015 (UTC)


 * What is the MsUpload? <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 01:46, 22 September 2015 (UTC)


 * The "Drop files here" header on the editing screen. <span class=nowrap>– · 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? –Preceding undated comment was added at 01:49, 21 September 2015‎ (UTC). Please sign your posts with


 * <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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, ? –Preceding unsigned comment was added by ( • ) 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. is a good place to start.
 * The list of categories a page belongs to is automatically added. See also . -- undefined 03:18, 30 September 2015 (UTC)

Replace with
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. 22:53, 6 October 2015 (UTC)
 * Apparently, the red logo doesn't even exist. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. –  <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">undefined/undefined 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.   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? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 13:01, 9 October 2015 (UTC)


 * I believe we shouldn't change the logo, so it is not confused with the regular Windows version.   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 ( • ) at 1:35, 10 October 2015 (UTC). Please sign your posts with


 * Yes, they do. See . <span class=nowrap>– · 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. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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. <span class=nowrap>– · 22:24, 25 October 2015 (UTC)


 * Personally I would appreciate it. As it stands I am not usually aware of changes. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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. —  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 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? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 01:40, 31 October 2015 (UTC)


 * I this. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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. <span class=nowrap>– · 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. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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., , , , etc). But at least there's now consistency over the wiki on this though.  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  04:37, 1 November 2015 (UTC)


 * Applause! – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:42, 1 November 2015 (UTC)
 * <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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, 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? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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. <span class=nowrap>– · 03:11, 1 November 2015 (UTC)


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


 * , added to the style guide. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  07:06, 5 January 2016 (UTC)

Notch videos
We have some pages, like, 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? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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). <span class=nowrap>– · 00:57, 15 November 2015 (UTC)
 * Only use sources that are directly from Mojang (YouTube videos don't work). <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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, 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. - ( 15:21, 14 November 2015 (UTC)


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


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


 * If we're treating the fixes as quotes, and applying, 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. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 00:43, 15 November 2015 (UTC)


 * Apparently, Munin.
 * - ( 01:14, 15 November 2015 (UTC)
 * - ( 01:14, 15 November 2015 (UTC)
 * - ( 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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 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; &middot;  &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. -- undefined 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. <span class=nowrap>– · 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. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 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.

-- 15:25, 18 November 2015 (UTC)

This doesn’t look as good as, but with the results. —  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. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 18:16, 18 November 2015 (UTC)

with approach 1 and approaches 2, 3 and 4. - ( 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? <span class=nowrap>– · 23:27, 18 November 2015 (UTC)


 * "Is it just based on the advantages of the first and disadvantages of the rest?" Yes. - ( 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? <span class=nowrap>– · 23:27, 18 November 2015 (UTC)

with 4. I don't see any reasons why the bugs should be immune from the style guide/general wiki convention in favour of correct capitalisation/readability. Titles like "minecart name lost" and "shulker collision box" are incredibly vague and would benefit from some proper rewording and explaining further what the bug actually is. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 05:35, 19 November 2015 (UTC)

with 4, for all the previously stated reasons. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:44, 19 November 2015 (UTC)

with 4. – - 19:05, 25 November 2015 (UTC)

most with 4. I don't remember edit wars in this section ever having been a problem – people usually appreciate a constructive edit when they see it, and in case of difference of opinion there's no reason not to just figure it out on talk pages, that's always been the way. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 07:30, 28 November 2015 (UTC)

Currently there are 5 people in agreement with approach 4 and BDJP007301 siding with approach 1. If there are no more responses opinions from new contributors, I think we can safely side with approach 4 at the start of the new month. , is your objection to approach 4 purely due to your condition rather than its merits? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 03:53, 26 November 2015 (UTC)


 * Clearly, I would say it is due to the following disadvantages given in approach 2, 3, and 4:
 * Edit warring
 * Edit warring
 * Even more edit warring.
 * If you don't feel like you need to see my user page, let me just say that effective December 1, 2015, I will no longer be working on Fixes sections in protest of this unanimous decision to comply with the style guide in terms of "tracker titles". Personally, I feel like a couple of Mojang employees should also get involved in this discussion. I'll see if I can contact them on Friday. - ( 04:28, 26 November 2015 (UTC)


 * Then, in turn, why are you worrying about edit warring? If you are tired of it, then it is just a personal matter. —  16:32, 26 November 2015 (UTC)


 * The date is 2015-12-03. Do we need to wait a bit more? If not, can we start working on a draft? -- 14:49, 3 December 2015 (UTC)


 * I feel like there is now adequate agreement among the majority of users. Would someone care to draft something for the style guide on this matter? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  07:02, 5 January 2016 (UTC)


 * I've written up a draft below in . I figure it is best to be kept in the same discussion rather than branching off to a little seen talk page. <span class=nowrap>– · 15:38, 5 January 2016 (UTC)

Mojang's response
So, it appears has responded firsthand:

- ( 05:56, 27 November 2015 (UTC)


 * A couple things in response to this:


 * 1) I don't really see the need to get Mojang employees involved in this - the wiki is independent of Mojang and as such its editors should be the ones making the decisions. Other changes to the style guide have been made without Mojang intervention, so I don't really see why this needs to be an exception. Nonetheless, it is nice to see Mojangsters responding to the community and taking the time to potentially engage in wiki discussions.
 * 2) Grum's response here essentially agrees with approach 4 - "In reality only the ticketnumber matters." This implies that as long as the ticket number is same, edits can be made to clear up confusion and to "make them "understandable".  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  00:36, 28 November 2015 (UTC)

Proposed style guide addition
Seeing as most people agreed with 's fourth approach, here is it written up as a style guide draft, with a few related things added from earlier discussions. Feel free to suggest improvements. This text would be added to :

<div style="background: white; padding: 0.5em 1em 1em; border:1px solid gray;"> The titles on the bug tracker may be freely edited to comply with the style guide. While users are encouraged to fix the titles as they find them; fixing the titles is not required, specifically when first adding the issues. Editors may make major changes to the title (such as rewording the whole title), though this is discouraged unless the original title fails to adequately describe the issue.

It basically saying you don't need to go to every article and fix the issue titles or rewrite the titles as you add them, but don't stop someone else if they are doing it. It also says if you are rewriting to try and make the original wording work, but don't avoid rewording if the original title has problems. <span class=nowrap>– · 15:38, 5 January 2016 (UTC)


 * this addition. —  15:56, 5 January 2016 (UTC)


 * . – - 18:55, 5 January 2016 (UTC)


 * . – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 05:06, 6 January 2016 (UTC)


 * . <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  03:42, 18 January 2016 (UTC)


 * Sigh... . *Cries away in a corner* - ( 01:07, 7 February 2016 (UTC)

Name over player's head
Is there an article that covers this, including at what range can you see the name, what affects its visibility, etc? It didn't seem to be in. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 18:09, 25 November 2015 (UTC)


 * I don't think any article covers this at the moment, perhaps it might be useful to state this on player. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  03:49, 26 November 2015 (UTC)


 * It's mentioned briefly in, but a more thorough description would be worth adding. -- undefined 04:22, 26 November 2015 (UTC)


 * Someone else would have to contribute the info; I don't have the opportunity to play multiplayer much, to figure it out myself. I remember being able to sneak to hide, but I don't remember all the fiddly details. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 07:34, 28 November 2015 (UTC)

MinecraftEdu
<div style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">

The result of the discussion was '''that an article for the was created. Per the website's FAQ (here), MinecraftEdu is now officially an unofficial modification to the game.'''

As MinecraftEdu is official as proved here and here along with the MinecraftEdu website and the TeacherGaming website, it needs to be on the Wiki as it is an officially lisenced product. The topic was debated before however it could not be agreed upon if it should be considered as an official mod or an official seperate game. I believe it is a seperate game as it has seperate features from the regular Minecraft game and is branded as a seperate game (simaller to Minecraft: Story Mode) as shown on the MinecraftEdu website which says "MinecraftEdu is a school-ready remix of the original smash hit game Minecraft. Minecraft Education Edition - Bring Minecraft to the Classroom! We provide discounted Minecraft licenses to educational institutions, a custom edition of the game with features designed especially for classroom use, and a hosting service to let users connect and play together." Please vote if you agree that it should be changed considered as a seperate game or disagree, and believe it should be considered as an official mod. 21:56, 25 November 2015 (UTC)


 * for all the reasons stated above.  21:56, 25 November 2015 (UTC)
 * per KnightMiner's comments in the earlier discussion. - ( 23:28, 25 November 2015 (UTC)
 * It seems as if KnightMiner did not disagree in the end, after a better source was provided. Therefore what are your reasons for disagreement? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  03:39, 26 November 2015 (UTC)


 * In addition, I don't think the page should necessarily have special requirements such as not being discussed on other pages. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 03:39, 26 November 2015 (UTC)
 * Currently due to the ambiguous wording of the Mojang's response (I didn't realise this at the time), but am willing to agree if there is enough evidence.  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  05:42, 26 November 2015 (UTC)
 * Got better evidence https://twitter.com/mojangsupport/status/669915408816672768 17:38, 26 November 2015 (UTC)
 * As there has been no response to this for a month, I will consider this evidence sufficient to it being a seperate game if there is no response within a week.  14:29, 27 December 2015 (UTC)
 * I do agree it is official and believe it can have its own page. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  10:44, 28 December 2015 (UTC)
 * The tweet is inconclusive; due to the way it was phrased, it's unclear if Mojang is saying the MinecraftEdu product is official, or if they're merely saying that the @MinecraftEdu Twitter account is official. As previously discussed, the Mojang support page links to them only in the context of providing educational discounts, and says nothing about the MinecraftEdu product. At this point, I don't see any evidence that it should be considered a Mojang-supported product, rather than a third-party mod. If you want to convince me otherwise, get a clearer statement from Mojang. -- undefined 04:22, 26 November 2015 (UTC)
 * Got better evidence https://twitter.com/mojangsupport/status/669915408816672768 17:38, 26 November 2015 (UTC)
 * As there has been no response to this for a month, I will consider this evidence sufficient to it being a seperate game if there is no response within a week.  14:29, 27 December 2015 (UTC)
 * We really can't consider that evidence "sufficient" enough as there are three people who oppose it as such and one person who agrees it as such. You really shouldn't be disrupting this wiki to make a point. - ( 17:57, 27 December 2015 (UTC)
 * The evidence is sufficient, as it does not matter the number of people who agree or disagree as there is new evidence and there is a lack of response from almost everyone involved. Also not sure what your link has to do with this discussion as 1. Wikipedia rules do not apply on the Minecraft wiki (two completely different things.) and the article doesn't even talk about saying evidence is sufficient as there has been no comment denying so for a month.  03:26, 28 December 2015 (UTC)
 * Agree with Wolffillms. – - 03:36, 28 December 2015 (UTC)
 * I am not sure that this is point-y behavior; I can't identify any ulterior motive of the parties discussing this.
 * Anyway I agree that it is official and can have its own page because if you look at Wolffillms' second link here (the customer service page, not the tweets) it says that MinecraftEdu is the only such licensed non-Mojang seller of Minecraft. Whatever 'official' means, it seems to me that Mojang has set aside a unique specific legal agreement with MinecraftEdu.  If it doesn't currently fit nicely within what we can put in our wiki, I would be in favor of amending the rules.  To me it seems MinecraftEdu is the kind of thing that fits, and to include it doesn't appear to open a can of worms in any way because of how, on the page, it's stated that it's the only one of its kind. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 19:27, 27 December 2015 (UTC)
 * I believe that everyone now agrees that MinecraftEdu is indeed official (however this discussion has veered all over the place :p), however the current debate is whether MinecraftEdu should be considered a seperate game (simaller to Minecraft: Story Mode) or an official mod (in which case it would be a one-of-a-kind.) Either way I'm not sure that there would need to be an amendment of the rules to allow for an article on MinecraftEdu.  03:26, 28 December 2015 (UTC)
 * False. Claiming that everyone agrees that MinecraftEdu is indeed official is deliberately gaming the system. Heck, there are three people who are still in opposition to this. - ( 03:39, 28 December 2015 (UTC)
 * Again, we aren't Wikipedia. And 4 users agree. – - 12:47, 28 December 2015 (UTC)
 * I see.  Then I am not convinced we know whether it's developed as a separate game or whether we know it's a mod.  I still think it would be fine to give it a top-level page, given the special relationship indicated at the customer service page, and just stick to the branding language they use, e.g. 'school ready remix'.  I personally can't infer from their language exactly what it is. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 13:57, 28 December 2015 (UTC)

Education Edition
As stated on the Mojang blog today, it seems Microsoft has acquired MinecraftEdu, and will now develop it as an official Minecraft project. With that new information I now definitely see it as notable here. <span class=nowrap>– · 15:26, 19 January 2016 (UTC)


 * And with this fancy piece, MinecraftEdu is now officially unofficial. We can finally lay this discussion to eternal rest. - ( 21:54, 19 January 2016 (UTC)

1.8.8 -> 1.8.x
Could someone get a bot to change the version nav prevparent on 1.9 snapshot pages from 1.8.8 to 1.8.x? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:28, 9 December 2015 (UTC)


 * . <span class=nowrap>– · 02:06, 10 December 2015 (UTC)


 * Thanks! – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 05:10, 10 December 2015 (UTC)

Possible bug with my userbox
Hello. Why my userbox wrote that I had the experience of 0 days, but I'm here 0.9 years. Fix this bug, please. Happy New Year! Regards,   13:30, 26 December 2015 (UTC)


 * You are incorrectly calling gsd. All template parameters names must be lowercase, not capitalized at the start. Though really you don't need a userpage template for the age in days part when we have age in days which does the exact same thing. <span class=nowrap>– · 15:36, 26 December 2015 (UTC)