Talk: Community portal

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

Sort History editions by date of first addition

I think that the editions in history should be sorted by date of first addition – if it was in Java first, put Java at the top; if it's in pe first, put PE at the top, etc. Just so people know roughly the chronology of the additions. – Nixinova  23:20, 31 October 2018 (UTC)

 Support. I've always thought this, but was too shy to say anything. Seems like a good way to honor whichever edition first hosted the innovation. – Sealbudsman talk | contribs 01:23, 1 November 2018 (UTC)

 Disagree​. I don't think people really care about that small detail, instead it will make the editions harder to locate. Lê Duy Quang (Make some words | Contributions) 13:40, 1 November 2018 (UTC)

 Weak support, while this would be chronologically more correct, it would be maybe a bit confusing for readers. 193.210.225.146 15:03, 1 November 2018 (UTC)

 Oppose, and sorry. I believe the editions should always be in a defined and consistent order. The order in which content was added to multiple editions can already be deduced from looking at the dates. But the tables for each edition can become very long on individual pages, making it difficult to find a particular edition of interest to the reader like others said above. Sorting editions to date of content will not help more than keeping them in consistent order would. – Jack McKalling [ ] 11:14, 3 November 2018 (UTC)

 Oppose per Jack McKalling. -BDJP ^(t|c) 12:40, 3 November 2018 (UTC)

{{Citation needed}} and {{verify}}

These two templates seem very similar. What's the main difference between them? 193.210.225.146 15:20, 1 November 2018 (UTC)

I'd say the difference is that verify is used for asking for testing generally, while citation needed is for things that would actually need a citation (such as the claim about the creator of spleef in Spleef#History). --Pokechu22 (talk) 15:39, 1 November 2018 (UTC)

I use verify for things that don't necessarily need a citation but might not be true. For example, verify could be used to check that cactuses don't grow if there is a block obstructing its path in Bedrock. Citation needed could be used for a statement telling what the last minecon Notch spoke at was. Jahunsbe (Talk) 20:44, 2 November 2018 (UTC)

Basically both templates are used to request verification of the correctness of content, but the verify one doesn't ask for an actual citation source to prove said correctness. – Jack McKalling [ ] 11:09, 3 November 2018 (UTC)

Use of {{issue list}}

Originally brought up on Template talk:Issue list but got no replies, so I thought I should bring this here as this affects all pages:

The template {{issue list}} doesn't seem to be necessary. No-one uses the wiki to report bugs anymore so it's useless having this in articles. It might have been useful 6 years ago before the bug tracker was created and the wiki was used to report bugs but everyone knows about the tracker now and adding this template to pages doesn't add any encyclopedic value. – Nixinova  03:27, 2 November 2018 (UTC)

Allegedly, the template originally was able to expand a list of issues inline (there was some way to expand it and make a table?), but then that broke. If it were able to do that, it would definitely be at least slightly useful, but I agree that it's not too helpful in its current state (other than for things where there might be multiple search terms). --Pokechu22 (talk) 03:30, 2 November 2018 (UTC)

Agreed. – Sealbudsman talk | contribs 13:04, 3 November 2018 (UTC)

I don't really like seeing it on every page myself, but it isn't really true that "everyone knows about the tracker now". There are new owners of Minecraft all the time, and we can't know whether they'll discover the wiki before they learn of more appropriate sources of support. Plus, there are still people who edit articles to mention bugs (I saw one just today, in fact). I'm not sure that removing the templates would result in an increase in these unwanted edits, but having them might discourage it. Before we do the massive work, maybe it would be smart to try it out on a few pages, especially those for persistently buggy features? – Auldrick (talk · contribs) 21:05, 3 November 2018 (UTC)

 Agree​. Cleaning up this equals to cleaning up a now obsolete section. Lê Duy Quang (Make some words | Contributions) at 3h44 | 10/11/2018

Loot chest per-item summaries as tables instead of prose

Several users have been unsatisfied with the often complicated/messy prose on item pages' Natural Generation sections, which is the output/fault of template {{LootChestItem}}. Brandcraft06 mentioned it could be done as tables, as they do it on the French wiki, and brought to our attention (in the #wiki channel on Discord) some innovations in Module:LootChest which JSBM had put together. Compare Apple#Natural generation vs fr:Pomme#Coffres, or for a more complicated/messy example, Armor#Natural generation vs fr:Armure#Génération naturelle.

I translated the relevant functions; see a few samples at User:Sealbudsman/LootChest.

So what do people think, should we do these things as tables instead of prose? – Sealbudsman talk | contribs 14:50, 4 November 2018 (UTC)

Big support for this. It's much, much easier to find what you're looking for than having to parse all that repetitive text. I don't remember where it was now, but I once saw a case where the template output was unbearably hideous and I wanted to fix it, but when I found out it was a template I forbore because I didn't have time to learn how it worked or how my fixes would affect other pages. I'm curious, though: Why is there no Java Edition heading? It makes Bedrock Edition look like an exception. Also, there's an unexpanded {{Upcoming}} in your sample page, probably just a typo I'd guess. – Auldrick (talk · contribs) 15:02, 4 November 2018 (UTC)

