Minecraft Wiki talk:Community portal

From Minecraft Wiki
(Redirected from Minecraft Wiki talk:PORTAL)
Jump to: navigation, search

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[edit]

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! Wikipedia-logo.png psl85 (talkcontribs) 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#Speed 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) Wikipedia-logo.png psl85 (talkcontribs) 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#Speed, or redirect it to the other use? Wikipedia-logo.png psl85 (talkcontribs) 03:34, 2 August 2018 (UTC)

What should we do of the "/video" subpages?[edit]

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 · 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𝓣𝓟𝓒 🗸 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:19, 6 August 2018 (UTC)


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

 Weak support, I think the "/Update Video" subpages should be kept for their utility. - Hugman_76 [ User page Talk page Contributions ] 16:30, 5 August 2018 (UTC)
Agreed. FVbico (talk) 13:36, 16 August 2018 (UTC)
 Support, 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)
 Support, 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[edit]

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[edit]

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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 19:43, 10 August 2018 (UTC)

Merge fish back together[edit]

The result of the discussion was do not merge.

I  Disagree with the recent split up of the Fish (food) page. The split hasn't done away with parenthesized page names and has made things very inconsistent with the mob form, which is currently all merged. Therefore I propose that it be merged back together, but this time under the title Fish (item), which looks more natural. If this is done, people won't have to constantly switch between pages when they want to compare the items, and it also means there will be less pages to update and maintain. MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 05:58, 15 August 2018 (UTC)

I severely  Oppose for all reasons mentioned that are for splitting and the severe lack of opposing arguments that was provided during the time the split proposal was made in the first place. FVbico (talk) 06:02, 15 August 2018 (UTC)
The opposing arguments simply failed to be mentioned. But now they're right above your very comment. MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 06:10, 15 August 2018 (UTC)
“during the time the split proposal was made in the first place.” This time spanned more than 2 weeks, there was no “failed to be mentioned”, there just wasn’t anyone (literally) opposing the split; and now there literally isn’t anybody supporting your merge request. As others have already stated, you can have several internet tabs open in order to compare, so that argument of yours is repelled. Additionally ALL other items have their own page, even cooked and raw food have their own pages, so if anything’s inconsistent right now, it’s the entity and block pages that (still) talk about several different entities/blocks.
As for the parenthesized names, that’s because item and entity are still on different pages; perhaps if the entity page got split, the cod mob and cod item page could be merged, the salmon mob and salmon one, pufferfish mob and pufferfish, and tropical fish mob and tropical fish, but for now it’s still better to have the parenthesized names until such time. FVbico (talk) 06:36, 16 August 2018 (UTC)
There are hundreds of active editors on this wiki, and yet how many of them were aware of, let alone took part in, the splitting discussion? The opposing arguments simply failed to be mentioned, period. And have you ever tried switching between tabs on mobile? It's quite a frustrating and time-consuming process. Contrast that to when the different information is right next to each other in the same article, and the comparison can be made in literally no time at all. MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 16:33, 17 August 2018 (UTC)
I switch/close tabs on mobile all the time, takes less than 2 seconds (1/2 second if you exclude looking which tab you need to select, that’s also an issue on pc/laptop), so again, that argument has been repelled.
After a being open for several weeks, it’s safe to assume that everybody who cares about the article saw it, and there’s been a lot of people who supported the split, even now; you don’t have a single person who supports merging it back together. It’s more than safe to say that nobody opposed (except for you). FVbico (talk) 17:10, 17 August 2018 (UTC)
 Oppose merging fish item pages. They were split to separate the confusing mess of content. The same could be done for the fish mob page, if you so want consistency. The parenthesized names are fine, they make it clearer what the pages are about. – Jack McKalling [ Talk Contrib ] 08:18, 15 August 2018 (UTC)
Well, if we merge it again, we can take the opportunity to ensure that it's less confusing. Right Jack? MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 01:32, 16 August 2018 (UTC)
 Oppose — I have taken a look at the fish mob article and noticed that its content is cluttered by the description of pufferfish’s poison-inflicting self-defense and tropical fish’s varieties. Their respective item forms are similarly outstanding: tropical fish cannot be cooked, and pufferfish is very poisonous (and nauseating), is used as a brewing ingredient, and can’t be cooked as well. Cod and salmon also have specific traits regarding areal, behavior, drops, saturation and nourishment of their respective item forms etc. This justifies not only the separation of fish items, but also a potential split of the fish mob article. — BabylonAS (talk | ru.Wiki Admin) 16:18, 15 August 2018 (UTC)
I also fail to see how “less pages to update and maintain” can be a viable argument. The effective amount of content remains the same, including overlapping text on multiple articles: if it is to be edited, then on all articles simultaneously, which might not be a problem if the edits and edited texts are identical. Regarding having multiple pages to compare against each other: with modern multi-tab and multi-window browsers it isn’t much of a problem either (and even initially console-only operating systems like FreeBSD feature multiple switchable consoles). — BabylonAS (talk | ru.Wiki Admin) 16:23, 15 August 2018 (UTC)
 Oppose. "(A) is done, but (B), which is similar to (A), isn't, therefore (A) should be reverted"? Uh... what? --AttemptToCallNil (report bug, view backtrace) 16:35, 15 August 2018 (UTC)
