Minecraft Wiki talk:Community portal

This is the community's main discussion page.

Talk about anything wiki-related here!

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

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

Cleanup disambig pages with only two things
Disambiguation pages with only two items is useless, such as speed and Wither Skull are useless, but some, like ingot and nugget are useful, I thinking that we could change disambiguation pages with two items only to be redirected to the thing that refer most to the title, and place about or redirect template on the page and link to the other page, what should we change with disambiguation pages with only two items? Here have I three suggestions:
 * 1) Keep them, they are useful
 * 2) Redirect them to the thing that refer mot to the title and place a about or redirect template that leads to the other thing
 * 3) Delete them

Any comments are welcome!  psl85  (talk • contribs) 11:41, 31 July 2018 (UTC)


 * They are useful if they are disambig from the title like your two examples. I see no problem with the user deciding what they mean by Wither Skull or Speed instead of deciding for them. – KnightMiner  · (t) 02:13, 1 August 2018 (UTC)


 * The ingot, golem, and nugget disambiguation pages is useful, but I think less useful disambiguation pages, like speed, heart, and Wither Skull, should we redirect speed to example status effect and place "about" or "redirect" template on the speed section and link to the other use, or should we keep them?

(See Category:Disambiguation pages for a full list)  psl85  (talk • contribs) 04:31, 1 August 2018 (UTC)


 * I just said I think we should keep them, why are you asking me again? Yes, you can redirect them and place an about, but that is only useful if one of them is the more likely target (which in both of your two original cases neither is, heart arguably is more useful as health but even that is a bit rough), plus sectional redirects are rough to add an about to.
 * I suggest you look at specific pages and give a clear opinion on what you want done, rather than stating in general disambig pages with 2 pages is bad. It could also be done on the dedicated talk pages instead of needing a community portal topic. – KnightMiner  · (t) 00:55, 2 August 2018 (UTC)


 * We could start here a community discussion where users can choose to keep or redirect disambiguation pages with only two items, here have i an example: speed, should i keep it, or redirect it to status_effect, or redirect it to the other use? Wikipedia-logo.png psl85  (talk • contribs) 03:34, 2 August 2018 (UTC)

What should we do of the "/video" subpages?
Hello everybody,

Recently, after discussing with CrsBenjamin, I was told that, contrary to what I (and others) thought, the Curse videos (from the "/video" subpages) are not subjected to the Curse video policy. They were not "placed at or near the top of a content page by staff members" and we can manage them ourselves, including removing them from the pages, unprotect these pages or even delete them.

I would like to hear what you think we should do with them now. Do you think we should include videos on the pages at all? On which pages? Do you think we should remove the current videos and replace them? Or simply remove the ones that are outdated and that's it?

In addition, do you think the protection should be lowered on these subpages to Auto-confirmed? We could also decide to include them directly on the pages instead, removing the need for the subpages entirely.

