Talk: Community portal

Revision as of 21:27, 11 June 2019

Shortcuts

This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.

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:

Provide readers with more facts about the game.
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.

Lê Duy Quang (Make some words | Contributions) 12:10, 7 November 2018 (UTC)

Update: Here is my suggestion about the placement of the new section. Lê Duy Quang (Make some words | Contributions) 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. – Luckowskiᵗᶜ ᵘ 12:18, 7 November 2018 (UTC)

I know, I know. I meant this section is on the main page. Sorry for not being clear... Lê Duy Quang (Make some words | Contributions) 12:32, 7 November 2018 (UTC)

Oh. Well, that's a great idea! Support – Luckowskiᵗᶜ ᵘ 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. – Jack McKalling [

] 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. Lê Duy Quang (Make some words | Contributions) 13:03, 7 November 2018 (UTC)

I have implemented the content display module. Preview:

Did you know... ... that in Java Edition, a blaze has the exact same hitbox size as the player? ... that precious blocks like beacons, conduits and shulker boxes can be retrieved by hand? ... that the original iron sword texture was taken from Notch's abandoned game Legend of the Chambered? ... that deep dark biomes are more likely to be found beneath mountainous areas? ... that the Frost Walker enchantment creates a special type of ice known as frosted ice? ... that pointed dripstone does not need a dripstone block above it to fill a cauldron with lava, or to convert mud into clay? ... that there are armor stands equipped with iron armor in taiga villages? ... that creepers initially had a melee attack, and exploded only when it is killed?

I would love if you have some facts to feed in here.

Lê Duy Quang (Make some words | Contributions) 13:20, 8 November 2018 (UTC)

Support Sounds good, and makes the main page more interesting. 193.210.224.228 05:32, 9 November 2018 (UTC)

Status update: Proposed to the editcopy. Lê Duy Quang (Make some words | Contributions) 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.-- Madminecrafter12^{Talk to me} 14:26, 23 November 2018 (UTC)

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

Well, for that matter, Module:DidYouKnow and Module:DidYouKnow/facts 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 Module:DidYouKnow/facts/proposals or Module:DidYouKnow/facts\editcopy?-- Madminecrafter12^{Talk to me} 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? 🙃🙃🙃 --AttemptToCallNil (report bug, view backtrace) 17:22, 23 November 2018 (UTC)

If we have a director go to the dark side, I think we'll be in a lot bigger trouble than this. :-)-- Madminecrafter12^{Talk to me} 17:24, 23 November 2018 (UTC)

Bump. Anyone want to comment on this?-- Madminecrafter12^{Talk to me} 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). 「ディノ奴千？！」^{☎ Dinoguy1000} 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. Lê Duy Quang (Make some words | Contributions) at 12h21:26 | 1/12/2018 (UTC)

There is no extended confirmed protection on Minecraft Wiki. --AttemptToCallNil (report bug, view backtrace) 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.-- Madminecrafter12^{Talk to me} 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? – Auldrick (talk · contribs) 14:28, 1 December 2018 (UTC)

So we will have to parse manually? Lê Duy Quang (Make some words | Contributions) 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.-- Madminecrafter12^{Talk to me} 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.) – Auldrick (talk · contribs) 15:06, 1 December 2018 (UTC)

{{DidYouKnow}} Lua error... -- Madminecrafter12^{Talk to me} 15:36, 16 December 2018 (UTC)

I edited the module to have it display randomly chosen facts. --AttemptToCallNil (report bug, view backtrace) 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. --AttemptToCallNil (report bug, view backtrace) 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). –Sonicwave ^talk 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

07:33, 8 May 2019 (UTC)

Sonicwave32 for admin?

We have needed more admins on MCW for a while now, and one of the few candidates I've seen that I really thought would make a really great admin is Sonicwave32. Sonicwave joined the MCW in 2014, long before I did, and has since improved the MCW in a huge variety of ways, whether it's making basic copy-edits, adding sound files, or correcting/adding information. However, Sonicwave's primary area of focus is vandalism fighting. Many great qualities I've noticed about Sonicwave32 is that he always leaves clear edit summaries when making edits, is absolutely wonderful at communication, and never bites newbies.

So why should Sonicwave32 to become an admin? Well, as I mentioned, he's a wonderful vandalism fighter. In the event of a persistent vandal, he would be able to block them himself rather than wait for another admin to get to them. He knows exactly what is vandalism and what is not, as well as to give users friendly notices when they are making disruptive edits but acting in good faith, so I'm confident that he can be trusted with the block button. In addition, Sonicwave32 is experienced and accurate with tagging pages for deletion, and Category:Pending deletion has always been a backlogged area. From what I have observed, Sonicwave has great judgement, is experienced, and is "clueful." I believe that Sonicwave would make a great admin, and thus Support him, and I hope that the rest of the community feels the same way.

Sonicwave, if you would like to add something, please do so, or if I missed something, please let me know.-- Madminecrafter12^{Talk to me} 21:23, 20 November 2018 (UTC)

Thanks for taking the time to write this out, and I accept this nomination. –Sonicwave ^talk 02:38, 21 November 2018 (UTC)

While I admit I'm not really a regular user on this wiki, I would like to point a few things that I feel are important.

I'm not quite sure Sonicwave is active enough recently to solve by himself the issue about the lack of admins... While I don't disagree that he may be a good candidate for the role, this wiki really need a more present admin team. Thus, it would probably be a good idea to look at all the possible candidates — and I have to disagree with you, there is a bunch of editors here who would make some excellent admins! So, if the community want more than one additional admin, well, Sonicwave would definitively be a good candidate and I of course support him, but others should also be considered!

Regarding that, I would like to point out that FVbico seems another really solid candidate to become admin on this wiki, and I really think the community should also discuss to promote him as well. With his impressive knowledge of the game, his important contributions and his general motivation, he is definitively someone to think about for the role. I know some could be concerned about a bit of edit warring, and we should absolutely encourage him to improve himself on that aspect — but despite that, he's still someone who would really help the wiki if promoted. Promoting both of them could be a good way to resolve the lack of admins issues.

On another subject, the promotion system seems a bit ineffective right now... If the wiki is needing more admins for a while, without anything done to address the issue, perhaps it would be interesting to make a new system for the promotions. A Request for Adminship system is the most common elsewhere, this wiki should perhaps think about it (or something else). But anyway, that's not the point.

So this is my contribution to that subject. I hope I will have brought an helpful point of view for this discussion. JSBM (talk) 04:17, 21 November 2018 (UTC)

So you propose we implement sophisticated systems for tasks which, until now, have been served well by simpler equivalents, with no apparent substantial drawbacks? And yet you complain that Minecraft Wiki is bureaucratic? --AttemptToCallNil (report bug, view backtrace) 07:18, 21 November 2018 (UTC)

I'm suggesting this wiki is reviewing its process, to make sure there is always enough admins to do the tasks on this big wiki. By encouraging people who are interested to become admin to identify themselves instead of this weird habit of choosing them when it's really too late, we could resolve a lot of problems. I'm not suggesting a RfA is the best system, of course, simply one who have been successful elsewhere. And for me, having new bureaucratic system is not in itself an issue; having some that are useless or used abusively is however. In this case, the goal would simply be to set clear rules and process on how promotion should work here, to make the process more fair and open to all. (I suggest that if you want to further talk about this, you should open a new section instead, to give a proper place for the community to answer on this subject.) JSBM (talk) 15:44, 21 November 2018 (UTC)

I don’t object to being nominated. :) FVbico (talk) 10:20, 21 November 2018 (UTC)

Support of User:Sonicwave32 being admin. He is doing great anti-vandalism work and might also be trusted with the "block" button to block vandals. --

psl85 (talk • contribs) 09:58, 21 November 2018 (UTC)

I don’t object to accepting both Sonicwave32 and FVbico. I don’t recall any problems with either users, at least when I had been actively observing the English wiki. — BabylonAS (talk | ru.Wiki Admin) 14:58, 23 November 2018 (UTC)

No objections against Sonicwave getting the admin flag. --AttemptToCallNil (report bug, view backtrace) 15:58, 23 November 2018 (UTC)

Support why not? =^^= Iludido (talk) 01:19, 24 November 2018 (UTC)