Do you have any better counterarguments than that? Just because it's been split doesn't mean it can't be merged back together! MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 01:36, 16 August 2018 (UTC)
You have answered all replies except mine. Apparently you don't have patience to read my nice little wall of text. — BabylonAS (talk | ru.Wiki Admin) 05:48, 16 August 2018 (UTC)
As per the wiki rules, please refrain from personal attacks against other users. -- Orthotopetalk 10:21, 16 August 2018 (UTC)
Where do you see an attack? Or am I not allowed to use adverbs in discussions? At least thanks for not removing the comment. — BabylonAS (talk | ru.Wiki Admin) 12:53, 16 August 2018 (UTC)
I addressed both of your arguments in favor of splitting in this proposal, and yet you still opposed. Since you haven't answered my above reply for almost a month, I'm going to assume you now  Support. MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 23:18, 12 September 2018 (UTC)
Do not speak for others. This is still considered an  Oppose. --Pepijn (talk) 01:47, 13 September 2018 (UTC)
No, it's a  Support. And please stop being mean. MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 02:35, 13 September 2018 (UTC)
 Oppose. Merging is often not helpful to the reader. You mention having to switch tabs to compare items, but what things are you wanting to compare that aren't covered by comparison pages such as food? MajrTalk
08:01, 18 August 2018 (UTC)
It would obviously be information that isn't covered by those pages, such as obtaining and non-food usages. Now do you support? MarcelTheHippie (talkcontribslogsblock log) 🐷🥕☮️ 20:46, 24 August 2018 (UTC)
"What things are you wanting to compare not covered by those pages?" "Obviously info that isn't covered by those pages" is not an answer. The food page also does cover obtaining, and what non-food usages are you needing to compare for food? Data values? Advancements? Trading? All seem to have pages. Only notable thing I can see is usage, which could totally be covered on the food page (which also seems to need updating in general). MajrTalk
04:17, 3 September 2018 (UTC)

Judging by flaws in the proposer's argumentation, I suggest closing the fish item part of this discussion off, and switch exclusively to discussing splitting the fish mob article where it actually should be. — BabylonAS (talk | ru.Wiki Admin) 07:50, 18 August 2018 (UTC)

Considering this has gone absolutely nowhere, with a lot of opposition and no support, I would suggest to wrap this up for now. Things are just going in circles. In the end, it's just a page about virtual fish so no reason for people to take this so personal. This can always be brought up again in the future if people so desire but let it rest for now. --Pepijn (talk) 04:49, 13 September 2018 (UTC)

Aboud "id", "id name", "data value", "name" and so on[edit]

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:<color>_wool". And in the section "wool#dava values", its "id" is "minecraft:<color>_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:管理员告示板#id、id名称、名称、数据值等名称混乱):

  • 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 · 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[edit]

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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:31, 19 August 2018 (UTC)

Should ids in infoboxes appear with namespaces?[edit]

For example, in the section wool#Data Values, Java Edition IDs may be "minecraft:<color>_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 minecraft. 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 minecraft:. --Hubry (talk) 10:44, 30 August 2018 (UTC)
We could add a hover text over the "nameid" label that says it's namespaced with minecraft, 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[edit]

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 [ Talk Contrib ] 12:21, 15 September 2018 (UTC)

Navbar hollow's edge behind the search bar[edit]

Should this be retextured? Lê Duy Quang (Make some words | Contributions) 12:26, 19 September 2018 (UTC)

Navbar hollow's edge behind search bar.png

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 [ Talk Contrib ] 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[edit]

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)

 Strong oppose. This would make the wiki way more confusing to navigate then before. -BDJP (t|c) 16:35, 19 September 2018 (UTC)
 Neutral on this implementation,  Weak support 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)
 Strong oppose creating new pages for everything.  Support 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)
 Strong oppose 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 [ Talk Contrib ] 07:48, 20 September 2018 (UTC)
 Oppose 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)
 Oppose 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)
 Neutral 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)
 Support 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)
 Neutral. 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:
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[edit]

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[edit]

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. 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 · contribs) 17:17, 1 October 2018 (UTC)

Author rewards program[edit]

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. 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 [ Talk Contrib ] 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)
 Soft-redirected 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:42, 12 October 2018 (UTC)

Articles for Deletion: Texture pack lists[edit]

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 AttemptToCallNil asked can be addressed.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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:

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)

 Speedy delete for all reasons as stated above. -BDJP (t|c) 17:42, 8 October 2018 (UTC)
I  Approve these quotes. And deletion as well. – Jack McKalling [ Talk Contrib ] 18:37, 8 October 2018 (UTC)
 Delete, the lists are very incomplete and rarely updated, making them hardly useful for anyone. 04:07, 9 October 2018 (UTC)
 Delete. –Sonicwave talk 04:20, 12 October 2018 (UTC)

Articles for Deletion: Programs and editors/Inventory editors[edit]

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)

 Support the deletion of Programs and editors/Inventory editors too. It seems to be incomplete and rarely updated, making it useless. 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 Sonicwave32.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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)
 Delete 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. 05:16, 20 October 2018 (UTC)

Create abuse filter for "Roblox" vandalism[edit]

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? Wikipedia-logo.png psl85 (talkcontribs) 06:15, 9 October 2018 (UTC)

 Support, 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. 07:06, 9 October 2018 (UTC)
 Note Filters for "Robux", "Robucks" and "Roblocks" would maybe be helpful as well. 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 (talkcontribs) 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. :)-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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!-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:01, 3 November 2018 (UTC)

