Minecraft Wiki talk:Community portal

This is the community's main discussion page.

Talk about anything wiki-related here!

Sign your posts with, add new posts below others, and click "Add topic" above for new topics.

Note that this page is NOT for suggesting new ideas about the game. That belongs on the forums.

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

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

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


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

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


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


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


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


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


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


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


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


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

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

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

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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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

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

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


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


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


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


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


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


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

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


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


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


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


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


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


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

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

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


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

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


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

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

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


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


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


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


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


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


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


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


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


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


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

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

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

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


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


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

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


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

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


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

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

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

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


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


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


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

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

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


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


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


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


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


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


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


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


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


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


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


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


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


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

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

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


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


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


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


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


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

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

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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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