Minecraft Wiki talk:Community portal/Archive 26

Add "Did you know..." section
In this wiki there are many things that not every player knows, so adding a "Did you know..." section will:
 * 1) Provide readers with more facts about the game.
 * 2) Make the wiki more interesting.

Of course, the tone shouldn't be playful, just be like revealing a secret or something. I'm terrified of the playful voice on Discord already...

More information: This section is on the main page and will have something random to tell from the articles.

( | ) 12:10, 7 November 2018 (UTC)

Update: is my suggestion about the placement of the new section. ( | ) 03:16, 9 November 2018 (UTC)


 * We already have that section, it's called Trivia, and the wiki pages already tell all there is to know. –  12:18, 7 November 2018 (UTC)
 * I know, I know. I meant this section is on the main page. Sorry for not being clear... ( | ) 12:32, 7 November 2018 (UTC)
 * Oh. Well, that's a great idea!  –  12:40, 7 November 2018 (UTC)


 * Do you mean some (automated) semi-randomized message from a set of predefined messages, or more like a single message news feed that we manually populate? I'd rather like the former, would be a nice flair to the main page that isn't too much of a burden to maintain. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:57, 7 November 2018 (UTC)
 * There can be a queue that is fed several facts at a time and then the contents will be revealed one by one. ( | ) 13:03, 7 November 2018 (UTC)


 * I have implemented . Preview:
 * {| class="wikitable"


 * Did you know...
 * Did you know...


 * }


 * I would love if you have some facts to feed in.
 * ( | ) 13:20, 8 November 2018 (UTC)
 * Sounds good, and makes the main page more interesting. 05:32, 9 November 2018 (UTC)

Proposed to. ( | ) at 3h57:42 | 11/11/2018 (UTC)