Mob and Block Renders[edit]

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 (talkcontribs) 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.[edit]

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  Oppose 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|c) 22:04, 22 October 2018 (UTC)

That's basically saying you oppose the split because you don't like it. I am  Neutral 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)
 Support 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)
 Support the split. Just like Nixinova said, the page is a bit hard to read on mobile. 16:06, 23 October 2018 (UTC)
 Support 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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[edit]

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 [ User page Talk page Contributions ] 09:49, 23 October 2018 (UTC)

The discussion can now be found here: /Archive 24#Should we migrate mods to another wiki like FTB. 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 [ Talk Contrib ] 09:58, 23 October 2018 (UTC)
 Oppose 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. 16:02, 23 October 2018 (UTC)

Math format according to user settings[edit]

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 [ Talk Contrib ] 08:04, 24 October 2018 (UTC)

Not every statement needs to end with a period[edit]

This is probably something I should have brought up earlier, but it's getting out of hand at this point. HaydenBobMutthew, Hugman 76, Jack McKalling. 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 [ Talk Contrib ] 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 [ User page Talk page Contributions ] 21:31, 24 October 2018 (UTC)

(seems like I forgot someone else who's been doing this: Nixinova) --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[edit]

I should know this already, but I don't. IP user is making edits for Bedrock Beta, claiming that the function 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 · 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 · 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[edit]

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 · contribs) 22:52, 24 October 2018 (UTC)

Minecraft Staff should be involved in this discussion. – Auldrick (talk · 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 [ Talk Contrib ] 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[edit]

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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 (talkcontribs) 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 [ Talk Contrib ] 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 [ Talk Contrib ] 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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)
 Support the deletion of Template:Protected. The locks are definitely better, because unlike the template, the locks show the type of the protection. 05:12, 26 October 2018 (UTC)
I posted a minor script improvement suggestion on the gadget talk page. – Jack McKalling [ Talk Contrib ] 17:46, 3 November 2018 (UTC)
 Done with the help of Jack and ATCN.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 21:50, 3 November 2018 (UTC)

Collaboration needed on page[edit]

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?[edit]

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, -- 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 · 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 § History?[edit]

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 Grid Book and Quill.png Grid Diamond Pickaxe.png 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)
 Agree. 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[edit]

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 Grid Book and Quill.png Grid Diamond Pickaxe.png 23:20, 31 October 2018 (UTC)

 Support. I've always thought this, but was too shy to say anything. Seems like a good way to honor whichever edition first hosted the innovation. – Sealbudsman talk | contribs 01:23, 1 November 2018 (UTC)
 Disagree. I don't think people really care about that small detail, instead it will make the editions harder to locate. Lê Duy Quang (Make some words | Contributions) 13:40, 1 November 2018 (UTC)
 Weak support, while this would be chronologically more correct, it would be maybe a bit confusing for readers. 15:03, 1 November 2018 (UTC)
 Oppose, and sorry. I believe the editions should always be in a defined and consistent order. The order in which content was added to multiple editions can already be deduced from looking at the dates. But the tables for each edition can become very long on individual pages, making it difficult to find a particular edition of interest to the reader like others said above. Sorting editions to date of content will not help more than keeping them in consistent order would. – Jack McKalling [ Talk Contrib ] 11:14, 3 November 2018 (UTC)
 Oppose per Jack McKalling. -BDJP (t|c) 12:40, 3 November 2018 (UTC)

{{Citation needed}} and {{verify}}[edit]

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

I'd say the difference is that verify is used for asking for testing generally, while citation needed is for things that would actually need a citation (such as the claim about the creator of spleef in Spleef#History). --Pokechu22 (talk) 15:39, 1 November 2018 (UTC)
I use verify for things that don't necessarily need a citation but might not be true. For example, verify could be used to check that cactuses don't grow if there is a block obstructing its path in Bedrock. Citation needed could be used for a statement telling what the last minecon Notch spoke at was. Jahunsbe (Talk) 20:44, 2 November 2018 (UTC)
Basically both templates are used to request verification of the correctness of content, but the verify one doesn't ask for an actual citation source to prove said correctness. – Jack McKalling [ Talk Contrib ] 11:09, 3 November 2018 (UTC)

Use of {{issue list}}[edit]

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 Grid Book and Quill.png Grid Diamond Pickaxe.png 03:27, 2 November 2018 (UTC)

Allegedly, the template originally was able to expand a list of issues inline (there was some way to expand it and make a table?), but then that broke. If it were able to do that, it would definitely be at least slightly useful, but I agree that it's not too helpful in its current state (other than for things where there might be multiple search terms). --Pokechu22 (talk) 03:30, 2 November 2018 (UTC)
Agreed. – Sealbudsman talk | contribs 13:04, 3 November 2018 (UTC)
I don't really like seeing it on every page myself, but it isn't really true that "everyone knows about the tracker now". There are new owners of Minecraft all the time, and we can't know whether they'll discover the wiki before they learn of more appropriate sources of support. Plus, there are still people who edit articles to mention bugs (I saw one just today, in fact). I'm not sure that removing the templates would result in an increase in these unwanted edits, but having them might discourage it. Before we do the massive work, maybe it would be smart to try it out on a few pages, especially those for persistently buggy features? – Auldrick (talk · contribs) 21:05, 3 November 2018 (UTC)
 Agree. Cleaning up this equals to cleaning up a now obsolete section. Lê Duy Quang (Make some words | Contributions) at 3h44 | 10/11/2018