Per the above discussion, and given it's been several days since the last comment, I've Promoted Sonic to admin. 「ディノ奴千？！」^{☎ Dinoguy1000} 03:59, 28 November 2018 (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:

Jack McKalling (talk • contribs • logs • block log) (opted out)
FVbico (talk • contribs • logs • block log) (promoted by Majr at 05:39, 3 March 2019, see below)
Nixinova (talk • contribs • logs • block log) (promoted by Madminecrafter12 on 8 May 2019, see below)
Pokechu22 (talk • contribs • logs • block log) (opted out)
Sealbudsman (talk • contribs • logs • block log) (see below, would be fine with being an admin but has found little time to contribute)
Nicolerenee (talk • contribs • logs • block log) (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. --AttemptToCallNil (report bug, view backtrace) 15:58, 23 November 2018 (UTC)

@AttemptToCallNil: 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?-- Madminecrafter12^{Talk to me} 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. --AttemptToCallNil (report bug, view backtrace) 16:26, 23 November 2018 (UTC)

Shouldn't we ask people if they actually want to be an admin before a typical consensus nomination?-- Madminecrafter12^{Talk to me} 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. --AttemptToCallNil (report bug, view backtrace) 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.-- Madminecrafter12^{Talk to me} 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? --AttemptToCallNil (report bug, view backtrace) 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.-- Madminecrafter12^{Talk to me} 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. --AttemptToCallNil (report bug, view backtrace) 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.-- Madminecrafter12^{Talk to me} 16:48, 23 November 2018 (UTC)

Yes. --AttemptToCallNil (report bug, view backtrace) 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. – Sealbudsman talk | contribs 16:47, 23 November 2018 (UTC)

@Sealbudsman: 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.-- Madminecrafter12^{Talk to me} 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). --Pokechu22 (talk) 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... – Jack McKalling [

] 10:46, 26 November 2018 (UTC)

Nixinova and Nicolerenee since there's no word of you two yet, I'm just going ahead and ask. Do you accept being nominated for admin? FVbico (talk) 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). – Jack McKalling [

] 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? – Nixinova

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. --AttemptToCallNil (report bug, view backtrace) 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. FVbico (talk) 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. Majr 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. Frisk (Talk page) 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. –Majr ᐸ Talk
Contribs 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. Frisk (Talk page) 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? FVbico (talk) 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.--Madminecrafter12 ^{(Talk to me | View what I've done)} 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. FVbico (talk) 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 Oppose, 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: [1], [2], and [3], 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 biting newcomers. 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 here; for a newcomer acting in good faith, 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. Jungle biome, Mushroom biome, and Swamp Biome 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 extremely picky people 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 Discord, for the sake of transparency and keeping all discussion in one place. But do try to stay civil. :-) Best of wishes, -- Madminecrafter12^{Talk to me} 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). FVbico (talk) 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!-- Madminecrafter12^{Talk to me} 14:15, 28 November 2018 (UTC)

I hope I'm not being indiscreet to bring this up. FVbico, 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? – Auldrick (talk · contribs) 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. FVbico (talk) 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! JSBM (talk) 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 own projects 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. Madminecrafter12 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. Frisk (Talk page) 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?--Madminecrafter12 ^{(Talk to me | View what I've done)} 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. :)--Madminecrafter12 ^{(Talk to me | View what I've done)} 00:26, 10 February 2019 (UTC)

Support 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.--Madminecrafter12 ^{(Talk to me | View what I've done)} 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.) –Majr ᐸ Talk
Contribs 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. – Nixinova

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. FVbico (talk) 22:05, 17 December 2018 (UTC)

@Nixinova: 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 Category:pending deletion? 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!-- Madminecrafter12^{Talk to me} 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). – Nixinova

19:04, 18 December 2018 (UTC)

(Bump) – Nixinova

18:04, 22 February 2019 (UTC)

I'd support the promotion. - User-12316399 (talk) 10:56, 3 March 2019 (UTC)

Support Frisk (Talk page) 11:22, 3 March 2019 (UTC)

Support JSBM (talk) 02:51, 4 March 2019 (UTC)

Support Marinah (talk) 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. Special:Diff/1354822 and Special:Diff/1344993). I understand that mobile view doesn't allow you to leave explanations on rollbacks though, and aside from that I have no issues. –Sonicwave ^talk 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

06:43, 16 April 2019 (UTC)

That rollback issue is now fixed. – Nixinova

20:21, 25 April 2019 (UTC)

Support 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. —Memetics ^{talk | edits} 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 Nixinova 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 (example). 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 Granted him the administrator role.--Madminecrafter12 ^{(Talk to me | View what I've done)} 02:07, 8 May 2019 (UTC)

Page protection locks gadget: New padlocks?

Wikipedia has implemented a set of new padlocks to signal page protection, the reasons behind this implementation are in the RfC in the first link. Should we implement these same padlocks for our gadget? --AttemptToCallNil (report bug, view backtrace) 14:47, 21 November 2018 (UTC)

Support, would definitely be easier to tell what type of protection was applied at a glance. –Sonicwave ^talk 05:43, 22 November 2018 (UTC)

One thing I didn't think of: we use the black padlock to signal a level of protection which doesn't exist on Wikipedia; if we're going with the new Wikipedia padlock approach, we'll need someone willing and able to edit a vector image for us. --AttemptToCallNil (report bug, view backtrace) 07:31, 22 November 2018 (UTC)

About the SVGs, I believe I can modify the thing. Lê Duy Quang (Make some words | Contributions) at 14h25:41 | 30/11/2018 (UTC)

Here is my proposal for the director protected icon:

Lê Duy Quang (Make some words | Contributions) at 13h44:28 | 1/12/2018 (UTC)

I think you should remove the white design elements and make the letter substantially thicker. This icon is going to be used in 25px resolution, where the white design elements aren't visible, and the D is visible just barely; see it for yourself —

. --AttemptToCallNil (report bug, view backtrace) 14:06, 1 December 2018 (UTC)

Here is version 2 with thicker lines:

Lê Duy Quang (Make some words | Contributions) at 14h30:53 | 1/12/2018 (UTC)

...or with just a D:

Lê Duy Quang (Make some words | Contributions) at 14h33:30 | 1/12/2018 (UTC)

The lines don't actually add any useful information for the readers, and they make the D (which is more or less useful information) less legible, so yes, I support the third version. --AttemptToCallNil (report bug, view backtrace) 14:47, 1 December 2018 (UTC)

Change Windows icon?

I feel like the Windows icon should be changed to one that is used for Windows 10; instead of keeping the XP-7 icon. Jarl penguin (talk) 14:10, 22 November 2018 (UTC)

Yeah. It should be the iconic icon of Windows 10, but I'm afraid other editors will argue that readers will be confused between Minecraft: Windows 10 edition and Minecraft: Java edition. If you think it is right, you can propose it in the main page's editcopy. Lê Duy Quang (Make some words | Contributions) at 12h53:20 | 1/12/2018 (UTC)

Strong Oppose – Would cause confusion with both the Bedrock Edition and the aforementioned Windows 10 Edition. -BDJP ^(t|c) 20:48, 15 May 2019 (UTC)

While I agree the icon should not be that of windows XP anymore, the icon for Windows 10 is not suitable either. The edition that the icon represents, and the one the icon is clashing with, Java Edition and Bedrock Edition for Windows 10, need to be differentiated. To use distinct icons. Because the icons should be representing the edition, and not the platform it runs on. I have ideas on how to do that, but in no way can I myself because I have no graphics software to do it. But somebody should fix this once and for all, I keep seeing the two parties colliding on which icon should be used and if a new icon could be made that fits both arguments (different icon but not the old logo), both parties should be able to agree. – Jack McKalling [

] 20:49, 15 May 2019 (UTC)

No, it should represent platform instead of edition. Along with macOS, linux, etc. Cause I don't remember there is actually "Minecraft: Java Edition macOS Edition". – ItsPlantseed ⟨₰|₢⟩ 20:54, 15 May 2019 (UTC)

Then come up with a different solution, instead of saying "no you're wrong". – Jack McKalling [

] 20:56, 15 May 2019 (UTC)

Everyone should be aware that there is no "Minecraft: Windows 10 Edition". It doesn't exist, there are only three or four that are considered as edition, instead it got replaced by Bedrock Edition. Thus, the icon on main page should refer to platforms instead of editions, since Bedrock and Java are also available in Windows. Windows 10 has been out for years. Using two distinct Windows logos will make other people believe that Windows 10 is representing edition in the long term, believing that the edition is still exist. I don't come up with a solution since I don't think it needed a change. – ItsPlantseed ⟨₰|₢⟩ 21:09, 15 May 2019 (UTC)

They should both be windows 10 as it's about the platform not the edition of the game. Both Java and bedrock can be played on Windows 10, so the logo should be the same. – Nixinova

21:08, 15 May 2019 (UTC)

But Java can also be played on Windows XP and higher; that’s why the confusion regarding the logo should be avoided. -BDJP ^(t|c) 21:16, 15 May 2019 (UTC)

If Windows version was the problem, instead of diffirentiating Windows 10 Edition with Java Edition, adding "or lower" under the Windows logo should help just fine. – ItsPlantseed ⟨₰|₢⟩ 21:28, 15 May 2019 (UTC)

This being discussed before, twice, (even though those discussions were for Windows 8 only, the logo hasn't changed), and is has been pointed out that there is another problem with the post-W7 logo: it is uniformly blue, thus less visible on the wiki's light blue background, and on lower resolutions, like 20px in infoboxes, it may not be sufficiently recognizable even if contrast is sufficient.

It may not be the best comparison, but I thought of comparing the issue of the "old" Windows logo with using floppy disks as icons for "Save"-like actions in software. --AttemptToCallNil (report bug, view backtrace) 22:03, 15 May 2019 (UTC)

The main page will use the blue on yellow/red, so that point is not that relevant, and the windows 8 logo is still easily recognisable in low resolution. – Nixinova

22:49, 15 May 2019 (UTC)

More opinions

I've been patrolling the deletion category and deleting/untagging what I can, but I would like to have some more opinions on the following pages before making a decision, because I'm really not sure if they should be deleted or not:

~~1.4.3 (redirect to 1.4.2, may be a useful typo because there is no 1.4.3 but there is 1.4.3-pre)~~ Solved. Kept and changed to redirect to 1.4.3-pre instead per discussion below
Custom servers/MCSharp and Custom servers/MossyCraft (both tagged for deletion as old and outdated custom servers)
[[Minecraft: Bedrock Edition]], [[Minecraft: Legacy Console Edition]], [[Minecraft: New 3DS Edition]], [[Minecraft: PC Edition]], and [[Minecraft: Switch Edition]]
[[Mods/Humans+]] and [[Mods/Runester]] (both tagged for deletion as old and outdated mods)
Mods/IndustrialCraft² (tagged for deletion because the page is outdated and it already has an official wiki, but it's not a Gamepedia wiki)
[[Virtual reality Edition]] (tagged for deletion as superfluous disambig)
~~[[Talk:Tree farming]], [[Talk:Trolling]], [[Talk:Tutorials/Monster Spawner traps]], and [[Talk:Units of measure]] (tagged for deletion as unnecessary redirects)~~ Solved; deleted per below

If possible, I'd appreciate some of y'all helping me come to a decision on some or (preferably) all of these so that we can eventually empty the deletion category. Thanks, -- Madminecrafter12^{Talk to me} 00:31, 24 November 2018 (UTC)

1.4.3 should be kept as in-game he f3 screen doesn't say "pre" – Nixinova

01:01, 24 November 2018 (UTC)

The launcher also uses 1.4.3 too despite being a pre-release.--skylord_wars (talk) 10:46, 24 November 2018 (UTC)

@Skylord wars and Nixinova: do you think it would be better to redirect to 1.4.3-pre instead then?-- Madminecrafter12^{Talk to me} 15:11, 24 November 2018 (UTC)

By the way, I think that "1.4.3-pre" should be renamed and redirected to "1.4.3 (Pre-release)". --HaydenBobMutthew ^{(talk, contribs)} 15:15, 24 November 2018 (UTC)

Yeah since in-game that's all it's known as. – Nixinova

18:15, 24 November 2018 (UTC)

Alright, Done. I've modified the target of the redirect, removed {{delete}} from the redirect, and struck through the 1.4.3 bullet point in this post with an explanation. Thanks for helping me out with this!-- Madminecrafter12^{Talk to me} 18:38, 24 November 2018 (UTC)

I went ahead and deleted the talk page redirects and it seems pretty uncontroversial. Feel free to scream at me if you have any objections. :-)-- Madminecrafter12^{Talk to me} 02:35, 27 November 2018 (UTC)

Anyone want to comment on this? Bumping this discussion.-- Madminecrafter12^{Talk to me} 19:25, 5 December 2018 (UTC)

I don't really have anything to say, the deletion reasons are valid, and I see no real reason to keep them. FVbico (talk) 19:30, 5 December 2018 (UTC)

Some suggestion about private issue description rule

To settle about MC-137819's description revert yesterday, I have the following suggestions on the style guide:

For security issues mentioned on the official change log, use the title from the change log, since it has been disclosed by Mojang.
For security issues NOT mentioned on the official change log, use “private security issues (involving...)” instead.

--HaydenBobMutthew ^{(talk, contribs)} 14:01, 24 November 2018 (UTC)

I would Support that. If the issue fix is something Mojang's okay with having on an official change log, then I don't see why it can't be revealed on the wiki. Maybe we should add this to the style guide?-- Madminecrafter12^{Talk to me} 14:02, 24 November 2018 (UTC)

Support. --HaydenBobMutthew ^{(talk, contribs)} 14:04, 24 November 2018 (UTC)

Also, for security issues mentioned on the official change log, use the title from the change log with ref to the change log, influenced by 1.8.4, 1.8.5 and 1.8.6. --HaydenBobMutthew ^{(talk, contribs)} 14:06, 24 November 2018 (UTC)

Support. -BDJP ^(t|c) 15:57, 24 November 2018 (UTC)

Mixed opinions. For some issues, I think it's definitely fine, but I'm not sure about whether it's a good idea to include it for all issues. My general opinion on it is that for issues that only affect snapshots, it's fine to include it; for ones that affect releases more care must be taken (but it also varies on the issue; duplication issues I think are generally safer to make public, but that's only my stance). I should also note: I'm generally in favor of making private issues public eventually, though that hasn't really happened on the tracker. I should probably look into that again; the super old issues for 1.8 and the like probably can be made public at some point... (n.b. I am a bug tracker moderator, so I have access to the details of these reports, which does mean I have additional context others don't have) --Pokechu22 (talk) 18:09, 24 November 2018 (UTC)

Comment Like Pokechu, I'm a moderator on the bug tracker. I want to mention a couple of things for consideration.

1) There are 2 reasons we make bug reports private: Either they contain personal information, or they describe an exploit. I believe the intent of the rule is to avoid giving publicity to exploits, but editors generally wouldn't be able to tell which reason applies (and both could apply simultaneously). If necessary, editors could ask one of us for a publishable description of a bug.

2) There are some reports that we make public despite describing an exploit. This is generally when they are already published on YouTube or Reddit and we therefore anticipate them being reported many times. We encourage users of the bug tracker to search before submitting a report, but they can't find a private report that way, so we make it public to try and avoid a lot of duplicate reports. Thus, "public" ≠ "not an exploit".

I don't think it's a good idea to publish exploits on the wiki at all, regardless whether they're public or private. They can absolutely ruin the game sometimes, especially on multiplayer servers. (Examples include disruption of a server's economy, invincibility during PVP, and surrounding a player with illegally obtained bedrock to extort, coerce, or disable them.) So maybe the rule should prohibit mentioning a bug's exploitative aspect instead. For instance, if the reverted edit that started this had said merely "Shulker boxes can't be dyed" and left out the duplication effect, it needn't have been reverted.

For these reasons, I suggest that the rule should focus on not promoting exploits, instead of whether a bug report is public or private. – Auldrick (talk · contribs) 13:47, 27 November 2018 (UTC)

Comment I think that Java Edition “fixes” section should be consistent with Bedrock Edition “fixes” section to solve this problem. HaydenBobMutthew ^{(talk, contribs)} 05:14, 29 November 2018 (UTC)

Sound file licensing

Do all non-music sound files need to be licensed as {{License C418}}, or is {{License Mojang}} sufficient for some of them? If it's the latter, which cases are these? --AttemptToCallNil (report bug, view backtrace) 21:18, 1 December 2018 (UTC)

Many sounds are creative commons licensed (the exact one varies though); see the sound attribution page. --Pokechu22 (talk) 21:37, 1 December 2018 (UTC)

Are the CC BY-licensed sounds specified as such on the wiki?
Are the non-CC BY-licensed sounds all C418-licensed? --AttemptToCallNil (report bug, view backtrace) 21:56, 1 December 2018 (UTC)

When do we describe bugs in articles? Pt. II

I'd like to reopen the discussion at Minecraft Wiki talk:Community portal/Archive_18#When_do_we_describe_bugs_in_articles.3F since it doesn't really reach a consensus. I just came from a discussion about some unexpected parrot behaviour that I thought the wiki would have informed me about. I couldn't add it because the page was locked, and a user dismissed my request because it seemed too much like a bug. I've been describing things that could be suspected as bugs whenever I encountered them, treating the wiki as "this is how the game is", but maybe I misunderstood the goal of the wiki? 86.82.30.109 00:04, 3 December 2018 (UTC)

When we characterize ourselves as describing "how the game is", we don't mean that to contrast with "how the game isn't, but rather with "how the game is now" versus how it used to be or how it might be at some point in the future. It's intended to remind us to remove information that's obsolete, or at least to clearly mark it as such, and also to avoid treating mere rumors about upcoming changes as real information.

With respect to bugs, we only acknowledge a bug if it has been around for a long time and Mojang isn't actively planning to fix it. The reason is that we don't want to mislead people into depending on behavior that's likely to change in an upcoming release, and also because it's highly possible that nobody would remember to remove the bug description after the bug is fixed, at which point it would become misinformation.

I also took a look at your edit history to familiarize myself with the behavior you're talking about and saw what I assume is the discussion you say you just came from. To summarize, the other editor described the behavior as (paraphrasing) "parrots wouldn't follow or teleport to me while I was in an Ice Spikes biome". Then they jumped to the conclusion that "parrots […] become lethargic in a cold biome". You, in turn, appeared to accept that reasoning. The problem is that this conclusion is a generalization that doesn't automatically follow from the behavior. The assumption could be wrong: Maybe it doesn't happen in all cold biomes. Or the conclusion could be incomplete: Maybe it happens in some warm biomes, too. It's also possible that the true explanation is based on something completely different: Maybe a bug is making you untrackable by any mob when you're standing on ice. There's no way you can generalize from a specific event to a behavior description without making some assumptions about Mojang's intentions, and no way you can validate those assumptions unless you have access to the code base. Consequently, any generalizations of this type from non-Mojang staff have to be treated skeptically unless there's a very convincing argument. – Auldrick (talk · contribs) 06:07, 3 December 2018 (UTC)

Request for Comment: Get rid of change log collections on Development Version subpages

At the moment, a query grabs all articles for a particular release version's development versions and transcludes most of these articles on a single page. There was a time when a single page was enough for complete change logs for all development versions, this was obviously not acceptable as a permanent solution. Apparently, keeping such complete change log collections on a per-version basis was deemed enough of a compromise to avoid scrapping change log collections entirely in favor of a single, minimalistic list. In this request for comment, apparent issues with the current approach are described, and a resolution is proposed.

It is questionable that such collection pages are substantially useful for readers. Releases contain substantial numbers of snapshots, with many changes in each snapshot, and this often results in incredibly large pages where needed information is hard to find. The feature that would mitigate (not significantly) this navigational difficulty is the built-in browser search (Ctrl+F in desktop Mozilla Firefox)... however, it's very possible many readers aren't aware of this feature. This paragraph does not even consider mobile devices, where the pages and/or the search feature may be even less usable. As an extra note, bandwidth and client performance may be a concern assuming non-text content gets transcluded from many individual version articles at once.

As a result of this approach, editors who contribute to snapshot articles are expected to properly insert onlyinclude tags into snapshot articles to avoid breaking the collection pages. Beyond that this is not something obvious to beginning editors, it is not even documented where exactly should these tags be placed, and in a recent incident, a user attempted to have the tags contain the video section, resulting in a mass revert.

Additionally, collection pages require a system of complicated templates and categories which has to be maintained by more technically capable editors. The complexity of this system could be substantially reduced by removing collection pages. (An even less substantial issue is that some automatically generated lists will list the development versions collections as well as the version articles themselves, resulting in somewhat inaccurate category/list population counts.)

Proposal:

Decide whether to keep change log collections or to get rid of them.
1. If it is decided to keep the collections, the placement of onlyinclude tags in individual version articles will need to be documented.
2. If it is decided to delete the collections, details of the deletion procedures will need to be discussed.
Decide whether to replace minimalistic version lists on the per-edition development versions pages with more informative versions.

--AttemptToCallNil (report bug, view backtrace) 18:54, 3 December 2018 (UTC)

There's not really much point in them. Want a list of all features? go to the 1.x page. Want to look through the specific snapshots? Go to YYwWWn and click the next= link. – Nixinova

19:01, 3 December 2018 (UTC)

Comment I use these pages. The main reason why is to find (using Ctrl+F) what snapshot a behavior was added in (usually so I can test bugs related to that feature, but others would have a different reason to do it). These pages are the most convenient way to do this, since that information isn't in the full article and the specific things I'm looking for generally aren't in the history section of an article (e.g. options changes). That would probably be solved by a more complete history section in those articles, but that's my current use case. --Pokechu22 (talk) 19:08, 3 December 2018 (UTC)

Oppose I like the collection pages. They are specially useful, if you search for a change but don't know in which snapshot it changed (e.g. research for an {{history}} entry). Without the collection you would need to click through all 40+ snapshot pages.

MarkusRost (talk) 19:12, 3 December 2018 (UTC)

Question There's not a single link to one of these collection pages in this topic, nor is one of them even named. I'm left wondering if I've ever even seen one of these; I don't remember ever seeing a giant version-related page full of transcludes. (That might be because I don't often concern myself with Java history stuff.) Are these pages actually linked on the wiki, or are they only available by typing a secret URL? – Auldrick (talk · contribs) 20:11, 3 December 2018 (UTC)

1.14/Development versions. Clicking "view all" in the infobox on any 1.x page. – Nixinova

20:17, 3 December 2018 (UTC)

Should we move all Tutorials pages to a own namespace?

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

Support, nothing else to add. FVbico (talk) 20:04, 5 December 2018 (UTC) The arguments from other people below actually convinced me, so it's become a No for me. FVbico (talk) 15:01, 29 January 2019 (UTC)

Support, but I don't think Tutorials:Main Page would be the right place to put an index. I like Tutorials:Index better, similar to how Help:Contents works on wikipedia (n.b. Help:Main Page redirects there too). --Pokechu22 (talk) 20:15, 5 December 2018 (UTC)

Support and Comment There is at least one subpage of Tutorials that is linked to directly from a main page, I think using a {{main}} template. (Sorry, off the top of my head I can't remember exactly which page it is. Maybe Enchanting? But there could be others, too.) If this gains consensus, I hope we can make a split between them. – Auldrick (talk · contribs) 21:16, 5 December 2018 (UTC)

There are actually a large amount of "normal" mainspace pages that are linked to Tutorials subpages, such as Carrot.-- Madminecrafter12^{Talk to me} 18:58, 11 December 2018 (UTC)

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

] 22:16, 5 December 2018 (UTC)

Strong oppose The proposal uses only cyclic argumentation (we should do it because it should be done) for support. I ever heard only one solid reason to move tutorials outside the main namespace (not even its current subpage pseudo-namespace) was that they were of poor quality, and people shouldn't see such poorly written pages when they click "Random page", but this is an argument for improving the tutorials rather than putting them somewhere where they're even less likely to be found. Are there any real reasons we should do this? --AttemptToCallNil (report bug, view backtrace) 09:10, 6 December 2018 (UTC)

Because the tutorials do not describe the game. They describe suggestions from player to player, and aren't really articlespace worthy within the vision of the wiki, in my opinion. They have a different tone, different set of editors, different audience and different intentions. – Jack McKalling [

] 09:24, 6 December 2018 (UTC)

Do we have a standard definition for what exactly the main namespace is for? --AttemptToCallNil (report bug, view backtrace) 09:36, 6 December 2018 (UTC)

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

Weak oppose Meh, I don't really see a good reason for this. One disadvantage is that if we do this, the pages will not show in the search bar because namespaces don't. The article namespace is for content relating to the game, which tutorials are, and I can't think of a reason why we need to go to the trouble to move these all to a new namespace and just complicate things.-- Madminecrafter12^{Talk to me} 13:41, 11 December 2018 (UTC)

Comment If we move the pages to a new namespace, we could make in the LocalSettings.php so these could show up by default in the search bar. --

psl85 (talk • contribs) 18:53, 11 December 2018 (UTC)

Oh, I didn't realize that was configurable; thanks for the enlightenment. However, again, I still don't see a good reason to do this and it would create quite a bit of extra work.-- Madminecrafter12^{Talk to me} 18:55, 11 December 2018 (UTC)

Support Per the above reasons and I would like to be able to block seeing these pages on recent changes. Also the namespace should be singular (Tutorial:) – Nixinova 03:46, 17 December 2018 (UTC)

Strong oppose It is specifically because the tutorial pages need fixing that they shouldn't be moved to a new namespace. Moving them to a different name-space doesn't fix tutorial pages, it just tries to hide them. Though the Minecraft Wiki is meant to explain factual data about the game, it cannot fully do that without the tutorial pages. Things such as redstone circuits, general farms, game quirks, functions, and information about the game's UIs all are stored within the tutorials. This is factual evidence that can only really be given in a tutorial format. I agree that the tutorial pages on this wiki are terrible, but the wiki needs tutorial pages, so instead of hiding them where they'll get edited less, the pages should be kept in the open so they're more likely to be maintained or fixed. -SuperDyl19 (talk) 06:29, 18 December 2018 (UTC)

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

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

Oppose - but only for part of the tutorials.

I'm persuaded both by Skylord wars' and SuperDyl19's reasoning. As SuperDy119 points out, the tutorial sections often are critical for users' understanding of how the game works, particularly for new users who might not have a good grasp of features like redstone mechanics or minecart functionality. As a new player, I referred to the redstone tutorials many times and still do on occasion, and I play with other experienced players who also will turn to the tutorial information to look up some specific kind of redstone circuit when needed. Not all of the tutorials are this kind of information, however, so maybe some of it should be organized separately, such as the "suggestions from player to player" information that has less to do with advanced or nuanced game mechanics and more to do with game strategy ideas.

As a rough analogy, moving or striking the tutorial section as being "not valid information about the game" would be like having a computer programming textbook that defines what variables and procedures are but that does not include any examples of actual working procedures. Many new programmers would find it difficult to understand how to write procedures and make them work within a program without seeing those examples. Such examples are definitely important to illustrate a particular core feature of the language.

Yes, the tutorial pages are in need of significant improvement in various ways (last I checked), and they may need to be reorganized to distinguish ones that are more fundamental to understanding how the game works from ones that merely offer suggested play strategies, but I'd argue that the former at least need to be kept as part of the main wiki space. —Memetics ^{talk | edits} 18:53, 27 April 2019 (UTC)

Thoughts on adding the "Java Edition" prefix to version pages

Now that this has calmed down a bit, what are people's thoughts on prefixing version pages with Java Edition?

Pros: Doesn't look like we have any bias, less confusion (in the long run; especially since bedrock version numbers are catching up to Java and we're gonna get to the point where it's "upcoming 1.17 and Bedrock Edition 1.17").
Cons: Have to move a whole lot of pages.

I, personally, am Neutral on this. – Nixinova 21:04, 20 December 2018 (UTC)

Oppose moving pages. Neutral on changing upcoming template behavior to include "java" prefix which would reduce confusion in that case. --Pokechu22 (talk) 21:13, 20 December 2018 (UTC)

Simulation distance

A while back the Options page contained the information about the technical details about the render distance sliders (increment info, # of chunks, such as: 2x increments starting at 6 chunks max 16-24 chunks, 4x increment starting at 8 chunks max 28-48 chunks etc). It's been removed and I copied that data over to a different page.

It's come to my knowledge that the simulation distance slider also varies with device just like render distance.

1 device has the simulation distance slider in 2 step increments starting at 4 chunks and ending at 8 chunks, another device has 2 step increments starting at 4 chunks and ending at 12.

Does anyone have the specific technical info about the sliders for the Simulation distance? Specifically the increments, starting number and max range of chunks.

Something like this:

Simulation distance chunks

a
4 chunks	4	4	8	8	8	8	8
6	6	6	12	12	12	16	16
8	8	8	16	16	16	24	24
	10	10		20	20	32	32
		12			24		40

and so on so forth

Delvin4519 (talk) 01:51, 25 December 2018 (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 LCE version history 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. – Nixinova 22:02, 27 December 2018 (UTC)

See User:Nixinova/PS4 1.83. – Nixinova

22:10, 27 December 2018 (UTC)

Support 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 …) --HaydenBobMutthew ^{(talk, contribs)} 06:22, 28 December 2018 (UTC)

Support, but only for the PS4 Edition instead of all editions. -BDJP ^(t|c) 11:19, 28 December 2018 (UTC)

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

Support. 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! Terronscibe (talk) 12:35, 14 January 2019 (UTC)

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

Features with different names for different editions

Some features have different names depending on the edition. For example, the block called “nether brick block” in Bedrock Edition is called “nether bricks” in Legacy Console Edition and “nether brick” in Java Edition. Currently, we use the name in Java Edition for the title of the page (e.g., the page about nether brick blocks is called “Nether Bricks”).

A few years ago, the Java Edition was simply called ‘’Minecraft’’, so it was reasonable to choose the Java Edition as the “default” Edition. However, since the Better Together Update, the Bedrock Edition was the edition that is simply called ‘’Minecraft’’. It is therefore reasonable to consider the Bedrock Edition the “default” edition.

For features with different names for different editions, we should move the pages so that the page titles would correspond to the Bedrock Edition name rather than the Java Edition name (e.g., Nether Bricks would be moved to “Nether Brick Block”. The Blobs 15:51, 31 December 2018 (UTC)

Support. We should also rename other pages like Snow to Top snow to make it persistent with other pages. Karadine once moved it, but it was quickly reverted by Dinoguy1000 and the page was protected. According to him, the name "Top Snow" is not an official name and should be discussed. --skylord_wars (talk) 16:26, 31 December 2018 (UTC)

That was what I could tell at the time. I don't have access to any Bedrock Edition release of the game, so I can't check names for myself. I will note, however, that to my knowledge, since that happened, no one else has come forward even claiming without proof that the BE name for Snow is Top Snow (though I'd be happy to be proven wrong, on either count here).

For the proposal itself, I support documenting alternate official names as a matter of course, but am ambivalent towards which edition to consider the "main" edition or whether to rename pages to reflect that. 「ディノ奴千？！」^{☎ Dinoguy1000} 16:35, 31 December 2018 (UTC)

Strong oppose. Without getting into ideological concerns, the 1.13 brought about The Flattening, which modernized and organized names. To my understanding, bedrock has not yet had that. Thus, the names from 1.13 should be considered more final. --Pokechu22 (talk) 19:02, 31 December 2018 (UTC)

Oppose per Pokechu22. -BDJP ^(t|c) 19:03, 31 December 2018 (UTC)

Strong oppose prr Pokechu22; additionally, we have confirmation from HelenAngel that bedrock will fillow the 1.13 names sooner or later (ie smooth sandstone is already renamed to cut sandstone as well. FVbico (talk) 19:26, 31 December 2018 (UTC)

Conditional support. I propose having it so that the name that is in more editions is the name of the page so we don't have any version bias. For example, snow would stay there since it's used in JE and LCE but not BE but rose red would be moved to red dye even before 1.14 is released. – Nixinova

19:42, 31 December 2018 (UTC)

No two editions have the same term for nether brick blocks, so your idea would not work universally. The Blobs 19:45, 31 December 2018 (UTC)

In that case the edition that has had the feature added first may have the priority, so as a result Nether Bricks would retain their name. — BabylonAS (talk | ru.Wiki Admin) 20:03, 31 December 2018 (UTC)

Bot's task request

Ag001bot (talk • contribs • logs • block log)

This bot will be used on:

Cosmetic changes
Repair interwiki links
Text replacement
Automatically welcome new users (Use with {{subst:Welcome}})
Automatically clean Sandbox
~~Automatically archive~~

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

Bump and . – Nixinova

04:11, 9 April 2019 (UTC)

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

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

Redirect PlayStation 4 Edition 1.82 etc. to Legacy Console Edition version history

Just a suggestion. What do you think? Note that these redirects will take the form "<edition> <version number>". --HaydenBobMutthew ^{(talk, contribs)} 11:03, 6 January 2019 (UTC)

Issues pages: keep them or delete them?

Argumentation taken from the Discord server:

FVbico [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? --AttemptToCallNil (report bug, view backtrace) 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. 「ディノ奴千？！」^{☎ Dinoguy1000} 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

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. –Sonicwave ^talk 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. --Pokechu22 (talk) 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. 「ディノ奴千？！」^{☎ Dinoguy1000} 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

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 Issues 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.--Madminecrafter12 ^{(Talk to me | View what I've done)} 21:23, 10 May 2019 (UTC)

Never mind, it looks like the Issues redirect was modified to point to Bug tracker instead. Well, either way I've added a hatnote on the Bug tracker page linking to Issues/notice, and would suggest to continue to have such a hatnote even if the issues pages are moved into the MCW namespace.--Madminecrafter12 ^{(Talk to me | View what I've done)} 21:24, 10 May 2019 (UTC)

Moved to MCW:Issues and its subpages. – Nixinova

23:00, 10 May 2019 (UTC)

Minigames page?

I propose a generic minigames page, where, like mods, people can create subpages explaining a certain minigame. Minigames are more relavant to the Minecraft than mods since they can be played in vanilla or semi-vanilla so I reckon they have more of a place on this wiki. Also, they aren't going to get quickly outdated since they don't necessarily apply to just one version of Minecraft. – Nixinova 05:11, 7 January 2019 (UTC)

I like the page, but I think it would be beneficial to clarify on both the minigames page and on the specific pages (such as Spleef) that they are not in any way official features, and are more player-made concepts or something similar. It's implied currently, but yeah. -PancakeIdentity (talk) 05:27, 26 May 2019 (UTC)

List of blocks and items

On the list of blocks and items, 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. an_awsome_person (talk) 04:12, 11 January 2019 (UTC)

Is "NBT tag" redundant?

FVBico and I disagreed on Discord about whether the phrase "NBT tag" is redundant because "NBT" is an initialism for "Named Binary Tag". FVBico suggested making edits to change the phrasing so that it's grammatically correct when you substitute the expanded name in the sentence, and opined that we should do so globally on the wiki. I think that's unnecessary and even harmful in some cases. We agreed to bring the discussion to the community.

In my opinion, NBT is an initialism that has become a word with its own denotation, something that popular initialisms do frequently (often even losing their original association with a phrase, as happened to "snafu" and "radar"). When we read such an initialism, we don't ordinarily translate it into the expanded phrase, but rather conceive of it as an independent thing. It functions as a noun in a sentence (even when the original wasn't a noun phrase, e.g. "snafu"), and therefore it shouldn't be judged grammatically as if the expanded phrase were substituted for it. In the specific case of NBT, we conceive it as referring to a method of coding, not to an individual tag as the expanded phrase would suggest. I leave it to FVBico to present his point of view, obviously. – Auldrick (talk · contribs) 17:31, 11 January 2019 (UTC)

Yes, it is redundant; it's an instance of RAS syndrome like "ATM machine". Both of these should be avoided IMO, because of the redundant expansion. --Pokechu22 (talk) 17:35, 11 January 2019 (UTC)

I would point out that the cited Wikipedia article contains a refutation by author Bill Bryson, who says "only the ultra-finicky would deplore them". – Auldrick (talk · contribs) 17:46, 11 January 2019 (UTC)

I agree with Auldrick. Yes, it's redundant, but No, it's not necessarily a bad form of redundancy. --AttemptToCallNil (report bug, view backtrace) 17:48, 11 January 2019 (UTC)

My opinion on the matter is that "NBT" could be seen as a short form of "NBT Format" which is a short form of "Named Binary Tag Format". In "NBT tag", the "NBT" doesn't mean the tag itself, but the format in which the tag is saved. (At least that's my interpretation of that.) I think using "NBT" instead of "NBT Tag" everywhere will make it more difficult to understand what's actually meant. Then again, you could just use "tag" instead of "NBT tag", but there are so many tags in Minecraft that this could get confusing as well. That's the reason why there's the "NBT" in front of it, so that you actually know what kind of tag it is.
TL;DR: my opinion would be No | violine1101^(Talk) 20:05, 11 January 2019 (UTC)

Just elaborating here, as already stated, "NBT tag" is a form of RAS syndrome, and the term is not short for NBT Format, but actually just "Named Binary Tag", as stated on the wiki as well. The "NBT tag" when referring to the name of a variable can easily be changed to use "key" instead, as string NBT (as in when used in commands) is actually derived from JSON format, which is key: value pairs, which is exactly the same in NBT, even block states are adressed this way, key=value pairs; when referring to the whole key:value pair, it can simply be called "the NBT". So any mention of "NBT tag" can actually easily be changed to not have RAS syndrome, while not making it hard to understand, and naming it "NBT tag" is bad grammar. FVbico (talk) 20:50, 11 January 2019 (UTC)

So you think we should say things like "NBT key" and "NBT value"? --AttemptToCallNil (report bug, view backtrace) 20:53, 11 January 2019 (UTC)

It would be equally clear, if not even more clear, and be grammatically correct. FVbico (talk) 20:58, 11 January 2019 (UTC)

Clarifying, I did not say that "NBT" is short for what Violine calls "NBT Format", but that it denotes it. The difference is important. Furthermore, redundancy isn't a grammatical issue, it's a style issue. Grammar is concerned with structure, not meaning. Grammatically, "NBT tag" is an ordinary attributive noun phrase. – Auldrick (talk · contribs) 21:18, 11 January 2019 (UTC)

Being a non native English speaker I still feel "NBT tag" is a little redundant, and that just using "NBT" is not precise enough. I would opt for doing "NBT data" or "NBT key/value", as it feels correct without loosing its meaning if expanded. Holroy ^{talk◆contribs} 23:38, 11 January 2019 (UTC)

I was thinking of that exact solution as well. Fully agreed. – Jack McKalling [

] 09:17, 13 January 2019 (UTC)

But without disagreeing with Holroy here, I wanted to add/clarify that "NBT" isn't an accurate acronym for what it actually means. It stands for something what the format contains many instances of, which isn't a really good name for a format. However, using the acronym as an adjective to any noun like in "NBT tag", will have the same meaning as if you were just calling it a "Mojang tag", as it has nothing to do with what the acronym stands for but is just a plain adjective trying to differentiate what kind of tag this is. So there is an ambiguous meaning here to begin with. Although I feel this "tag" differentiation is more important than it is meaningfully common for someone to actually know what the acronym stands for, because of the many, many different kinds of "tags" that are there already, a different phrasing altogether would be best. – Jack McKalling [

] 00:13, 15 January 2019 (UTC)

Any further opinions? If not, this discussion kind of hit a dead end with support and opposes being balanced out.

To everyone who opposed, what do you think about replacing it with "NBT key/value" when referring to the tag name or value, and "the NBT" when referring to the full pair? FVbico (talk) 13:33, 7 March 2019 (UTC)

Although I, too, find the redundancy slightly annoying (similar to "PIN number"), I feel that this is an instance of needing to honor and record the term that the Minecraft community commonly uses, rather than risk creating confusion by trying to change it. Let it remain QWERTYed into the lexicon. —Memetics ^{talk | edits} 10:41, 28 April 2019 (UTC)

I support "NBT key" and "NBT value", but not "the NBT" because I think that's more confusing. Given you propose to use this to refer to a full pair, I propose using "NBT pair" instead. However, I'm not that proficient with Minecraft technical terminology, so this term may be inaccurate. --AttemptToCallNil (report bug, view backtrace) 20:29, 20 May 2019 (UTC)

I can agree to that. FVbico (talk) 20:40, 20 May 2019 (UTC)

NBT tag is redundant, however, I think it has been used to such extend now, that this form of RAS syndrome has literally been petrified. Changing it now to something different would, in my opinion, raise eyebrows. This does not take away that I'd support NBT key for the tag's name and NBT value for the tag's value and NBT data for a set of NBT tags (or should I say a set of NBT key/value pairs? {so lengthy...}).

In short, NBT tag is a form of redundancy, however, this expression has become petrified and thus I no longer consider it a redundancy. If you want to use other expressions than NBT tag, be my guest, but don't be surprised some eyebrows are raised. —DarkShadowTNT (t ♦ c) 20:54, 20 May 2019 (UTC)

Oh yeah, "petrified". 🙃 --AttemptToCallNil (report bug, view backtrace) 21:17, 20 May 2019 (UTC)

Should we make a "farmable" section on item pages?

It isnt exactly the same as "renewable", but it can be an extra option for it. What I'm reffering to here is if it can be renewed without player interaction. Just a suggestion.–Preceding unsigned comment was added by AFellowEditorLikeYou (talk • contribs) at 1:47, 14 January 2019 (UTC). Please sign your posts with ~~~~

I don't really understand this. Can you give examples of "farmable" items and items that are renewable but not "farmable"? an_awsome_person (talk) 16:43, 27 January 2019 (UTC)

Items renewable only through trading would not be farmable.

Oppose I don't really see a use for this. I understand the difference, but it gets muddy with the inclusion of redstone and such. Are logs just renewable because saplings need to be planted by the player, or farmable because they can be broken and gathered without player interaction? Renewable works perfectly fine imo. -PancakeIdentity (talk) 05:30, 26 May 2019 (UTC)

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:

This article is a stub.

You can help by expanding it.

This feature is exclusive to Java Edition.

This article describes content that may be included in a future update.

This content has appeared in development versions, but the full update containing it has not been released yet.

– Nixinova 03:34, 17 January 2019 (UTC)

I wrote a custom template for the Russian wiki to address the issues I see with message boxes. You can see two these templates on the admin noticeboard (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... --AttemptToCallNil (report bug, view backtrace) 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? – Jack McKalling [

] 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?). --AttemptToCallNil (report bug, view backtrace) 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

18:55, 17 January 2019 (UTC)

Even that would be better than what we have now. --AttemptToCallNil (report bug, view backtrace) 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? --AttemptToCallNil (report bug, view backtrace) 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. - User-12316399 (talk) 13:29, 17 January 2019 (UTC)

I personally like the History template as it is but the others definitely need reconsidering. – Nixinova

18:54, 17 January 2019 (UTC)

Here's a table that I made, 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. - User-12316399 (talk) 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. - User-12316399 (talk) 13:12, 5 February 2019 (UTC)

No support for flattening, No strong opinion 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. --Pokechu22 (talk) 16:50, 20 January 2019 (UTC)

Support making large tables easier to navigate. Another large one isn Template:Tutorials. 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 Jahunsbe (talk • contribs) 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. --AttemptToCallNil (report bug, view backtrace) 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. jahunsbe (talk) 03:29, 23 January 2019 (UTC)

McEdu

Hi ! I made a few edits on the wiki, mainly about McEdu : Special:Contributions/User-100138291 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. --User-100138291 (talk) 16:23, 17 January 2019 (UTC)

Hi user-100138291! 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 GDPR (I can explain that in more detail if you'd like). Thank you for contributing to the wiki and I hope you continue!-- Madminecrafter12^{Talk to me} 18:44, 17 January 2019 (UTC)

Thank you very much. I hope I'm not making any mistake by trying to correct some... --User-100138291 (talk) 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! --Pokechu22 (talk) 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. – Nixinova 22:03, 18 January 2019 (UTC)

@Nixinova: There is. Minecraft Wiki:Style guide/Versions#Fixes 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.-- Madminecrafter12^{Talk to me} 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 "bug titles shouldn't end with a period" thing is mostly me being pedantic, but I still think it's correct (they are titles, not complete sentences). --Pokechu22 (talk) 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. – Nixinova 20:15, 16 January 2019 (UTC) Ping – 04:41, 24 January 2019

Support based on above reasoning. –Sonicwave ^talk 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

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. – Nixinova, 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. – Nixinova, 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 (pages with absolutely no translation work are already agreed to be deletable instantly - 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? - User-12316399 (talk) 16:53, 23 January 2019 (UTC)

Support, I find the OP's argumentation satisfactory. --AttemptToCallNil (report bug, view backtrace) 18:17, 23 January 2019 (UTC)

Support Nuke them all. I find it very annoying having so many of these outdated pages cluttering everything. – Nixinova

19:04, 23 January 2019 (UTC)

Support 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. 「ディノ奴千？！」^{☎ Dinoguy1000} 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 Special:WantedPages (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 this. - User-12316399 (talk) 13:26, 29 January 2019 (UTC)

There's now several extremely old and outdated translation pages awaiting deletion. - User-12316399 (talk) 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. –Majr ᐸ Talk
Contribs 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. - User-12316399 (talk) 13:28, 25 February 2019 (UTC)

Wiki cleanup

I propose the following changes:

Export subpages of mods to ftb: and nuke it.
Nuke custom servers
- “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)
Delete translation projects older than 4 years (see directly above).
- 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)

Thoughts? – Nixinova 23:31, 23 January 2019 (UTC)

For the first one, we should finally stop talking about it and do it. I Support the other two points as well. --AttemptToCallNil (report bug, view backtrace) 22:33, 24 January 2019 (UTC)

Not sure what to do specifically. 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 programs and editors. 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. --Pokechu22 (talk) 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 programs and editors. The wiki shouldn't be a database of third-party software. WP:INDISCRIMINATE applies. – Nixinova

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. --Pokechu22 (talk) 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 Mods 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.-- Madminecrafter12^{Talk to me} 14:25, 25 January 2019 (UTC)

We need FTB Wiki admins to import the pages we export. Beyond that, probably nothing. --AttemptToCallNil (report bug, view backtrace) 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 Xbony2 is an admin over on FTB.-- Madminecrafter12^{Talk to me} 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. – Jack McKalling [

] 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. 「ディノ奴千？！」^{☎ Dinoguy1000} 10:15, 26 January 2019 (UTC)

Dinoguy1000 Yeah, but how would he be able to export if he doesn't have admin rights?--Madminecrafter12 ^{(Talk to me | View what I've done)} 20:20, 31 January 2019 (UTC)

You don't even need to be logged in to export pages. --AttemptToCallNil (report bug, view backtrace) 20:25, 31 January 2019 (UTC)

Hmm, thanks, I didn't know that. So it's just import that requires admin rights.--Madminecrafter12 ^{(Talk to me | View what I've done)} 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. Nupanick (talk) 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. – Jack McKalling [

] 14:33, 14 May 2019 (UTC)

User pages

On the topic of cleaning up the wiki: it seems a lot of pages belonging to inactive users link to either a lot of relatively useless and outdated redirects, or straight up redlinks and missing files. Could we have the option to outright blank inactive userpages (I'd say before January 1, 2017 would be a reasonable cutoff date), removing these redlinks in the process, and possibly including a template on the page stating the action taken (similar to the box placed on inactive user talk pages)? Of course, if the user ends up returning, they can revert this blanking at will, hopefully fixing up their page in the process as well.

The only main concern I have regarding this is userpage images; removing these from the page would result in them possibly being linked to from nowhere, and would likely result in their deletion, which may be undesirable. Might be prudent to keep such images linked somehow, for example in a gallery, for their preservation, although this might not be the most visually desirable option. - User-12316399 (talk) 11:55, 29 January 2019 (UTC)

Support, and the gallery could be wrapped in a display: none div which will render it invisible, but keep the images "used" from the engine's perspective. --AttemptToCallNil (report bug, view backtrace) 12:03, 29 January 2019 (UTC)

I've went ahead and created Template:InactiveUserpage. I might pop it on a few of the more notorious pages later on. - User-12316399 (talk) 08:59, 30 January 2019 (UTC)

I don't see any reason to avoid performing basic maintenance on userpages such as updating/removing links to pages that have been renamed or deleted. I have no objections to simply blanking old userpages when the user hasn't edited for some time (I do it myself on another wiki I edit regularly), but I do think it should be left to the discretion of the editor performing the cleanup whether they want to just blank the page, or take the time to actually fix the issues with it (though on the gripping hand, I'd be surprised if many people chose not to blank, since blanking is much easier and faster). 「ディノ奴千？！」^{☎ Dinoguy1000} 11:18, 30 January 2019 (UTC)

Considering changing the cutoff date to August 1, 2018 (from January 1, 2017); this will cover all userpages created before the Update Aquatic and therefore before the removal of numeric IDs. Any objections? - User-12316399 (talk) 22:33, 14 May 2019 (UTC)

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. – Nixinova 00:17, 30 January 2019 (UTC)

I don't object, but if the content has special significance, we could either keep the page or move the content elsewhere. --AttemptToCallNil (report bug, view backtrace) 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. MCW:Requests for Comment should be created where we add important discussions (like the above). – Nixinova 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.-- Madminecrafter12^{Talk to me} 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. --AttemptToCallNil (report bug, view backtrace) 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. FVbico (talk) 14:25, 25 January 2019 (UTC)

Sorry, I should have said "unresolved" there as well. --AttemptToCallNil (report bug, view backtrace) 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. -- psl85 (talk • contribs) 17:41, 24 January 2019 (UTC)

Weak oppose. 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.-- Madminecrafter12^{Talk to me} 14:14, 25 January 2019 (UTC)

Oppose, 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. --AttemptToCallNil (report bug, view backtrace) 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 wp:BLP? 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. --AttemptToCallNil (report bug, view backtrace) 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. Frisk (Talk page) 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: wp:BLP exists to protect Wikipedia from legal liability. Someone from Gamepedia/Curse (Game widow?) should be part of this discussion. – Auldrick (talk · contribs) 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. — Game widow ^(talk) 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. JSBM (talk) 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 Nathan Adams § Trivia). This plays in to things like the removed ruby. --Pokechu22 (talk) 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. JSBM (talk) 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. – Sealbudsman talk | contribs 21:57, 11 May 2019 (UTC)

Infobox item images are improperly scaled. Reupload?

Based on this original suggestion by Majr. 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. --AttemptToCallNil (report bug, view backtrace) 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.

// JavaScript code
$(function() {
	var blockedDiv = $(".blocked");
	if (blockedDiv.length > 0) {
		var usernameSpan;
		var username;
		var targetBlock = $(".userinfo");
		if ($("#mw-mf-viewport").length > 0) { // Detect mobile mode
			usernameSpan = $("#section_0");
			username = usernameSpan.html().match(/UserProfile:(.*)/)[1];
		} else {
			usernameSpan = $("h1 .mw-headline");
			username = usernameSpan.attr("id");
		}

		$('<div class="blocked-no-stamp">').append(
			$('<span>')
			.append("This user is currently blocked! ")
			.append($("<a>")
				.attr("href", "https://minecraft.gamepedia.com/index.php?title=Special:Log/block&page=User%3A" + username)
				.attr("title", "Block log")
				.text("Check the block log")
			).append(" • ")
			.append($("<a>")
				.attr("href", "https://minecraft.gamepedia.com/Special:GlobalBlockList?wpTarget=" + username)
				.attr("title", "Global block log")
				.text("List global blocks")
			).append("")
		).appendTo(targetBlock);
	}
});

/* CSS code */
.curseprofile .blocked {
	display: none;
}

.blocked-no-stamp {
	clear: right;
}

.skin-minerva .blocked-no-stamp {
	float: right;
	text-align: right;
}

.blocked-no-stamp span {
	font-weight: bold;
	font-size: 125%;
}

Enhancement suggestions are welcome. I consider seeing this, or something like this, becoming the default to be a major victory for the community. --AttemptToCallNil (report bug, view backtrace) 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: ~~Example~~ (blocked). Any links you want/need could be added within those brackets then. – Jack McKalling [

] 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. --AttemptToCallNil (report bug, view backtrace) 11:59, 29 January 2019 (UTC)

Look in the searchbar, the image with a person with a forbidden sign can we use as icon on blocked users' pages.

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

psl85 (talk • contribs) 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. --AttemptToCallNil (report bug, view backtrace) 14:25, 29 January 2019 (UTC)

@AttemptToCallNil: 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 🙂😃 --

psl85 (talk • contribs) 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. --AttemptToCallNil (report bug, view backtrace) 14:35, 29 January 2019 (UTC)

Okay, I understand that. Okay 😄 --

psl85 (talk • contribs) 14:37, 29 January 2019 (UTC)

Use official Mojang trailers over slicedlime videos?

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

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

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

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? - User-12316399 (talk) 21:15, 1 February 2019 (UTC)

If you'd like to do that then yes. – Nixinova

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? - User-12316399 (talk) 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. – Nixinova 02:35, 15 February 2019 (UTC)

~ This is planned to go through when the Java rename is completed. – Nixinova

06:30, 27 February 2019 (UTC)

New bureaucrat

The result of the discussion was Promote.

Since Dinoguy1000 has sadly retired, there have been several discussions on Discord 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, --Madminecrafter12 ^{(Talk to me | View what I've done)} 18:32, 22 February 2019 (UTC)

Sure – Nixinova

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 Support. I would also support Orthotope and KnightMiner for bureaucrat, as they've been here for a long time. – Jack McKalling [

] 08:52, 24 February 2019 (UTC)

Support both User:Madminecrafter12 and User:Orthotope to be bureaucrats. I say Neutral to User:KnightMiner because he are not so much active. User:Madminecrafter12, and User:Orthotope: What should you do if you want to be bureaucrat? --

psl85 (talk • contribs) 07:05, 25 February 2019 (UTC)

Hi Psl85, 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".--Madminecrafter12 ^{(Talk to me | View what I've done)} 13:41, 25 February 2019 (UTC)

Support 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. –Sonicwave ^talk 07:29, 25 February 2019 (UTC)

Comment 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 Agree 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. –KnightMiner · (t) 02:23, 27 February 2019 (UTC)

@KnightMiner: 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.--Madminecrafter12 ^{(Talk to me | View what I've done)} 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. –KnightMiner · (t) 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.--Madminecrafter12 ^{(Talk to me | View what I've done)} 02:56, 27 February 2019 (UTC)

@Majr: 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?--Madminecrafter12 ^{(Talk to me | View what I've done)} 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. –Majr ᐸ Talk
Contribs 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]. It remains a working link and doesn't put the page on the wanted page list. – Nixinova 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. –Majr ᐸ Talk
Contribs 05:43, 1 March 2019 (UTC)

Auto-refresh button on recent changes?

Can we please add an "Auto-Refresh"-button on special:recentchanges, special:watchlist, 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 Support that this would be added. Any suggestions or opinions? -- psl85 (talk • contribs) 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. – Jack McKalling [

] 08:10, 2 March 2019 (UTC)

@Jack McKalling: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 here 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 special:recentchanges and the watchlist.--

psl85 (talk • contribs) 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 edit with revision ID 1 million. 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. --AttemptToCallNil (report bug, view backtrace) 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. -BDJP ^(t|c) 18:42, 1 March 2019 (UTC)

About File:SchematicSprite.png

I have made a new version of the sprite because of the outdated textures (e.g. wool, water, lava) in the current sprite sheet, but I can't upload it. Do you accept the new textures in the new sprite sheet? --HaydenBobMutthew ^{(talk, contribs)} 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. FVbico (talk) 13:26, 11 March 2019 (UTC)

While on the subject, glazed terracotta 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. jahunsbe (talk) 17:03, 12 March 2019 (UTC)

Clock circuit, Logic circuit, Pulse circuit, Memory circuit, Transmission circuit

Should these pages really be at the location they're currently at? The scope of these pages makes me feel as though these would all be much better as subpages of Tutorials, rather than as top-level mainspace articles. - User-12316399 (talk) 12:30, 12 March 2019 (UTC)

Weak oppose. According to MCW:NOTABILITY, "Gameplay strategies, guides, how-to's, etc., should be subarticles of Tutorials." The redstone articles are more like a encyclopedia than most tutorial pages. Tutorial pages are usually aimed more at readers wanting to construct something rather than to learn about something. That doesn't necessarily mean they couldn't go under tutorials though. jahunsbe (talk) 13:30, 12 March 2019 (UTC)

Oppose. But I agree at the same time, that they're not right in their current state. These pages are not tutorials in the same sense of the word like the other tutorials. They are indeed more about documenting something rather than guiding you through something. These pages are documenting game mechanics, and are using a completely different tone than any other "tutorial". Similar to enchantment mechanics, which has been (in my opinion) erroneously moved to a subpage of Tutorials. I bet there are more examples of this, like anvil mechanics, village mechanics. You can see the pattern here. In my opinion we should rather be looking for a new top level page, like Mechanics (for game mechanics, redstone mechanics, anything about not specifically one particular game object), next to the tutorial one, and then move all these pages as a subpage of that instead. – Jack McKalling [

] 14:57, 12 March 2019 (UTC)

Proposal

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

So I propose the following page structure. There may be more pages that should belong in here but I just listed some examples, you may add more if you know of any. – Jack McKalling [ ] 09:01, 26 April 2019 (UTC)

If what Jack's suggesting is that Mechanics is its own section, not part of Tutorials but on the same level as Tutorials, then I Support . —Memetics ^{talk | edits} 05:58, 27 April 2019 (UTC)

Yes that is what I'm suggesting. Currently the Mechanics page redirects to a really old and outdated subpage of Tutorials, and is not the kind of page I was thinking about. I didn't link it for the reason that I'm thinking of a completely new page, similar to Java Edition guides. That one, this new Mechanics page, as well as the Tutorials page, in this proposal, would all be top level pages that provide a neat overview of all their subpages. – Jack McKalling [

] 07:20, 28 April 2019 (UTC)

Support – Nixinova

06:26, 27 April 2019 (UTC)

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? Mincerafter42 (talk) 22:57, 25 March 2019 (UTC)

This should answer your question: Minecraft Wiki:Standardized views. jahunsbe (talk) 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.Mincerafter42 (talk) 00:21, 26 March 2019 (UTC)

Hi Mincerafter42, 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, --Madminecrafter12 ^{(Talk to me | View what I've done)} 00:59, 26 March 2019 (UTC)

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

The concept of "raw materials" is mentioned at Template:Items, Item#Raw_materials, and Category:Raw materials; however it doesn't appear to be a distinction made in-game. Each page also categorizes items differently (Template:Items lists glass bottles and sticks as raw materials, while the Items page puts them under manufactured).

The Items page has "Raw materials are used for crafting, brewing, and smelting other items and blocks.", but that can include anything that's used in a recipe, such as bows being used to craft dispensers. The category page says "Raw resources in Minecraft used to create other resources", which is also somewhat vague.

In my opinion, the "raw materials" classification should be defined better if we decide to keep them in the first place. I'm thinking something like "Items and blocks used for crafting, brewing, and smelting other items and blocks, and are not themselves craftable or smeltable", which would exclude things like bows. However I'm not sure if "raw materials" or "manufactured" is necessary in the first place. Many other items that fit into either category (e.g. green dye or arrows) are placed in more specific categories instead, leaving only 10-20 items in the "manufactured" category. There could simply be a "miscellaneous" category instead, which might be less confusing. –Sonicwave ^talk 22:20, 4 April 2019 (UTC)

Support removing the concept of "raw materials". Doesn't make much sense given a lot of very different things can become "raw materials", and the common definition for the class seems arbitrary and useless: what really depends on whether an item is a "raw material" or not? --AttemptToCallNil (report bug, view backtrace) 19:56, 5 April 2019 (UTC)

Support Several months ago, I proposed replacing several of the item classifications, including raw materials and manufactured, and with a simple list of all items. I think they are unnecessary and have vague definitions. So I would support just about anything that involves removing item classifications. an_awsome_person (talk) 00:54, 6 April 2019 (UTC)

Support removal of both raw materials and manfuactured classifications. -BDJP ^(t|c) 03:51, 9 April 2019 (UTC)

The method we should go with is automatic categorisation based off values in the infobox, e.g. add [[Category:{{{type|}}}]] to {{Items}}. That would be easy to deal with and less vague. – Nixinova

04:02, 9 April 2019 (UTC)

There does not seem to be any reason we can't go ahead with disbanding that category. No objections and no arguments against, with substantial arguments for it. Anyone up for the task? --AttemptToCallNil (report bug, view backtrace) 21:55, 8 April 2019 (UTC)

Could also get rid of passive/neutral/hostile mobs classification while we're at it... --AttemptToCallNil (report bug, view backtrace) 22:11, 8 April 2019 (UTC)

Can we remove block classifications (plants, mechanisms, utility, etc.), too? an_awsome_person (talk) 15:36, 20 April 2019 (UTC)

Support - and I support replacement of hostile/neutral/passive with expanded overview text instead. Also block classifications, unless someone has good reasons why they should be kept. —Memetics ^{talk | edits} 11:22, 28 April 2019 (UTC)

I don't think I can edit the infobox templates, but can I remove the classifications on the block and item pages? I want to replace them with a table of all blocks or all items, like what I have on my user page right now. an_awsome_person (talk) 17:35, 28 April 2019 (UTC)

Voiced over pages

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

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

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

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

InvSprite is out of memory again

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

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

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

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

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

They aren't? Hmm, that's too bad. How difficult would it be to allow multi-page InvSprites?--Madminecrafter12 ^{(Talk to me | View what I've done)} 13:41, 21 April 2019 (UTC)

A system of completely multi-page sprites would also have other limitations. For example, it would be difficult to move sprites between pages. There would not be a centralized location to edit all sprites.

The real issue is the pre-generated sprite list. There is no other significant limitation to sprites: we're over 2000 (probably over 3000 now!) sprites for InvSprite, and the file size isn't a quarter of the 8 MB maximum (plus, I almost don't doubt this maximum can be doubled upon request).

Whatever the new system of sprites will be, it needs to:

1) allow as easy sprite sheet editing as the current one, both using the sprite editor and manually (given translating the sprite is easier manually especially if external Lua scripts are used to assist with translation);

2) not be much harder to maintain than the current one (meaning the restructuring of sprite data, like addition of a new field for IDs, should not require extensive rewrites to complex JS);

3) not be too complex to translate;

4) not be prohibitively difficult to develop.

Any system where sprites are split would be relatively easy to develop, but difficult to maintain and difficult to modify.

Any other system I can think of requires runtime-generation of the sprite list, which either complicates manual editing or requires implementing a Lua parser in JavaScript.

Does anyone have any ideas? --AttemptToCallNil (report bug, view backtrace) 14:50, 21 April 2019 (UTC)

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

How about keeping all invsprites in one definition file like they are right now, but split them into categories, such as "current", "old revision", "colour states" etc, and document these separate categories on different pages? I don't know much about lua or sprites, but just an idea. – Jack McKalling [

] 07:06, 22 April 2019 (UTC)

I say that while we are not at a limit of the sprite sheet, its a lot more effort than its worth to split into multiple docs. The issue comes down to what do you logically split at so it remains in space for the sprite editor.

Personally, I say just move all the legacy stuff to another sheet once 1.14 releases, as by that point none of the main pages would still need them. I honestly cannot think of a good reason to keep every single old version on the main sheet anyways, it not like the crafting templates specifically call for the old textures ever. –KnightMiner · (t) 19:37, 22 April 2019 (UTC)

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

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

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

To-do

1.14 is out, and since it changed all the textures, we need to modify a lot of things:

Move current invsprite to a separate template, to maintain the pre–Texture Update textures.
Change usages in the history section to point to ~~this new template~~ revision n files.
Move all images to a separate file ~~and move the TextureUpdate files there~~.
- Again, update the history section to point to these.
Add all texture update files to their respective pages ("Changed the texture of PAGENAME.").

– Nixinova 19:56, 23 April 2019 (UTC) edited 23:09, 10 May 2019 (UTC)

I'd say we split InvSprite up a bit more, just so we don't run into memory issues. InvSprite could be split up into BannerSprite for banners, SlotSprite for slot icons as well as the "tool needed" icons the wiki uses, a template for old item sprites, and a template for old block models in the inventory. - User-12316399 (talk) 20:03, 23 April 2019 (UTC)

That would work. – Nixinova

20:26, 23 April 2019 (UTC)

Regarding InvSprite, I disagree with splitting it up just like that, after all, it solves nothing. Also, go here regarding discussing the InvSprite issue. FVbico (talk) 20:36, 23 April 2019 (UTC)

Present or past tense in lead section of a version release?

Recently the Java Edition 1.14 and other versions' pages were modified to switch the tense of the lead section to the past. But I don't agree with this. I'm convinced the text about what the update does should be present simple perspective, and just the release date part of it in the past. Because only the release of an update lies in the past, everything else about the update is present. Anyone can choose any version of the game to play at anytime they want, using launcher profiles, so it doesn't make sense to force the contents of an update to reside in the "past", it will confuse the perspective even if it is supposedly in a player's present or even future. Present simple is the default for this. For example, in my opinion it should be phrased like:

1.14, the first release of Village & Pillage, is a major update to Java Edition that was released on April 23, 2019. It focuses mainly on villages, adds (...)

Just because the update happened in the past, doesn't mean its content is as well. It is a product that is still available right now, and so is its content. Like a car, it may have been designed in the past, but it can still be bought right now. Pinging Nixinova, as you were involved in this edit (series). – Jack McKalling [ ] 08:31, 25 April 2019 (UTC)

Present tense for me. The argument that it shouldn't use present after it released is wrong, since it should be in future tense until it releases ("will add", "will focus", etc) if not present. Past tense just seems silly. --Pokechu22 (talk) 15:51, 25 April 2019 (UTC)

Present if the version of the game is currently accessible and playable (e.g. through the launcher). If we're talking about a future update, then we use future tense, and if the version is lost/unavailable, past tense. - User-12316399 (talk) 16:00, 25 April 2019 (UTC)

Do you both then also agree that the part about the release date should always be past tense though, unless of course it hasn't happened yet? – Jack McKalling [

] 16:02, 25 April 2019 (UTC)

"1.14 is an update to Java Edition that was released in 2019." That does make sense, so it should be past tense if is/was is present and referring to a past date. - User-12316399 (talk) 16:28, 25 April 2019 (UTC)

Yeah, the release date should be in past tense, "was released", and anything directly related to the release probably should be too; however attributes of the update itself should be present IMO. The closest example elsewhere I can think of is television episodes — pulling up a random one from wikipedia (Gridlock (Doctor Who)), with present tense in blue and past tense in red:

“	"Gridlock" is the third episode of the third series of the British science fiction television series Doctor Who, which was first broadcast on BBC One on 14 April 2007. It was written by Russell T Davies and directed by Richard Clark. The episode is set five billion years in the future on the planet New Earth, a planet humanity settled on following the destruction of the Earth in the 2005 episode "The End of the World". In the episode, alien time traveller The Doctor (David Tennant) and his new travelling companion Martha Jones (Freema Agyeman) discover the remainder of humanity on the planet live in perpetual gridlock within the Motorway, a highway system beneath the city state of New New York. When Martha is kidnapped, the Doctor races to find her before she enters the dangerous "fast lane".	„
	— Wikipedia on Gridlock (Doctor Who)

I think the same style makes perfect sense here as well. --Pokechu22 (talk) 19:10, 25 April 2019 (UTC)

Present per Pokechu22. -BDJP ^(t|c) 16:05, 25 April 2019 (UTC)

Past. The update is in past tense—the version isn't being "updated" anymore—but if you then say "1.7 is a version of Java Edition" that is fine. It also doesn't make sense to have one word in present tense while the rest of the paragraph is in past. "1.x was an update to Java Edition released on x y z that added a b c d and e" reads better than "1.x is an update released". – Nixinova

19:51, 25 April 2019 (UTC)

The difference between version and "update" is irelevant in my opinion here, as we're documenting the version of the game anyway. How it works, how it looks, what it has, what it does, and what it thinks, if that were a thing. In other words, the page is describing the product, not the event. For the reason that readers will be reading and interpreting it as a version of the game, and not as a point in time when stuff happened. – Jack McKalling [

] 19:58, 25 April 2019 (UTC)

present per Pokechu's example, as that's exactly how I understand the tense of iteratively released content which remains available. – Sealbudsman talk | contribs 22:09, 11 May 2019 (UTC)

Why haven't we reached consensus yet about this? Nixinova, you're the only one so far who wants to put everything in past tense. In my example above, I'm using past tense for the date-related aspect of the update, and put the content it contains in present tense. This is what I think is the best way, and all others who have replied to this discussion so far. Do you have any argument against this suggestion other than your preference? – Jack McKalling [

] 07:57, 1 June 2019 (UTC)

I still prefer past tense. 1.4.2 was a major update to Minecraft (Java Edition) released on October 25, 2013, which added a number of new mobs... reads much better than

1.4.2 is a major update to Minecraft (Java Edition) that was released on October 25, 2013, which adds a number of new mobs...

. When you say "update" you think of something new – this update occured many years ago, and as such using past tense sounds better. – Nixinova

08:04, 1 June 2019 (UTC)

How about we don't call it "update" but just "version"? Would you then agree on the tense used in my suggestion above? You're completely ignoring the argument that the content of a release is not exclusive to the past, but is still available. Keeping all content described as happened in past tense is confusing some people and we need to address that. Your argument is purely your own preference, and I can't think of a different way to address that too. – Jack McKalling [

] 08:22, 1 June 2019 (UTC)

Categorize images of generated structures and other images?

Should we categorize images of etc. generated structures, such as fossils to Category:Fossils or pillager outposts to Category:Pillager outposts? Then, sub-structures could be categorized to a subcategory, such as zombie villages to Category:Zombie villages and then add "Category:Villages" to the zombie villages category, so the images of generated structures are easier to find. Any suggestions? -- psl85 (talk • contribs) 12:38, 25 April 2019 (UTC)

You can already find images of generated structures on their mainspace articles. Why do you think searching in categories is easier than searching in the gallery section of a mainspace article? an_awsome_person (talk) 01:03, 7 May 2019 (UTC)

Phantom links from Template:Extension DPL

This, among other pages, appears to be linked from the page Template:Extension DPL despite no link existing and the page itself appearing to be auto-generated. These phantom links seem to be persistent and have remained on WantedPages for quite a while now. What's going on here, and can it be fixed? - User-12316399 (talk) 07:57, 29 April 2019 (UTC)

Maybe the Module:Development versions has a bug where it doesn't correctly prefix "Java Edition" to links? I don't know lua. – Jack McKalling [

] 08:51, 29 April 2019 (UTC)

Fixed it with a null edit to Template:Extension DPL. This list of pages there created the link. Why do you even have that list there? It's just the same as Special:WhatLinksHere/Template:Extension DPL. We don't do that for other templates and it just creates cached red links for deleted pages that require a null edit.

MarkusRost (talk) 15:31, 29 April 2019 (UTC)

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

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

What should I do to solve this bug? -- psl85 (talk • contribs) 16:16, 6 May 2019 (UTC)

I found a bug in your common.js. Try now. --AttemptToCallNil (report bug, view backtrace) 16:35, 6 May 2019 (UTC)

AttemptToCallNil Thank you 😛 what was the bug? --

psl85 (talk • contribs) 18:03, 6 May 2019 (UTC)

I explained it in the summary of the edit I made to your common.js. --AttemptToCallNil (report bug, view backtrace) 18:11, 6 May 2019 (UTC)

The code that Attempt commented out, caused the entire body itself of the page effectively be removed from it, in case it had the "show-ads" class. You could just try removing only the class to prevent the ads, instead of the whole element, if that effect is what you intended with that particular code. – Jack McKalling [

] 21:09, 6 May 2019 (UTC)

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

Just a thought. For an example, take Wool. Can we have the infobox display the white wool render by default (static), then have it switch to whatever render is associated with the invslot the user clicks? Such as if the red wool invslot is clicked, display the red wool render as the main image, and the same for all other variants.

I think this is better than having an unstoppable and uncontrollable animation of 16 images. --AttemptToCallNil (report bug, view backtrace) 21:34, 8 May 2019 (UTC)

I like the idea, though accessibility is a concern (though equally, invslot has accessibility issues which I brought up on a module talk page that nobody seems to have noticed). But, ignoring that, maybe it'd be best to have the animation automatically cycle, but clicking an individual image would set it to that one and stop the cycling? --Pokechu22 (talk) 22:23, 8 May 2019 (UTC)

Since you've brought it up, I do remember that when I was a reader of the MCW who knew nothing about how it worked from the technical side, I found it annoying that some block images were replaced by others before I could take a good look at them. I'd definitely support fixing this, but I'm not sure how. I'm a bit skeptical of having only one image appear unless the reader clicks an InvSlot; something like Pokechu's idea might work better, though if we replaced the left-clicking an image functionality with stopping the cycling, that wouldn't allow the easy maneuver to the file's own page, which could be problematic.--Madminecrafter12 ^{(Talk to me | View what I've done)} 22:33, 8 May 2019 (UTC)