There's no Java heading because Bedrock was a relatively recent addition to this template, and yes that could be an improvement, I would support that. The exact same issue occurs in the text version and in the table version btw. Good pointing that out. – Sealbudsman talk | contribs 18:20, 4 November 2018 (UTC)

Support, especially because I see how horrible the current description on the Armor page is. --AttemptToCallNil (report bug, view backtrace) 15:23, 4 November 2018 (UTC)

 Strong support. Auldrick worded this much better than I could, but for module-generated info such as this, prose looks so messy and choppy; using a table instead would be a significant improvement.-- Madminecrafter12^{Talk to me} 15:24, 4 November 2018 (UTC)

I think it would be helpful if the template also generated a single line of prose before the table, e.g. "Apples can be found as loot in chests in the following locations:". Without it, you have to study the table for a bit to realize it's about chest loot. Also, the table makes me realize there are differences between Java and Bedrock (and question whether these differences are real). That's something I never would have noticed in the prose form, so one additional benefit of using tables. – Auldrick (talk · contribs) 15:43, 4 November 2018 (UTC)

Good idea I think. The percentage chance differences bw Java and Bedrock are mostly because of different items elsewhere in the loot tables throwing off the weights, and only occasionally because of actual different drop chances. – Sealbudsman talk | contribs 18:20, 4 November 2018 (UTC)

One more idea: Allow the Item column to be suppressed. In typical cases, it would only contain the item that the article is about, so it's just redundant and takes up space unnecessarily on mobile devices. – Auldrick (talk · contribs) 15:50, 4 November 2018 (UTC)

Sounds good to me. – Sealbudsman talk | contribs 18:20, 4 November 2018 (UTC)

 Support tables. But please make them sortable. When the list gets very large, it'd be helpful if you could re-sort the table by name, percent, structure, etc. I've had troubles with this loot chest output before, where multiple variants of the title item were available under different circumstances among different game platforms, but all resulting in almost the exact same sentence 10 times. Really unhelpful. – Jack McKalling [ ] 19:50, 4 November 2018 (UTC)

Someone may have to put a slight bit of thought into how to sort the table without losing edition and version differences. Sort User:Sealbudsman/LootChest#Apple to see what i mean. Maybe each version/edition gets its own table? – Sealbudsman talk | contribs 21:17, 4 November 2018 (UTC)

Yes each edition its own table. Probably the best to do, if reasonable. – Jack McKalling [ ] 21:39, 4 November 2018 (UTC)

Currently, edition / version differences are differentiated as if Java were the main version, and then some exceptions for whatever is different in Bedrock and upcoming versions. The module's loot tables aren't structured that way actually, so it actually introduces all kinds of complexity to boil it down from the full loot tables into the current form, which even if you ignore the Java-centrism, still leads to no end of ambiguity as to how to read all those versions taken together. It would be simpler to just display full tables, one for each different edition and version. Just an update on my thoughts. – Sealbudsman talk | contribs 19:03, 5 November 2018 (UTC)

Are you thinking of it more as a list of tables with edition headers, or a list of edition section headers with one table per section? Are there any advantages either way, or are they entirely equivalent? (The section headers would appear in the TOC, but whether that's advantage is unclear. Some TOCs are already kind of cluttered.) – Auldrick (talk · contribs) 19:10, 5 November 2018 (UTC)

The first one. – Sealbudsman talk | contribs 21:10, 5 November 2018 (UTC)

 Support​ this. But make the table transparent so that the readers' eyes won't be hurt. Lê Duy Quang (Make some words | Contributions) 14:50, 6 November 2018 (UTC)

The default wikitable style is white background, and it's on the majority of tables in the wiki; is it a big issue? If it is, maybe raise a separate topic ..? – Sealbudsman talk | contribs 16:56, 6 November 2018 (UTC)

Eh, I just thought a big table should be less bright compared to the whole page. Lê Duy Quang (Make some words | Contributions) 01:15, 7 November 2018 (UTC)

 I have a question: How are we planning to organize the table? That means, what will the table look like in general? Lê Duy Quang (Make some words | Contributions) at 3h53:37 | 11/11/2018 (UTC)

Any way to overlay one image on top of another in an infobox?

I'm thinking for the cat page we could have seperate images for the collars in the different colors displaying over the images of the skins, this way each skin will be seen with several different collar colors as the animations go on. But can it be done? If not, could a method of doing this be added? – Luckowskiᵗᶜᵘ 07:04, 7 November 2018 (UTC)

I don't see any simple solutions to do this but you could try a scuffed way similar to template:loom with negative margins and stuff. – Nixinova  07:13, 7 November 2018 (UTC)

I would not recommend doing this. We already have an animation for looping through all the different cat types, it'll become a mess that isn't done before on any other page if we then loop through all collar colours for each one. Regardless of technique used. The red collar should be enough really. – Jack McKalling [ ] 08:15, 7 November 2018 (UTC)

Add "Did you know..." section

In this wiki there are many things that not every player knows, so adding a "Did you know..." section will:

1. Provide readers with more facts about the game.
2. Make the wiki more interesting.

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

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

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)