Loot chest per-item summaries as tables instead of prose[edit]

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

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

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

Big support for this. It's much, much easier to find what you're looking for than having to parse all that repetitive text. I don't remember where it was now, but I once saw a case where the template output was unbearably hideous and I wanted to fix it, but when I found out it was a template I forbore because I didn't have time to learn how it worked or how my fixes would affect other pages. I'm curious, though: Why is there no Java Edition heading? It makes Bedrock Edition look like an exception. Also, there's an unexpanded {{Upcoming}} in your sample page, probably just a typo I'd guess. – Auldrick (talk · contribs) 15:02, 4 November 2018 (UTC)
There's no Java heading because Bedrock was a relatively recent addition to this template, and yes that could be an improvement, I would support that. The exact same issue occurs in the text version and in the table version btw. Good pointing that out. – Sealbudsman talk | contribs 18:20, 4 November 2018 (UTC)
Support, especially because I see how horrible the current description on the Armor page is. --AttemptToCallNil (report bug, view backtrace) 15:23, 4 November 2018 (UTC)
 Strong support. Auldrick worded this much better than I could, but for module-generated info such as this, prose looks so messy and choppy; using a table instead would be a significant improvement.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 · contribs) 15:43, 4 November 2018 (UTC)
Good idea I think. The percentage chance differences bw Java and Bedrock are mostly because of different items elsewhere in the loot tables throwing off the weights, and only occasionally because of actual different drop chances. – Sealbudsman talk | contribs 18:20, 4 November 2018 (UTC)
One more idea: Allow the Item column to be suppressed. In typical cases, it would only contain the item that the article is about, so it's just redundant and takes up space unnecessarily on mobile devices. – Auldrick (talk · contribs) 15:50, 4 November 2018 (UTC)
Sounds good to me. – Sealbudsman talk | contribs 18:20, 4 November 2018 (UTC)
 Support tables. But please make them sortable. When the list gets very large, it'd be helpful if you could re-sort the table by name, percent, structure, etc. I've had troubles with this loot chest output before, where multiple variants of the title item were available under different circumstances among different game platforms, but all resulting in almost the exact same sentence 10 times. Really unhelpful. – Jack McKalling [ Talk Contrib ] 19:50, 4 November 2018 (UTC)
Someone may have to put a slight bit of thought into how to sort the table without losing edition and version differences. Sort User:Sealbudsman/LootChest#Apple to see what i mean. Maybe each version/edition gets its own table? – Sealbudsman talk | contribs 21:17, 4 November 2018 (UTC)
Yes each edition its own table. Probably the best to do, if reasonable. – Jack McKalling [ Talk Contrib ] 21:39, 4 November 2018 (UTC)

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

Are you thinking of it more as a list of tables with edition headers, or a list of edition section headers with one table per section? Are there any advantages either way, or are they entirely equivalent? (The section headers would appear in the TOC, but whether that's advantage is unclear. Some TOCs are already kind of cluttered.) – Auldrick (talk · contribs) 19:10, 5 November 2018 (UTC)
The first one. – Sealbudsman talk | contribs 21:10, 5 November 2018 (UTC)
 Support this. But make the table transparent so that the readers' eyes won't be hurt. Lê Duy Quang (Make some words | Contributions) 14:50, 6 November 2018 (UTC)
The default wikitable style is white background, and it's on the majority of tables in the wiki; is it a big issue? If it is, maybe raise a separate topic ..? – Sealbudsman talk | contribs 16:56, 6 November 2018 (UTC)
Eh, I just thought a big table should be less bright compared to the whole page. Lê Duy Quang (Make some words | Contributions) 01:15, 7 November 2018 (UTC)
 I have a question: How are we planning to organize the table? That means, what will the table look like in general? Lê Duy Quang (Make some words | Contributions) at 3h53:37 | 11/11/2018 (UTC)

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

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 [ Talk Contrib ] 08:15, 7 November 2018 (UTC)

Add "Did you know..." section[edit]

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

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

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

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

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

Update: Here is my suggestion about the placement of the new section. Lê Duy Quang (Make some words | Contributions) 03:16, 9 November 2018 (UTC)

We already have that section, it's called Trivia, and the wiki pages already tell all there is to know. – Luckowski 12:18, 7 November 2018 (UTC)
I know, I know. I meant this section is on the main page. Sorry for not being clear... Lê Duy Quang (Make some words | Contributions) 12:32, 7 November 2018 (UTC)
Oh. Well, that's a great idea!  Support – Luckowski 12:40, 7 November 2018 (UTC)
Do you mean some (automated) semi-randomized message from a set of predefined messages, or more like a single message news feed that we manually populate? I'd rather like the former, would be a nice flair to the main page that isn't too much of a burden to maintain. – Jack McKalling [ Talk Contrib ] 12:57, 7 November 2018 (UTC)
There can be a queue that is fed several facts at a time and then the contents will be revealed one by one. Lê Duy Quang (Make some words | Contributions) 13:03, 7 November 2018 (UTC)
I have implemented the content display module. Preview:
Did you know...

Lua error in Module:DidYouKnow at line 26: attempt to concatenate field '?' (a nil value).

I would love if you have some facts to feed in here.
Lê Duy Quang (Make some words | Contributions) 13:20, 8 November 2018 (UTC)
 Support Sounds good, and makes the main page more interesting. 05:32, 9 November 2018 (UTC)

 Status update: Proposed to the editcopy. Lê Duy Quang (Make some words | Contributions) at 3h57:42 | 11/11/2018 (UTC)

Before adding this...[edit]

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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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?-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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. :-)-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 17:24, 23 November 2018 (UTC)
Bump. Anyone want to comment on this?-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 · 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 · contribs) 15:06, 1 December 2018 (UTC)