What if on hover of the invslots and the infobox image itself, the animation stops indefinitely, but immediately resumes again when moused out (or alternatively, the animation automatically resumes again after a longer interval than currently)? And then on click of the infobox image it of course opens its file page, and onclick of the invslots it switches out the infobox image as the original suggestion. – Jack McKalling [

] 22:52, 8 May 2019 (UTC)

Nice idea, Jack, that solves all of my concerns. Support!--Madminecrafter12 ^{(Talk to me | View what I've done)} 23:46, 8 May 2019 (UTC)

I like this and I think it'd be more obvious behavior-wise, but I'm not sure about accessibility. Would it make sense to have clicking on the images in the invslot simply open the file itself, the same way as the one in the infobox works? Granted I'm not sure if it's too big a deal, and people have been able to live with the current inaccessible version this long. --Pokechu22 (talk) 23:51, 8 May 2019 (UTC)

Support original proposal if this is possible to do. – Nixinova

23:40, 8 May 2019 (UTC)

Support Jack's idea or original proposal. This is one of the most annoying aspects of the wiki, imo. Some kind of fix is desirable! —Memetics ^{talk | edits} 07:35, 9 May 2019 (UTC)

Support Jack's idea or original proposal. Although what about entities like Wolf or Cat? – Sealbudsman talk | contribs 05:27, 10 May 2019 (UTC)

Support Jack’s idea or original proposal. -BDJP ^(t|c) 07:24, 10 May 2019 (UTC)

Looks like Jack's idea (22:52, 8 May 2019) gets implemented? Presuming someone knows how to code that. —Memetics ^{talk | edits} 23:08, 20 May 2019 (UTC)

We can pretty much reuse the code that pauses animations for crafting recipes on hover, for other animations (I'm thinking a generic class to apply to any container that should pause animations when hovered). Having the image change based on the invslot however is not so easy. The naive approach of just showing frame 1 for invslot 1 would be very simple and work for many cases. But many wouldn't. Wood has two rows of invslots and images, so it would have to only change the image 1 for row 1 and image 2 for row 2. Potion has a bunch of rows, but only one image. Bell has a multiple frames and images rows, but only one invslot. Bed has a whole set of invslots for BE that are only different in the inventory, not the world so there's no different image to show. In other words, you'd need a way to assign specific slot(s) to specific image(s), and handle cases where there's slots without corresponding images, and images where there aren't corresponding slots. It'd be a nice feature to have, but it's just not simple to set up properly. –Majr ᐸ Talk
Contribs 07:31, 25 May 2019 (UTC)

Move translation pages out of mainspace

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

Strong support - another thing is that they appear in the Special:AllPages page that lists mainspace articles, which I'm not much of a fan of. - User-12316399 (talk) 10:30, 11 May 2019 (UTC)

If there's no opposition to this proposal within the next week, I'll move all translation pages to this format. - User-12316399 (talk) 17:20, 20 May 2019 (UTC)

Not so fast, give people the time to notice this, and voice concerns. FVbico (talk) 22:11, 20 May 2019 (UTC)

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

A slight problem with the namespaced approach is that it would no longer be possible to look up translations of an English article by viewing its list of subpages (but see point 3).

With a subpage approach, listing translations in a language can be done by using categories, PrefixIndex would not be required.

I also have concerns that this move would make translations less visible, which should not be considered good. Even though this is possible with the namespaced approach as well, perhaps a form of translation navigation lists at the top of articles with translations would be beneficial?

Additionally, using the subpage approach for translations is somewhat of a convention for MediaWiki. In particular, mediawiki.org adheres to it. --AttemptToCallNil (report bug, view backtrace) 22:14, 20 May 2019 (UTC)

Does MediaWiki address similar issues as noted by Nixinova's OP? Has a similar proposal been vetted there, I wonder? —Memetics ^{talk | edits} 23:12, 20 May 2019 (UTC)

Make pages from old major releases accessible.

All the wiki pages seem to be updated for 1.14, but so many mechanics have changed that when I'm playing on a 1.12 server, I have to keep digging through wiki history to find the correct info. Additionally, if I wanted to add some *new* info specific to an old version, like an explanation of a glitch, there's currently no good place for it. I would like to propose something like is done for programming documentation, where old stable versions are moved to their own pages, so you could look up, say, "Smelting" versus "Smelting (1.12)". Nupanick (talk) 13:59, 14 May 2019 (UTC)

What you're asking for is already available. The History tab lists every past version of the page. If you determine the dates that the release (e.g. 1.12) you want was current, you can simply click on a date in that range to get a historical version of the page without the interference from later changes. You can even bookmark those pages' URLs, or make yourself a private index of them in your user space. Am I missing something? – Auldrick (talk · contribs) 15:20, 14 May 2019 (UTC)

My two main points with that are 1) accessibility, and 2) editing. For 1, yeah, I could go to the version history, work out the dates, cross-reference it with the page I want, switch to Desktop view so the "history" tab appears, and find the version I need. But it seems like major versions should be easier to reach than that. Python's docs just have a drop-down to switch between v2 and v3, and its important since both still get considerable use.

Point 2), editing, I don't think can be addressed any other way. If I want to add a useful note on 1.12- villager mechanics, there's simply nowhere I can insert that into an old version of the page. Nupanick (talk) 15:56, 14 May 2019 (UTC)