JSBM (talk) 21:07, 2 August 2018 (UTC)


 * For reference, list of all "/video" subpages


 * List of all "/Update Video" subpages


 * Many of the videos have been outdated for a long, long time, and all of them were created to describe Java Edition specifically, so they certainly wouldn't meet our standards if they were transcribed into prose. On the other hand, they're funny, entertaining, and most of the information in them is still accurate (since they're fairly general). They're better than nothing, I'd say. They were still valuable to me as a noob, and I feel a bit nostalgic about them. I'd be sad if we decided to delete most of them. – Auldrick (talk &middot; contribs) 21:35, 2 August 2018 (UTC)


 * Technically most of them weren't created for an edition, since back then Java was the only platform for Minecraft. But back to the point at hand, if any of them are still relevant, they should just be included directly on the pages. If it's decided not to be used, either delete them, or use media links on a video archive page to keep them linked to something in case someone wants to find them. In either case, the video subpages themselves really don't have a practical use. DSquirrelGM &#120035;&#120031;&#120018; &#128504; 23:38, 2 August 2018 (UTC)


 * I believe it would be best to remove them only when they are very overrated (few of the cases) - Iludido (talk) 20:44, 4 August 2018 (UTC)


 * I believe the videos are useful (mostly due to what Auldrick said), so I don't think we should delete all or most of them. However, I propose to remove videos that are very outdated and a lot of the information doesn't apply anymore, such as the video for Adventure. I also strongly support lowering the protection. Admin-only seems extreme. Maybe we could change the /video subpage abuse filter so that it only prevents the edit if the user has made less than 50 edits and lower the actual protection to semi. I'm not sure how much I like lowering it completely, as I could see IPs adding their own videos and such.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 00:16, 6 August 2018 (UTC)


 * Also, we need to rewrite the video policy. The page is currently confusing and full of inconsistencies.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 00:19, 6 August 2018 (UTC)

Proposal
Given the few answers, I'm directly going to make a proposition instead.

I suggest that we do the following:
 * For articles that doesn't benefits from an additional visual explanation (for example, blocks like Dirt, Cobblestone or Wool; items like Apple or Gold Ingot), the videos should be simply removed. These pages are generally good with only text, and there is no reason to keep a video.
 * For articles that can be better understood with some visual content (for example, blocks like Comparator or Note Block; items like Eye of Ender; most mobs and biomes), the current videos should be kept only if they are still accurate and reasonably up to date. Videos that are too outdated should be removed. (For now, they would not be replaced, but see the next section for that.)
 * Snapshot and update articles should keep their videos. However, they should be put between  tags when necessary to prevent them from showing on pages like 1.13/Development versions.

In addition:
 * All "/video" (and "/Update Video") subpages should be removed, and videos should be directly inserted in the articles;
 * The abuse filter that prevent from creating or editing "/video" subpages should be removed;
 * We should start discussions to decide if we should encourage people to add new or more up to date video on pages where they could be useful. We should also discuss if we want to replace outdated video, and which video should replace them. Potentially update the Video policy too.

I think it would be a good start. We would already clean up a good part of the videos on the Wiki, and it would allow us to make a decision in the future on more complex or specific case, or about the future of videos on this Wiki. So, please share your opinion on this proposal, it would be greatly appreciated!

JSBM (talk) 16:19, 5 August 2018 (UTC)


 * , I think the "/Update Video" subpages should be kept for their utility. - Hugman_76 [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 16:30, 5 August 2018 (UTC)


 * Agreed. FVbico (talk) 13:36, 16 August 2018 (UTC)


 * , definitely. I like the idea (from point #1) that we might start only adding/keeping videos because they are useful because they convey ideas that are difficult in text. I notice that's already in the video policy, though, the first section. Definitely support weeding through them though. – Sealbudsman talk | contribs 21:24, 5 August 2018 (UTC)


 * , I'm working on each of the videos. As I have mentioned several times, I would like to visually contribute some articles: first I am uploading right now a new tutorial video for the Beginner's Guide page. I would like to set up a small "media" team whose job would be to leave the site updated and expressed in harmony. For example, the x or y in-game server or minecraft news/foruns/etc. sites has a group of people focused mainly on the part of the presentation. -- Iludido (talk) 00:10, 6 August 2018 (UTC)

InvSprite vs ItemSprite
There are currently two templates that manage the display of item inventory sprites on the wiki: InvSprite and ItemSprite. Are there any known differences in the purposes of these templates? Could they be unified in some way? InvSprite has a more complete listing of sprites, but ItemSprite has a handy associated linking template in ItemLink. So far as I can tell though, the overlapping sprites between the two templates are the same. I believe somehow merging these templates would allow for easier maintenance of sprites going forward, but I am not sure as to the best way of doing this without having significant, site-wide consequences. Any ideas? — Bg samm (talk) 21:26, 7 August 2018 (UTC)


 * The easiest way to merge the spritesheets would probably be to resize File:InvSprite.png and set a scale of 2 in Module:InvSprite. The hard part would be making the names consistent. The names from one or the other could be set to deprecated, or each template could use different names. It would be better to make all the names consistent. Unfortunately that would entail setting ~2,368 sprites names as deprecated. A solution to that could be to make Module:Sprite format names to lowercase and space replaced with -. It would need a parameter to turn that on/off. Jahunsbe (Talk) 23:55, 7 August 2018 (UTC)

Don't assume all edits are vandalism
A friendly reminder to everyone - just because an edit changes factual information, comes from an IP, or is unexplained does not mean it's vandalism. I have seen this happen a lot - a user makes an edit, an experienced user just assumes it's bad and doesn't verify it, so they revert it, a lot of the time with no edit summary, and it turns out the user was correct. This seems to have occurred repeatedly within the past week or so. So I just thought it would be nice to remind all of you - before reverting an edit for being "vandalism," look over the edit and see if it seems probable that it's actually correct information rather than just assuming that it's vandalism. If you have the game, of course you can test it there - otherwise, we do have User:Jack McKalling/patroller-requests. I have noticed this happening more often after we started promoting a lot of patrollers - if a new user makes an edit, it's just assumed to be vandalism and rolled back without an explanatory edit summary, assuming that it's vandalism.

Do note that it is not at all one specific person doing this, or even a few specific people. And I do know everyone is trying to help the wiki, and all of your work is greatly appreciated. I've just seen this from many different users several times, so I just thought I would point this out. Remember, not all edits that look like vandalism are vandalism. Not all IP editors all vandals. Not all unexplained changes are incorrect. Just something to keep in mind.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 19:43, 10 August 2018 (UTC)

Aboud "id", "id name", "data value", "name" and so on
Each one of the nouns above may have different meanings in different pages.

For example, wool. In the infobox, its "data value" is 35, and "name" is "minecraft: _wool". And in the section "wool", its "id" is "minecraft: _wool" and "data value" is an integer between 1 and 16 (in BE).

In the page advancements, the id names of advancements are called "interal id", for example, "minecraft:story/obtain_armor".

In the page Java Edition data values, those id names are called "IDs", but in the section Biome IDs, the IDs are called ID names. In the Enchantment IDs and Status effects section, those id names are called "Name". The whole page is names "data values", but includes id names and so on. "Block data further defines blocks placed, describing for example the height of water or the direction a torch points.", but "block data" means the NBT of block entityes (chests, signs etc).

So these concepts need clear names (see also zh:Minecraft Wiki:管理员告示板):


 * The id names of things with namespaces, all-lower cases and underlines, including blocks, entities, advancements, recipes, functions, advancement triggers, criteria, bossbars, effects, particles, loot tables, structures, biomes, dimensions, type of buffet and enchantments.
 * The number id of blocks, enchantments and so on before 1.13 and in BE.
 * The integer to specify the block's facing, color, variant and so on before 1.13 and in BE, for example, the "3" in.
 * The NBTs of blocks and entities, which can be modified with . --SolidBlock (not good at English!) 05:08, 17 August 2018 (UTC)


 * ID
 * Numeral ID
 * Metadata/block data/ item data item damage (Item data makes more sense for NBT)
 * NBT data/entity data/item data
 * These would be the most logical to use, and wouldn’t require changing most things. FVbico (talk) 05:23, 17 August 2018 (UTC)


 * Several of these labels have now been changed to "Numeral ID", which I find quite jarring. I was taught "numeral" as a noun denoting the symbols "1", "2", "3", etc. (especially in the phrase "Roman numerals"), and I don't remember ever seeing the adjective used before this. It's in my dictionary, but I don't think it's in frequent use. I would use "numeric ID" or the synonymous "numerical ID", and I think other American English users would as well, but I can't speak for non-U.S. speakers. Do native English speakers in other countries and regions also find "numeral ID" awkward? – Auldrick (talk &middot; contribs) 01:42, 13 September 2018 (UTC)


 * I have now put this on my pending tasks page, with the following:
 * the namespaced, lowercase and underscore IDs: Name ID
 * the numeric IDs: Numeric ID
 * the NBT data: Block/Entity/Item data
 * the integer for item damage, block variant, etc.: Metadata
 * Please tell me if this seems good, or what needs changing, so I can make it correct someday soon. FVbico (talk) 12:34, 11 December 2018 (UTC)

Creating a template
Can I create a new template on this wiki? -- Lxazl5770 zh.admin （ 论 • 功 ） 10:27, 19 August 2018 (UTC)


 * What for? There’s no requirements AFAIK, but just to make sure no such template exists already. FVbico (talk) 10:59, 19 August 2018 (UTC)


 * If you think that a new template could be helpful, I'd say go for it. But like FVbico said, make sure it doesn't exist already - if it does, though, it may make a good redirect.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 12:31, 19 August 2018 (UTC)

Should ids in infoboxes appear with namespaces?
For example, in the section wool, Java Edition IDs may be "minecraft: _wool" (although namespaces can be removed almost everywhere in game); in the infobox of the page Snowy Tundra, the "Biome ID" can be "minecraft:snowy_tundra" rather than "snowy_tundra". I think ids with namespaces can be more scientific. --SolidBlock (not good at English!) 10:38, 30 August 2018 (UTC)


 * I don't think this matters much - firstly, if not specified, it defaults to . Secondly, this wiki focuses on vanilla Minecraft content, and mods (and possibly datapacks in the future, if that ever catches on), if documented here at all, are clearly marked as such. We can safely assume every registry name defaults to starting with  . --Hubry (talk) 10:44, 30 August 2018 (UTC)


 * We could add a hover text over the "nameid" label that says it's namespaced with, but as already stated, it doesn't matter if it's specified at all, and even worse: in bedrock the namespace has to be omitted (in commands at least). So I think namespace shouldn't be specified. (Though I do think mod pages should specify it, either in the value or hover text.) FVbico (talk) 11:03, 30 August 2018 (UTC)

Use of Minecraft: Bedrock Edition
On this page, the term Minecraft: Bedrock Edition was used. This was never officially used by Mojang or Microsoft. Is there something to do with it?-- skylord_wars (talk) 08:25, 15 September 2018 (UTC) ''Edited on 08:27, 15 September 2018 (UTC) ''


 * It is officially used by Mojang now. What is your question? – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:21, 15 September 2018 (UTC)

Navbar hollow's edge behind the search bar
Should this be retextured? Lê Duy Quang (Make some words | Contributions) 12:26, 19 September 2018 (UTC)




 * I looked into it, and this isn't a texture. It's the solidly coloured border of an element, made to look like this specifically with the stylesheet. The dark background of the search bar is all style, no images here that overlay the page background. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 13:02, 19 September 2018 (UTC)


 * Then make a background image for it maybe? I made this image for that edge but didn't know exactly how to put it in...


 * Edge retextured.png


 * Lê Duy Quang (Make some words | Contributions)

Split different Minecraft versions
Pages are becoming increasingly cluttered and difficult to read as the different versions of Minecraft (e.g. Java Edition, Bedrock Edition, Education Edition, etc.) drift further apart. Currently, articles tend to describe all the different Minecraft versions in a very disorganised manner. It is frustrating trying to read an article when only a proportion of the information is relevant to the version you are using.

I propose splitting each page into a separate page for each version of Minecraft, as this will greatly improve readability. This could be done in a manner similar to the Star Wars Wiki: Many of their articles have separate pages for "Canon" and "Legends", with tabs at the top of the page to switch between the two. Minecraft Wiki articles could include similar tabs to switch between the different Mincraft versions.

--J p smith (talk) 15:59, 19 September 2018 (UTC)


 * . This would make the wiki way more confusing to navigate then before. -BDJP (t 16:35, 19 September 2018 (UTC)
 * on this implementation, the idea of somehow allowing readers to choose preferred editions, or otherwise allow them to find content relevant to a specific edition faster. --AttemptToCallNil (report bug, view backtrace) 16:39, 19 September 2018 (UTC)


 * creating new pages for everything. Creating new articles where most needed, and for finding better ways to organize editions. I agree that the split between editions is somewhat disorganized, but I think that creating a page for every article is too drastic. There's not too many edition differences other than little quirks and edition exclusive features. I would rather do something like the Terraria Wiki(literally just hit random page) where they use icons to show the differences between editions. Jahunsbe (Talk) 00:44, 20 September 2018 (UTC)


 * like the others above for splitting all pages. Please refer to these existing discussions instead: COMPORTAL:Archive20:Not in Pocket Edition, Template:Only:Adding a complementary template and Projects:Renaming:Opportunity for CSS stylesheets, and check out the project Highlighting Edition-Specific Information. This is a hot topic, different, more convenient approaches have been discussed in many places as you can see, even on this page's archives. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:48, 20 September 2018 (UTC)


 * Will make the pages even more confusing than they already are. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 08:09, 20 September 2018 (UTC)


 * This is not the way it should be done. Works well on Wookieepedia as things are often very different in Legends than Canon, but Minecraft has many editions and differences are smaller. - Erufailon4 (talk · contribs) 10:03, 20 September 2018 (UTC)


 * I do not understand what would be the advantage of this, even with your explanation. But I agree that we should think of a better way to make the pages less confusing, according to the editions of the game Iludido (talk) 05:41, 21 September 2018 (UTC)


 * I Believe that this will make the wiki a lot easier to read and acess, but it would take a LONG time to change everything. However, I still thing that thi is the best way to go. Thelarry79 (talk) 00:25, 22 October 2018 (UTC)


 * . The idea of putting version onto tabs is not a very nice idea. On the Mobile version, it doesn't even have any tabs at all, and there are many versions currently, which will make the navbar look like so:


 * [[File:Navbar with many versions.png]]


 * Also, putting everything in one page will help one compare between versions.


 * Lê Duy Quang (Make some words | Contributions) 01:33, 28 October 2018 (UTC)

To everyone: Voting in discussions
There is this one issue with many editors' interpretations of discussion procedures which has the potential of being highly damaging to the project. It's that wiki discussions are votes. They are not, and are not supposed to be.

The wiki is a resource written for readers, almost none of whom are editors. According to the admin analytics dashboard, all Minecraft Wikis in total had more than 4.5 million visitors (you can safely assert that 3 million of them visited the English wiki) over the last 30 days, while during the same time period only 237 accounts have performed any actions at all on the English wiki, and if you exclude blocked accounts, known alts and bots, as well as users with less than 5 actions and without extended rights, this list gets down to 70 entries.

That is, out of every roughly 43 thousand visitors only one can very remotely (5 actions is an incredibly low bar) be considered an editor. And given the number of those who participate in discussions is even lower, we can with no hesitation assert we have not the slightest idea about the opinions of almost every visitor on matters which will almost definitely affect almost all of them. In other words, the set of people expressing their opinions in wiki discussions is an insignificant subset of the actual community affected by decisions made in these discussions.

And yet, I have seen many times that decisions have been made, or that it has been implied that a decision should be made, on the basis of the number of users who expressed their support or opposition to a proposal. In addition to the already stated misrepresentation issue, there are multiple others.

First, in a discussion it's meaningful not only to introduce a new viewpoint, whether entirely original or derived from an already stated one, but also to support an existing one. Just supporting an existing viewpoint is equivalent to saying "I have reviewed your proposal, haven't found substantial flaws in it, and would like to see it implemented". Just opposing it without any explanation is saying "I have found flaws in your proposal I'm not telling you which I think mean the proposal shouldn't be implemented". Do I need to tell you how constructive it is to be told there are significant errors in your work without a slightest hint at what these errors are? Yet I have seen editors rebuked for insisting raw opposition is meaningless. Just one example of a stated opinion which shouldn't affect the outcome.

Consider also this scenario which serves to demonstrate the nonuniformity of local and general competence among wiki editors. A proposal is made which is supported by ten users, yet an eleventh user comes and points out a significant and easily verifiable flaw in the proposal which means the proposal would be harmful if implemented. Do we need to delay dropping the proposal until either five of the supporters concede to Comrade Eleven, or twelve more users come and express their agreement with them? No, because the presented evidence takes priority over the number of initial supporters.

If you're going to go further, there's fact people are more likely to express discontent rather than content; I have been told by another prominent editor on the Russian wiki that they consider pure support unconstructive. I pointed out that this means a very good proposal won't receive any comments, rendering it unable to pass if the proponent wishes for a second user to review and support it before implementing it.

And that's not even considering arguments can be plain wrong. As a classic example, and one which I find very annoying, is this: Let's do X, like on Wikipedia! --User 1
 * Oppose. We're not Wikipedia. --User 2

Neither user really provides a point. There are many reasons why a procedure vital for Wikipedia could be highly detrimental to Minecraft Wiki. For one, we are a much smaller community with a significantly more narrow focus, and especially complicated procedures modelled after Wikipedia may backfire if implemented here, such as by exorbitantly draining the time and strength of our editors and administrators. Neither does User 1 in the example present issues on Minecraft Wiki their proposal is meant to mitigate, nor does User 2 properly analyze the proposal and present future readers of the conversation with the apparent intent and effects of the proposed procedure or action.

To summarize, counting opinions cannot be used as a substitute for analyzing arguments and evidence. Also, I'm very tired due to recent real-life events, so please forgive me for writing Frisk-sized walls of text with the clarity of a poorly constructed artificial intelligence. --AttemptToCallNil (report bug, view backtrace) 16:31, 22 September 2018 (UTC)


 * Except that of those many many visitors, a large portion has no experience with this wiki or wikis in general. The people who are frequent editors are, in general, the people who have the most experience with the wiki. This is only a response to your first "point" about the significance of a vote in the grand scheme of the wiki and its users. --Pepijn (talk) 19:16, 22 September 2018 (UTC)


 * It took your post, and some time during a sleepless night interspersed with thinking about legally privileged child abuse and nonprosecutability of obstruction of medical services with the intent to cause death of another, to conclude that the problem was way worse than I initially thought.
 * The problem isn't that most readers are not experienced enough to offer useful feedback in discussions. Users' experience is covered by the "10 vs. 1" point. The problem is that readers are affected by something they will not influence for several reasons.
 * First, it's that the fact the wiki has a metapedic component at all is obscure for most readers. The idea that every software product or a website has the work of people behind it is not one which occurs to most people when they use it. To read a wiki, it is "sufficient" to view it as a black box which typically provides useful information when a request is made.
 * Second, it's indeed that people often lack the experience to notice improvements can be made at all. Such inference requires familiarity with many more concepts than even your slightly above-average Alison or Solomon would know. "Not everyone is a web designer" is an understatement.
 * Third, it's that people are being purposefully conditioned by powerful entities such as governmental and religious institutions not to express any form of discontent, but rather to accept the world as it is made for them without questioning the actions or their "superiors", let alone trying to change anything.
 * Referencing the third point, during my high school years (not so long ago as some of you might think) I have noticed what seemed to be a misspelling in the history textbook. While the teacher (she was hardly less than 70 years old at that point) agreed, half the class started fervently convincing me there is no error (despite none of the actors having higher language grades than me). It shouldn't come as a surprise I spent some time in the evening trying to figure out which opinion is the right one. I determined that the form used in the textbook had only recently entered dictionaries as a valid alternative, and writing practices listed in some less widely known, yet authoritative sources prescribe using the new form only in some contexts the older form was used in; the example from the textbook wasn't one such context.
 * Summarizing: even though our decisions affect so many, so few of them will ever participate in our decision-making processes. This requires a reader to be familiar with the wiki (and/or wikis in general), being able to generate ideas they would consider useful, and willing to offer their suggestions to others. At this point, we most likely no longer have a reader, but an editor; and I listed the ratio of readers to editors in my previous post, which is sufficiently accurate even considering various errors and potentially inaccurate assumptions made when calculating it. --AttemptToCallNil (report bug, view backtrace) 06:24, 23 September 2018 (UTC)

Thanks for the fish
The fact that the splash message "Thanks for the fish" is a reference to Hitchhiker's Guide to Galaxy should be mentioned on the page about splash messages. I already posted a few comments about this topic on the Talk:Splash page, but no one seems to have noticed them, so I posted the issue here. 193.210.231.109 17:05, 1 October 2018 (UTC)


 * The actual sentence in Hitchhiker's Guide is "So long, and thanks for all the fish", while "thanks for the fish" is an ordinary sentence that might be said spontaneously by any dolphin in the game if you imagine it could speak. What evidence is there that Mojang intended the splash to reference the book? I find it believable that they did, but I'd be more convinced if the splash included the word "all". – Auldrick (talk &middot; contribs) 17:17, 1 October 2018 (UTC)

Author rewards program
This page is not Minecraft-related in any way and sounds like blatant advertising. I think it doesn't belong to Minecraft wiki and should be deleted. 85.76.69.41 11:22, 8 October 2018 (UTC)


 * Although this page was made by some of the hosting Gamepedia platform's staff members, and was legitimate back then, the page is old and I don't believe relevant anymore. It contains dead external links and mentions an "as of" date of over 5 years ago. The associated talk page also discusses whether or not to delete it. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:50, 8 October 2018 (UTC)


 * I asked on Slack what should be done with this page. --AttemptToCallNil (report bug, view backtrace) 12:02, 8 October 2018 (UTC)


 * by ATCN. I personally still don't necessarily like the idea of having a mainspace page that's not fit for mainspace, even if it is a soft redirect, but it's better than it was before.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 00:42, 12 October 2018 (UTC)

Articles for Deletion: Texture pack lists
The result of the discussion was delete. I'm going to be deleting the 3 subpages of Texture pack below, and am moving the Programs and editors/Inventory editors deletion discussion to a subsection and leave it open, so that the questions asked by asked can be addressed.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 01:16, 18 October 2018 (UTC).

Quoting myself from Discord, they are "unmaintainable collections with no definable inclusion/exclusion criteria". Another quote from Jack McKalling:
 * Texture pack/Low
 * Texture pack/Native
 * Texture pack/High
 * there is no reason to keep them anyway, it would just be another (set of 3) pages sitting and doing nothing
 * it's not there for people to refer to either, because they are not really linked to

Your thoughts? --AttemptToCallNil (report bug, view backtrace) 17:35, 8 October 2018 (UTC)


 * for all reasons as stated above. -BDJP (t 17:42, 8 October 2018 (UTC)


 * I these quotes. And deletion as well. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 18:37, 8 October 2018 (UTC)
 * , the lists are very incomplete and rarely updated, making them hardly useful for anyone. 46.132.188.174 04:07, 9 October 2018 (UTC)
 * . – Sonicwave talk  04:20, 12 October 2018 (UTC)

Articles for Deletion: Programs and editors/Inventory editors
I would also support the deletion of Programs and editors/Inventory editors (which is outdated and contains few items) under the same criteria. – Sonicwave talk  04:20, 12 October 2018 (UTC)
 * the deletion of Programs and editors/Inventory editors too. It seems to be incomplete and rarely updated, making it useless. 193.210.226.226 07:33, 17 October 2018 (UTC)
 * Just that subpage? You think some other subpages of Programs and editors (or that page itself) should be kept? If so, tell me why. --AttemptToCallNil (report bug, view backtrace) 19:19, 17 October 2018 (UTC)
 * Pinging . -- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 01:46, 18 October 2018 (UTC)


 * I wouldn't really mind the deletion of any of them (especially the list style articles or extreme stubs), though I think Programs and editors/Mod Coder Pack may still have some significance (partially since it was developed by Searge and ProfMobius). – Sonicwave talk  23:52, 19 October 2018 (UTC)
 * all. Every one of the lists seems to be rarely updated and almost every program listed on those pages is incompatible with the most recent versions of the game. I don't think these pages are useful for anybody. 46.132.190.234 05:16, 20 October 2018 (UTC)

Create abuse filter for "Roblox" vandalism
I see that the "Roblox" word is often added to the pages by some IP users and is often added, should we create abuse filter for "Roblox" vandalism that does not allow inserting the word into pages?  psl85  (talk • contribs) 06:15, 9 October 2018 (UTC)
 * , a filter like that would be very useful in preventing vandalism and won't create false positives, since there is no good reason why that word should be added to any page. 85.76.86.84 07:06, 9 October 2018 (UTC)
 * Filters for "Robux", "Robucks" and "Roblocks" would maybe be helpful as well. 193.210.225.169 16:20, 23 October 2018 (UTC)
 * It looks like filter 6 (the disallow certain words filter) isn't completely working now, which is why your test edit went through. I thought it might be something I messed up, but I don't see how that would be possible. How the abuse filter rule works, is all of the words in the filter are fully capitalized (i.e. GAY), but it apparently previously disallowed the edit when the same word is entered with ANY capitalization. However, as apparent with some recent vandalism, it no longer catches the certain words if they're in lowercase. A staff for Gamepedia believes it may be because of an abuse filter upgrade in preparation for the next MediaWiki update (which overall I'm very excited about). I'm not an expert with AFs, so I may consult with someone who has better understanding. As for your suggestion, I'm not sure how helpful Robux, Robucks, and Roblocks filters would be, but if it becomes a problem I'd be happy to add them to the filter.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:40, 23 October 2018 (UTC)
 * Ok, but i would be happy if you or some staff add them to the filter now because the words have no use in any page, and if there is problem with the words, please add them to the filter. Also, when is the next MediaWiki release? Wikipedia-logo.png psl85  (talk • contribs) 16:51, 23 October 2018 (UTC)
 * We generally wouldn't add a word to the filter for the sole reason of never having any use, but rather if a word becomes a problem. So far, there hasn't been any vandalism regarding Robux, Robucks, and Roblocks as far as I know (correct me if I'm wrong please), so there's not any point adding them to the filter. If we were to add every possible variation of a word as long as it has no use, we would add "g*y," "ga*," "ga*y," "gy," "gaay," "gaey," and the filter would eventually get clogged up. Also, words will sometimes create false positives when you can't even imagine it would, so it's better to put as few words as possible while still making the filter effective against vandalism. Again though, if it becomes a problem, let me know and I'd be happy to add them. :)-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 15:59, 3 November 2018 (UTC)
 * Also, MarkusRost was kindly able to help me fix the problem regarding the capitalization errors by just adding a bit of regex coding, so the filter should be working now. About the next MediaWiki release, I don't know exactly when it will come out, but hopefully soon!-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:01, 3 November 2018 (UTC)

Mob and Block Renders
Where exactly do the images of mc mobs and blocks come from? How are they made? Who makes them? –Preceding unsigned comment was added by Thelarry79 (talk • contribs) at 6:51, 14 October 2018 (UTC). Please sign your posts with


 * See MCW:Standardized views --Giorgosarv18 (talk/contribs) 08:24, 14 October 2018 (UTC)

Proposed 3DS version history split.
After that small edit war which sort of felt like that time in which the crown when to Henry VI and then to Edward IV in the War of the Roses that seemed to never end, we have a discussion woo.

Anyway, this discussion is in regards to the splitting of the New Nintendo 3DS Edition version history article into several version articles (example).

Personally, I do the split because I feel like the split is not really necessary and it would be better off if the version history stayed within the main article. -BDJP (t 22:04, 22 October 2018 (UTC)


 * That's basically saying you oppose the split because you don't like it. I am towards the split because while that single history page is somewhat hard to read and navigate, it's also rather short. Also, that table layout makes me cringe. So much empty space. Maybe refactor it into sections of regular text? --AttemptToCallNil (report bug, view backtrace) 22:36, 22 October 2018 (UTC)


 * Well obviously I support this split as I already did it. There is literally no reason not to and all other versions that go by only one name get their own pages. And that table layout is horrendous especially on mobile. You have yet to really provide an actual argument against splitting, BDJP. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 22:40, 22 October 2018 (UTC)
 * the split. Just like Nixinova said, the page is a bit hard to read on mobile. 193.210.225.169 16:06, 23 October 2018 (UTC)


 * splitting. First of all, I appreciate that we're actually discussing this, rather than just revert, revert, revert, revert, screams on the talk page to stop, page protection... lol. In short, I feel like it would help the wiki more to split rather than harm it. The table is cluttering and I see no benefit to having it there. Also, the pages Nixinova had created are actually quite long, so it's not like there's hardly any information that can be said about these versions making separate pages useless. The version history page for the Nintendo 3DS Edition has looked terrible for a long time, and I definitely think there's enough information about each page to go ahead and do the split.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:25, 23 October 2018 (UTC)
 * I'm going to remove the deletion templates since there's supports don't revert pls. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 00:48, 24 October 2018 (UTC)

Mubble migration - need to talk
Earlier in the past months I've seen a lot of discussion about moving Mods pages to the FTB wiki. I've got my own mod which is Mubble and before this topic started to trend again I've actually already had many pages of documentation about the mod here. After the topic came in again, I started thinked about what I should have to do. Then, I contacted the Gamepedia administrator team to make my own wiki about the mod, their reply was to move to the FTB wiki. So at this point, almost everything led me to migrate Mubble to the FTB wiki.

Today, I can fairly say that more than everything documented here have been moved to the FTB wiki: right here.

However, I still wonder if Mubble should be kept here, as many many pages and files have been created for it and I don't know how the topic of "moving mods to FTB" evolved. So I'm asking to you, do you support or oppose the idea of keeping the Mubble mod here? - Hugman_76 09:49, 23 October 2018 (UTC)


 * The discussion can now be found here: /Archive 24. Judging from the arguments, the idea of the migration was to move from here over to ftb, which indeed means our pages would get deleted after having been implemented there. It's not really a migration if we keep the pages on our wiki. I don't think it'd be a problem if we need to delete that many pages, as long as a link to the new location is put in the deletion summary (either the main entry of the mod for each page, or an individual link for each page). – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:58, 23 October 2018 (UTC)
 * keeping Mubble here. In fact, I oppose keeping any sort of mods here. The FTB wiki is the right place for them, not this wiki. 193.210.225.169 16:02, 23 October 2018 (UTC)

Math format according to user settings
When I view this wiki (and every other site that uses English), I almost always have to face this format:

40,000.8 / 4 x 1.2 = 12,000.24

However, in my Vietnam, it writes like this:

40 000,8 : 4 . 1,2 = 12 000,24

And the result is I usually take my brain into calculating what is 40,000.8 (=320).

Recently because of my habit, when I was rewriting some portions of pages, I also applied my format to the things related to math and numbers.

But people use the 40,000.8 format, and they in turn are confused.

So I thought would it be possible if there is something to reformat these stuff for each user? Like when the page is generated, MediaWiki formats them according to the requesting user's settings.

Or do I have to learn to be familiar with the 40,000.8 format, which will force me to be two different people at the same time? Lê Duy Quang (Make some words | Contributions) 23:44, 23 October 2018 (UTC)


 * I would use US standard formatting for consistency throughout the wiki, much like we use US English spelling. Other language wikis are free to select a style that is more familiar for native speakers of that language. I don't know of a way to automatically reformat numbers and math; it would probably require writing an extension, and using a template to mark what parts of a page should be reformatted. -- Orthotopetalk 00:23, 24 October 2018 (UTC)


 * Yes it is confusing when you're used to a different format. But this wiki is supposed to follow American language and so formatting as well. It's possible a javascript gadget could be written to allow for flexible formats, customizable on a user basis, but there is currently no such thing available on the wiki. It doesn't have to be an extension (if I'm not mistaken) – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:04, 24 October 2018 (UTC)

Not every statement needs to end with a period
This is probably something I should have brought up earlier, but it's getting out of hand at this point. ,, . Not everything needs to be a complete sentence. In particular, the issue links thing bothers me: issue titles are generally titles, not sentences; adding a period to the end of "private security issue" is grammatically worse. Adding periods in a list of titles is really not useful, I think; it's also counter to how Mojang writes it on their changelogs and how JIRA generates release notes. It's just a bit of a mess to add periods to everything, especially without rewriting all the titles (which I don't think is a good use of anyone's time either).

In other articles and contexts, it may make some sense, but e.g. in tables and lists converting things into a sentence just to add a period isn't worthwhile. (An example of a list on wikipedia like this: Mark Twain bibliography). --Pokechu22 (talk) 15:30, 24 October 2018 (UTC)


 * In my defence, I never tried to do this up until someone did in my stead. I always merely just copy what others do. But still sorry, if you're not the only one who believes this, I'll adapt yet again no problem. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 15:47, 24 October 2018 (UTC)


 * No worries, just pinging you since I've seen that you've done it in the past. As I said, I probably should have brought it up earlier (I mentioned it on the slack and said I'd make a post, but never got around to it).  --Pokechu22 (talk) 16:12, 24 October 2018 (UTC)


 * Thanks for this! This saves more time than you can imagine, I've been doing this since I also saw this sort of thing happening. Thanks again! - Hugman_76 [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 21:31, 24 October 2018 (UTC)

(seems like I forgot someone else who's been doing this: ) --Pokechu22 (talk) 20:52, 24 October 2018 (UTC)
 * I just do it because everyone else does. I'm fine with not adding them to the bug fixes. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 21:16, 24 October 2018 (UTC)

"Discovered" features
I should know this already, but I don't. IP user 79.66.44.40 is making edits for Bedrock 1.8.0.11 Beta, claiming that the command was added. I have no doubt that this is something he found in the command autocomplete list, but it's not listed in the official changelog (and I'm guessing it probably doesn't work yet either). Do we have a consensus about including information about such "discovered" changes in the wiki? – Auldrick (talk &middot; contribs) 18:31, 24 October 2018 (UTC)
 * Well if it wasn't in 0.10 but is in 0.11 I see no reason not to add it. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 18:34, 24 October 2018 (UTC)
 * One possible argument is that if it hasn't been announced officially, they could postpone adding it indefinitely or even cancel it altogether. – Auldrick (talk &middot; contribs) 18:36, 24 October 2018 (UTC)
 * And thus we shouldn't mention it at all? Why not at least mention it explicitly as a not officially announced (or implemented) feature? --AttemptToCallNil (report bug, view backtrace) 18:48, 24 October 2018 (UTC)
 * It was still added and we can't tell the future so it should be on the page. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 20:09, 24 October 2018 (UTC)

Pages maintained by Mojang
Certain of our pages, notably Bedrock Edition Creator Guidelines, Bedrock Edition entity components, Bedrock Beta Add-On Documentation, Bedrock Beta Script Documentation, and Bedrock Beta UI Documentation, are maintained as official technical documentation by Mojang staff. We may have an occasional need to fix typos or make edits to bring them into compliance with the style guide (e.g., the names of the newest pages aren't capitalized properly), but in general these pages shouldn't be edited by non-Mojang staff. Should we have banners on these pages to warn people? What else can or should we do to protect these pages from vandalism, trolling, and even just misguided edits made in good faith? – Auldrick (talk &middot; contribs) 22:52, 24 October 2018 (UTC)
 * should be involved in this discussion. – Auldrick (talk &middot; contribs) 22:59, 24 October 2018 (UTC)


 * There is a template like disclaimer, I don't see why we can't have a similar (or modification of that) template to say something like "The contents of this page are directly supported by (...)" or something like that. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 23:13, 24 October 2018 (UTC)
 * Of course, we need another template which is excessively hostile and disruptive, and which has been fully protected for the purpose to ensure that it perpetually remains excessively hostile and disruptive. But seriously, a template wouldn't hurt, just don't go overboard with veiled threats warnings or praise. --AttemptToCallNil (report bug, view backtrace) 04:23, 1 November 2018 (UTC)


 * I suggest all of them should have at least an autoconfirm users protection to prevent vandalism. We can make an needs update above or create a template specifically for these pages.-- skylord_wars (talk) 01:33, 1 November 2018 (UTC)
 * What you're trying to accomplish would probably work better with FlaggedRevs stabilization, but I doubt this will get approved. I don't think the matter or vandalism protection can be meaningfully discussed without Mojang staff. --AttemptToCallNil (report bug, view backtrace) 04:23, 1 November 2018 (UTC)

Protection locks
Hey folks! Per this now archived discussion, I've enabled a gadget which makes a lock show up in the top-right corner of protected pages, with the color of the lock depending on the protection level. Currently, it is not on by default, so you have to go to the gadgets section of your preferences in order to turn it on. I was a bit bold in doing this, as not all the details had been worked out, but the discussion had gone silent for a while and I thought it would be nice to actually get this done. That being said, now that it's been implemented, if any one has any suggested improvements or changes you think would make the script better, please discuss here. Here may be some questions that should be answered:


 * Should we make this gadget on by default? Update: It's now on by default
 * Should we add locks to signal move protection or upload protection?
 * Should we use locks different than Wikipedia's, such as the ones Violine's suggestion or Leduyquang's?
 * Should we delete or deprecate protected?

One thing I would definitely support is making this on by default and only allow registered users to disable it. I might even support adding the script to the global JS and removing the gadget. Feel free to discuss any or all of these points here.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 12:52, 25 October 2018 (UTC)


 * Good script, and I see the lock on the mob page, and I support adding it on by default, the lock makes it easier to see the protection level, instead of needing to view source on locked pages to see the protection level. We can also use upload/move locks to see upload/move protection level without trying to move the page or upload new version of a file, and then the page is protected, and the protected is almost completely useless because the ugly message box and simply says "This page is protected due to a common vandlism target" or a commonly transcluded template. We can delete the protected templae, it is complete useless while it is now locks available. --Wikipedia-logo.png psl85  (talk • contribs) 13:18, 25 October 2018 (UTC)


 * I like it. It's sad that the locks are only displayed at the end of the page loading cycle though, and I too, think it should be turned on for everyone. It's pointless if it has to be enabled first. I don't know the pros and cons of using a gadget versus just dumping it into our common style and script files though, but I'm guessing we can move it further up the loading phase if we would, not sure. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 13:29, 25 October 2018 (UTC)
 * Also, I really think all the different types of locks should appear as separate ones. Show a separate lock for the move protection, and another for file protection, etc. This makes sense, because they can happen at the same time, but otherwise building a "tree" hierarchy of these colours would be confusing. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 13:33, 25 October 2018 (UTC)


 * Considering the original intent of the discussion was probably to have these on by default, I've now made the gadget so that it's automatically installed for everyone, but registered users can still disable it in their preferences.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 13:52, 25 October 2018 (UTC)


 * I haven't checked out the locks yet because there is nothing to toggle the gadgets in the mobile version. Is the lock texture the one for "Lock Difficulty" button in the game? If so, how do I change them to my sweet, sweet locks, because I am still wondering if I am able to make my own version of the gadget? Anyway, you seemed to have done a great job on this. :) Lê Duy Quang (Make some words | Contributions) 15:12, 25 October 2018 (UTC)


 * P/S: If I can make my own version then I may implement some of my humble ideas. Those are not yet very clear in my mind to be spoken out, though. Lê Duy Quang (Make some words | Contributions) 15:20, 25 October 2018 (UTC)


 * PP/S: I have reviewed my locks and the criticism about "the antialiasing and the black border just don't fit in Minecraft at all". I will redraw them tomorrow or so so that there is no anti-aliasing. Lê Duy Quang (Make some words | Contributions) 15:34, 25 October 2018 (UTC)


 * OK, so I've forked my own version of the gadget and have my locks there instead. You can see them here: User:Leduyquang753/Locks_test.
 * However, I think there should be more states for the indicator. For example the template Message box, there is a lock version called Template protected which indicates that the template cannot be edited by anyone except Administrators. It is also similar for Upload protection.
 * And I am thinking of adding some more features to the gadget. You can always check out my version here: User:Leduyquang753/ProtectionIndicator.js.
 * Lê Duy Quang (Make some words | Contributions) 03:36, 26 October 2018 (UTC)


 * the deletion of Template:Protected. The locks are definitely better, because unlike the template, the locks show the type of the protection. 85.76.67.198 05:12, 26 October 2018 (UTC)


 * I posted a minor script improvement suggestion on the gadget talk page. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 17:46, 3 November 2018 (UTC)


 * with the help of Jack and ATCN.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 21:50, 3 November 2018 (UTC)

Collaboration needed on page
Currently, I am writing a tutorial for creating a resource pack for Bedrock Edition. The tutorial is on an advanced level, and one funny thing is that this is the first time I have ever touched on Bedrock Edition's resource pack.

I am trying to inspect the default resource pack to describe the work in a way that is as useful and detailed as possible. However, there are things in the creative aspect that I cannot write about, so I need someone to help me in the creation of this page.

Thanks. Lê Duy Quang (Make some words | Contributions) 12:18, 26 October 2018 (UTC)

I Bought Minecraft Java Edition in 2011 or 2012, so how do I get my Free Windows 10 Edition?
The Windows 10 Edition page (the main one) says that people that bought Java Edition prior to 10/19/2018 get the Windows 10 Edition for free. How do I claim it? My Minecraft username is Goat__Man. If this deal is a fake or is outdated, is there any way I can get Java Edition on Windows 10? I couldn't find an answer to either on the Internet. Thanks, --38.128.149.2 22:46, 26 October 2018 (UTC)


 * I'm sorry to say the wiki is not owned or managed by Mojang, so we can't provide sales and technical support. I'd suggest using the Support link in the bar on the left side of every page. – Auldrick (talk &middot; contribs) 23:15, 26 October 2018 (UTC)


 * You have to buy it after Minecraft Windows 10 has released and before 19/10/2018. If you are sure you meet those criterions, log on to your Mojang account page and look for your Minecraft Windows 10 gift code. Lê Duy Quang (Make some words | Contributions) 01:12, 28 October 2018 (UTC)

Texture Update changes on &sect; History?
Should every iteration to the texture changes be documented in the history section of articles? For example, add "changed texture" on everything for 43a and then add that again for stone, sand, cactus, etc for 44a. – Nixinova  19:06, 31 October 2018 (UTC)


 * Previously, every texture change was recorded. But the Texture Update is a huge one. I think we should follow how we did to The Flattening.-- skylord_wars (talk) 01:27, 1 November 2018 (UTC)


 * Perhaps a history section could be used on the Texture Update page tracking all the changes? jjlr (talk) 04:32, 1 November 2018 (UTC)
 * I think that would be good. – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 04:53, 1 November 2018 (UTC)


 * &#8203;. This will take a long time, but worth doing. Maybe we can at the same time add The flattening to each article. Lê Duy Quang (Make some words | Contributions) 13:37, 1 November 2018 (UTC)


 * What do you mean, add the flattening to sll articles? every flattening change is already listed for all blocks and items; I’ll go through the sounds, biomes and alike at a later date though. But I’m still unsure what you’re referring to, what’s left to add to those pages? FVbico (talk) 23:19, 24 November 2018 (UTC)

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)


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


 * &#8203;. 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)
 * , 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)


 * , 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:14, 3 November 2018 (UTC)


 * per Jack McKalling. -BDJP (t 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). --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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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 &middot; contribs) 21:05, 3 November 2018 (UTC)


 * 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. 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 had put together. Compare Apple vs Pomme, or for a more complicated/messy example, Armor vs Armure.

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 in your sample page, probably just a typo I'd guess. – Auldrick (talk &middot; 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)


 * . 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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 &middot; 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 &middot; contribs) 15:50, 4 November 2018 (UTC)


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


 * 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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 &middot; contribs) 19:10, 5 November 2018 (UTC)


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


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


 * 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 Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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!  – 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:57, 7 November 2018 (UTC)
 * There can be a queue that is fed several facts at a time and then the contents will be revealed one by one. Lê Duy Quang (Make some words | Contributions) 13:03, 7 November 2018 (UTC)


 * I have implemented the content display module. Preview:
 * {| class="wikitable"


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


 * }


 * 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)
 * Sounds good, and makes the main page more interesting. 193.210.224.228 05:32, 9 November 2018 (UTC)

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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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. -- Orthotopetalk 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 17:19, 23 November 2018 (UTC)


 * >I really don't think we should be allowing any registered user to vandalize them
 * So we should only allow directors to vandalize them? 🙃🙃🙃 --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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 17:24, 23 November 2018 (UTC)


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


 * I have no strong feelings on the proposal. As far as transcluding unprotected pages is concerned, though, I just added cascading protection to the main page, which will protect against that (though we shouldn't rely on it; pages should still be directly protected). 「 ディノ 奴 千？！ 」☎ 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 13:47, 1 December 2018 (UTC)


 * Unfortunately, an entry for November 6 in the News section uses the w template, a shortcut to the wikipedia template, so now that (in my opinion, totally unnecessary) template and shortcut are fully protected. If we're going to use the cascade option, shouldn't we ban the use of common unprotected templates on it? – Auldrick (talk &middot; 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 14:47, 1 December 2018 (UTC)


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


 * DidYouKnow Lua error... -- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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 ("/" 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 (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)


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


 * , this makes sense, as each external link entry is not an actual history item, but more of a "historic message".  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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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)


 * . 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 page shows how these external links can be well-phrased, and are easy to the eyes. In contrast, the Lectern page does not. It is too messy, clunky and the text is not straight to the point. This argument was mentioned to me by . Paraphrasing here in her name, because I think it is a very valid point. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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. 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 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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 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)


 * of User:Sonicwave32 being admin. He is doing great anti-vandalism work and might also be trusted with the "block" button to block vandals. --Wikipedia-logo.png 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)


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


 * 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 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:

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)


 * 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:22, 23 November 2018 (UTC)
 * I intended this to be a typical nomination. Just as the one above. With the intent to reach consensus. --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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:26, 23 November 2018 (UTC)
 * Well, we won't actually promote anyone unless/until we get a "I'm fine with being an admin" from them. --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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:31, 23 November 2018 (UTC)
 * Do you want to insist other users shouldn't comment on a nominee unless/until they confirm the subject is willing to be an admin? --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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:38, 23 November 2018 (UTC)
 * I didn't really say we should start seeking consensus right now. And it is actually a somewhat casual comment. But I think a resolution would be desired. --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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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)
 * 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:55, 23 November 2018 (UTC)


 * I personally don't think I have enough time to be a full admin on the wiki; I already do a lot of work on other things (e.g. the bug tracker) and I don't think I have time to take on more responsibilities. (However, my situation might change in the future; I'm not 100% sure). --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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:46, 26 November 2018 (UTC)


 * and since there's no word of you two yet, I'm just going ahead and ask. Do you accept being nominated for admin? 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:09, 1 December 2018 (UTC)


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


 * I don't think there's a fix for that other than wait for the developers to address the issue, which may not even happen. --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, 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: , , and , of which a few times rollback was used without any kind of edit summary (though most of the time undo was used instead or rollback with a summary, which is a good thing); using rollback w/o summary to edit war is really something that should never happen. I also have a few concerns about possibly 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 03:32, 28 November 2018 (UTC)


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


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


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


 * If you were to be an admin, what admin-related areas would you be involved in? E.g., would you patrol recent changes and block users when necessary? Patrol 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 18:42, 18 December 2018 (UTC)
 * I patrol and revert on recent changes currently, so I would block users making blatant vandalism, I think I would probably patrol pending deletion (if there aren't too many pages in it *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 Grid Book and Quill.png Grid Diamond Pickaxe.png 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)


 * , 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:


 * Director protected proposal.svg


 * 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 — Director protected proposal.svg. --AttemptToCallNil (report bug, view backtrace) 14:06, 1 December 2018 (UTC)


 * Here is version 2 with thicker lines:


 * Director protected proposal 2.svg Director protected proposal 2.svg


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


 * ...or with just a D:


 * Director protected proposal D only.svg Director protected proposal D only.svg


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


 * 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: 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 00:31, 24 November 2018 (UTC)
 * 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) . 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) ; deleted per below
 * 1.4.3 should be kept as in-game he f3 screen doesn't say "pre" – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 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)
 * do you think it would be better to redirect to 1.4.3-pre instead then?-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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 Grid Book and Quill.png Grid Diamond Pickaxe.png 18:15, 24 November 2018 (UTC)
 * Alright, . 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 02:35, 27 November 2018 (UTC)


 * Anyone want to comment on this? Bumping this discussion.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 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: -- HaydenBobMutthew ( talk, contribs ) 14:01, 24 November 2018 (UTC)
 * 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.


 * I would 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 14:02, 24 November 2018 (UTC)


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


 * . -BDJP (t 15:57, 24 November 2018 (UTC)


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


 * 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 &middot; contribs) 13:47, 27 November 2018 (UTC)
 * I think that Java Edition “fixes” section should be consistent with Bedrock Edition “fixes” section to solve this problem. HaydenBobMutthew  ( talk, contribs ) 05:14, 29 November 2018 (UTC)

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


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


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

When do we describe bugs in articles? Pt. II
I'd like to reopen the discussion at Minecraft Wiki talk:Community portal/Archive_18 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 &middot; 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  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.
 * 2) If it is decided to keep the collections, the placement of   tags in individual version articles will need to be documented.
 * 3) If it is decided to delete the collections, details of the deletion procedures will need to be discussed.
 * 4) 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 link. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 19:01, 3 December 2018 (UTC)


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


 * 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.  HorseHead.png GRASP logo.png MarkusRost (talk) 19:12, 3 December 2018 (UTC)


 * 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 &middot; contribs) 20:11, 3 December 2018 (UTC)
 * 1.14/Development versions. Clicking "view all" in the infobox on any 1.x page. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 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)


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


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


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


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


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


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

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? I, personally, am on this. – Nixinova   21:04, 20 December 2018 (UTC)
 * 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.


 * moving pages.  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

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 Grid Book and Quill.png Grid Diamond Pickaxe.png 22:10, 27 December 2018 (UTC)


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


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

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)
 * . 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"?


 * . 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 BlobsPaper.png 15:51, 31 December 2018 (UTC)


 * . We should also rename other pages like Snow to Top snow to make it persistent with other pages. once moved it, but it was quickly reverted by  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)


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


 * per Pokechu22. -BDJP (t 19:03, 31 December 2018 (UTC)


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


 * . 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 Grid Book and Quill.png Grid Diamond Pickaxe.png 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 BlobsPaper.png 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


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

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

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 " ". -- 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 Nixinova sig image 1.png Nixinova sig image 2.png 18:40, 6 January 2019 (UTC)


 * I would support moving them into project namespace and agree that they may be useful/interesting for historical context (e.g. old talk pages), though I don't have any strong arguments against deletion either. – 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?
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 &middot; contribs) 17:31, 11 January 2019 (UTC)


 * , 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 &middot; contribs) 17:46, 11 January 2019 (UTC)


 * I agree with Auldrick. Yes, it's redundant, but, 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 | 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 &middot; 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 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 [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:09, 17 January 2019 (UTC)


 * They take too much space and use it suboptimally – that's my biggest concern. And centering of text makes them hard to read. The boxes need to stand out indeed, but that doesn't mean they need to stand out as much as possible (you'd agree red boldcaps on green background is not going to happen, right?). --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 Nixinova sig image 1.png Nixinova sig image 2.png 18:55, 17 January 2019 (UTC)
 * Even that would be better than what we have now. --AttemptToCallNil (report bug, view backtrace) 20:43, 17 January 2019 (UTC)

Reduce the number of gigantic tables on the wiki?

 * Template:History
 * Achievements
 * 1.13/Flattening
 * 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 Nixinova sig image 1.png Nixinova sig image 2.png 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)


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


 * making large tables easier to navigate. Another large one is n 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 ! 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 18:44, 17 January 2019 (UTC)
 * Thank you very much. I hope I'm not making any mistake by trying to correct some...  --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)


 * There is. Minecraft Wiki:Style guide/Versions 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 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 22:08, 18 January 2019 (UTC)


 * My thought is, no, using the square brackets is definitely not necessary (however, I am a bug tracker moderator and I have the power to actually edit the issue titles directly, though generally I don't bother with grammatical issues). And of course, adding links to commands and code formatting and such is sometimes helpful, though also probably not necessary most of the time.  The "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)


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

Wiki cleanup
I propose the following changes: Thoughts? – Nixinova   23:31, 23 January 2019 (UTC)
 * Export subpages of mods to ftb: and nuke it.
 * Nuke custom servers
 * “None of them have any claims of notability and are just added willy-nilly. Most of them are stubs and/or orphans and many contain blatand advertising. They require a lot of maintenance even though they haven't been relevant for almost a decade now. Unmaintainable pages which include installing programs is a recipe for disaster when anyone can edit (virus alert). These pages have nothing to do with Mojang nor with modern versions of Minecraft itself.” 04:22, 24 January 2019 (UTC)
 * Delete translation projects older than 4 years (see directly above).
 * Move the remainders to [MCW:Projects/language translation/page] so maintenance can be way easier and then they don't clutter search, etc. "SuffixIndex" is not a thing so it's really hard to ctually find these translation pages. 04:24, 24 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)