Before adding this...
I wholly support this idea, but after seeing that it's been added to the editcopy and was syncing the editcopy to the main page, I noticed 2 major issues that probably should be addressed before adding it the main page. The first is that if we don't make any amendments, anyone will be able to edit the main page. Yes, indeed; all it takes is for some random IP to blank the DidYouKnow template and replace it with "poop" and the main page will have been vandalized. A solution to that would be to directors-only protect DidYouKnow and have an editcopy for it instead. Another problem is the fact that anyone can add anything to a trivia section of a page, even if it's false, and it may not get reverted before a curious user adds it to the DidYouKnow template. Therefore, there should likely be a requirement that all DYK hooks must be tested in the game if they involve in-game material before they're added to the template. However, I'm not sure if we should restrict this ability to certain users so that not just anyone can claim that a random fact is true. I also think that if it's a hook that requires a citation (e.g. a planned update), the article should have an official source supporting the claim in the hook.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:26, 23 November 2018 (UTC)


 * Protecting the template is the easiest solution, since the actual content is at . Of course, that page then needs to be at least semi-protected, maybe directors-only. -- undefined 17:15, 23 November 2018 (UTC)


 * Well, for that matter, and  should likely be directors-protected as well. These will still appear on the main page, regardless of whether they're a direct transclusion or not, so I really don't think we should be allowing any registered user to vandalize them. Perhaps we could have something like  or ?--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 17:19, 23 November 2018 (UTC)


 * >I really don't think we should be allowing any registered user to vandalize them
 * So we should only allow directors to vandalize them? 🙃🙃🙃 -- 17:22, 23 November 2018 (UTC)


 * If we have a director go to the, I think we'll be in a lot bigger trouble than this. :-)-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 17:24, 23 November 2018 (UTC)


 * Bump. Anyone want to comment on this?-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:18, 30 November 2018 (UTC)


 * I have no strong feelings on the proposal. As far as transcluding unprotected pages is concerned, though, I just added cascading protection to the main page, which will protect against that (though we shouldn't rely on it; pages should still be directly protected). 「」undefined 14:29, 30 November 2018 (UTC)


 * I don't think we should highly-protect the facts, because that means additions must wait in a queue and I'm worried that sometimes admin will even forget to pull the editcopy. Even without protection, the facts module hasn't been added facts and it will only survive to 4 | 5/12/2018 if no one cares about it. At most, the facts module should be extended-confirmed protected, so we can filter out potential vandals while still open it for dedicated contributors. ( | ) at 12h21:26 | 1/12/2018 (UTC)


 * There is no extended confirmed protection on Minecraft Wiki. -- 12:22, 1 December 2018 (UTC)


 * Correct. We shouldn't let anyone edit the main page if they can't edit the main page itself (which now it's impossible to do so anyways due to the cascading protection, which to clarify is a good thing). A better idea might be to get a ton of hook ideas before we even make this life so that the editcopy won't have to be edited to often.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 13:47, 1 December 2018 (UTC)


 * Unfortunately, an entry for November 6 in the News section uses the w template, a shortcut to the wikipedia template, so now that (in my opinion, totally unnecessary) template and shortcut are fully protected. If we're going to use the cascade option, shouldn't we ban the use of common unprotected templates on it? – ( &middot; ) 14:28, 1 December 2018 (UTC)


 * So we will have to parse manually? ( | ) at 14h37:16 | 1/12/2018 (UTC)


 * Hmm that is a concern. This means that if we add anything such as ctrl or code to the main page, the template will be only editable by directors. The thing is, that may be something we want. Should we really allow anybody to vandalize the main page using one of its templates? It is true that most vandals are probably knowledgeable enough with wikis to know they can do it; still, we shouldn't take risks, imo, so I support the cascading protection. Wonder if we could have a separate template that duplicates an existing template but is what we use on the main page so that the other duplicate template can still be editable by anyone? We've already done that for FrontPageSprite. For this particular case, we probably could just replace the w template with the bare coding, as it's a very simple template.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:47, 1 December 2018 (UTC)


 * Before I commented above, I did search the main page for any other templates that would be affected, and there weren't any. All other template calls on the page were already to protected templates. So I'm not sure it's a big problem. However, any director merging editcopy changes would need to look out for them, as would directors of other language wikis who frequently update the main page directly. (Incidentally, I feel like that's an abuse of their power in many cases. They aren't EN wiki administrators, and should only edit the EN wiki as registered users. But that's another topic.) – ( &middot; ) 15:06, 1 December 2018 (UTC)


 * DidYouKnow Lua error... -- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 15:36, 16 December 2018 (UTC)


 * I edited the module to have it display randomly chosen facts. -- 16:06, 16 December 2018 (UTC)
 * Also fixed a random formatting issue with the table, got rid of all template calls in the facts, and added a list of all facts to the documentation page. -- 16:28, 16 December 2018 (UTC)


 * Is it safe to add this template/module to the Main Page? It's been on the editcopy for a few months, and doesn't seem to have any formatting issues (though I haven't looked at it that closely). – undefined  23:35, 10 April 2019 (UTC)
 * I've synced the main page editcopy completely since it's been sitting there for half a year with no opposition. –  Nixinova sig1.png Nixinova sig2.png 07:33, 8 May 2019 (UTC)

Extra nominations
The original discussion on Discord (which led to this community portal post) included mentions of several other users who have been deemed potential candidates for admins. Of course, we can't really promote them against their will or against consensus, but I think it will be useful to get people's views on this matter.

The users mentioned (beyond Sonicwave32, who is the subject of the main topic) were:
 * (opted out)
 * (promoted by Majr at 05:39, 3 March 2019, see below)
 * (promoted by Madminecrafter12 on 8 May 2019, see below)
 * (opted out)
 * (see below, would be fine with being an admin but has found little time to contribute)
 * (does not use talk pages for personal reasons and sadly seems to have stopped editing as well)

Their opinions on their nominations, as well as the opinions of other users on their nominations, are welcome. -- 15:58, 23 November 2018 (UTC)


 * I'm not quite clear; is this a general thing where we just provide informal input? Is this a reaching-a-consensus thing? Or are we just asking these users if they want to be an admin for now, without any outside input?-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:22, 23 November 2018 (UTC)
 * I intended this to be a typical nomination. Just as the one above. With the intent to reach consensus. -- 16:26, 23 November 2018 (UTC)
 * Shouldn't we ask people if they actually want to be an admin before a typical consensus nomination?-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:26, 23 November 2018 (UTC)
 * Well, we won't actually promote anyone unless/until we get a "I'm fine with being an admin" from them. -- 16:29, 23 November 2018 (UTC)
 * I suppose that works, but I still don't necessarily think it's fair to present these editors to the community and allow everyone to scrutinize their behavior and find reasons why they may not make a good admin, without even having their consent.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:31, 23 November 2018 (UTC)
 * Do you want to insist other users shouldn't comment on a nominee unless/until they confirm the subject is willing to be an admin? -- 16:34, 23 November 2018 (UTC)
 * I have no issue with a subtle comment, like what we did on Discord for Sonicwave, but you specifically said that this is a consensus thing. Some people may not want to be formally nominated and discussed by the community.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:38, 23 November 2018 (UTC)
 * I didn't really say we should start seeking consensus right now. And it is actually a somewhat casual comment. But I think a resolution would be desired. -- 16:46, 23 November 2018 (UTC)
 * Oh, so you're thinking just present them here and wait for them to accept or decline the nomination, and then we can start supporting or opposing while providing reasoning of course? That could work. FVbico's the only one who's accepted as of right now.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:48, 23 November 2018 (UTC)
 * Yes. -- 16:49, 23 November 2018 (UTC)


 * For me, I don't particularly mind it being brought up in this manner, and don't mind any scrutiny it might invite. So, thank you, but I should be up-front:  I don't find myself having much time for this project and this community, these days.  I haven't opened Discord in many weeks.  I would be unresponsive to things that need to be done here, and would be perennially out of the loop.  If that doesn't disqualify me, well, I would accept the permissions, and do my best, as I'm able, because you all are amazing and great and I've had a great time here. –   |  16:47, 23 November 2018 (UTC)
 * I think you're a great editor, have excellent judgement, and have a nice, mature temperament; those are definitely great qualities for an admin. You don't have that much experience in admin-related areas, however, although you have tagged some pages for deletion months ago. For admin candidates, I generally want to see decemt knowledge of when to block vs. protect, block lengths, etc., but that would mainly be true if blocking/protecting is an area you plan on being involved in. If you were to be an admin, do you have specific areas in mind which you would work in? That will likely help me out a bit when trying to decide my position here. I doubt I'd outright oppose you, but if I do, please don't take it as anything personally.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:55, 23 November 2018 (UTC)


 * I personally don't think I have enough time to be a full admin on the wiki; I already do a lot of work on other things (e.g. the bug tracker) and I don't think I have time to take on more responsibilities. (However, my situation might change in the future; I'm not 100% sure). --  01:29, 24 November 2018 (UTC)


 * I'm grateful for the nomination, but in-line with my previous statements (including on discord) I don't want to be an admin. Sorry. I don't want the responsibility, and I'm planning on tuning down my activity. If it were the case that I need to be, I'd be willing to accept, but I don't think this is the case. I only have a limited timespan of focus, and sadly I'm running out already... – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:46, 26 November 2018 (UTC)


 * and since there's no word of you two yet, I'm just going ahead and ask. Do you accept being nominated for admin?   13:59, 1 December 2018 (UTC)


 * I don't think Nicolerenee could be an admin, as she's not going to use talk pages for her private reasons. I think she may be a good admin, not personally voting against, but in this state she can't communicate on the wiki (or even post her opinion here). – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:09, 1 December 2018 (UTC)


 * Yes, I do accept being nominated. I've been editing for over 5 years now and I think I have a good idea of how this wiki works. One thing, though: I edit a lot on mobile, and the mobile view hides the 'undo' and 'revert with edit summary' buttons, and it's annoying to have to switch between mobile and desktop view. Can that be fixed? –  Grid Book and Quill.png Grid Diamond Pickaxe.png 18:10, 1 December 2018 (UTC)


 * I don't think there's a fix for that other than wait for the developers to address the issue, which may not even happen. -- 18:34, 1 December 2018 (UTC)


 * Bumping, this discussion/evaluation has been open for a long time, yet there's only like 4 people who responded at all.  21:52, 28 January 2019 (UTC)
 * Considering the bad reputation the Minecraft Wiki discussions have (for a good reason) I'm not planning on contributing to it. Are there any objections from you regarding the nominations? I admit that activity on the extra nominations is rather low but at the same time there were no opposes and I know many people saw this discussion 10 times already.   14:51, 20 February 2019 (UTC)


 * The lack of participation is the root cause of discussions not going anywhere, so that isn't helping. As for nominations, I figure it's appropriate to fill in a replacement for dinoguy, but I'm not active enough to have a strong enough opinion to pick someone myself. – ᐸ  10:57, 21 February 2019 (UTC)


 * Oh well, in this case I guess we are heading for discussion to die. Note, I'm not blaming anyone, just a bit disappointed that discussion ends this way.  11:59, 21 February 2019 (UTC)


 * So, what do we do now? Nothing? Give admin (looking at the little opposes)? Add a notice to the wiki’s main page?  17:32, 23 February 2019 (UTC)


 * Both FVbico and Nixinova have been promoted to admin now. Consider this discussion completed/closed now; considering how old this is, any new nominations or comments about adminship in general should probably go in a new section. Thanks to everyone who helped bring these discussions forward.-- ( 02:21, 8 May 2019 (UTC)

FVbico for admin
The result of the discussion was Promote.

Vote and voice concerns about FVbico here.


 * (Just for clairity) I already stated I have no objections to being nominated above.  16:14, 23 November 2018 (UTC)


 * The reason I haven't responded yet to FVbico's nomination is because I've had to spend some time thinking about it. It's a tough decision, but I'm going have to go with an, with much regret. (I support now) First of all, let me make this clear; FVbico is an excellent editor, a very hard worker, and most definitely one of the most active users we have here, so I don't like having to oppose him, but I do have some concerns that make me unsure about how he would use the administrative tools. In particular, there have been quite a bit of edit warring issues, most notably as follows: , , and , of which a few times rollback was used without any kind of edit summary (though most of the time undo was used instead or rollback with a summary, which is a good thing); using rollback w/o summary to edit war is really something that should never happen. I also have a few concerns about possibly . Working with newcomers is very difficult and saying one thing wrong can make them never want to edit again; they are even more likely to get scared away if it's an admin who says the wrong thing – although adminship really is no big deal, newcomers don't know this. An example is ; for a newcomer acting in , you shouldn't command them to do something by using multiple exclamation marks. Some other problems with civility (that are not targeted towards newbies) include here and more severely here; it is true that the second one was several months ago, so I am a bit more lenient about that one, i.e. that alone would not be a reason for me to oppose. I am a bit concerned about deletion tagging as well. , , and were tagged for deletion by FVb, despite being common alternate names and very plausible search terms; this makes me a bit unsure about how they'd do with the delete button. I also have some minor concerns of inappropriate rollback use, but I'm not one of these  for adminship requests who opposes for a few tiny little single mistakes, so that alone definitely wouldn't be a reason for me to oppose. :-)
 * I'm sorry I had to oppose, as FVbico is clearly a very helpful editor. However, these concerns are just too much for me to be comfortable giving him my full support for adminship. This is definitely not a "never" thing, just a "not quite yet" thing; if FVb keeps up the good work for several more months, addressing these concerns clearly and without having new concerns pop up, I see no reason why I shouldn't fully support him for adminship. If any of the community wishes to post a reply to my comment, I'd appreciate if you could do so here rather than on, for the sake of transparency and keeping all discussion in one place. But do try to stay civil. :-) Best of wishes, -- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 03:32, 28 November 2018 (UTC)


 * “of which many times rollback was used without leaving a summary”, um what? The histories you linked I provided a summary for all rollbacks/reverts; with maybe 1 or 2 exceptions...
 * On the other points, yes I do have some anger management issues (partially related to past experiences with certain parts of the community) and am trying to correct that, but I don’t always succeed in it. Sometimes things are really frustrating, even here, and that swaps over to anger quickly to me. Which causes my more hostile behavior (the biting and editwarring).  08:25, 28 November 2018 (UTC)


 * There have been quite a few times where rollback was used without leaving a summary (when edit warring it's generally accepted that you always should) but you're correct that most of the time you did leave an edit summary, so I've modified the wording a bit. Thanks!-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:15, 28 November 2018 (UTC)


 * I hope I'm not being indiscreet to bring this up., your sudden and angry departure from Mojira a few months ago after what seemed to me to be a highly defensive response to criticism and attempts to calm you, worries me. I was not directly involved in that incident and don't have an opinion on whether you were treated unfairly or whether your leaving was an overreaction, but it saddened many of the other moderators and helpers and was generally disruptive. You and I have never had a conflict, but I can't help but be concerned by that incident. Do you feel you've learned enough from it that you can confidently say your anger wouldn't steer your exercise of administrator authority? And in the event that it does, will you be able to gracefully accept constructive criticism from the other administrators? Those are genuine questions, not wishy-washy expressions of doubt. I feel that your passion can be a great asset, provided you keep it harnessed and use it positively. So I'm asking for your honest self-evaluation: Are you ready to be an administrator now, or would it be better to wait until you've had more opportunity to practice self-control? – ( &middot; ) 15:07, 28 November 2018 (UTC)


 * Leaving mojira was something I thought abaout MANY times before that, and it was (justified) distrust towards others that drove me away, not the critisism. I won't work with people who go talk crap behind my back (those who did, and read this will know that I'm referring to them), such as calling me asshole, or even putting other people against me. Additionally, aside from the distrust, I was being portrayed as villan (regarding MC-123456) because "of a joke", while I asked over a douzen times to not do that, yet people continued. In general, it was not a spontanious thing, but something brewing up over the last couple of years. I'm fine with critisism (if it's actually constuctive), and I have not actually abused any administrative powers before (aside from the last action I did on mojira, to try and get people to stop portraying me as villan, non-mods couldn't even see what I did).
 * FYI, I have no intent to return to mojira, and have been trying to forget it.  15:54, 28 November 2018 (UTC)


 * Well, in case it wasn't clear already, I firmly believe FVbico should be promoted. He would make a fantastic admin!  01:00, 29 January 2019 (UTC)
 * 2 months since November went by and I haven't seen any new concerns regarding FVBico, looking through his contributions he is on the wiki daily, active both in the community (by doing patroller requests, his and active on MCW Discord) and on the wiki from the content side. His knowledge about game is exceptional and he is a great contributor. As I said in the past, I find Mad's concerns valid but very nitpicky. Those were single exceptions from the rule, ones that I think he improved upon. I do believe he should be given a chance.  have you changed your mind for 2 months or do you need several more? I'd hate to see this discussion die like that, especially when I see someone who actually would fit into an admin.   23:58, 9 February 2019 (UTC)


 * Still oppose from me. On Discord he said that this was a moderator nomination. How dare he not recognize a difference between admin and moderators?!? That means he thinks that he's going to become a moderator. Wth? Mods aren't even on this wiki anymore. Remember, we're moving them to the Ftb wiki. So he's probably going to create a bunch of mod pages and then delete everyone who doesn't create mod pages and block the main page and protect Curse... what was the question again? -- ( 00:23, 10 February 2019 (UTC)


 * Ok serious reply: Thanks for the ping. I definitely feel like FVb's behavior has improved since my oppose, I've been seeing a lot less edit warring and a lot kinder demeanor to other users, particularly new ones. I do not think my concerns were nitpicky, however; they were absolutely stuff that would be concerning were FVb were to be admins. But again, that's in the past now and FVb has taken the feedback well since. Well, anyways, it's late and I'm tired and I want pizza so I'll take a bit more time to think on this, but I'm leaning towards a support right now and I certainly don't think I would oppose anymore. Taking the feedback of others is, imo, one of the most important qualities for adminship, and FVbico has proven to have that. :)-- ( 00:26, 10 February 2019 (UTC)


 * now. Admin actions can always be undone and FVb seems to be good at taking feedback, considering how much he's improved since my oppose. So, support from me and best of luck if you do get admin. I do wish this discussion could come to a resolution some way or other, whether the outcome is made to promote FVb or not. I agree with Frisk that it's sad to see this go absolutely nowhere.-- ( 18:01, 22 February 2019 (UTC)


 * Well doesn't seem like there's much community interest in whether or not more admins are promoted, so the few supports we have so far will have to do for consensus, so closing this as approved. (I support having another admin to replace dinoguy for what it's worth.) – ᐸ  05:39, 3 March 2019 (UTC)

Nixinova for admin
The result of the discussion was Promote.

Vote and voice concerns about Nixinova here.


 * I think this discussion is a bit old but I have no objections to being nominated. –  Grid Book and Quill.png Grid Diamond Pickaxe.png 03:54, 17 December 2018 (UTC)


 * I don't really have any objections to making Nixinova an administrator, from what I saw there’s nothing wrong with any of the actions made.  22:05, 17 December 2018 (UTC)


 * If you were to be an admin, what admin-related areas would you be involved in? E.g., would you patrol recent changes and block users when necessary? Patrol ? Perform fully-protected page edits, such as to high-traffic templates and the main page? This would be helpful for me to know before having an opinion. Thanks!-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 18:42, 18 December 2018 (UTC)
 * I patrol and revert on recent changes currently, so I would block users making blatant vandalism, I think I would probably patrol pending deletion (if there aren't too many pages in it). –  Grid Book and Quill.png Grid Diamond Pickaxe.png 19:04, 18 December 2018 (UTC)


 * (Bump) –  Nixinova sig1.png Nixinova sig2.png 18:04, 22 February 2019 (UTC)


 * I'd support the promotion. -  10:56, 3 March 2019 (UTC)
 * 11:22, 3 March 2019 (UTC)
 * 02:51, 4 March 2019 (UTC)
 * 20:08, 25 April 2019 (UTC)
 * No real objections from me; the only minor thing is that there are a few rollbacks that I would personally prefer to leave an explanation on (e.g. and ). I understand that mobile view doesn't allow you to leave explanations on rollbacks though, and aside from that I have no issues. – undefined  23:35, 10 April 2019 (UTC)
 * The former rollback was because I misread what they added (I went back and fixed on in the next edit) and the latter was because they were adding download links to a fake version. –  Nixinova sig1.png Nixinova sig2.png 06:43, 16 April 2019 (UTC)
 * That rollback issue is now fixed. –  Nixinova sig1.png Nixinova sig2.png 20:21, 25 April 2019 (UTC)


 * Not only is Nixinova very active, but also from what I've seen of him on the Minecraft Wiki Discord server (since I joined recently), he seems to be well involved with this community and to have the right temperament for serving as an administrator.
 * I'd also point out that this discussion seems to have run its course and has reached an obvious and definitive consensus among those members of the community who are active and willing to share their thoughts here, and there has been no substantive opposition. So I'd call for the closing of the discussion and the implementation of the promotion forthwith.  &#8212; &#124; 06:46, 27 April 2019 (UTC)


 * This discussion has gone on for nearly half a year now and I think there's a pretty clear agreement to promote, given that many experienced users have given well-reasoned support and there has been no opposition. I've interacted with quite often and I haven't noticed any major issues that would prevent me from promoting him; however, I would recommend for him to try to leave edit summaries with clear reasoning for almost all admin actions he may perform in the future, as I have noticed that sometimes he would leave inadequate or no explanation for potentially controversial edits . Putting nitpicks and personal opinions aside, like I said there's a solid consensus to make Nixinova an admin; therefore, I have gone ahead and  him the administrator role.-- ( 02:07, 8 May 2019 (UTC)

Split PlayStation 4 information
Now that PS4 is the only console being updated, I've changed the exclusive, history and only templates to support the "ps4" param. Since ps4 is going to be the only thing in from now on, should the 1.83 and 1.84 (and future) updates be their own pages? Before we didn't split LCE because we didn't know what the pages should be called; now that's no longer than case as ps4 is the only edition being updated. –   22:02, 27 December 2018 (UTC)


 * See . –  Grid Book and Quill.png Grid Diamond Pickaxe.png 22:10, 27 December 2018 (UTC)


 * I also think that LCE updates articles can be spilt into individual articles, In categories of every editions, such as Xbox 360 Edition TUxx (instead of Legacy Console Edition TUxx / CUxx …) -- 06:22, 28 December 2018 (UTC)


 * , but only for the PS4 Edition instead of all editions. - ( 11:19, 28 December 2018 (UTC)

From my perspective, I think that should be categorized and split to solely PS4. Another solution is to create a new page specialized for PlayStation 4 Edition.--  16:37, 31 December 2018 (UTC)
 * . But what should we do for the, should we keep it in its current form? 2. Should we name the updates "PS4 1.x" or "Patch 1.x"?


 * . There's soo much confusion between the many versions and editions. Some of my edits been shut down by users that are concerned with PC versions of Minecraft. Personally, I feel that the PC Minecraft Community is ruthless!  12:35, 14 January 2019 (UTC)


 * - I'd split every single console's information, even if that would result in a lot of duplication. -  11:22, 15 February 2019 (UTC)

Redirect PlayStation 4 Edition 1.82 etc. to
Just a suggestion. What do you think? Note that these redirects will take the form " ". -- 11:03, 6 January 2019 (UTC)

Issues pages: keep them or delete them?
Argumentation taken from the Discord server: [19:57] on topic: why do we still have all the Issues/ pages around? they’re all either fixed, invalid, WAI, or reported to mojira These pages annoy me too, given they're a lot of red links and template transclusions and are nothing but barely used archives...

Should we delete the issues pages now? Do we keep them available for readers for some time? For 1 year? 10 years? Until October 23, 2077? Until the heat death of the universe? -- 15:24, 6 January 2019 (UTC)


 * They're a historical record, though I don't know if anyone particularly cares about them, nor how much value they actually have as a record. I would be sad to see them go, but wouldn't really oppose deletion. Though if it would be sufficient to address some of the complaints (e.g. by cleaning up the redlinks, or maybe moving the whole thing into the project namespace), I would prefer they be kept. 「」undefined 15:29, 6 January 2019 (UTC)
 * I think it has interesting historical value but they don't really need to be in the mainspace so maybe move into MCW:? –  Nixinova sig image 1.png Nixinova sig image 2.png 18:40, 6 January 2019 (UTC)


 * I would support moving them into project namespace and agree that they may be useful/interesting for historical context (e.g. old talk pages), though I don't have any strong arguments against deletion either. – undefined  20:21, 6 January 2019 (UTC)


 * I think they should be kept around for historical purposes, since sometimes they're useful for context on what changed (I've dug into them once or twice when looking at changes in old versions). It's strange that they're incomplete around beta -- why only beta 1.5 and beta 1.8.1, and not the various 1.7 builds for instance?  Did those once exist and get deleted?  Did they never exist?  I don't know :/.  I do support moving them to the MCW namespace, though, and probably treating them the same way as old talk pages.  --  20:29, 6 January 2019 (UTC)


 * Without checking where in the timeline of the issues pages those versions fell, towards the end (I think after the bugtracker was started, though I've never been very clear on when exactly that was) some issues pages were created but never actually used; some time after we stopped allowing people to use the issues pages for reporting new issues, I went through and deleted the pages that had never had any actual bug reports. So the gap you noted may be that. 「」undefined 20:57, 6 January 2019 (UTC)


 * Should I go ahead and move them into the MCW namespace? I've been converting all the links to static so they dont show up in special pages. –  Nixinova sig1.png Nixinova sig2.png 21:18, 10 May 2019 (UTC)


 * I would support moving them into the MCW namespace as well and could help you out with doing so. I do think we should leave a redirect from the page (but none of its subpages) just so it can be found easier considering it's been like this for so many years - one of those rare cases where a mainspace to project namespace redirect might actually be useful. -- ( 21:23, 10 May 2019 (UTC)


 * Never mind, it looks like the redirect was modified to point to  instead. Well, either way I've added a hatnote on the Bug tracker page linking to, and would suggest to continue to have such a hatnote even if the issues pages are moved into the MCW namespace.-- ( 21:24, 10 May 2019 (UTC)
 * Moved to and . –  Nixinova sig1.png Nixinova sig2.png 23:00, 10 May 2019 (UTC)

List of blocks and items
On the list of s and s, I want to get rid of most or all of the subsections and replace them with one big alphabetical list. I think some of the subsections are unnecessary and complicated, and I never know what to do with things that fit in multiple subsections. Some other subsections, like education edition only or removed blocks/items, might be worth keeping. 04:12, 11 January 2019 (UTC)

Fixed-width notice boxes
Other Gamepedia wikis use amboxes which have a fixed width. I think what we have currently is quite annoying, especially if you have many boxes on top of each other. This is a common sight on new pages and is quite an eyesore:

–   03:34, 17 January 2019 (UTC)
 * I wrote for the Russian wiki to address the issues I see with message boxes. You can see two these templates on  (look for the two orange bars in the top of the page). Would that be a better option? However, if we go that way, we'd need something like small icons for different editions to replace the exclusive template images... and I sense the edition icons could be useful in so many ways... --  04:12, 17 January 2019 (UTC)


 * To be honest, I think the fixed-width ones do stand out more, which is what they're there for. What exactly is annoying about them? Is it the irregularity, the aesthetics? – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:09, 17 January 2019 (UTC)


 * They take too much space and use it suboptimally – that's my biggest concern. And centering of text makes them hard to read. The boxes need to stand out indeed, but that doesn't mean they need to stand out as much as possible (you'd agree red boldcaps on green background is not going to happen, right?). -- 10:14, 17 January 2019 (UTC)
 * I'm thinking more of Amboxes which don't take up 100% of the width but still look good. –  Nixinova sig image 1.png Nixinova sig image 2.png 18:55, 17 January 2019 (UTC)
 * Even that would be better than what we have now. -- 20:43, 17 January 2019 (UTC)

Reduce the number of gigantic tables on the wiki?


All of these are examples of huge tables. Such tables are problematic for mobile users or users with lower-resolution displays, and the tables tend to use space suboptimally in all cases. It should be possible to replace most if not all such tables with design elements not having these issues. Are there any suggestions regarding such changes? -- 12:54, 17 January 2019 (UTC)


 * I personally would support a "tabbed" design for the History template; this would not only conserve space, but one thing that annoys me greatly is that the version column appears to always stick with the same width across all different editions, leading to unnecessarily wide stretched version columns which crowd out text next to them (this is especially the case for console edition features, as well as features implemented in Java Edition 1.0.0). I have a few other ideas pertaining to the History template; I can elaborate further if desired. -  13:29, 17 January 2019 (UTC)
 * I personally like the History template as it is but the others definitely need reconsidering. –  Nixinova sig image 1.png Nixinova sig image 2.png 18:54, 17 January 2019 (UTC)


 * , which only lists Java Edition versions. I'd keep each edition in a separate table if possible, and use the tabbed system I proposed above. -  11:30, 20 January 2019 (UTC)


 * ...but before we implement a tabbed system, I'd prefer it if each edition were split into its own table/template, similarly to how the German wiki currently handles it. -  13:12, 5 February 2019 (UTC)


 * for flattening, for the rest.  The flattening article really doesn't need to be read by hand and really isn't applicable if on a mobile device, since it's mostly just data without analysis.  I don't think it's worth investing time in making it easier to read, since the main use for me is with control+F to find a specific entry.  --  16:50, 20 January 2019 (UTC)


 * making large tables easier to navigate. Another large one is n . It had been talked about in the past to make parts collapsible but never really went anywhere. I would suggest making all large tables collapsible. For some of the particularly long ones, they take a while to scroll past. If a user was not interested in the table but instead wanted to read the article, it could save time to collapse it, especially if they needed to go back a forth referencing material. –Preceding unsigned comment was added by ( • ) at 22:01, 20 January 2019 (UTC). Please sign your posts with


 * Mobile view doesn't have collapsibles and is intended exactly for those devices most likely to have problems with large tables. -- 05:13, 21 January 2019 (UTC)


 * That's interesting, it seems like that would be especially helpful on mobile. It does appear mobile can collapse sections, so at least that can help a bit. The tables look really bad in mobile portrait orientation though and collapsing doesn't help there.  03:29, 23 January 2019 (UTC)

McEdu
Hi ! I made a few edits on the wiki, mainly about McEdu : I'm quite new around here, so feel free to discuss them and perhaps made more edits if what I did wasn't accurate according to your own self. PS : Sorry for the aweful ID. -- 16:23, 17 January 2019 (UTC)


 * Hi ! From what I can see, your edits look constructive and helpful. However, please don't be offended if someone else reverts them; this happens a lot and it's nothing to take personally, some of my edits are reverted from time to time. If you'd like to change your username, fill out this form and specify that you're requesting a username change and what your requested new username would be. Your username was probably automatically changed to the current because you didn't consent to the account-name retaining for the Gamepedia/Wikia merge thing, so your username was changed to a random string of numbers to comply with the (I can explain that in more detail if you'd like). Thank you for contributing to the wiki and I hope you continue!--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 18:44, 17 January 2019 (UTC)
 * Thank you very much. I hope I'm not making any mistake by trying to correct some...  --  13:01, 18 January 2019 (UTC)
 * Yep, that edit was useful. The other two links were also incorrect; I've fixed those too (by checking version_manifest.json and then the relevant JSON file from there, but most people don't know that exists).  Thanks! --  17:13, 18 January 2019 (UTC)

Are fixes summaries quotes?
In the fixes section on snapshot pages, is each individual bug fix a quote? So should grammatical/spelling fixes be marked with square brackets? There's not really a guideline for this. –   22:03, 18 January 2019 (UTC)


 * There is. says the following:


 * The titles from the bug tracker issues 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.


 * So no, they're not necessarily quotes and grammatical/spelling errors should be fixed, at least based on what the current style guide says.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 22:08, 18 January 2019 (UTC)


 * My thought is, no, using the square brackets is definitely not necessary (however, I am a bug tracker moderator and I have the power to actually edit the issue titles directly, though generally I don't bother with grammatical issues). And of course, adding links to commands and code formatting and such is sometimes helpful, though also probably not necessary most of the time.  The  is mostly me being pedantic, but I still think it's correct (they are titles, not complete sentences). --  18:36, 19 January 2019 (UTC)

Move Bedrock Edition version pages to their ".0" title
The version number both on the Feedback site and in-game display "1.x.0", so that should be the names of each page. –   20:15, 16 January 2019 (UTC) Ping – 04:41, 24 January 2019


 * based on above reasoning. – undefined  03:32, 2 February 2019 (UTC)
 * 1.8.0 has been moved to that title. Should the rest be? 1.9 and 1.10 should definitely be moved. Has the ".0" been included all the way back to 1.1? –  Nixinova sig image 1.png Nixinova sig image 2.png 03:35, 2 February 2019 (UTC)
 * I've moved 1.4–1.7 to their ".0" title. I can't confirm 1.9 and 1.10 as they aren't out yet but will probably follow the pattern. – a, 04:29, 2 February 2019 (UTC)
 * Someone now needs to go through and replace "parent=1.x" (or "snapshotfor=1.x") with "parent=1.x.0" and then move the "Bedrock Edition 1.x builds" categories. –, 04:38, 2 February 2019 (UTC)

Outdated pages belonging to translation projects - what do?
Right now, it seems like there exists a particularly large amount of pages which belong to certain translation projects. While I do not oppose translation projects (despite what it may seem), I've noticed that a sizeable chunk of such pages that still exist have received little to no attention actually regarding either translating the page ( - 22:45, 23 January 2019 (UTC)) or keeping the information on said page up to date. As a result, it seems that a lot of the information provided on the pages can be potentially quite dangerously out of date (up to seven years plus), which obviously is not a good thing for a site striving to provide up-to-date information. I think it might be in our best interests to outright delete some such pages - that way, if someone eventually does come along and wants to translate the page again, they can do so without the risk of spreading information potentially almost a decade out of date.

Personally I think we should delete translations that haven't been updated since January 1, 2016 or earlier - that sets the threshold at just about the late pre-1.9 era. We'd exclude maintenance edits to fix up things like redlinks and images, since those obviously aren't updating the textual information provided in the article. Any other proposals? -  16:53, 23 January 2019 (UTC)


 * , I find the OP's argumentation satisfactory. -- 18:17, 23 January 2019 (UTC)
 * Nuke them all. I find it very annoying having so many of these outdated pages cluttering everything. –  Nixinova sig image 1.png Nixinova sig image 2.png 19:04, 23 January 2019 (UTC)
 * Some months back I brought this up in Discord or Slack, but people at the time argued against it. Needless to say, I'd be quite happy if this proposal passes; there is no point in keeping "translation" pages that are just X-year-old copies of random articles that were never touched after being copied (there's also no point in keeping these pages with some translation work when the content is grossly out of date). In all cases, a prospective translator would have to recopy the current article anyways, and doing that with a redlink is less effort than having to first determine if the content of a preexisting translation subpage is up-to-date. 「」undefined 21:21, 23 January 2019 (UTC)

I've marked several old translation navbox templates for deletion; these have never been updated since the 2016 cutoff, some of them aren't 100% translated, they are quite outdated (one stretching back as far as when 1.3 was still in the snapshot stages) and they are EXTREMELY major offenders on (constituting well over three quarters of the content there). Deleting these should hopefully help clean that page up, since it's currently in a bit of a ridiculous state, and then we can move on to higher priority issues with WantedPages such as. -  13:26, 29 January 2019 (UTC)

There's now several extremely old and outdated translation pages awaiting deletion. -  16:20, 18 February 2019 (UTC)


 * Starting deleting, just doing a few sections a day, so don't add any more until the current set is done. – ᐸ  10:50, 21 February 2019 (UTC)

I'm considering changing the cutoff date to be January 1, 2017, or maybe even January 1, 2018, given the major technical changes the game has faced since then. However, personally I find it to be a much more tempting option to outright nuke every single translation project altogether (except Icelandic translation), given the overall minimal activity across them. Feel free to comment. -  13:28, 25 February 2019 (UTC)

Wiki cleanup
I propose the following changes: Thoughts? –   23:31, 23 January 2019 (UTC)
 * 1) Export subpages of  to  and nuke it.
 * 2) Nuke
 * 3) *“None of them have any claims of notability and are just added willy-nilly. Most of them are stubs and/or orphans and many contain blatant advertising. They require a lot of maintenance even though they haven't been relevant for almost a decade now. Unmaintainable pages which include installing programs is a recipe for disaster when anyone can edit (virus alert). These pages have nothing to do with Mojang nor with modern versions of Minecraft itself.” 04:22, 24 January 2019 (UTC)
 * 4) Delete translation projects older than 4 years (see directly above).
 * 5) * Move the remainders to [MCW:Projects/language translation/page] so maintenance can be way easier and then they don't clutter search, etc. "SuffixIndex" is not a thing so it's really hard to actually find these translation pages. 04:24, 24 January 2019 (UTC)
 * For the first one, we should finally stop talking about it and do it. I the other two points as well. --  22:33, 24 January 2019 (UTC)


 * . However, "blatand advertizing" does not seem applicable on this subject; these are open-source programs and it's just as useful as the various other .  The subpages maybe are less valuable, but a list of some sort is still useful. However it's worth noting that much of the same information is replicated on wiki.vg's Client List and Server List articles (side note: interwiki really needs to be set up for that, I really should bring that up more formally).  Since wiki.vg is also where the protocol documentation is hosted, it may make more sense to keep those lists there.  However I don't think your deleting of significant amounts of information that's been there for quite some time without any consensus is any good. --  23:31, 24 January 2019 (UTC)
 * Unless Mojang had said they use one of the software listed, nuke the outdated items (pre-1.13) on . The wiki shouldn't be a database of third-party software. applies. –  Nixinova sig image 1.png Nixinova sig image 2.png 01:49, 25 January 2019 (UTC)
 * I still disagree. I think it's at least useful to keep this information around, or at least not get rid of historically notable content.  (And it's worth noting that there are some servers that are still developing around classic -- I see edits to the CPE page occasionally on wiki.vg, though I have no idea who those people are).  Cleanup is one thing; eliminating information about the past entirely is another (for the same reason I don't like the removal of the old issues pages).  Now it might make sense to just export and migrate the data elsewhere, but I don't think nuking is appropriate.  --  05:00, 25 January 2019 (UTC)


 * What is holding us off on the first one? I believe we've discussed this several times and there's a clear consensus to move the mods there. Do we need to contact the wiki manager to export the pages or something? I do think we should keep the page itself, for an explanation of what mods are and the fact that they can be found on the ftb. If nothing is holding us off and all we need to do is contact the wiki manager, I can let her know right now.--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:25, 25 January 2019 (UTC)


 * We need FTB Wiki admins to import the pages we export. Beyond that, probably nothing. -- 14:28, 25 January 2019 (UTC)


 * Hmm I never realized normal admins could actually export or import. I don't know anything about how this works. :-) I do know that is an admin over on FTB.--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:31, 25 January 2019 (UTC)
 * Indeed, Xbony2 is the one you should contact and coordinate with. He (was) asked about this before in an earlier discussion and was willing to help. What exactly needs to be done here or how, I don't know. As far as I'm aware, there wa no one before who could "lead" the process. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:44, 26 January 2019 (UTC)


 * All that would be required on our end is an export of these pages (with the full page history), which can be performed by any user, followed by deletion, or at least being tagged for deletion. It would probably be best for Xbony to export the pages himself, to avoid the need for handing the dump files off between people. Any files would also have to be uploaded locally on FTB, if they aren't already, though this doesn't require exporting anything from this wiki, just directly downloading the files. So at this point I suppose we're just waiting on Xbony to comment here. 「」undefined 10:15, 26 January 2019 (UTC)


 * Yeah, but how would he be able to export if he doesn't have admin rights?-- ( 20:20, 31 January 2019 (UTC)
 * You don't even need to be logged in to export pages. -- 20:25, 31 January 2019 (UTC)
 * Hmm, thanks, I didn't know that. So it's just import that requires admin rights.-- ( 20:27, 31 January 2019 (UTC)


 * Why the FTB Wiki specifically? Not all mods are in FTB, and it seems to me like it would make more sense to write about mods on the same wiki as the game itself. I'm not totally on board with migrating everything there -- I think we should bring more of it in here.  14:09, 14 May 2019 (UTC)
 * No. The FTB wiki covers all mods, not just what mods are in FTB. This wiki is specifically for the game itself, FTB wiki for the mods. Our editor base here is not sufficient enough to keep mod pages updated, which is more harmful than not. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:33, 14 May 2019 (UTC)

IP talk pages
Should IP talk pages older than, say, a year be deleted? They're not of use to anyone as the IP would definitely not be using that same IP anymore. –   00:17, 30 January 2019 (UTC)
 * , but if the content has special significance, we could either keep the page or move the content elsewhere. -- 08:46, 30 January 2019 (UTC)

Create requests for comments page
MCWiki is very good at starting important discussions and never finishing them because this CP has so many topics. should be created where we add important discussions (like the above). –   04:34, 24 January 2019 (UTC)


 * How would that be any better than having the requests for comments section on the community portal page? I suppose it's true that it could be more noticeable, rather than buried underneath other information.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:19, 25 January 2019 (UTC)


 * The thought of an unresolved discussion tracker often crosses my mind. I think we should at least fill the RfC section as completely as we can with links to active discussions. -- 14:22, 25 January 2019 (UTC)


 * Define active, because a lot of discussions have not come to conclusions, but are as dead as I don't know what.  14:25, 25 January 2019 (UTC)


 * Sorry, I should have said "unresolved" there as well. -- 14:27, 25 January 2019 (UTC)

Semi-Protect all pages in the File: namespace?
All IP edits to pages in the File: namespace are usually only vandalism, and I have a suggestion, should we semi-protect all pages in the File: namespace so only users with registered accounts can edit it and if there is an edit the IP want to make (such as an reupload request) they should make a request on the files talk page. -- ( • ) 17:41, 24 January 2019 (UTC)


 * . It's definitely true that many IP edits to the File: namespace are vandalism, but there are constructive edits being made and I don't think the vandalism frequency is quite enough to warrant protection. The vandalism edits aren't necessarily difficult to handle, there aren't that many of them and they get reverted quickly, and I think protection would be annoying for the IP editors who make constructive edits to files, and they may not feel like going to the trouble to post on the talk page and wait for a response. I'm open to changing my mind, however.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:14, 25 January 2019 (UTC)


 * , File NS vandalism from IPs is a rather small portion of all vandalism, and it's less visible due to file pages being less exposed to average readers. Namespace restrictions will harm users with good intentions more than vandals. -- 14:18, 25 January 2019 (UTC)

Articles about persons: what to include and what not to include?
Following a discussion from Discord, what should and what shouldn't be included in articles about people? What's our equivalent of ? Do we need to list employees' marital status and the number of their children? There are several people opposing including the latter into MCW articles. -- 20:16, 24 January 2019 (UTC)
 * I believe adding such information as marital status or number of their children does not belong on the wiki. Prefer sticking to information relevant to Minecraft like position in the company, what the person is doing there.  20:28, 24 January 2019 (UTC)
 * I agree that we shouldn't be publishing such personal details as marital and parental status. I see no reason we should publish anything about people unless it's already public and it helps our readers play the game or participate in the community. Even if somebody volunteers additional information on their Twitter account, etc., that doesn't necessarily make it freely publishable by us, especially if they change their mind later. I understand wanting to give Mojang people credit for their contributions, but that should be Mojang's job, not ours. In fact, I'd love it if we only published biographical articles that people write about themselves (subject to vetting, of course).
 * There's one more thing to consider: exists to protect Wikipedia from legal liability. Someone from Gamepedia/Curse (?) should be part of this discussion. –  ( &middot; ) 21:21, 24 January 2019 (UTC)
 * We have no hard and fast policy for such information, but personally I agree that marital status/offspring etc are not pertinent to the subject area of the wiki. —  21:30, 24 January 2019 (UTC)
 * Unless it's somewhat related to the game (for example, Notch made a special offer during his wedding, IIRC), personal life should probably be left to the minimum. There is absolutely no reason to add them here. And it's a bit creepy, really.  01:04, 29 January 2019 (UTC)
 * I don't have any opinion on marital status or the like (it doesn't seem particularly important, but also it doesn't seem like something that should be avoided per se). However, I think there is some such info that is useful, and my example of it is dinnerbone being red-green colorblind (see ).  This plays in to things like the removed .  --  01:11, 29 January 2019 (UTC)
 * For me, his color-blindness is more a fun fact than a real personal information, so I don't think it would have been necessary to remove it anyway.  16:11, 29 January 2019 (UTC)
 * I definitely feel that their children should not be part of the page. I feel identifying information ought to be forbidden while they're a minor. And even the mention of the children/parenting should be avoided unless mentioned minimally when it has some direct bearing on the game... though I don't have criteria in mind for that really. –  |  21:57, 11 May 2019 (UTC)

Infobox item images are improperly scaled. Reupload?
by. Arguments for the proposal are provided there. Additionally, I think some currently used images have been made by scaling directly from 16x16 to 150x150 with nearest neighbor interpolation, which results in distorted images (some texture elements are scaled into 9x9 squares or 9x10 rectangles, while many are scaled into 10x10 squares).

Assuming we don't need IE 11 support, we could also try using sprites with CSS rendering method configuration, instead of reuploading 150x150 images with 160x160 versions.

The proposal still needs comments, which were completely absent in its original instance.

As a side note, the Russian wiki has been recommending 160x160 item images for some time now. -- 18:42, 26 January 2019 (UTC)

Gadget proposal: Less annoying alternative to the BLOCKED stamp on Curse profiles
Arguments against that stamp:
 * Can't be translated easily (only irrelevant if non-English communities are treated as second-class citizens)
 * Takes a lot of traffic for something which can be done only with text (only irrelevant if users on mobile and low-bandwidth connections can be disregarded)
 * Takes a lot of screen space and obstructs useful elements even if it's click-through (only irrelevant if we don't care about good design)
 * Excessive for short-term technical blocks (only irrelevant if we don't care about community health)

Arguments for that stamp:
 * Satisfying (irrelevant because it's shown to everyone and not only the blocking admin)
 * Public shaming (irrelevant because only toxic communities think public shaming is not something bad)
 * "I like it" (this argument is only relevant if more substantial arguments don't exist, and I have four)
 * "There haven't been much complaints about it" (never relevant, indicates Gamepedia staff members who support this argument are acting in bad faith to subvert constructive change).

This gadget I propose doesn't prevent the image from loading, but replaces it with less obtrusive, translatable (when implemented on non-English wikis) and ergonomic version which also adds relevant links. I have tested it on both mobile view and desktop view and found it works satisfactorily on most environments I could recreate.

Enhancement suggestions are welcome. I consider seeing this, or something like this, becoming the default to be a major victory for the community. -- 11:32, 29 January 2019 (UTC)


 * I agree with you arguments, and the code looks good to me, but I also have my own idea. A blocked user's name should be with strikethrough formatting, suffixed with (blocked) or something like that, eg: (blocked). Any links you want/need could be added within those brackets then. –  [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:50, 29 January 2019 (UTC)


 * That was pretty much the first version of my code, but I found this was clumsy on low-width screens. -- 11:59, 29 January 2019 (UTC)
 * Look at the image to the right; the "blocked" icon in the upper right corner should we use as a icon on blocked user's curseprofile rather than the stamp. While howering over the icon, a tooltip could appear with "This user is blocked" with link to th block log. Any proposals to the image? -- Wikipedia-logo.png ( • ) 14:16, 29 January 2019 (UTC)
 * 1. There is also the global block log which should be linked to as well. 2. There are no tooltips for mobile devices due to no way to activate hover events. 3. The meaning of that icon is not immediately obvious. -- 14:25, 29 January 2019 (UTC)
 * AttemptToCallNil@undefined Why did you remove the image? The image I uploaded want I to display to see the blocked icon. Please make the image display again 🙂😃 -- Wikipedia-logo.png ( • ) 14:33, 29 January 2019 (UTC)
 * I replaced the image with a link to an image (sorry, should have mentioned that here) because a 1000px wide image embedded in a talk page is the total opposite of a good option. --  14:35, 29 January 2019 (UTC)
 * Okay, I understand that. Okay 😄 -- Wikipedia-logo.png ( • ) 14:37, 29 January 2019 (UTC)
 * Okay, I understand that. Okay 😄 -- Wikipedia-logo.png ( • ) 14:37, 29 January 2019 (UTC)

Block sounds
Can the placement, breaking, stepping, landing, etc. sounds for blocks be uploaded and added to the pages of blocks, and historical sounds added to the History section where applicable? -  21:15, 1 February 2019 (UTC)
 * If you'd like to do that then yes. –  Nixinova sig image 1.png Nixinova sig image 2.png 21:26, 1 February 2019 (UTC)

Does anyone have access to a version of Pocket Edition for iOS between 0.5.0 and 0.11.0, so I can rip the sounds for it? Or, if providing the actual version directly isn't legally possible, could they directly rip the sounds and upload them instead so I can transclude them on History sections where appropriate? -  18:02, 2 February 2019 (UTC)

Move In(f)dev pages
I don't think "In(f)dev (month day, year)" is the best way to go. I think we should follow the version jar name of "In(f)dev ymd-n" (eg "Infdev 20091231-2"). It's much easier to link to and is shorter. It also isn't as conjectural as what is currently in use as it's the name of the jar. –   02:35, 15 February 2019 (UTC)
 * This is planned to go through when the Java rename is completed. –  Nixinova sig1.png Nixinova sig2.png 06:30, 27 February 2019 (UTC)

New bureaucrat
The result of the discussion was Promote.

Since has sadly retired, there have been several discussions on  to promote a new bureaucrat. Several users mentioned me in particular as a potential bureaucrat. Currently, we only have one active bureaucrat. Because MCW has patrollers, directors, an inactive-admin demoting "policy", etc., bureaucrats have somewhat of an active role here, at least more so than many other Gamepedia wikis, so having more bureaucrats would probably be useful. So would you, as the community, want me as a bureaucrat? As for what I'd do with the bureaucrat tools, I would probably primarily promote patrollers if they're clearly fit for the role, update directors as they're promoted on other wikis, and occasionally demote inactive admins. I only want this position if it's something the community clearly wants, so if there is a flood of opposes for this I'd be happy to withdraw this request. Also, bear in mind that I'm not the only person who could be a bureaucrat; there are five other admins besides me who are active and not bureaucrats. Thanks, -- ( 18:32, 22 February 2019 (UTC)
 * –  Nixinova sig1.png Nixinova sig2.png 23:08, 22 February 2019 (UTC)


 * You have been very involved with the roles of users on the wiki already, and you're very accessible on the wiki in cases where users need your help. I also think that having someone from the community itself rather than a wiki manager (or similar), who is active and can look into the activity of other users is necessary for a wiki like this one. Our wiki manager(s) are not so much involved with bureaucracy for us, so why not one of us? So I . I would also support for bureaucrat, as they've been here for a long time. –  [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:52, 24 February 2019 (UTC)
 * both and  to be bureaucrats. I say  to  because he are not so much active., and : What should you do if you want to be bureaucrat? --Wikipedia-logo.png ( • ) 07:05, 25 February 2019 (UTC)
 * Hi, thanks for commenting; I think by "What should you do if you want to be bureaucrat?" you mean what specific purposes I would use the bureaucrat tools for were I to be a bureaucrat, but I could be wrong. If so, I answered this already in my original post: "promote patrollers if they're clearly fit for the role, update directors as they're promoted on other wikis, and occasionally demote inactive admins".-- ( 13:41, 25 February 2019 (UTC)


 * Madminecrafter; he's been active and observant on the wiki and has often requested Dinoguy to promote/demote other users in the past, and I would trust him with the bureaucrat tools. I have no particular objections against Orthotope or KnightMiner either. – undefined  07:29, 25 February 2019 (UTC)


 * I can say as far as me as a bureaucrat, while I do respond to discord pings pretty quickly, any promotions/demotions I make would primarily be requests from others; one of the more active admins who is more engaged in the community would be a better choice as they know who to promote. While I am not sure how active he is lately I can say I with Orthotope for bureaucrat based on my experience with him on the wiki. I am a bit more neutral about Madminecrafter12 as bureaucrat as I have not had as much experience with him as an admin as with Orthotope, but seeing as he is the one making a lot of the right change requests I think granting him the rights makes sense.
 * As a potential alternative, since admin rights changes should not need to happen often, why not allow admins to grant the director and/or patroller right to other users? Those are the rights that change the most anyways, and would alleviate the requests on the bureaucrat(s). Directors definitely makes sense as no consensus is needed to grant the right (its just for language parity), and I cannot forsee an admin abusing granting the patroller right. If this is done, it would still make sense to add another bureaucraft, but they would not need to remain as active. – · 02:23, 27 February 2019 (UTC)


 * Well, for what it's worth, I actually did briefly ask on Slack if it would be possible to allow bureaucrats to promote and demote directors. As you point out, promoting/demoting directors doesn't require any contributions reviewing, discretionary decision-makings, etc.; you just give it to users if they're an admin on another Minecraft Wiki. However, I was told that for some reason, because Directors is a local group rather than a global group, there is not a way to enable certain user groups to grant specifically Directors to individual users, without giving those certain user groups (e.g. in this case it would be admins) the "Edit all user rights" user right (which of course would allow the adding/removing of admin and crat). I would assume it would be the same way for patrollers.-- ( 02:38, 27 February 2019 (UTC)


 * Well, that's an unfortunate limitation. If we cannot allow admins to grant just those two rights, then I will increase my support for a second bureaucrat. I agree with either you or Orthotope, though I would like a comment from Orthotope on the matter before giving full support. – · 02:54, 27 February 2019 (UTC)


 * I do think we should have Orthotope respond here before taking any final action regarding him as bureaucrat; it's possible that he does not want the role.-- ( 02:56, 27 February 2019 (UTC)


 * This has gone on for over a week now; as the only active bureaucrat, do you think action could be taken from this now? Or do you think further discussion would be beneficial?-- ( 23:20, 2 March 2019 (UTC)


 * As I've said before, I believe another admin to replace dinoguy is appropriate (FVbico is now promoted as a result), but I don't believe another bcrat is necessary as role changes aren't particularly frequent or time-sensitive, so I'm easily able to keep up with approved requests, and we have gp staff to assign another bcrat if I drop dead. However, since there is reasonable community consensus to have another bcrat anyway, I'm fine with promoting you. – ᐸ  05:47, 3 March 2019 (UTC)

Unlinking on talk pages
There isn't a set way of removing links to deleted pages on talk pages. Some people nowiki it and others remove the link altogether. I think the best way to do this is to replace the link with [{{FULLURL: page name} } page name]|undefined. It remains a working link and doesn't put the page on the wanted page list. –   06:27, 27 February 2019 (UTC)


 * I proposed converting archives to be static on the admin noticeboard, and this is one of the conversions that would be performed. – ᐸ  05:43, 1 March 2019 (UTC)

Auto-refresh button on recent changes?
Can we please add an "Auto-Refresh"-button on, , and some other pages that can be used to track changes, the button is very useful, thus allowing use of Recent Changes and the Watchlist without needing to reload the page every time to update the recent changes, I would that we add this function as a gadget that is enabled by default, so if users dont want this function they can simply uncheck the box on their options page, as a suggester i that this would be added. Any suggestions or opinions? -- ( • ) 10:37, 1 March 2019 (UTC)


 * I can't see why we would need this. It would put more stress on the wiki needlessly if people load long datasets from those pages. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:10, 2 March 2019 (UTC)
 * Why do you oppose this addition? The Auto-Refresh checkbox might be very useful to easily patrol RecentChanges without needing to reload the page, if you don't want to have to refresh the recent changes every time to see newest changes, i have a script, just copy/paste it to your .js if you don't want to have to refresh recent changes, please explain why you don't want it? the most important pages is  and the watchlist.-- Wikipedia-logo.png ( • ) 13:41, 4 March 2019 (UTC)

Some user cleared their messages a couple years ago, not a single revert. How is this acceptable?
An example is the. Yes, this isn't new, but why did no one revert this before? Posting here instead of the Discord server because people there are quick to force a more "important" discussion whenever I raise an issue. -- 18:11, 1 March 2019 (UTC)


 * Definitely not acceptable per the talk page guidelines:
 * "Do not delete topics or comments, unless they are your own topic/comment and they have not been replied to. An exception is when archiving or if the topic violates one of the other rules."


 * Going to revert it in a minute. - ( 18:42, 1 March 2019 (UTC)

About
I have made a new version of the sprite because of the outdated textures (e.g., , ) in the current sprite sheet, but I can't upload it. Do you accept the new textures in the new sprite sheet? -- 12:39, 11 March 2019 (UTC)


 * You can upload them under a different sprite ID for now; I’m doing the same with the block and effect sprites, rename/replace them when the texture update is released.  13:26, 11 March 2019 (UTC)


 * While on the subject, should probably be added to the sheet. It is used with pistons and can't always be replaced by obsidian. Not all of them would need to be added; just 1 should be sufficient.   17:03, 12 March 2019 (UTC)

Is there any standard for the block and entity renders?
Many pages on this wiki have a render of the block or entity that the page is about. Is there any standard for these renders? Is there a specific software used for all these renders? 22:57, 25 March 2019 (UTC)


 * This should answer your question: .  00:04, 26 March 2019 (UTC)
 * Yes, that does answer my question. Thanks. I don't know if I'm supposed to do something with my topic and the replies now that my question has been answered. 00:21, 26 March 2019 (UTC)
 * Hi, for now this discussion can be left as is. Generally discussions aren't removed just because they have been answered (although if a talk page is getting long and a discussion is old, it may be archived to a separate page); they can be useful for record purposes, makes it easy for other users to add more replies if necessary, and does not hurt anything. Cheers, -- ( 00:59, 26 March 2019 (UTC)

Should we move all Tutorials pages to a own namespace?
The result of the discussion was no consensus. No new comments in several months; feel free to create a separate discussion if someone wants to bring this up again. – Sonicwave talk  17:13, 5 November 2019 (UTC)

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


 * , nothing else to add. FVbico (talk) 20:04, 5 December 2018 (UTC) The arguments from other people below actually convinced me, so it's become a for me. FVbico (talk) 15:01, 29 January 2019 (UTC)
 * , but I don't think Tutorials:Main Page would be the right place to put an index. I like Tutorials:Index better, similar to how Help:Contents works on wikipedia (n.b. Help:Main Page redirects there too). --Pokechu22 (talk) 20:15, 5 December 2018 (UTC)
 * and There is at least one subpage of Tutorials that is linked to directly from a main page, I think using a main template. (Sorry, off the top of my head I can't remember exactly which page it is. Maybe Enchanting? But there could be others, too.) If this gains consensus, I hope we can make a split between them. – Auldrick (talk &middot; contribs) 21:16, 5 December 2018 (UTC)
 * There are actually a large amount of "normal" mainspace pages that are linked to Tutorials subpages, such as Carrot.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 18:58, 11 December 2018 (UTC)


 * "Tutorial" and "Tutorial talk" namespaces (singular, in line with the others). Also, redirect Tutorials to Tutorial:index or Tutorial:contents, instead of to "Tutorial:Main Page". It will be an exhaustive overview of contents (an "index"), more than a regular page describing the content of the namespace as a "main page" would. All current tutorial pages would have to be redirected to the new namespace, not just the top level "Tutorials" page. I don't think we need a second search box though, the one we have will be just fine this way. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 22:16, 5 December 2018 (UTC)


 * The proposal uses only cyclic argumentation (we should do it because it should be done) for support. I ever heard only one solid reason to move tutorials outside the main namespace (not even its current subpage pseudo-namespace) was that they were of poor quality, and people shouldn't see such poorly written pages when they click "Random page", but this is an argument for improving the tutorials rather than putting them somewhere where they're even less likely to be found. Are there any real reasons we should do this? --AttemptToCallNil (report bug, view backtrace) 09:10, 6 December 2018 (UTC)
 * Because the tutorials do not describe the game. They describe suggestions from player to player, and aren't really articlespace worthy within the vision of the wiki, in my opinion. They have a different tone, different set of editors, different audience and different intentions. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:24, 6 December 2018 (UTC)
 * Do we have a standard definition for what exactly the main namespace is for? --AttemptToCallNil (report bug, view backtrace) 09:36, 6 December 2018 (UTC)


 * Don't really have a strong opinion on this, although I would prefer "Tutorial:" over "Tutorials:" and "Tutorial:Index" or "Contents" over "Main Page" (for reasons stated by Pokechu22 and Jack McKalling). Just as a general note though, there are currently 351 content pages and 273 redirects beginning with "Tutorials/", although around 50 of them are /video subpages. – Sonicwave talk  21:21, 6 December 2018 (UTC)


 * Meh, I don't really see a good reason for this. One disadvantage is that if we do this, the pages will not show in the search bar because namespaces don't. The article namespace is for content relating to the game, which tutorials are, and I can't think of a reason why we need to go to the trouble to move these all to a new namespace and just complicate things.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 13:41, 11 December 2018 (UTC)
 * If we move the pages to a new namespace, we could make in the LocalSettings.php so these could show up by default in the search bar. --Wikipedia-logo.png psl85  (talk • contribs) 18:53, 11 December 2018 (UTC)
 * Oh, I didn't realize that was configurable; thanks for the enlightenment. However, again, I still don't see a good reason to do this and it would create quite a bit of extra work.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 18:55, 11 December 2018 (UTC)
 * Per the above reasons and I would like to be able to block seeing these pages on recent changes. Also the namespace should be singular (Tutorial:) – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 03:46, 17 December 2018 (UTC)
 * It is specifically because the tutorial pages need fixing that they shouldn't be moved to a new namespace. Moving them to a different name-space doesn't fix tutorial pages, it just tries to hide them. Though the Minecraft Wiki is meant to explain factual data about the game, it cannot fully do that without the tutorial pages. Things such as redstone circuits, general farms, game quirks, functions, and information about the game's UIs all are stored within the tutorials. This is factual evidence that can only really be given in a tutorial format. I agree that the tutorial pages on this wiki are terrible, but the wiki needs tutorial pages, so instead of hiding them where they'll get edited less, the pages should be kept in the open so they're more likely to be maintained or fixed. -SuperDyl19 (talk) 06:29, 18 December 2018 (UTC)


 * According to this page, the only reason I found to use a custom namespace is that it can be used to hold content that should not be shown on the search results page. Though most wikis use custom namespace so that only users that require additional privilege(s) can edit. For this case, tutorial pages does not require special privileges to edit and is not restricted. -- skylord_wars (talk) 17:10, 31 December 2018 (UTC)


 * - The aim of the mainspace is for information on the game (and, by extension, Mojang) to be documented. Tutorials do not fall within the scope of what the mainspace should document, and as such should not be kept in the same namespace. It's also worth noting that other Gamepedia wikis such as the Terraria Wiki already have namespaces dedicated to tutorials. - User-12316399 (talk) 12:59, 12 March 2019 (UTC)


 * - but only for part of the tutorials.
 * I'm persuaded both by Skylord wars' and SuperDyl19's reasoning. As SuperDy119 points out, the tutorial sections often are critical for users' understanding of how the game works, particularly for new users who might not have a good grasp of features like redstone mechanics or minecart functionality.  As a new player, I referred to the redstone tutorials many times and still do on occasion, and I play with other experienced players who also will turn to the tutorial information to look up some specific kind of redstone circuit when needed.  Not all of the tutorials are this kind of information, however, so maybe some of it should be organized separately, such as the "suggestions from player to player" information that has less to do with advanced or nuanced game mechanics and more to do with game strategy ideas.
 * As a rough analogy, moving or striking the tutorial section as being "not valid information about the game" would be like having a computer programming textbook that defines what variables and procedures are but that does not include any examples of actual working procedures. Many new programmers would find it difficult to understand how to write procedures and make them work within a program without seeing those examples.  Such examples are definitely important to illustrate a particular core feature of the language.
 * Yes, the tutorial pages are in need of significant improvement in various ways (last I checked), and they may need to be reorganized to distinguish ones that are more fundamental to understanding how the game works from ones that merely offer suggested play strategies, but I'd argue that the former at least need to be kept as part of the main wiki space. &#8212; Memetics  talk &#124; edits 18:53, 27 April 2019 (UTC)

Bot's task request
The result of the discussion was no consensus/abandoned. No action for over 6 months, concerns raised over a significant portion of proposed tasks. --AttemptToCallNil (report bug, view backtrace) 18:05, 6 November 2019 (UTC)



This bot will be used on:
 * Cosmetic changes
 * Repair interwiki links
 * Text replacement
 * Automatically welcome new users (Use with )
 * Automatically clean Sandbox
 * Automatically archive

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


 * Bump and . – Nixinova Nixinova sig1.png Nixinova sig2.png 04:11, 9 April 2019 (UTC)
 * Bots making purely cosmetic edits to page wikitext are controversial, I wouldn't recommend that task. Automatically welcoming new users with a bot is very often perceived as annoying, defeats the purpose of welcoming, and disruptive users may be welcomed (vandals, spammers, users with unacceptable usernames). --AttemptToCallNil (report bug, view backtrace) 08:21, 9 April 2019 (UTC)


 * I agree with ATCN about welcoming new users with a bot; the software already gives you notifications for making your first/10th/100th edit if I'm not mistaken. Cleaning the sandbox might be useful, but it doesn't get edited that frequently and it isn't much trouble to clean it by hand. Repairing interwiki links would be useful, and for text replacement it would depend on what text is being replaced (large scale text replacements should probably be discussed first). – Sonicwave talk  23:00, 10 April 2019 (UTC)

Minigames page?
The result of the discussion was page created.

I propose a generic minigames page, where, like mods, people can create subpages explaining a certain minigame. Minigames are more relavant to the Minecraft than mods since they can be played in vanilla or semi-vanilla so I reckon they have more of a place on this wiki. Also, they aren't going to get quickly outdated since they don't necessarily apply to just one version of Minecraft. – Nixinova   05:11, 7 January 2019 (UTC)
 * I like the page, but I think it would be beneficial to clarify on both the minigames page and on the specific pages (such as Spleef) that they are not in any way official features, and are more player-made concepts or something similar. It's implied currently, but yeah. -PancakeIdentity (talk) 05:27, 26 May 2019 (UTC)

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


 * for both only, not for removing slicedlime's. FVbico (talk) 20:27, 20 February 2019 (UTC)


 * Same: allowing both. – Sealbudsman talk | contribs 21:59, 11 May 2019 (UTC)

Should we make a "farmable" section on item pages?
The result of the discussion was no consensus to implement. About half a year with no comments, almost 10 months since the topic was started. The topic opener is no longer active. Concerns on the merit of the proposal have been stated. --AttemptToCallNil (report bug, view backtrace) 23:49, 16 November 2019 (UTC)

It isnt exactly the same as "renewable", but it can be an extra option for it. What I'm reffering to here is if it can be renewed without player interaction. Just a suggestion. –Preceding unsigned comment was added by AFellowEditorLikeYou (talk • contribs) at 1:47, 14 January 2019 (UTC). Please sign your posts with
 * I don't really understand this. Can you give examples of "farmable" items and items that are renewable but not "farmable"? an_awsome_person (talk) 16:43, 27 January 2019 (UTC)
 * Items renewable only through trading would not be farmable.
 * I don't really see a use for this. I understand the difference, but it gets muddy with the inclusion of redstone and such. Are logs just renewable because saplings need to be planted by the player, or farmable because they can be broken and gathered without player interaction? Renewable works perfectly fine imo. -PancakeIdentity (talk) 05:30, 26 May 2019 (UTC)

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


 * I thought we're indeed going to split the template, hence the Template:InvSpriteTextureUpdate. I proposed this in an old discussion, but everytime I asked about this nobody seems to care. – ItsPlantseed ⟨₰|₢⟩ 19:04, 20 April 2019 (UTC)


 * Surey we could relocate the banner textures to another file entirely, given how much space they take up? - User-12316399 (talk) 22:49, 20 April 2019 (UTC)


 * The best idea I can think of is to split away some of the sprites to a separate template (not to single files). The banners take up a lot (there appears to be over 1000 over them, in fact), so as 12316399 suggested, separating them might be a good start.--Madminecrafter12 (Talk to me 13:36, 21 April 2019 (UTC)


 * How are we going to use the split-off sprites in inventory slots? Our slot and UI modules aren't designed to handle multi-page InvSprites. --AttemptToCallNil (report bug, view backtrace) 13:40, 21 April 2019 (UTC)


 * They aren't? Hmm, that's too bad. How difficult would it be to allow multi-page InvSprites?--Madminecrafter12 (Talk to me 13:41, 21 April 2019 (UTC)


 * A system of completely multi-page sprites would also have other limitations. For example, it would be difficult to move sprites between pages. There would not be a centralized location to edit all sprites.
 * The real issue is the pre-generated sprite list. There is no other significant limitation to sprites: we're over 2000 (probably over 3000 now!) sprites for InvSprite, and the file size isn't a quarter of the 8 MB maximum (plus, I almost don't doubt this maximum can be doubled upon request).
 * Whatever the new system of sprites will be, it needs to:
 * 1) allow as easy sprite sheet editing as the current one, both using the sprite editor and manually (given translating the sprite is easier manually especially if external Lua scripts are used to assist with translation);
 * 2) not be much harder to maintain than the current one (meaning the restructuring of sprite data, like addition of a new field for IDs, should not require extensive rewrites to complex JS);
 * 3) not be too complex to translate;
 * 4) not be prohibitively difficult to develop.
 * Any system where sprites are split would be relatively easy to develop, but difficult to maintain and difficult to modify.
 * Any other system I can think of requires runtime-generation of the sprite list, which either complicates manual editing or requires implementing a Lua parser in JavaScript.
 * Does anyone have any ideas? --AttemptToCallNil (report bug, view backtrace) 14:50, 21 April 2019 (UTC)


 * From my experience, I don't think that centralized sprite edit will be efficient in any way. Long documentation is a pain to deal with, I'd think by downloading the old sprites and uploading them afterwards into a separate not-so-long-list of sprites is a lot easier than moving them one by one to their section respectively on the same page. So with separate pages, you don't have to scroll through the long documentation to move the old sprites. And of course this would only make sense if we are going to split pages between the olds and the up-to-date ones. (P.S. I can only think of splitting them, not sure if I can come up with one with less drawbacks) – ItsPlantseed ⟨₰|₢⟩ 15:48, 21 April 2019 (UTC)


 * How about keeping all invsprites in one definition file like they are right now, but split them into categories, such as "current", "old revision", "colour states" etc, and document these separate categories on different pages? I don't know much about lua or sprites, but just an idea. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:06, 22 April 2019 (UTC)


 * I say that while we are not at a limit of the sprite sheet, its a lot more effort than its worth to split into multiple docs. The issue comes down to what do you logically split at so it remains in space for the sprite editor.
 * Personally, I say just move all the legacy stuff to another sheet once 1.14 releases, as by that point none of the main pages would still need them. I honestly cannot think of a good reason to keep every single old version on the main sheet anyways, it not like the crafting templates specifically call for the old textures ever. – KnightMiner  · (t) 19:37, 22 April 2019 (UTC)

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


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

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

To-do
1.14 is out, and since it changed all the textures, we need to modify a lot of things: – Nixinova   19:56, 23 April 2019 (UTC) edited 23:09, 10 May 2019 (UTC)
 * Move current invsprite to a separate template, to maintain the pre–Texture Update textures.
 * Change usages in the history section to point to this new template revision n files.
 * Move all images to a separate file and move the TextureUpdate files there.
 * Again, update the history section to point to these.
 * Add all texture update files to their respective pages ("Changed the texture of PAGENAME.").


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

Categorize images of generated structures and other images?
Should we categorize images of etc. generated structures, such as fossils to Category:Fossils or pillager outposts to Category:Pillager outposts? Then, sub-structures could be categorized to a subcategory, such as zombie villages to Category:Zombie villages and then add "Category:Villages" to the zombie villages category, so the images of generated structures are easier to find. Any suggestions? --  psl85  (talk • contribs) 12:38, 25 April 2019 (UTC)
 * You can already find images of generated structures on their mainspace articles. Why do you think searching in categories is easier than searching in the gallery section of a mainspace article? an_awsome_person (talk) 01:03, 7 May 2019 (UTC)

Phantom links from Template:Extension DPL
The result of the discussion was the issue is now addressed. The issue is fixed. --AttemptToCallNil (report bug, view backtrace) 18:21, 6 November 2019 (UTC)

This, among other pages, appears to be linked from the page Template:Extension DPL despite no link existing and the page itself appearing to be auto-generated. These phantom links seem to be persistent and have remained on WantedPages for quite a while now. What's going on here, and can it be fixed? - User-12316399 (talk) 07:57, 29 April 2019 (UTC)
 * Maybe the Module:Development versions has a bug where it doesn't correctly prefix "Java Edition" to links? I don't know lua. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:51, 29 April 2019 (UTC)
 * Fixed it with a null edit to Template:Extension DPL. This list of pages there created the link. Why do you even have that list there? It's just the same as Special:WhatLinksHere/Template:Extension DPL. We don't do that for other templates and it just creates cached red links for deleted pages that require a null edit.  HorseHead.png GRASP logo.png MarkusRost (talk) 15:31, 29 April 2019 (UTC)

Being unable to browse here due to user scripts bug - need help
The result of the discussion was the issue is fixed.

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

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

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


 * - another thing is that they appear in the Special:AllPages page that lists mainspace articles, which I'm not much of a fan of. - User-12316399 (talk) 10:30, 11 May 2019 (UTC)
 * If there's no opposition to this proposal within the next week, I'll move all translation pages to this format. - User-12316399 (talk) 17:20, 20 May 2019 (UTC)
 * Not so fast, give people the time to notice this, and voice concerns. FVbico (talk) 22:11, 20 May 2019 (UTC)


 * Support, it should make moving much easier, plus articles can have the correct (translated) name already then. FVbico (talk) 22:11, 20 May 2019 (UTC)


 * A slight problem with the namespaced approach is that it would no longer be possible to look up translations of an English article by viewing its list of subpages (but see point 3).
 * With a subpage approach, listing translations in a language can be done by using categories, PrefixIndex would not be required.
 * I also have concerns that this move would make translations less visible, which should not be considered good. Even though this is possible with the namespaced approach as well, perhaps a form of translation navigation lists at the top of articles with translations would be beneficial?
 * Additionally, using the subpage approach for translations is somewhat of a convention for MediaWiki. In particular, mediawiki.org adheres to it. --AttemptToCallNil (report bug, view backtrace) 22:14, 20 May 2019 (UTC)
 * Does MediaWiki address similar issues as noted by Nixinova's OP? Has a similar proposal been vetted there, I wonder?  &#8212; Memetics  talk &#124; edits 23:12, 20 May 2019 (UTC)


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

Make pages from old major releases accessible.
All the wiki pages seem to be updated for 1.14, but so many mechanics have changed that when I'm playing on a 1.12 server, I have to keep digging through wiki history to find the correct info. Additionally, if I wanted to add some *new* info specific to an old version, like an explanation of a glitch, there's currently no good place for it. I would like to propose something like is done for programming documentation, where old stable versions are moved to their own pages, so you could look up, say, "Smelting" versus "Smelting (1.12)". Nupanick (talk) 13:59, 14 May 2019 (UTC)
 * What you're asking for is already available. The History tab lists every past version of the page. If you determine the dates that the release (e.g. 1.12) you want was current, you can simply click on a date in that range to get a historical version of the page without the interference from later changes. You can even bookmark those pages' URLs, or make yourself a private index of them in your user space. Am I missing something? – Auldrick (talk &middot; contribs) 15:20, 14 May 2019 (UTC)


 * My two main points with that are 1) accessibility, and 2) editing. For 1, yeah, I could go to the version history, work out the dates, cross-reference it with the page I want, switch to Desktop view so the "history" tab appears, and find the version I need. But it seems like major versions should be easier to reach than that. Python's docs just have a drop-down to switch between v2 and v3, and its important since both still get considerable use.
 * Point 2), editing, I don't think can be addressed any other way. If I want to add a useful note on 1.12- villager mechanics, there's simply nowhere I can insert that into an old version of the page. Nupanick (talk) 15:56, 14 May 2019 (UTC)


 * You are correct. There's no easy way to improve or correct information on old versions just by history.  (And, as a side note, the historical versions do experience interference from later pages, as a side effect of updated templates or images or various projects moving pages into arbitrary locations and breaking all the links.  I don't complain about these things just because I'm grumpy...)
 * I don't know how to solve it, though. The issue with adding separate articles like that is that the number of them quickly grows, which makes maintenance painful.  (If there was an old inaccuracy that was only now noticed, then it'd need to be fixed on all the forked copies of the pages).  I do think that documentation of historical information is important, and at least for older mechanics it'd be useful, but copying every article with a version suffix would be too much. --Pokechu22 (talk) 17:13, 14 May 2019 (UTC)


 * Doesn't Bulbapedia have this exact problem? The pokemon series has several "major versions", and it's useful to be able to reference how mechanics worked in a specific version. I think they handle this problem by combining multiple versions of the mechanics into one page when it can be easily done with sections, and splitting the page into "old" and "new" versions as a last resort. So for example, we could add an extra column to the charts on the Smelting page to specify how much XP they produced in one version versus another, but the Village Mechanics page would warrant a complete split. Nupanick (talk) 23:48, 14 May 2019 (UTC)
 * Pokemon is very different from Minecraft. Pokemon only has 7 major updates; Minecraft has literally hundreds. – Nixinova Nixinova sig1.png Nixinova sig2.png 06:02, 15 May 2019 (UTC)


 * There's no viable way to do what you're asking. How far back would it go? Classic? We can't have 500 pages about the same thing. – Nixinova Nixinova sig1.png Nixinova sig2.png 01:17, 15 May 2019 (UTC)


 * Glitches or bugs should not be added to the page unless it is a major one. If that specific feature is only available at previous versions, like the Far Lands, it deserves it's own page. Some features also have their own page due to their uniqueness despite the feature is still available now, like Biome/Before Beta 1.8, the root page remains the same. skylord_wars (talk) 12:15, 16 May 2019 (UTC)


 * I agree with the others that keeping old versions of wiki pages, or old info on current pages, would be impractical. An ambitious editor (such as yourself?) might start a separate project (or a separate wiki?) devoted to a specific popular version of the game, and then copy the applicable page histories from here to there to enable editing and maintenance of that info set for that particular game version of interest.


 * As for the pain of looking up wiki pages for historical info, a useful workaround is to use archive.org - by starting on one of its archived pages for this wiki from a specific point in the past, one can follow the links to other archived pages in that era, without having to dig into the history here for each page separately. For example: Farmland (Minecraft 1.8).  &#8212; Memetics  talk &#124; edits 04:51, 21 May 2019 (UTC)

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


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


 * Didn't know about that, thank you! -PancakeIdentity (talk) 21:51, 27 May 2019 (UTC)

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


 * A good idea Marinah (talk) 02:10, 8 June 2019 (UTC)


 * Feel free to remove outdated videos, it already had consensus for awhile. –Majr ᐸ Talk Contribs 14:31, 8 June 2019 (UTC)


 * Alright, I'll go ahead with that. Is there anywhere I can read this consensus, just out of curioisity? -PancakeIdentity (talk) 18:55, 8 June 2019 (UTC)


 * There are some, you can find it here, here, here, and here. – ItsPlantseed ⟨₰|₢⟩ 04:42, 9 June 2019 (UTC)


 * I'd love if I could get some opinions on how to move forward with this in the topic below. -PancakeIdentity (talk) 02:37, 14 June 2019 (UTC)