You are correct. There's no easy way to improve or correct information on old versions just by history. (And, as a side note, the historical versions do experience interference from later pages, as a side effect of updated templates or images or various projects moving pages into arbitrary locations and breaking all the links. I don't complain about these things just because I'm grumpy...)

I don't know how to solve it, though. The issue with adding separate articles like that is that the number of them quickly grows, which makes maintenance painful. (If there was an old inaccuracy that was only now noticed, then it'd need to be fixed on all the forked copies of the pages). I do think that documentation of historical information is important, and at least for older mechanics it'd be useful, but copying every article with a version suffix would be too much. --Pokechu22 (talk) 17:13, 14 May 2019 (UTC)

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

Pokemon is very different from Minecraft. Pokemon only has 7 major updates; Minecraft has literally hundreds. – Nixinova

06:02, 15 May 2019 (UTC)

There's no viable way to do what you're asking. How far back would it go? Classic? We can't have 500 pages about the same thing. – Nixinova

01:17, 15 May 2019 (UTC)

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

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

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

Legacy Console Edition inevitability

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

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

] 10:48, 27 May 2019 (UTC)

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

Old Item Overview Videos

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

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

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

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

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

Stop overwriting renders and upload new images instead

The texture update highlighted a long-standing issue caused by our current method of updating textures, where we upload over a render with the new version, then reupload the old version somewhere else (seem to be using "Revision X" currently, but the naming scheme is irrelevant right now). This is great for updating all the places the image is used in most cases, but when it comes to historical places such as history sections, removed feature pages, and the texture update page itself, this actually causes a problem as we should've kept the original image. Someone now needs to find all those locations and update them to use the newly uploaded revision file, so it goes back to the correct version. This issue was a real big problem on the texture update page, where it was using the current render for the "old" column and a TextureUpdate version for the "updated" column, which then all broke when the original files were overwritten with the texture update versions, and required changing all the "old" column to revision files, and the TextureUpdate files in the "updated" column are now all duplicates of the original file, which should be removed.