Make the "News and events" icon in the main page dynamic[edit]

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 ("12/2018" 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[edit]

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

 Support this idea. I think the implementation history should be something to describe the statements in detail. Lê Duy Quang (Make some words | Contributions) at 3h37 | 10/11/2018 (UTC)
 Good idea, this makes sense, as each external link entry is not an actual history item, but more of a "historic message".(changed my mind, see below) Do you suggest to modify all used history tables that have external link entries to pre-implementation information, or are you talking about a specific subset of pages? – Jack McKalling [ Talk Contrib ] 10:33, 13 November 2018 (UTC)
Yes, everything with a version title of "month day, year" andan ext link should be moved into prose and leave the history template for changes ingame. – Nixinova  02:37, 14 November 2018 (UTC)
 Oppose. The information related to the external links are still part of history, and extracting it from the table and leaving it as prose above does not help the flow of the page. It would make the page less readable. However, if the text were rephrased to state exactly the information, it would be a lot better. For instance, the panda#History page shows how these external links can be well-phrased, and are easy to the eyes. In contrast, the Lectern#History page does not. It is too messy, clunky and the text is not straight to the point. This argument was mentioned to me by Nicolerenee. Paraphrasing here in her name, because I think it is a very valid point. – Jack McKalling [ Talk Contrib ] 19:55, 15 November 2018 (UTC)

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

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/" 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?[edit]

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

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

Sonicwave, if you would like to add something, please do so, or if I missed something, please let me know.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 FVbico seems another really solid candidate to become admin on this wiki, and I really think the community should also discuss to promote him as well. With his impressive knowledge of the game, his important contributions and his general motivation, he is definitively someone to think about for the role. I know some could be concerned about a bit of edit warring, and we should absolutely encourage him to improve himself on that aspect — but despite that, he's still someone who would really help the wiki if promoted. Promoting both of them could be a good way to resolve the lack of admins issues.
On another subject, the promotion system seems a bit ineffective right now... If the wiki is needing more admins for a while, without anything done to address the issue, perhaps it would be interesting to make a new system for the promotions. A Request for Adminship system is the most common elsewhere, this wiki should perhaps think about it (or something else). But anyway, that's not the point.
So this is my contribution to that subject. I hope I will have brought an helpful point of view for this discussion. JSBM (talk) 04:17, 21 November 2018 (UTC)
So you propose we implement sophisticated systems for tasks which, until now, have been served well by simpler equivalents, with no apparent substantial drawbacks? And yet you complain that Minecraft Wiki is bureaucratic? --AttemptToCallNil (report bug, view backtrace) 07:18, 21 November 2018 (UTC)
I'm suggesting this wiki is reviewing its process, to make sure there is always enough admins to do the tasks on this big wiki. By encouraging people who are interested to become admin to identify themselves instead of this weird habit of choosing them when it's really too late, we could resolve a lot of problems. I'm not suggesting a RfA is the best system, of course, simply one who have been successful elsewhere. And for me, having new bureaucratic system is not in itself an issue; having some that are useless or used abusively is however. In this case, the goal would simply be to set clear rules and process on how promotion should work here, to make the process more fair and open to all. (I suggest that if you want to further talk about this, you should open a new section instead, to give a proper place for the community to answer on this subject.) JSBM (talk) 15:44, 21 November 2018 (UTC)
I don’t object to being nominated. :) FVbico (talk) 10:20, 21 November 2018 (UTC)
 Support of User:Sonicwave32 being admin. He is doing great anti-vandalism work and might also be trusted with the "block" button to block vandals. --Wikipedia-logo.png psl85 (talkcontribs) 09:58, 21 November 2018 (UTC)
I don’t object to accepting both Sonicwave32 and FVbico. I don’t recall any problems with either users, at least when I had been actively observing the English wiki. — BabylonAS (talk | ru.Wiki Admin) 14:58, 23 November 2018 (UTC)
 No objections against Sonicwave getting the admin flag. --AttemptToCallNil (report bug, view backtrace) 15:58, 23 November 2018 (UTC)
 Support why not? =^^= Iludido (talk) 01:19, 24 November 2018 (UTC)
Per the above discussion, and given it's been several days since the last comment, I've  Promoted Sonic to admin. ディノ千?!☎ Dinoguy1000 03:59, 28 November 2018 (UTC)

Extra nominations[edit]

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)