Make the "News and events" icon in the main page dynamic

Currently, the main page's "News and events" section has an icon which resembles a calendar of 11/2011 and displays the date 6 | 18/11/2011 (although it actually displays Saturday). Since this is severely outdated, I have made a new version of the icon which you can check out in my version of the main page:

User:Leduyquang753/New main page

The actual font size of the month text ("4/2024" at the moment) is 7px, depending in your browser, the size may be limited to a minimum number, which makes it larger and displaced.

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

Nice idea. I copied parts for the german /editcopy. And I cleaned the code a bit. Oliver Scholz - Wiki Admin 14:42, 9 November 2018 (UTC)

Proposed to the editable copy. Lê Duy Quang (Make some words | Contributions) at 3h40 | 10/11/2018 (UTC)

Status update: DESTROYED (per Style guide). Lê Duy Quang (Make some words | Contributions) at 14h28:06 | 12/11/2018 (UTC)

Put information pre-addition in prose

At the moment, any time the feature was mentioned prior to addition, it gets pushed into the table. I don't think this is the best way of doing things, especially on features like the lectern or lantern that have a ton of history before addition. I feel this would work better in prose above the table. For example, see Ender Dragon#History (which has a ton of inline external links that would work better as references), and compare it to Nixinova/1.14/Lantern. It has a ton of links there that shouldn't be grouped in with the versions. – Nixinova  18:34, 9 November 2018 (UTC)

 Support​ this idea. I think the implementation history should be something to describe the statements in detail. Lê Duy Quang (Make some words | Contributions) at 3h37 | 10/11/2018 (UTC)

 Good idea, this makes sense, as each external link entry is not an actual history item, but more of a "historic message".^{(changed my mind, see below)} Do you suggest to modify all used history tables that have external link entries to pre-implementation information, or are you talking about a specific subset of pages? – Jack McKalling [ ] 10:33, 13 November 2018 (UTC)

Yes, everything with a version title of "month day, year" andan ext link should be moved into prose and leave the history template for changes ingame. – Nixinova  02:37, 14 November 2018 (UTC)

 Oppose. The information related to the external links are still part of history, and extracting it from the table and leaving it as prose above does not help the flow of the page. It would make the page less readable. However, if the text were rephrased to state exactly the information, it would be a lot better. For instance, the panda#History page shows how these external links can be well-phrased, and are easy to the eyes. In contrast, the Lectern#History page does not. It is too messy, clunky and the text is not straight to the point. This argument was mentioned to me by Nicolerenee. Paraphrasing here in her name, because I think it is a very valid point. – Jack McKalling [ ] 19:55, 15 November 2018 (UTC)

Getting error upon attempt to upload 80-frame gif file. Please help!

I made renders for the different cat breeds with different collar colors and threw them together in an 80-frame gif, meant to be used on the page for cats in place of the cycling images displaying the different breeds all in red collars. However, I cannot seem to upload this file, constantly getting a "500 Internal Server Error, openresty/1.13.6.2" error upon attempting the upload.

If anyone has a fix for this issue, please let me know! – Luckowskiᵗᶜᵘ 13:29, 12 November 2018 (UTC)

It's a global Gamepedia issue, Gamepedia is aware of the issues and hopefully will fix it soon. Frisk (Talk page) 13:37, 12 November 2018 (UTC)

Oh, okay! Thanks for the information, I thought it was just gamepedia disliking the size of the gif file or something haha – Luckowskiᵗᶜᵘ 13:39, 12 November 2018 (UTC)

Seems to be fixed now. --Giorgosarv18 (^talk/_contribs) 14:45, 12 November 2018 (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)
• FVbico (talk • contribs • logs • block log)
• Nixinova (talk • contribs • logs • block log)
• Pokechu22 (talk • contribs • logs • block log)
• Sealbudsman (talk • contribs • logs • block log)
• Nicolerenee (talk • contribs • logs • block log)

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)

FVbico for admin

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. 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)

Nixinova for admin

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 *flashbacks*) and I'd edit {{v}} whenever a new update is released since I'm pretty active on this wiki and am usually the first to make Bedrock beta versions. – Nixinova   19:04, 18 December 2018 (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)

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)

1. Are the CC BY-licensed sounds specified as such on the wiki?
2. 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:

1. 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.
2. 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)

 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)

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)

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)

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)

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)

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)

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

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:

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

• Template:History
• Achievements#List of achievements
• 1.13/Flattening#Block and Item IDs
• Statistics#List of general statistics

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)

 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

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)

Wiki cleanup

I propose the following changes:

1. Export subpages of mods to ftb: and nuke it.
2. 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)
3. 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)

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)