As such, I propose we move all current renders to whatever name we would've used for the current version had the texture been changed (don't bikeshed about the naming scheme here, we can decide that elsewhere if people aren't happy with whatever we're using now), and leave the original name as a redirect. When a texture is changed, we just upload a new revision file, and update the redirect to point to the new revision. That way all pages that want the latest version will get it via the redirect, and historical places will keep using the revision file directly.

For example: we would move Grass Block.png to Grass Block Revision 6.png, leaving a redirect and continue using Grass Block.png in places it should update, but use Grass Block Revision 6.png in the history entries about the texture update, so those won't break in the future. If the texture is changed again, we'd upload Grass Block Revision 7.png and update the Grass Block.png redirect to point to it.

I would also recommend we standardise on linking all the different revisions of a texture on each file page, so you can navigate them easily, and add a note (on the redirect page too) about using e.g.: [[File:Grass.png]] when you want a file that updates with the game, and [[File:Grass Revision X.png]] when you want the file to stay the same.

The only issue I see with this is I'm assuming redirects don't work for shared repositories, so language wikis relying on these images will be missing them until they create redirects themselves or upload the images locally. That being said, while the shared repo is a useful crutch for new language wikis first starting up so they don't need to duplicate all the files, it is not something that should be relied on long-term as it's prone to being broken due to our files being modified to work for our own articles, as it's not practical to check in with every wiki to see if a file can be modified. –Majr ᐸ Talk
Contribs 15:20, 8 June 2019 (UTC)