(Just for clairity) I already stated I have no objections to being nominated above. FVbico (talk) 16:14, 23 November 2018 (UTC)
@AttemptToCallNil: I'm not quite clear; is this a general thing where we just provide informal input? Is this a reaching-a-consensus thing? Or are we just asking these users if they want to be an admin for now, without any outside input?-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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?-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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)
@Sealbudsman: I think you're a great editor, have excellent judgement, and have a nice, mature temperament; those are definitely great qualities for an admin. You don't have that much experience in admin-related areas, however, although you have tagged some pages for deletion months ago. For admin candidates, I generally want to see decemt knowledge of when to block vs. protect, block lengths, etc., but that would mainly be true if blocking/protecting is an area you plan on being involved in. If you were to be an admin, do you have specific areas in mind which you would work in? That will likely help me out a bit when trying to decide my position here. I doubt I'd outright oppose you, but if I do, please don't take it as anything personally.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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 [ Talk Contrib ] 10:46, 26 November 2018 (UTC)
The reason I haven't responded yet to FVbico's nomination is because I've had to spend some time thinking about it. It's a tough decision, but I'm going have to go with an  Oppose, with much regret. First of all, let me make this clear; FVbico is an excellent editor, a very hard worker, and most definitely one of the most active users we have here, so I don't like having to oppose him, but I do have some concerns that make me unsure about how he would use the administrative tools. In particular, there have been quite a bit of edit warring issues, most notably as follows: [1], [2], and [3], of which a few times rollback was used without any kind of edit summary (though most of the time undo was used instead or rollback with a summary, which is a good thing); using rollback w/o summary to edit war is really something that should never happen. I also have a few concerns about possibly biting newcomers. Working with newcomers is very difficult and saying one thing wrong can make them never want to edit again; they are even more likely to get scared away if it's an admin who says the wrong thing – although adminship really is no big deal, newcomers don't know this. An example is here; for a newcomer acting in good faith, you shouldn't command them to do something by using multiple exclamation marks. Some other problems with civility (that are not targeted towards newbies) include here and more severely here; it is true that the second one was several months ago, so I am a bit more lenient about that one, i.e. that alone would not be a reason for me to oppose. I am a bit concerned about deletion tagging as well. Jungle biome, Mushroom biome, and Swamp Biome were tagged for deletion by FVb, despite being common alternate names and very plausible search terms; this makes me a bit unsure about how they'd do with the delete button. I also have some minor concerns of inappropriate rollback use, but I'm not one of these extremely picky people for adminship requests who opposes for a few tiny little single mistakes, so that alone definitely wouldn't be a reason for me to oppose. :-)
I'm sorry I had to oppose, as FVbico is clearly a very helpful editor. However, these concerns are just too much for me to be comfortable giving him my full support for adminship. This is definitely not a "never" thing, just a "not quite yet" thing; if FVb keeps up the good work for several more months, addressing these concerns clearly and without having new concerns pop up, I see no reason why I shouldn't fully support him for adminship. If any of the community wishes to post a reply to my comment, I'd appreciate if you could do so here rather than on Discord, for the sake of transparency and keeping all discussion in one place. But do try to stay civil. :-) Best of wishes, -- Madminecrafter12Orange Glazed Terracotta.pngTalk 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!-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:15, 28 November 2018 (UTC)
I hope I'm not being indiscreet to bring this up. FVbico, your sudden and angry departure from Mojira a few months ago after what seemed to me to be a highly defensive response to criticism and attempts to calm you, worries me. I was not directly involved in that incident and don't have an opinion on whether you were treated unfairly or whether your leaving was an overreaction, but it saddened many of the other moderators and helpers and was generally disruptive. You and I have never had a conflict, but I can't help but be concerned by that incident. Do you feel you've learned enough from it that you can confidently say your anger wouldn't steer your exercise of administrator authority? And in the event that it does, will you be able to gracefully accept constructive criticism from the other administrators? Those are genuine questions, not wishy-washy expressions of doubt. I feel that your passion can be a great asset, provided you keep it harnessed and use it positively. So I'm asking for your honest self-evaluation: Are you ready to be an administrator now, or would it be better to wait until you've had more opportunity to practice self-control? – Auldrick (talk · contribs) 15:07, 28 November 2018 (UTC)
Leaving mojira was something I thought abaout MANY times before that, and it was (justified) distrust towards others that drove me away, not the critisism. I won't work with people who go talk crap behind my back (those who did, and read this will know that I'm referring to them), such as calling me asshole, or even putting other people against me. Additionally, aside from the distrust, I was being portrayed as villan (regarding MC-123456) because "of a joke", while I asked over a douzen times to not do that, yet people continued. In general, it was not a spontanious thing, but something brewing up over the last couple of years. I'm fine with critisism (if it's actually constuctive), and I have not actually abused any administrative powers before (aside from the last action I did on mojira, to try and get people to stop portraying me as villan, non-mods couldn't even see what I did).
FYI, I have no intent to return to mojira, and have been trying to forget it. FVbico (talk) 15:54, 28 November 2018 (UTC)
Nixinova and Nicolerenee since there's no word of you two yet, I'm just going ahead and ask. Do you accept being nominated for admin? FVbico (talk) 13:59, 1 December 2018 (UTC)
I don't think Nicolerenee could be an admin, as she's not going to use talk pages for her private reasons. I think she may be a good admin, not personally voting against, but in this state she can't communicate on the wiki (or even post her opinion here). – Jack McKalling [ Talk Contrib ] 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)

Page protection locks gadget: New padlocks?[edit]

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

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

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

About the SVGs, I believe I can modify the thing. Lê Duy Quang (Make some words | Contributions) at 14h25:41 | 30/11/2018 (UTC)
Here is my proposal for the director protected icon:
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?[edit]

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

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

More opinions[edit]

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, -- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:31, 24 November 2018 (UTC)

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)
@Skylord wars and Nixinova: do you think it would be better to redirect to 1.4.3-pre instead then?-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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,  Done. I've modified the target of the redirect, removed {{delete}} from the redirect, and struck through the 1.4.3 bullet point in this post with an explanation. Thanks for helping me out with this!-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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. :-)-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 02:35, 27 November 2018 (UTC)
Anyone want to comment on this? Bumping this discussion.-- Madminecrafter12Orange Glazed Terracotta.pngTalk 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[edit]

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

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

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