A big part of this project has been changing history sections to be correct as well. I honestly don't see what's wrong with the current system as long as we're vigilant about updating things, and your way just seems like the current way but more complicated. And it doesn't even make sense. If you move a page, the redirect redirects there, not an old version of the page. In my opinion, the file named "grass block" or whatever should always have the most recent version of the texture on it, and the current system seems like a good way to do that. If you (or anyone else) sees an incorrect history page, fix it! That's the beauty of a publicly editable wiki. -PancakeIdentity (talk) 18:54, 8 June 2019 (UTC)

So you mean Grass Block.png would redirect to Revision 6? Strong support. This would be a much better method than having all these duplicated files. – Nixinova

19:18, 8 June 2019 (UTC)

My problem is that I feel that people should be able to link Grass Block.png and always have it show the latest texture. I might be missing something here though. -PancakeIdentity (talk) 19:32, 8 June 2019 (UTC)

The proposal says redirect the non-revision version to the latest revision, so you'd be able to do that. FVbico (talk) 20:16, 8 June 2019 (UTC)

Oh alright, I see. Thank you! Support -PancakeIdentity (talk) 20:35, 8 June 2019 (UTC)

Support. FVbico (talk) 20:16, 8 June 2019 (UTC)

Interesting idea, the author deserves praise for creatively solving technical challenges. Support. --AttemptToCallNil (report bug, view backtrace) 21:08, 8 June 2019 (UTC)

Full Support. Complete solution to a troublesome problem, no counter-arguments. Also thanks for the clear examples, that cleared up a bit of misunderstanding, as "just upload a new revision file" was ambiguous for me, and I understand now that you're talking about texture revision, not a revision of the file's page. – Jack McKalling [

] 11:08, 9 June 2019 (UTC)

Aim of the wiki and other titles in the franchise

This Discord message is the reason I'm posting this here. Since the introduction of an entirely separate game, Story Mode, questions have been raised about whether we need to provide detailed coverage of other Minecraft titles, or delegate this task to other wikis and settle for brief descriptions instead. Given the upcoming release of Minecraft: Dungeons, it would be better if this question was finally answered.

The aim of the wiki was implicitly and informally defined too long ago, when what is now Java Edition was the sole work titled Minecraft. As such, it cannot be said that we document Minecraft and therefore only the main game. This statement could be made broader, to the point that since what we call Bedrock Edition is the sole work officially named "Minecraft" without any other words in the title, we could say that this wiki should only document Bedrock Edition and delegate coverage of other editions to other wikis. While such an approach isn't going to be taken because of substantial similarity between Minecraft editions, something not true for completely independent titles in the franchise, it underlines the main issue with this argument: "Minecraft" in "we document Minecraft" isn't defined. And I have started this very topic specifically to help the community determine what definition is appropriate.