I would  Support that. If the issue fix is something Mojang's okay with having on an official change log, then I don't see why it can't be revealed on the wiki. Maybe we should add this to the style guide?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:02, 24 November 2018 (UTC)
 Support. --HaydenBobMutthew (talk, contribs) 14:04, 24 November 2018 (UTC)
Also, for security issues mentioned on the official change log, use the title from the change log with ref to the change log, influenced by 1.8.4, 1.8.5 and 1.8.6. --HaydenBobMutthew (talk, contribs) 14:06, 24 November 2018 (UTC)
 Support. -BDJP (t|c) 15:57, 24 November 2018 (UTC)
 Mixed opinions. For some issues, I think it's definitely fine, but I'm not sure about whether it's a good idea to include it for all issues. My general opinion on it is that for issues that only affect snapshots, it's fine to include it; for ones that affect releases more care must be taken (but it also varies on the issue; duplication issues I think are generally safer to make public, but that's only my stance). I should also note: I'm generally in favor of making private issues public eventually, though that hasn't really happened on the tracker. I should probably look into that again; the super old issues for 1.8 and the like probably can be made public at some point... (n.b. I am a bug tracker moderator, so I have access to the details of these reports, which does mean I have additional context others don't have) --Pokechu22 (talk) 18:09, 24 November 2018 (UTC)
 Comment Like Pokechu, I'm a moderator on the bug tracker. I want to mention a couple of things for consideration.
1) There are 2 reasons we make bug reports private: Either they contain personal information, or they describe an exploit. I believe the intent of the rule is to avoid giving publicity to exploits, but editors generally wouldn't be able to tell which reason applies (and both could apply simultaneously). If necessary, editors could ask one of us for a publishable description of a bug.
2) There are some reports that we make public despite describing an exploit. This is generally when they are already published on YouTube or Reddit and we therefore anticipate them being reported many times. We encourage users of the bug tracker to search before submitting a report, but they can't find a private report that way, so we make it public to try and avoid a lot of duplicate reports. Thus, "public" ≠ "not an exploit".
I don't think it's a good idea to publish exploits on the wiki at all, regardless whether they're public or private. They can absolutely ruin the game sometimes, especially on multiplayer servers. (Examples include disruption of a server's economy, invincibility during PVP, and surrounding a player with illegally obtained bedrock to extort, coerce, or disable them.) So maybe the rule should prohibit mentioning a bug's exploitative aspect instead. For instance, if the reverted edit that started this had said merely "Shulker boxes can't be dyed" and left out the duplication effect, it needn't have been reverted.
For these reasons, I suggest that the rule should focus on not promoting exploits, instead of whether a bug report is public or private. – Auldrick (talk · contribs) 13:47, 27 November 2018 (UTC)
 Comment I think that Java Edition “fixes” section should be consistent with Bedrock Edition “fixes” section to solve this problem. HaydenBobMutthew (talk, contribs) 05:14, 29 November 2018 (UTC)

Sound file licensing[edit]

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

Many sounds are creative commons licensed (the exact one varies though); see the sound attribution page. --Pokechu22 (talk) 21:37, 1 December 2018 (UTC)
  1. Are the CC BY-licensed sounds specified as such on the wiki?
  2. Are the non-CC BY-licensed sounds all C418-licensed? --AttemptToCallNil (report bug, view backtrace) 21:56, 1 December 2018 (UTC)

When do we describe bugs in articles? Pt. II[edit]

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

When we characterize ourselves as describing "how the game is", we don't mean that to contrast with "how the game isn't, but rather with "how the game is now" versus how it used to be or how it might be at some point in the future. It's intended to remind us to remove information that's obsolete, or at least to clearly mark it as such, and also to avoid treating mere rumors about upcoming changes as real information.
With respect to bugs, we only acknowledge a bug if it has been around for a long time and Mojang isn't actively planning to fix it. The reason is that we don't want to mislead people into depending on behavior that's likely to change in an upcoming release, and also because it's highly possible that nobody would remember to remove the bug description after the bug is fixed, at which point it would become misinformation.
I also took a look at your edit history to familiarize myself with the behavior you're talking about and saw what I assume is the discussion you say you just came from. To summarize, the other editor described the behavior as (paraphrasing) "parrots wouldn't follow or teleport to me while I was in an Ice Spikes biome". Then they jumped to the conclusion that "parrots […] become lethargic in a cold biome". You, in turn, appeared to accept that reasoning. The problem is that this conclusion is a generalization that doesn't automatically follow from the behavior. The assumption could be wrong: Maybe it doesn't happen in all cold biomes. Or the conclusion could be incomplete: Maybe it happens in some warm biomes, too. It's also possible that the true explanation is based on something completely different: Maybe a bug is making you untrackable by any mob when you're standing on ice. There's no way you can generalize from a specific event to a behavior description without making some assumptions about Mojang's intentions, and no way you can validate those assumptions unless you have access to the code base. Consequently, any generalizations of this type from non-Mojang staff have to be treated skeptically unless there's a very convincing argument. – Auldrick (talk · contribs) 06:07, 3 December 2018 (UTC)

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

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

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

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

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


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

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

There's not really much point in them. Want a list of all features? go to the 1.x page. Want to look through the specific snapshots? Go to YYwWWn and click the next= link. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 19:01, 3 December 2018 (UTC)
 Comment I use these pages. The main reason why is to find (using Ctrl+F) what snapshot a behavior was added in (usually so I can test bugs related to that feature, but others would have a different reason to do it). These pages are the most convenient way to do this, since that information isn't in the full article and the specific things I'm looking for generally aren't in the history section of an article (e.g. options changes). That would probably be solved by a more complete history section in those articles, but that's my current use case. --Pokechu22 (talk) 19:08, 3 December 2018 (UTC)
 Oppose I like the collection pages. They are specially useful, if you search for a change but don't know in which snapshot it changed (e.g. research for an {{history}} entry). Without the collection you would need to click through all 40+ snapshot pages.   HorseFace.png GRASP logo.png MarkusRost (talk) 19:12, 3 December 2018 (UTC)
 Question There's not a single link to one of these collection pages in this topic, nor is one of them even named. I'm left wondering if I've ever even seen one of these; I don't remember ever seeing a giant version-related page full of transcludes. (That might be because I don't often concern myself with Java history stuff.) Are these pages actually linked on the wiki, or are they only available by typing a secret URL? – Auldrick (talk · contribs) 20:11, 3 December 2018 (UTC)
1.14/Development versions. Clicking "view all" in the infobox on any 1.x page. – Nixinova 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?[edit]

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. -- Wikipedia-logo.png psl85 (talkcontribs) 19:55, 5 December 2018 (UTC)

 Support, nothing else to add. FVbico (talk) 20:04, 5 December 2018 (UTC)
 Support, but I don't think Tutorials:Main Page would be the right place to put an index. I like Tutorials:Index better, similar to how Help:Contents works on wikipedia (n.b. Help:Main Page redirects there too). --Pokechu22 (talk) 20:15, 5 December 2018 (UTC)
 Support and Comment There is at least one subpage of Tutorials that is linked to directly from a main page, I think using a {{main}} template. (Sorry, off the top of my head I can't remember exactly which page it is. Maybe Enchanting? But there could be others, too.) If this gains consensus, I hope we can make a split between them. – Auldrick (talk · contribs) 21:16, 5 December 2018 (UTC)
There are actually a large amount of "normal" mainspace pages that are linked to Tutorials subpages, such as Carrot.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:58, 11 December 2018 (UTC)
 Support "Tutorial" and "Tutorial talk" namespaces (singular, in line with the others). Also, redirect Tutorials to Tutorial:index or Tutorial:contents, instead of to "Tutorial:Main Page". It will be an exhaustive overview of contents (an "index"), more than a regular page describing the content of the namespace as a "main page" would. All current tutorial pages would have to be redirected to the new namespace, not just the top level "Tutorials" page. I don't think we need a second search box though, the one we have will be just fine this way. – Jack McKalling [ Talk Contrib ] 22:16, 5 December 2018 (UTC)
 Strong oppose The proposal uses only cyclic argumentation (we should do it because it should be done) for support. I ever heard only one solid reason to move tutorials outside the main namespace (not even its current subpage pseudo-namespace) was that they were of poor quality, and people shouldn't see such poorly written pages when they click "Random page", but this is an argument for improving the tutorials rather than putting them somewhere where they're even less likely to be found. Are there any real reasons we should do this? --AttemptToCallNil (report bug, view backtrace) 09:10, 6 December 2018 (UTC)
Because the tutorials do not describe the game. They describe suggestions from player to player, and aren't really articlespace worthy within the vision of the wiki, in my opinion. They have a different tone, different set of editors, different audience and different intentions. – Jack McKalling [ Talk Contrib ] 09:24, 6 December 2018 (UTC)
Do we have a standard definition for what exactly the main namespace is for? --AttemptToCallNil (report bug, view backtrace) 09:36, 6 December 2018 (UTC)
 Neutral Don't really have a strong opinion on this, although I would prefer "Tutorial:" over "Tutorials:" and "Tutorial:Index" or "Contents" over "Main Page" (for reasons stated by Pokechu22 and Jack McKalling). Just as a general note though, there are currently 351 content pages and 273 redirects beginning with "Tutorials/", although around 50 of them are /video subpages. –Sonicwave talk 21:21, 6 December 2018 (UTC)
 Weak oppose Meh, I don't really see a good reason for this. One disadvantage is that if we do this, the pages will not show in the search bar because namespaces don't. The article namespace is for content relating to the game, which tutorials are, and I can't think of a reason why we need to go to the trouble to move these all to a new namespace and just complicate things.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:41, 11 December 2018 (UTC)
 Comment If we move the pages to a new namespace, we could make in the LocalSettings.php so these could show up by default in the search bar. --Wikipedia-logo.png psl85 (talkcontribs) 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.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:55, 11 December 2018 (UTC)