I support documenting other titles on this wiki. Content pages for these titles could be placed in subpages or separate namespaces (like UESP does). --AttemptToCallNil (report bug, view backtrace) 14:51, 11 June 2019 (UTC)

Support franchise as a whole, as I already stated on discord. I'd prefer just subpages, rather than separate namespaces though, so they can be found better with the search then. FVbico (talk) 15:12, 11 June 2019 (UTC)

UESP definitely supports search suggestions for other content namespaces. There are server configuration options for enabling them as content namespaces and as namespaces to be searched by default. --AttemptToCallNil (report bug, view backtrace) 15:42, 11 June 2019 (UTC)

Uninvited, seriously I want to comment on this topic. I thought carefully about new community, the independent community is more new and dynamic, knowing how to running with scissors, like today Singapore and Japan. Singapore's approach gives a community the opportunity to develop independently, the new community is more focused on the gameplay writing of this new game.

A point of view made against AttemptToCallNil: A new game released by Mojang must have much gameplay in the future, if it is not advisable to take many subpages, the reader will only be busy looking for the subtitle page, rather than a complete wiki. Looking at the previous Minecraft Wiki and not preparing any subpage for Minecraft:Story Mode, it is obviously not appropriate to outline the entire page with a whole game.

I quote words from Gamepedia suggesting wiki interface:

“

At Gamepedia, our goal is to provide the #1 wiki resource for gamers spanning all genres and platforms. Whether you are starting a brand new wiki or moving an existing one over, gamepedia will provide your community with all the necessary tools to create a great wiki. Please answer the following questions to give us a better understanding of your preferred involvement.

„

FANDOM has the same wiki: https://minecraftdungeons.fandom.com . Why couldn't set up a new wiki on Gamepedia by interfering with the right of others to establish a wiki freedom?

So my opinion is given Oppose, sorry. All in all, we need to listen Gamepedia wiki managers and project creator's (Awesomeninja886) suggstion. --Angrydog001_{議(Talk)/誌(Logs)/勛(Contribs)} 17:41, 11 June 2019 (UTC)

I'm sorry, but I can't understand this post. I'm unable to see links between its parts, and sorry for being blunt, but it doesn't sound coherent enough. --AttemptToCallNil (report bug, view backtrace)

Conditional support. If Minecraft Dungeons has a lot of content that differs than the main game, and will receive constant updates, then it may be better to have a separate wiki for it. If the game is similar to the main game then it should be on here, as a subpages of Minecraft: Dungeons. We didn't have this discussion about story mode because it didn't add enough content but now with 2 new games on the horizon this is quite different. – Nixinova

19:22, 11 June 2019‎ (UTC).

How much is too much? Given this question is not answerable, this topic is not about whether to make a new wiki for MC: Dungeons, but about the scope of this wiki, and thus whether titles like Story Mode or Dungeons should be documented here in detail. --AttemptToCallNil (report bug, view backtrace) 20:07, 11 June 2019 (UTC)

I think this will should be more about the franchise as a whole, but I'm not sure of the extent we should document other games on here. I think subpages are the best idea at the moment for eg Dungeons exclusives. Story Mode can be easily described in one page. Though, what is technically the difference between bedrock, console, java, and dungeons? All are completely different games that just have similar content. To answer the main question... "probably". – Nixinova

21:07, 11 June 2019 (UTC)

I think I can't formally answer this question. Because first, I'd like to know how we could even document other games in the first place, and make it fit on the wiki. But seeing we're still stuck on the wiki-wide refactoring of edition-specific information already, I'm not seeing how we're going to get consensus on how to document an even wider scope. So generally speaking, it's my opinion we should discuss at least how we could achieve this, before deciding whether we should do it. But for what it's worth, depending on whether it could be done with a clear distinction between each game, I'd be leaning towards the whole franchise. Because although they might not be the same game, if they are part of the same franchise, they essentially are still "Minecraft"-y. But I'm heavily concerned about the implementation of this. – Jack McKalling [

] 21:27, 11 June 2019 (UTC)

@@ Line 1,286: / Line 1,286: @@
 :: How much is too much? Given this question is not answerable, '''this topic is not about whether to make a new wiki for ''MC: Dungeons'', but about the scope of this wiki, and thus whether titles like ''Story Mode'' or ''Dungeons'' should be documented here in detail'''. --[[User:AttemptToCallNil|AttemptToCallNil]] ([[User talk:AttemptToCallNil|report bug]], [[Special:Contribs/AttemptToCallNil|view backtrace]]) 20:07, 11 June 2019 (UTC)
 ::: I think this will should be more about the franchise as a whole, but I'm not sure of the extent we should document other games on here. I think subpages are the best idea at the moment for eg Dungeons exclusives. Story Mode can be easily described in  one page. Though, what is technically the difference between bedrock, console, java, and dungeons? All are completely different games that just have similar content. To answer the main question... "probably". – '''[[User:Nixinova|Nixinova]]''' [[File:Nixinova sig1.png|16px|link=User talk:Nixinova]] [[File:Nixinova sig2.png|16px|link=Special:Contribs/Nixinova]] 21:07, 11 June 2019 (UTC)
+: I think I can't formally answer this question. Because first, I'd like to know how we could even document other games in the first place, and make it fit on the wiki. But seeing we're still stuck on the wiki-wide [[mcw:Projects/Refactoring edition specific information|refactoring of edition-specific information]] already, I'm not seeing how we're going to get consensus on how to document an even wider scope. So generally speaking, it's my opinion we should discuss at least how we ''could'' achieve this, before deciding whether we should do it. But for what it's worth, depending on whether it could be done with a clear distinction between each game, I'd be leaning towards the whole franchise. Because although they might not be the same game, if they are part of the same franchise, they essentially are still "Minecraft"-y. But I'm heavily concerned about the implementation of this. – [[User:Jack McKalling|Jack McKalling]] [ [[File:Grid Book and Quill.png|16px|link=User talk:Jack McKalling]] [[File:Grid Diamond Pickaxe.png|16px|link=Special:Contributions/Jack McKalling]] ] 21:27, 11 June 2019 (UTC)