Minecraft Wiki
Minecraft Wiki
This page is an archive of past discussions. Do not edit the contents of this page. 
If you wish to start a new discussion or revive an old one, please do so on the current talk page.


request to create more protection levels

currently, we only have 2 levels of protections (and 1 abuse filter) that limit editing, Stop ip-addresses, Stop newcomers, and Stop all but admins. So i think that like wikipedia, we should hava a protection level that only autopatrol/experienced users(look at recent changes) can edit so that pages such as Template:Version/FP can be edited by trusted users, instead of admins only.---Humiebee Discuss anything with me Look at my edits 23:29, 12 August 2020 (UTC)

Autopatrol-level protection was suggested several times in the past (mostly in the Discord), but I believe it was mentioned that custom protection levels may cause technical issues, though I personally don't recall major issues with the custom directors protection that we already have. Autopatrol protection on Template:Version/FP wouldn't work since it's overridden by the main page's cascading protection (which is admin-only). –Sonicwave talk 23:51, 12 August 2020 (UTC)
I looked at previous discussions and unfortunately.......they can't add it😭😡---Humiebee Discuss anything with me Look at my edits 22:19, 16 August 2020 (UTC)
 Support more protection levels (specifically autopatrol) as they'd be useful in general, even if not applicable in the specific situation mentioned in the proposal. -PancakeIdentity (talk) 08:58, 16 August 2020 (UTC)
 Strong Oppose. Why? What are problems with current one? Also, auto patrols shouldn't are basicly editors, who are so editing, that admins have problems with monitoring other users. --TreeIsLife (talk) 22:56, 9 September 2020 (UTC)
 Disagree with that argument.  Strong Support for more protection levels. Autopatrol level protection is important, especially when abusive persistent vandalism and sockpuppetry forced the admins to set full protection. One example is Human, which was bombed over and over by sockpuppets until full protection halted all edits, delaying useful grammar edits for a month. That protection of Human recently wore off, but Splash is fully protected due to sockpuppetry. This isn't good, as the page has a work in progress template, and many other things there may need constructive editing. Expanding the protection from directors to autopatrol allows more edits, while requiring enough contribution to the wiki to be trusted. Blockofnetherite Talk Contributions 03:09, 21 September 2020 (UTC)
Not to mention that the WIP template doesn't use the section param. For now maybe the protection duration should be reduced to about 1 week instead of 1 month to resume constructive edits sooner. By the way, you should submit Gamepedia help tickets regarding the creation and modification of new protection levels, as even the admins of the wiki cannot modify protection levels. Fadyblok240 (talk) 02:33, 22 September 2020 (UTC)
The difference is that autopatrol users have been marked by an admin as having useful edits, so locking a page to autopatrol and above would be useful for pages that get sockpuppeted. It's especially useful now as accounts are now really easy to make due to the move away form solely Twitch, and since semi protection only locks it to registered accounts it's very easy to get around, leading to situations where Splash is director protected only due to spam from new accounts. I'll work on making an abuse filter that accomplishes autopatrol level page locking later.  Nixinova T  C   03:22, 21 September 2020 (UTC)
 Support a protection level similar to Wikipedia's semi-protection and extended-confirmed protection, based a mandatory combination of account age and number of edits on this wiki (say, 10 days and 20 edits).  Support a protection level allowing the autopatrol right only in extreme cases because it casts too wide a net, too many constructive editors don't have that right. ~ Amatulic (talk) 05:28, 21 September 2020 (UTC)
 Support. TheGreatSpring (talk) 05:30, 21 September 2020 (UTC)
Is it possible to create a protection level in which only 'Experienced Users' (recent changes) can edit, similar to wikipedias 30/500 protection? pages like splash could be demoted.---Humiebee Discuss anything with me Look at my edits 19:32, 21 September 2020 (UTC)
You're referring to "extended confirmed protection". I suggested 10/20 in my vote above. Maybe 10/100. For this wiki, 30/500 seems a bit aggressive. ~ Amatulic (talk) 05:47, 22 September 2020 (UTC)
True, I guess that is quite agressive, maybe wikipedia's semi-protection? I would be fine with yours. With the excpetion of previously blocked users, I never see vandalism on the 'learners' section.---Humiebee Discuss anything with me Look at my edits 12:02, 23 September 2020 (UTC)
 Comment Are we going to create any protection levels? It seems like we are on support. Any technical problems? Is making autopatrol level possible? Blockofnetherite Talk Contributions 19:21, 17 November 2020 (UTC)
 Comment Now that Human has been bombed again by the same sockmaster recently, it has been receiving more full protections. As stated above, are there any technical issues with making autopatrol protection? Is it possible for other protections to be made, like 10/20 or 10/100 or something like that? Blockofnetherite Talk Contributions 18:42, 25 November 2020 (UTC)

Proposal: remove images from history and put them into separate gallery subpages

This is distracting with how many animations there are. This is annoying to read and translate with how many images there are. This disrupts the flow of text because the images are large.

I propose to not put historical images into history lists directly, but instead maintain a history gallery subpage with the images. Notably, that would be a subpage and not a section, as I don't believe most readers would need those images, and so they're an invariable bandwidth/performance strain. --AttemptToCallNil (report bug, view backtrace) 09:26, 21 August 2020 (UTC)

 Support, and while doing that for revisions, maybe it's also an idea to do it for the block states sections like with redstone wire? Currently, some block states are hard to understand with the explanation they have. Images for visual block state differences would help. FVbico (talk) 09:37, 21 August 2020 (UTC)
 Support, it took a lot of time to update these spawn egg images on Chinese Wiki (from sprites to images), and barely does nothing. It might be a bit useful when there are a little images along with historical texts, but only a little.-- LakeJasonFace.png Lakejason0 (TalkContribs) 10:07, 21 August 2020 (UTC)
 Support, they are just an eyesore at this point. I had this idea beforehand but not encouraged enough to make a remark. For now, I would only think that separating them is the best decision. – ItsPlantseed|⟩ 10:30, 21 August 2020 (UTC)
I'd say this is more of an issue with the History template itself than its contents, and we can all agree that said template is way overdue for a revamping. - User-12316399 (talk) 12:00, 21 August 2020 (UTC)
 Agree with you, also  Neutral about this topic---Humiebee Discuss anything with me Look at my edits 12:56, 21 August 2020 (UTC)
 Support, sheep kinda does this already. -PancakeIdentity (talk) 03:32, 23 August 2020 (UTC)
 Support. — Thomanski | t | c | 13:15, 23 August 2020 (UTC)


I have created a potential mock-up on User:Thomanski/Sandbox/Gallery for Log. Any feedback appreciated. — Thomanski | t | c | 13:15, 23 August 2020 (UTC)

 Support. -DEJVOSS (talk) 13:47, 26 August 2020 (UTC)
Changed to  Support---Humiebee Discuss anything with me Look at my edits 17:29, 4 September 2020 (UTC)
 Support || Remember this thing? Nether Reactor Core BE1.png Because I do. --Ninji2701 14:17, 27 December 2020 (UTC)

The problem with subpages

I think subpages are overused on this wiki. Wikipedia has disabled subpages in the main namespace and some others. Subpages cannot be accessed by clicking on the "Random page" link and only support one hierarchy while they may be more. I'm not saying to get rid of all subpages in the content namespaces, but to discourage some uses. Here's what I think when subpages should and should not be used:
Acceptable uses:

  • Anything that Wikipedia accepts as subpages—User subpages, template documentation, etc. It is laughable to even think about removing these subpages from the Minecraft wiki.
  • Mod pages (until all mod pages are moved to FTB)—The Minecraft Wiki only concerns the vanilla game. Although some of these pages are full articles, we don't want readers to end up on pages about specific mods.

Disallowed uses:

  • Writing about a feature of the same name for a different edition—These pages are articles and there are better ways to disambiguate the name than making it look like one article forms part of another when it does not.
  • Category subpages—Categories were created to replace mainspace subpages on Wikipedia. Using subpages for categories is pointless and sometimes the names get ridiculously long.
  • Mechanics pages—These pages are also articles, and in the past there was a dispute on whether these pages should be named "Mechanics/X" or "X/Mechanics".
  • Tutorials subpages—These pages are less like encyclopedia articles, but they still contain helpful instructional material so they should be moved to a new namespace.
  • File subpages—I don't know whether there are such pages or even if the subpage feature is enabled, but it should be disabled because some filenames create accidental subpages and hierarchy among files is bad.


  • Previous versions of features—These articles are useful to a historical perspective, but completely irrelevant in the latest version of the game.
  • Command subpages—These pages are legitimate articles, but pages starting with "/" cause technical problems.
  • Schematic pages—They are merely pseudo-images that are transcluded, but sometimes they may be used on more than one page so maybe they should be converted to templates.

There are more uses of subpages on this wiki but I am still unsure about whether they are acceptable. Fadyblok240 (talk) 21:23, 23 August 2020 (UTC)

My opinion. I'm going to list my strongest support on top and strongest oppose on the bottom (of what subpages should be allowed)
  1. User subpages  Definitely should be allowed.
  2. Minecraft Wiki namespace subpages  Definitely should be allowed.
  3. Archive subpages  Definitely should be allowed.
  4. Documentation  Definitely should be allowed (template)
  5. Guides, Commands and Official subpages  Should be allowed.
  6. Previous versions of features  Should be allowed.
  7. Development versions subpages  Should be allowed (ex:Java Edition 1.0.0/Development versions)
  8. Subpages that make sense but are too technical to be in a main article (Ex:/DV, /Structure, Category Data Pages, or others).
  9. Mod subpages  Should be allowed (as they still haven't been completely exported yet)
  10. Writing about a feature of the same name for a different edition  Should maybe be allowed as it makes sense but the argument also makes sense so i'm sorta split?
  11. Mechanics pages should be  Moved to another subpage/possible tutorial namespace
  12. Tutorials subpage should be  Moved to another namespace
  13. Category subpages should be  Should not be allowed like theres such thing as subcategories (Ex Objects requiring isometric renders/Re-render)

1 more thing, what do you mean by previous versions of features? are you talking about Java Edition 1.13/Flattening? ---Humiebee Discuss anything with me Look at my edits 22:59, 23 August 2020 (UTC)

Kinda, I meant pages like "X/Before <version>". which in my opinion I am still not sure about. Fadyblok240 (talk) 17:21, 24 August 2020 (UTC)
I support keeping those as let's take the Far lands, old farlands sounds so wrong and also, merging the Far Lands/Java Edition and Far Lands will create a lot of confusion, thats why it was split---Humiebee Discuss anything with me Look at my edits 17:46, 24 August 2020 (UTC)
What does this (Writing about a feature of the same name for a different edition) mean? like I don't know any example and I'm pretty sure there's no subpage, can you give an example?---Humiebee Discuss anything with me Look at my edits 17:48, 24 August 2020 (UTC)
A page like Achievements/Java Edition. I prefer moving pages like these to "<edition> X" (i.e. Java Edition Achievements and Java Edition Far Lands). I also support moving the current Far Lands page and moving it to Bedrock Edition Far Lands and leaving a disambiguation page behind. –Preceding unsigned comment was added by Fadyblok240 (talkcontribs) at 17:58, 24 August 2020 (UTC). Please sign your posts with ~~~~
I don't think moving "X/Edition" to "Edition X" is a good idea; the former provides a semantic relation that is more visible to search engines. I'm not sure what "category subpages" are or whether they are used on MCW. As for mechanics, "X/Mechanics" has the same consideration of semantic relation as with editions. --AttemptToCallNil (report bug, view backtrace) 18:01, 24 August 2020 (UTC)
There are already articles using the "Edition X" format, e.g. Java Edition mentioned features. Also, there is such a thing as category subpages on this wiki. I have reworked Template:Needs render to avoid category subpages, but Template:Render uses dozens of category subpages (e.g. Category:Objects requiring isometric renders/Historical features/Stems/Invalid states) which is too much for me to handle. Fadyblok240 (talk) 18:36, 24 August 2020 (UTC)
Above is 1 such example---Humiebee Discuss anything with me Look at my edits 18:40, 24 August 2020 (UTC)
Oh, those? Yeah, I agree, they're not the best idea. --AttemptToCallNil (report bug, view backtrace) 18:43, 24 August 2020 (UTC)
Mixed opinion on this. Subpages automatically link back to their parent pages at the top and allows easy access to them; this is especially useful on mobile where neither categories nor navbox templates show up. With that in mind, I think it makes sense to keep at least the following as subpages (and probably other scenarios that I missed):
However, I would support template-like subpages (such as Renewable resource/row) to the template namespace, as well as cleaning up category subpages. I would also support moving "Mechanics/Redstone" to "Redstone mechanics" since the mechanics page itself is a redirect to a different page. Regarding some of the suggestions by Humiebee, I am neutral on moving Tutorials pages to a separate namespace (assuming that it's searchable like the MCD and MCE namespaces), but disagree with making a namespace for "X/Mechanics" pages as they are similar to regular articles, just more technical. –Sonicwave talk 20:08, 24 August 2020 (UTC)
Ok, I agree on pretty much your whole statement above including the gallery subpage idea but but I think the Mechanics should possibly go into Tutorials:Mechanics/whatever.---Humiebee Discuss anything with me Look at my edits 20:15, 24 August 2020 (UTC)
I dont know, if mechanics are (not) tutorials, but I have no problem with that. So I am  Supporting this idea.–Preceding unsigned comment was added by TreeIsLife (talkcontribs) at 20:50, 24 August 2020 (UTC). Please sign your posts with ~~~~
I mean it is teaching you the mechanics of whatever so that  Would make sense.---Humiebee Discuss anything with me Look at my edits 22:47, 24 August 2020 (UTC)
I don't think you make strong enough case for not using subpages, especially so for mechanics and tutorials pages. For example, you brought up the past dispute regarding the names of mechanics pages, but the fact that the dispute was had and solved, and the community arrived at a solution, is an argument in favour of keeping the current page hierarchy, if anything. I'm fine with the other suggestions but mechanics and tutorials subpages work fine without issues. Blue Banana whotookthisname (talk) 07:16, 25 August 2020 (UTC)
Many of the Tutorials subpages are ignored by the Minecraft Wiki's most active editors. Special:Random The "Random page" link never links to subpages. If the tutorials were moved to a new content namespace, they wouldn't be subpages and therefore be accessible from the Random page link and more likely for editors to notice. Fadyblok240 (talk) 02:09, 27 August 2020 (UTC)
Fadyblok240Special:Random does not link to anything besides mainspace so that's.......---Humiebee Discuss anything with me Look at my edits 02:24, 27 August 2020 (UTC)
The "Random page" link does link to other namespaces, namely Minecraft Earth and Minecraft Dungeons. If a Tutorials namespace were created, the wiki manager could classify it as a content namespace. Ironically, Special:Random also links to subpages, although the "Random page" link does not. I tested this after the migration to UCP and I still couldn't get to a subpage by using the "Random page" link on the sidebar. Fadyblok240 (talk) 02:40, 27 August 2020 (UTC)
This is because the Random page link in the sidebar uses Special:RandomRootpage instead. – Unavailablehoax (talk) 21:55, 15 October 2020 (UTC)
It was probably configured like that to bypass non-article pages that are subpages of articles, but there are also legitimate articles that are subpages. Maybe we should move article subpages to root pages or allow the random page link to access subpages and move non-article subpages of articles to other namespaces. Fadyblok240 (talk) 20:20, 7 November 2020 (UTC)
Ditto Sonicwave and Humiebee for the most part, don't have a whole lot to add. I'd also add history-esque subpages to the list of "acceptable" subpages, there's not really a better place for most of these and it keeps them tied to their parent pages really nicely. While yes the current version of a main article body should always reflect the current version (and only the current version), the wiki should still hold all the information on old versions of features. Usually a good history section can get the job done, but oftentimes the changes are too vast and/or complicated to be fully represented there (for example, loot table reworks, old villagers, etc). -PancakeIdentity (talk) 17:41, 27 August 2020 (UTC)
See Minecraft Wiki talk:Community portal/Archive 26#Should we move all Tutorials pages to a own namespace? for further info about moving tutorials to a new namespace. Fadyblok240 (talk) 00:22, 18 September 2020 (UTC)
Should you open up a new discussion about this? I would like a new tutorials namespace, supporing Psl85 and User-12316399 ideas.---Humiebee Discuss anything with me Look at my edits 01:19, 18 September 2020 (UTC)
Here is a quote

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.

---Humiebee Discuss anything with me Look at my edits 01:25, 18 September 2020 (UTC)
And Another one

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

All in all, the opposes are not very convincing but the supports are, should I reopej the discussion?---Humiebee Discuss anything with me Look at my edits 01:27, 18 September 2020 (UTC)

Bot noticeboard?

I know this sounds really dumb but I kind of want like a page, similar to the Minecraft Wiki:Admin noticeboard that people can post on that requests something that a bot would do such as fixing links due to UCP. Maybe is should be called something else but idk what. Link????Minecraft Wiki:Bot noticeboard---Humiebee Discuss anything with me Look at my edits 20:29, 26 August 2020 (UTC)

I'm kind of skeptical. The Russian wiki has made one long ago. Now it's unused. Completely. The last 3 edits were in 2016, 2017, and one IP request about a month ago. --AttemptToCallNil (report bug, view backtrace) 20:40, 26 August 2020 (UTC)
Is there a link?---Humiebee Discuss anything with me Look at my edits 20:40, 26 August 2020 (UTC)
ru:MCW:Запросы к ботоводам. --AttemptToCallNil (report bug, view backtrace) 21:07, 26 August 2020 (UTC)
Oh... ever since 2016, it's been unused??---Humiebee Discuss anything with me Look at my edits 21:17, 26 August 2020 (UTC)
It seemed to be pretty active at 2014 but for some reason, it completely died down..---Humiebee Discuss anything with me Look at my edits 21:18, 26 August 2020 (UTC)
Thanks!---Humiebee Discuss anything with me Look at my edits 21:16, 26 August 2020 (UTC)
 Weak support Wikipedia has a similar page named Wikipedia:WP:Bot requests but on the Minecraft Wiki there are not that many bots, so maybe the Bot Noticeboard doesn't warrant its own page, but should be a section of subpage of the Admin Noticeboard or linked directly on the sidebar. Fadyblok240 (talk) 20:46, 26 August 2020 (UTC)
I don't think it should be in the sidebar but I do  Agree on it to be a subpage/subsection of the admin noticeboard.---Humiebee Discuss anything with me Look at my edits 20:49, 26 August 2020 (UTC)
I would  Support a small section dedicated for this. Although I feel like the community portal would a better place for this than the admin noticeboard, as bot edits aren't necessarily for admins. — Thomanski | t | c | 21:55, 26 August 2020 (UTC)
Though bots rights are only given to bots of trusted users so I have some mixed opinions---Humiebee Discuss anything with me Look at my edits 21:56, 26 August 2020 (UTC)
It's not super hard to be considered a trusted user if you're somewhat active and consistently constructive. Also, bots don't really have many different rights than normal user accounts, it's more to do with reducing spam and stuff. -PancakeIdentity (talk) 21:53, 27 August 2020 (UTC)
 Weak oppose. Don't really see a need honestly. In my time here, I've only seen a few users ask for a bot to do something for them that they couldn't/didn't want to do themselves. And in these few instances, they were easily fulfilled through discord or this CP. -PancakeIdentity (talk) 17:34, 27 August 2020 (UTC)

Closing and merging projects

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Few of these projects were closed --TreeIsLife (talk) 11:57, 12 May 2021 (UTC)

Well. Currently, we have many, many, many active Wiki Projects in Minecraft Wiki:Projects. But many of them are duplicate, non-useful and others, which idk, how someone could create it.

So here's complete list of active projects, excluding language ones

  1. Welcome
  2. Screenshot Minecraft Versions
  3. Beginner's Guide Rewrite
  4. Minecraft in schools
  5. Screenshot Fixing
  6. Rewrite for Style
  7. Version cleanup
  8. Tutorials Modernization
  9. Userboxes standardization
  10. Redirect cleanup
  11. Renaming
  12. Cleanup open tags
  13. Capitalization Fixing
  14. Individual Biome Pages
  15. Upload Missing Wiki Sounds
  16. Refactoring edition specific information
  17. Minecraft Earth Wiki
  18. Texture Documentation Cleanup
  19. Gallery organization
  20. Wiki videos
  21. Minecraft: Story Mode Mobs

21 pages, with some of them could be deleted.

So i start with my ideas

  1. Fandom has automatic Messages from some MediaWiki page. Also i don't see anybody adding {{Welcome}} template, so I consider  Closing it.
  2. Should be merged with Screenshot fixing
  3.  Keep it
  4. Better merging with Minecraft in Education
  5. Should be merged with Screenshot Minecraft Versions
  6.  Keep it but, compleate it.
  7.  Keep it
  8. Ok,  Keep it
  9. Keep it
  10. No activity, it's in dead point from it's creation, consider removing it
  11. It is compleated, we should archive that
  12. Keeping it
  13. Keeping it
  14. Happy to see it will be done (one time), so keep it
  15. It is compleated, so archive
  16. Keeping longer for discuss
  17. Archive
  18. Keep
  19. This is not most useful project, so discussion
  20. Keep that
  21. Keep it, but i notice that's outdated.

--TreeIsLife (talk) 20:54, 26 August 2020 (UTC)

I have some opinions as well.
  1.  Somewhat Agree, Madminecrafter12 is the only user to even remotely work on it, completly unused though the template should still remain as the template, not the project is still used.
  2.  Agree
  3.  Agree
  4.  Agree
  5.  Agree
  6.  Merge, would be better to merge with capitalization fixing.
  7.  Agree
  8.  Agree
  9.  Agree
  10.  Disagree, don't bomb it, improve it.
  11.  Agree
  12.  Agree
  13.  Merge with Rewrite for Style
  14.  Agree
  15.  Agree
  16.  Agree
  17.  Agree
  18.  Agree
  19.  Don't really agree/disagree there's still a discussion with like 90% support and so more discussion is not really needed
  20.  Agree
  21.  Disagree Story mode is discontinued so since less people have it, I don't think it's worth the effort so  Bomb it---Humiebee Discuss anything with me Look at my edits 21:15, 26 August 2020 (UTC)
I think Rewrite for Style and Capitalization Fixing should be merged. Fadyblok240 (talk) 16:57, 27 August 2020 (UTC)
Mostly agree with your conclusions. At this point, I'm not sure we need #16 anymore, we only deal with two editions. We're not perfect in how we document them yet but I'm not sure if need a project, especially as it never really had much discussion on what to do. Also, just wanted to check, the Earth Wiki project has no relevance now that it has its own namespace, correct? -PancakeIdentity (talk) 17:32, 27 August 2020 (UTC)
The Minecraft Earth Wiki project is still relevant, as many of the articles in that wiki's namespace are stubs. Fadyblok240 (talk) 09:43, 31 August 2020 (UTC)
Also, we should reclassify some projects as semi-active, as the Minecraft Wiki is never complete. I have added a handy template called {{project status}} that categorizes projects by activity. The cleanup open tags project has turned into a white elephant project. Fadyblok240 (talk) 02:16, 19 September 2020 (UTC)

Documentation template revamp

Can somebody add links to "/sandbox" and "/testcases" subpages of templates to the Template:Documentation template? Fadyblok240 (talk) 19:08, 28 August 2020 (UTC)

Why? --TreeIsLife (talk) 22:39, 9 September 2020 (UTC)
I (along with Humiebee) have created several template sandboxes, but the documentation template does not recognize that they are template sandboxes and shows that they have no documentation; they appear in Category:Templates with no documentation instead of Category:Template sandboxes. Fadyblok240 (talk) 22:32, 26 September 2020 (UTC)
I don't see the need for those pages, they'd just become outdated and useless quickly. Just use the Template:Sandbox or your own user subpage instead.  Nixinova T  C   02:10, 27 September 2020 (UTC)
Template sandbox subpages would be useful for implementing major changes to high-risk templates with complex code or many parameters, where the "show preview" button alone would not guarantee whether the template is free of errors. Fadyblok240 (talk) 03:31, 5 October 2020 (UTC)
Okay, and what stops you from doing that on your own page or as a subpage on the sandbox, instead of creating additional maintenance for all templates? Very few templates are both high traffic enough that a major change is wiki breaking and get enough changes to warrant a permanent sandbox page. Likewise, {{BatchTest}} can handle doing test cases by comparing actual uses of the template to a sandboxed version.
I get that other wikis like Wikipedia do this, we don't have nearly the editing traffic they do so we don't have to adopt such complicated systems to make templates easy to maintain.KnightMiner · (t) 04:02, 5 October 2020 (UTC)

Move the Greek and Turkish Wiki back into translation projects

Why? Well for starters, Grid Files, the vast majority of them are used exclusively by the turkish wiki, also for both wiki, they have inactive admins. Another thing is that the amount of contributions to the wiki is miniscule. All I see is User:Fusion thermonucleaire, who is technically a bot, who puts interwiki links, User:Thomanski, who uploads files and thats pretty much it, for the Greek Wiki, it's main page is not even 100% translated and again, completely inactive.

A Summary

  1. Both have no active admin (Greek admin edits once a year, turkish admin hasn't edited since 2017)
  2. Both have no active real contributers (Greek wiki is slightly more active then Turkish, still, 80% of edits are by Fusion thermonucleaire)
  3. The Greek Wiki does not even have a 100% translated main page
  4. The Turkish wiki uses grid files and would ease the hassle of removing them.
  5. Those are my reasons
  6. ---Humiebee Discuss anything with me Look at my edits 17:39, 4 September 2020 (UTC)
 Comment, the reason why I upload files to those interwikis is to remove their dependency of the English wiki so we can finally remove the grid files here. I honestly don't know what to do with these wikis though. I don't think straight up deleting them is a good idea (for people that don't understand English), but on the other hand, these interwikis are REALLY outdated and inaccurate information is never a good thing for a wiki. — Thomanski | t | c | 21:45, 4 September 2020 (UTC)
Yeah, but like putting it into a translation project isn't harmful.---Humiebee Discuss anything with me Look at my edits 22:01, 4 September 2020 (UTC)
Hate to say it, but,  Strong support moving back to translation projects, as their state is actually harmfull to the readers (false/outdated info everywhere, and only partially translated) and only hinders changes on the english wiki due to the dependency. FVbico (talk) 22:04, 4 September 2020 (UTC)
I think it has to do with the Cyprus dispute Fadyblok240 (talk) 00:36, 5 September 2020 (UTC)
What does this have anything to do with the discussion?---Humiebee Discuss anything with me Look at my edits 00:42, 5 September 2020 (UTC)
 Weak oppose - why can't we just delete the untranslated pages instead, and add dedicated "this info is disgustingly outdated" templates to it instead? I wouldn't be against just getting rid of the wikis entirely either given the lack of interest. - User-12316399 (talk) 00:40, 5 September 2020 (UTC)
 Comment Yes, because whats the point about having a wiki page translated in multiple languages and the translated pages not even be finished and be forgotten about. I would consider it wiki clutter. So unless someone takes the time out of their day to rework all these translated pages, i think it's best to just axe em'. James Haydon (talk) 04:05, 5 September 2020 (UTC)
 Strong support doing something about these translations, the Greek wiki is just a complete import of the English one, issues pages and all (this should never be how translations are done), so everything is 3+ years outdated and clutters maintenance on this wiki. Add to that the fact that, since the wiki is in English, its a target for spammers who won't be reverted like they are here. E.g.: el:Alpha 1.2.4: there's no'one other than English wiki users to revert them. I can barely find many pages that have actually been translated apart from like a disambig, though there is el:Κρύσταλλος_του_Ender, el:Βιβλίο και Πένα, el:Κύβοι Διαμαντιού‏‎, el:Μπλοκ‏‎, but that's it. I'll just import all of the translated pages back here so they're safe if we feel like nuking that wiki.  Nixinova T  C   20:20, 5 September 2020 (UTC)
There: Special:Prefixindex/MCW:Projects/Greek translation/ – that's literally all the translated Greek pages. The wiki can be safely nuked now if that's decided.  Nixinova T  C   20:34, 5 September 2020 (UTC)
What about the turkish wiki?---Humiebee Discuss anything with me Look at my edits 22:53, 5 September 2020 (UTC)
 Strong support for the Greek wiki, mainly because so many pages are untranslated (which kinda defeats the purpose of a traduction).  Weak support for the Turkish wiki, mainly because of the inactivity. Sagessylu (discuss | edits) 17:37, 6 September 2020 (UTC)
Sagessylu, the Greek wiki is already translated.---Humiebee Discuss anything with me Look at my edits 20:55, 6 September 2020 (UTC)
 Done by Nixinova Greek wiki only---Humiebee Discuss anything with me Look at my edits 20:55, 6 September 2020 (UTC)
Well, not really, I've just moved a couple to this wiki, el: still exists.  Nixinova T  C   01:33, 7 September 2020 (UTC)
okay ill wait and see if someone will actually finish them now that there back in the works. James Haydon (talk) 00:50, 7 September 2020 (UTC)
I'm worried about the Ukrainian wiki potentially suffering from the same fate. It's also on the brink of dying out. There is one local user who appears to have edited in the last few days, but aside from that, there are predominantly edits by users from other wikis, notably Mak_and_Iv (a Russian admin) who is also an admin on the Ukrainian wiki. — BabylonAS *Happy Camper* 12:20, 30 September 2020 (UTC)
The thai wiki also only has like 1 contributer who keeps it alive and from anarchy as well but aside from that, it could die as well. – Preceding unsigned comment was added by Humiebee (talkcontribs) at 21:22, 3 November 2020 (UTC). Please sign your posts with ~~~~

Replace /ED, etc, subpages with DPL section transclusion

TIL that DPL can be used for labelled section transclusion: {{#dpl:title=Furnace|include=#Block entity}}. This can replace having /ED, /BE, etc subpages.  Nixinova T  C   22:47, 5 September 2020 (UTC)

Changing it might break some nbt inherit templates though. FVbico (talk) 20:58, 6 September 2020 (UTC)
What about change it to only certain templates where it won't break?---Humiebee Discuss anything with me Look at my edits 20:59, 6 September 2020 (UTC)
Oh, LST finally works now? I believe there could be a workaround for NBT pages, but if it can be easily done with non-NBT data, then I am all for it. — BabylonAS *Happy Camper* 07:23, 24 September 2020 (UTC)

Converting .ogg files to .mp3 and .wav

Given that .ogg files aren't supported on mobile, maybe we should convert all .ogg files into .mp3 (Music samples) and .wav (sounds) files with software like Audacity. One user at Terraria wiki did this to Terraria: Otherworld tracks, wich were .ogg files. --Superwill771 (talk) 15:55, 8 September 2020 (UTC)

 Oppose There will be much much work. Only if you want to do converting and uploads, then, i am  Neutral --TreeIsLife (talk) 16:04, 8 September 2020 (UTC)
Umm... for me, the sounds on skeleton#Sounds, which are ogg sounds, work fine on mobile. FVbico (talk) 16:12, 8 September 2020 (UTC)
Probably (as I understood from discussion) meant on mobiles with mobile view. But even there, it is working. --TreeIsLife (talk) 16:24, 8 September 2020 (UTC)
I use Duckduckgo on an ipad with desktop view and they don't work.--Superwill771 (talk) 16:36, 8 September 2020 (UTC)
Well, it can be problem with iPads/iPhones. Duckduckgo is search engine. --TreeIsLife (talk) 16:40, 8 September 2020 (UTC)
Ogg sounds are not supported in Safari browsers. --AttemptToCallNil (report bug, view backtrace) 17:49, 8 September 2020 (UTC)
Duckduckgo is also a browser app on iOS/Android. I don't know if they meant that. — Thomanski | t | c | 19:38, 8 September 2020 (UTC)
 Half-Support. For the above reasons that some devices don't support these ogg files, I support. However, looking at User:TreeIsLife,'s argument it is a lot of work, I say go ahead and do that, I don't see it as a bad thing. Good luck on that. Blockofnetherite Talk Contributions 18:05, 8 September 2020 (UTC)
 Changed to full support for below reasons. Blockofnetherite Talk Contributions 21:22, 9 September 2020 (UTC)
 Support, this wiki is about work, I use safari and it fails completely, the terraia wiki example is good.---Humiebee Discuss anything with me Look at my edits 19:26, 8 September 2020 (UTC)
 Weak support for conversion to MP3, definitely not WAV. See my explanation on Terraria Wiki. --AttemptToCallNil (report bug, view backtrace) 19:38, 8 September 2020 (UTC)
So your saying we could use FLAC?---Humiebee Discuss anything with me Look at my edits 19:41, 8 September 2020 (UTC)
It looks possible, but I don't think this was actually done on the wiki before. --AttemptToCallNil (report bug, view backtrace) 20:05, 8 September 2020 (UTC)
 Support, but I'm not gonna do it. — Thomanski | t | c | 19:39, 8 September 2020 (UTC)
 Strong oppose. Just because ogg isn't supported on some mobile devices now, doesn't mean it won't be later, given that it's a license-free open-source thing. Firefox and Chrome already support ogg. I note that the VLC player supports ogg on all mobile devices. And I believe the Opera browser does also, which is also available on any mobile device. ~ Amatulic (talk) 16:28, 9 September 2020 (UTC)
why strong oppose TheGreatSpring (talk) 07:56, 22 September 2020 (UTC)
As a matter of principle, I strongly oppose creating unnecessary time-wasting busy-work, which is basically what is being proposed. Ogg is playable on all desktop browsers and on all mobile devices using VLC. By the time all the work has been done to convert ogg to mp3, mobile browsers will likely be supporting it anyway. ~ Amatulic (talk) 21:13, 22 September 2020 (UTC)
 Weak support as a temporary measure until the majority of affected devices end up supporting playback. - User-12316399 (talk) 17:11, 9 September 2020 (UTC)
 Neutral. I definitely don't like mp3 because it's not lossless, and I think this wiki supposedly being a source of information should present that information without losses. I see the issues with wav and ogg as well, though. What other possibilities are there? Blue Banana whotookthisname (talk) 07:39, 21 September 2020 (UTC)
Well, the sounds and music are stored in Minecraft as Ogg files in the first place, so if data integrity is a concern, they should be used and uploaded directly, which was already done. (For music files, it’s possible to cut the file to 30 seconds without re-encoding it — FFmpeg does allow that, not so sure about Audacity.) — BabylonAS *Happy Camper* 15:09, 24 September 2020 (UTC)
 Weak support TheGreatSpring (talk) 07:56, 22 September 2020 (UTC)
 Oppose — Transcoding Ogg Vorbis (one lossy format) to MP3 (another lossy format, with worse quality by the way) isn't good practice in general, and using WAV will lead to much larger files. Safari not supporting Ogg is Apple's fault, and VLC is also available (if I recall correctly™) on iOS/macOS as well. As for royalty free, this advantage of Ogg is no longer relevant now, as all patents on MP3 have already expired, however Ogg Vorbis is still superior quality-wise (as in, Ogg file will sound better than an MP3 of identical size). It doesn't seem to be worth the effort. — BabylonAS *Happy Camper* 07:19, 24 September 2020 (UTC)
I now  Oppose the idea TheGreatSpring (talk) 12:56, 24 September 2020 (UTC)
 Weak Oppose. I don't really have any original arguments, just see the opposing arguments above. I especially wouldn't like MP3 if it is indeed more lossy than Ogg. It seems like a lot of work and I know how long it can take us to do these sorts of tasks. -PancakeIdentity (talk) 19:13, 24 September 2020 (UTC)
Changed to  Weak support for above reasons, still think it should be done. I am  Weak oppose for mp3,  Support for wav and  Weak oppose due to the amount of time and effort it woult cause.---Humiebee Discuss anything with me Look at my edits 16:08, 17 October 2020 (UTC)
 Comment - Doesn't Wikipedia have a web player or something? I'm able to play Ogg Vorbis sounds in Wikipedia while using Safari. – Unavailablehoax (talk) 16:30, 17 October 2020 (UTC)
I'm pretty sure that is .ogv, not .ogg and it's basically adding up .gif and .(a music file that is available in all search engines as well as not being lossy)---Humiebee Discuss anything with me Look at my edits 21:42, 28 October 2020 (UTC)
What makes you think it's a video? Here an example sound file from Wikipedia, which is in Ogg Vorbis and can be played in Safari. – Unavailablehoax (talk) 22:12, 28 October 2020 (UTC)
.ogv is just an extension, the base format is still the same (well, then you’d usually have Theora video together with Vorbis audio). As far as I know Wikipedia uses a different extension for media playback, which might in fact handle audio files somewhat differently. — BabylonAS 10:36, 29 October 2020 (UTC)

The Skeleton Horseman problem, and how should we fix it?

Recently, Skeleton Horseman has had its link changed from Skeleton Horse#Skeleton trap to MCD:Skeleton Horseman. Two major problems emerged from doing so:

  1. Many "Skeleton Horseman" links of the Minecraft jockey-like mob suddenly redirected into a Minecraft Dungeons mob. This created problems for the Minecraft topic section of the Skeleton (disambiguation) page.
  2. At least two templates, Template:EntitySprite and Template:EntityLink's id is "skeleton-horseman", not "skeleton-trap".

Is it called a skeleton trap, a skeleton jockey, or a skeleton horseman? This change of redirect of the [[Skeleton Horseman]] page has caused some confusion for me.
Blockofnetherite Talk Contributions 20:33, 8 September 2020 (UTC)

Ok, try do to your best and fix it, i have no other argument, so I am  Supporting. --TreeIsLife (talk) 20:40, 8 September 2020 (UTC)
 Comment Thanks for the support, but I currently don't want to fix it yet, as I still don't exactly know how to fix it, nor do I know how to change those two templates which use the id "skeleton-horseman". @Humiebee very recently undid @Fadyblok240 's edit, but it's not over. Blockofnetherite Talk Contributions 20:44, 8 September 2020 (UTC)
To avoid confusion, I added the {{redirect}} template.---Humiebee Discuss anything with me Look at my edits 20:46, 8 September 2020 (UTC)
It should be redirected back to skeleton trap with a hatnote ({{for}}) added to the top of the section. Vanilla should always take priority.  Nixinova T  C   20:41, 8 September 2020 (UTC)
 Comment What about the templates? Blockofnetherite Talk Contributions 20:47, 8 September 2020 (UTC)
 Done, but with {{redirect}} instead---Humiebee Discuss anything with me Look at my edits 20:43, 8 September 2020 (UTC)

Now that this issue is fixed, there are still questions remaining.

It seems that "skeleton trap" and "skeleton horseman" have been used interchangeably. In the Skeleton Horse page, where skeleton traps/horsemen are described, they call them skeleton traps. However, the {{EntitySprite}} and {{EntityLink}} templates use the id: "skeleton-horseman". So what are they, skeleton traps, skeleton horsemen, or skeleton/skeleton horse jockeys? What should we do, keep them as interchangeable terms, or merge into one?
Blockofnetherite Talk Contributions 16:15, 9 September 2020 (UTC)

 Comment: Skeleton trap: "The mechanic where skeletons riding horse skeletons have a chance to appear when a lightning hit the ground". Skeleton horseman: "The name of the compound entity made of 2 mobs". That's how I always have understood this thing, and I think that clarifying the definitions of the terms will help readers and editors to use them better. Thejoaqui777 (talk) 19:54, 21 March 2021 (UTC)
Skeleton traps are the skeleton horses that stand still and visually get struck by lightning when approached; they spawn 4 skeleton horsemen. Dhranios (talk) (Join the wiki videos project!) 20:03, 21 March 2021 (UTC)

Add shorthand Namespaces for certain things

Now there are shortened namespaces such as MCD:Zombie or MCE:Muddy Pig but others such as Templates don't have one. All namespaces except for main (obviously) should have an abbreviation.
Already Existing

  1. MCW (Minecraft Wiki)
  2. MCT (Minecraft Wiki talk)
  3. MCE (Minecraft Earth)
  4. MCD (Minecraft Dungeons)

Not Sure if exists

  1. Minecraft Dungeons talk or Minecraft Earth talk
  2. My proposals would be MDT and MET respectively

Does not exist, definitely want

  1. TP for Template
  2. TPT for Template talk
  3. MW for MediaWiki - Automaticly redirects to mediawiki.org, so that's impossible to add.
  4. New Proposal for MediaWiki. MDW for MediaWiki.
  5. MWT for MediaWiki talk
  6. CAT for Category
  7. CTT for Category talk
  8. M or MOD for Module
  9. MT or MDT for Module talk

If this gets implemented, want for consistancy

  1. T for talk
  2. U for User
  3. UT for User talk
  4. F for File
  5. FT for File talk
  6. H for Help
  7. HT for Help talk
  8. W for Widget (didn't even know this existed)
  9. WT for Widget talk
  10. S or SP for Special Page
  11. UP for UserProfile

Ones that I really just don't want or need but it would br nice for consistancy

  1. G(T) or GAD(T) for Gadget (talk)
  2. GD(T) for Gadget definition (talk)

---Humiebee Discuss anything with me Look at my edits 20:09, 11 September 2020 (UTC)

Not sure these should all be created, but I can definitely make a template that does this.  Nixinova T  C   20:10, 11 September 2020 (UTC)
I think, their existence wouldn't harm the wiki. FVbico (talk) 20:18, 11 September 2020 (UTC)
How do tou create a template for namespaces?---Humiebee Discuss anything with me Look at my edits 20:21, 11 September 2020 (UTC)
Not for the namespaces themselves, but for linking to them. That wouldn't affect searching, however, but I could also make a script that does this for individuals.  Nixinova T  C   20:29, 11 September 2020 (UTC)
I would love the script as I search for templates a lot and it's annoying when I misspell it as trmplate (r is on the way from t to e so yeah), where would the script go, common.js?---Humiebee Discuss anything with me Look at my edits 20:32, 11 September 2020 (UTC)
Yes, common.js, try adding mw.loader.load('/index.php?title=User:Nixinova/namespace-shortcuts.js&action=raw&ctype=text/javascript'); to yours to test my new script.  Nixinova T  C   20:49, 11 September 2020 (UTC)
Oh, ok, thank you, can you delete the test page I made and it's documentation?---Humiebee Discuss anything with me Look at my edits 20:51, 11 September 2020 (UTC)
Why does it go to like the search then the desired page, nothing of a big deal though, is it a limitation or is it diffucult to change that?---Humiebee Discuss anything with me Look at my edits 21:29, 11 September 2020 (UTC)
Fixed.  Nixinova T  C   21:45, 11 September 2020 (UTC)
I think it broke again.... I searched UT:Nixinova and it didn't work..., thanks for everything!---Humiebee Discuss anything with me Look at my edits 21:55, 11 September 2020 (UTC)
Fixed as well. Take further reports to User talk:Nixinova/namespace-shortcuts.js.  Nixinova T  C   22:07, 11 September 2020 (UTC)
(edit conflict) I think they could be implemented into shortcut redirects, but implementing them as aliases would require modifying the wiki software. Also, I prefer CAT: over C: for categories. Fadyblok240 (talk) 20:34, 11 September 2020 (UTC)
 Changed---Humiebee Discuss anything with me Look at my edits 20:39, 11 September 2020 (UTC)
I don't see the point of most of these, they would add confusion since most other wikis don't have these abbreviations. The only ones that I support are Minecraft Dungeons/Earth talk since these are more of a handful to type out, and are more likely to be linked to (as opposed to the MediaWiki namespaces, for example). –Sonicwave talk 22:14, 11 September 2020 (UTC)
I agree with you, especially about the talk pages of non-article pages except for the Minecraft Wiki: namespace. Even Wikipedia doesn't have alias for most types of talk pages. Fadyblok240 (talk) 22:52, 11 September 2020 (UTC)
 Oppose changing, except MDT and MET. Sry, but shortcuts are SHORT-CUTS. So it is for shorter things, and for things, which won't get confused. This means, it is for project talks or ns with more then 8 characters. And MediaWiki, NO! I don't know, how it will work, but MediaWiki shouldn't be shortcutted in any way! I don't want, that users will easily get to MediaWiki ns. Also, special pages,... No! --TreeIsLife (talk) 17:43, 12 September 2020 (UTC)
Why oppose special pages and templates? You gave no reason for special pages and templates have more than 8 characters and I use them as search terms a lot---Humiebee Discuss anything with me Look at my edits 22:12, 12 September 2020 (UTC)
 Done with {{sl}} and example U:Nixinova/namespace-shortcuts.js of course by Nixinova. The only issue is that it shows in S:WantedPages---Humiebee Discuss anything with me Look at my edits 20:10, 12 September 2020 (UTC)
I'll fix the wanted pages thing, however these still don't go towards making universal namespace shortcuts.  Nixinova T  C   20:12, 12 September 2020 (UTC)
Wait actually you just have to do {{sl}}, does it still come up in S:WantedPages?---Humiebee Discuss anything with me Look at my edits 20:29, 12 September 2020 (UTC)
Well, with {{sl}}, i'm not oppose, i only was scared, if many users, which want to browse wiki content will see MediaWiki:Hydra.css by just MDW or other things, which are not wiki content.--TreeIsLife (talk) 19:51, 13 September 2020 (UTC)
Why would they type media wiki in the first place? You would type the shortcut if you knew the destanation and as for {{sl}}, if they saw the link and pressed it, they would just press the back button (an example of this "back button" sense is TP:Disambiguation.---Humiebee Discuss anything with me Look at my edits 20:47, 13 September 2020 (UTC)
This is already partially implemented with {{sl}}, however, for this to be 100% implemented, U:Nixinova/namespace-shortcuts.js would have to be implemented to MediaWiki:common.js, however, tjis will need a consensus. There still has not been a clear answer but it seems like User:Nixinova is support and User:TreeIsLife is Oppose. Any thoughts or clear opinions?---Humiebee Discuss anything with me Look at my edits 20:52, 13 September 2020 (UTC)
 Oppose for most talk namespaces and site-wide automatic implementation. Even Wikipedia doesn't use shortcuts for most namespaces. We should use shortcuts on a page-by-page basis, meaning we can abbreviate the page name, not just the namespace. Fadyblok240 (talk) 22:45, 13 September 2020 (UTC)
 Comment Putting shortcuts on pages? There are so much more pages then shortcuts, I don't get why your proposing this and your only reason for opposition was

Even Wikipedia doesn't use shortcuts for most namespaces.

do you have any more opposition reasons? I mean the shortcut for searching substitutes it, not like normal Ex:If i'm searching MCT:CP, MCT doesn't turn into Minecraft Wiki talk:whatever page, it keeps it but this commons.js thing does this, T:Golden Apple->Talk:Golden Apple. Again, it's helpful and I don't see anything wrong, it's nice and convenient, also you have to put T: (colon) so it won't affect normal searching---Humiebee Discuss anything with me Look at my edits 00:19, 14 September 2020 (UTC)
 Support as this is a quality of life change that assists editors and viewers. I really don't see any real problems, and no technical issues as of what I know. Blockofnetherite Talk Contributions 00:14, 15 September 2020 (UTC)
I am still  Oppose about this idea. This is bad idea with auto redirect. Yes, even Wikipedia has no "shortcut ns". What you see like WP:R is basicly an article with redirect. Sry, but not everything is good. --TreeIsLife (talk) 18:04, 15 September 2020 (UTC)
 Support per above reasons. TheGreatSpring (talk) 10:32, 18 September 2020 (UTC)
 Oppose most shortcuts. A single letter namespace name is hard to read and can be confusing for new users, all for the gain of you typing 5 less letters. I don't see much point to that. For long namespaces such as Minecraft Wiki or Minecraft Dungeons (and cooresponding talk pages) I agree, but for short ones like Talk or Template, you are gaining a ton of confusion in favor of typing 6 less letters. (is T:Minecraft a talk page, or a template?). Plus, many of these rarely get links, such as widgets, MediaWiki, and Help. Template is also rarely linked directly, the template syntax automatically handles it. KnightMiner (t/c) 17:27, 10 November 2020 (UTC)

New proposal

It looks like the most support is headed towards implement for only MET and MDT and the others are not really nessicary, so would you support just

  1. Only MDT and MET
  2. MD, ME, MDT, MET
  3. Everything on my definitely list (+ MD and ME)
  4. Everything except Gadget, Widget, and their talk and definition variants.
  5. Everything

I feel like MD and ME could also be helpful (so that is why I added it to the list)---Humiebee Discuss anything with me Look at my edits 22:37, 19 September 2020 (UTC)

Option 1 and CAT: for Category:, H: for Help:, and T: for Template: instead of Talk: Fadyblok240 (talk) 23:37, 19 September 2020 (UTC)
Option 1 and that's it! This is not Project NS or talks, so there is no need to do other shortcuts. --TreeIsLife (talk) 11:41, 24 September 2020 (UTC)
Certainly Option 1 at least. I dislike the idea of CAT shortening (suggested by Fadyblok) because no category uses short names like Minecraft Wiki pages or even some templates do. Help shortening does seem to be helpful, the same may apply for templates, and if both these get shortcuts, then their talk pages should probably have them as well (HT and TT). But implementing shortcuts for all namespaces just for the sake of it is certainly not worth the effort.
As I said before, I don't support most namespace aliases (including CAT:); I only support them as pseudo-namespace redirects for some pages. Also, I would rather have W: point to Wikipedia pages than to Widget pages. Fadyblok240 (talk) 01:12, 22 November 2020 (UTC)
On a side note, why exactly MDT and MET? The respective article namespaces are abbreviated MCD and MCE. Unless such shortenings are limited to three letters for some reason, I’d suggest using MCDT and MCET respectively for the sake of consistency (though, we already have MCT for Minecraft Wiki talk...). — BabylonAS *Happy Camper* 06:27, 25 September 2020 (UTC)
For consistancy that is (all namespaces has 3 letter) and yes, it would be consistant with MCT (it's not MCWT))---Humiebee Discuss anything with me Look at my edits 14:11, 26 September 2020 (UTC)
Option 1 TheGreatSpring (talk) 06:58, 25 September 2020 (UTC)
Still staying with  Everything per my above reason. Just don't see anything wrong with this addition, saving characters is useful. Blockofnetherite Talk Contributions 19:31, 1 October 2020 (UTC)
Keep in mind that some of the proposed namespace shortcuts conflict with potential interlanguage links, such as ga: for Gadget and Irish (which doesn't make any sense since pages in the Gadget namespace, if any, cannot be accessed directly from the search bar) and tl: for Talk and Tagalog (which somewhat offends me since I am an ethnic Filipino). Another reason to  Oppose. Fadyblok240 (talk) 23:43, 23 October 2020 (UTC)
Okay, I don't think we need Gadget, Widget, or MediaWiki, because we shouldn't make it easier to see MediaWiki pages, as they contain information (like blocked words/website links on the inappropriate filter). Gadget and Widget are not so necessary. Talk is proposed to be short for T and not Tl. Still  Supporting MDT, MET, TP, TPT, CAT, CTT, MOD, MDT, T, U, UT, F, FT, H, HT, S and SP, and UP. Blockofnetherite Talk Contributions 18:10, 6 November 2020 (UTC)
See WP:Perennial_proposals#Create shortcut namespace aliases for various namespaces for why this was rejected in Wikipedia and probably the Minecraft Wiki. Fadyblok240 (talk) 04:05, 10 November 2020 (UTC)
I  Oppose the addition of a "T:" namespace, as "T" could stand for either "talk" or "template", and because of this, such a namespace would be more confusing than helpful. I  Oppose the "M:" namespace for the same reason, as "M" could stand for either "module" or "MediaWiki". I also  Oppose the "GA:" namespace as it would conflict with interwiki links. I  Support "MDT:" and "MET:", as the main Dungeons and Earth namespaces already have shortcuts, so the addition of shortcuts to their talk namespaces would create consistency. I'm  Neutral about the rest, as whilst I can't see much harm in adding them, I'm unsure whether they would be particularly helpful, either. GrogTheGreatEvilGoblinWarlord (talk) 06:00, 11 November 2020 (UTC)

Add sort keys for version exclusive articles (including articles about versions themselves)

I think it would benefit to add sort keys to remove prefixes from version exclusive articles. (e.g. the sort key for Java Edition level format would be Level format) It would provide a better ordering of lists of pages in version exclusive categories. Fadyblok240 (talk) 21:10, 12 September 2020 (UTC)

Go ahead, this should be an uncontroversial change.  Nixinova T  C   22:10, 12 September 2020 (UTC)
It may take a long time to add all the sort keys for the version articles. Maybe consider modifying or creating templates (see Template:Version nav/sandbox) to automatically create the sort key? Meanwhile, I will add sort keys for articles that are not about versions. Fadyblok240 (talk) 22:21, 12 September 2020 (UTC)

Change the main discussion from MCT:CP to MCW:Centralized discussion

This is a very big change proposal but I have some reasons to back it up.

  1. This page should be used for discussing the Community Portal itself
  2. The ftb wiki does this as well
  3. It could be linked on the sidebar (as centralized discussion)
  4. How did this name start anyways?
  5. There is not any page to describe this main community discussion, now that it is in MCW namespace instead of MCT namespace, it could have a proper talk page.
  6. This would be an enourmus change and could break a lot of links.
    1. However, I will try to fix the links
  7. However, it fits more nicely

---Humiebee Discuss anything with me Look at my edits 22:14, 28 September 2020 (UTC)

The community portal page itself needs almost no discussion as most of it is requesting pages or linking other discussions, I don't see a need for a dedicated talk page. This page is the portal to community, including community discussion, so the name seems clear enough to me. Plus, centralized discussion can lead to confusion, such as that the page is the only place we discuss wiki topics. Additionally, as you said, this is a huge change which will break basically any reference to the portal; none of the benefits you listed outweigh breaking all links from former discussions. KnightMiner · (t) 16:08, 29 September 2020 (UTC)
Looking at the What links here tool, 214 pages link here, and since at least like 50 of them are like redirects and duplicates (yes if it shows a redirect, it shows it indented below the redirect AND as normal) so it shouldn't be such a hard task. Since this page would not be used as much, it's redirects could just change without worry of the actual page, and like you said, if there is no discussion, it could temporaraly become a redirect while the links try to be fixed.---Humiebee Discuss anything with me Look at my edits 22:24, 30 September 2020 (UTC)
In my opinion, the community portal can very well be discussed about on the community portal, "wiki name"/Community portal is default and thus very widely used in other Gamepedia wikis, ftb is completely unrelated to this wiki, apart for the remaining mod pages, and, as you said yourself, this would be a enormous disruptive change.  Oppose. Sagessylu (discuss | edits) 17:19, 1 October 2020 (UTC)
 Massive Oppose - Seriously? Ok, Wikipedia works this way, but this is ultra massive change, which won't end up being useful. You could name this section - Proposal, which will never get any support. Idk, why, but your ideas are sometimes really outside of reality. This will be so much work, that idk, how will be doing this. A bot? Admins? You? No, this is outside reality change this page, as ut is so active, that it will be bad. Also, even we will end up doing this, it won't be MCW:Centralized discussion, but some MCW:Village pump (just like Wikipedia has it) --TreeIsLife (talk) 12:03, 3 October 2020 (UTC)
 Oppose. I don't really see the point in fixing something that isn't really broken. ~ Amatulic (talk) 17:28, 3 October 2020 (UTC)
 Weak support Well, I guess I'm the only one who supports this at all. Fadyblok240 (talk) 15:26, 20 October 2020 (UTC)
 Massively oppose, there's absolutely nothing to gain from this change, and it would break so much. Every wiki does things slightly differently, consistency with other wikis really isn't a reason to do something. Not only pages on the wiki link to the community portal, links outside of the wiki (such as on discord) will all break too, and you cannot fix those. Do consider all of these in your proposals, because, as stated by others, this idea is way outside of the scope of reality. Nothing to gain, everytging to break. Dhranios (talk) 16:06, 20 October 2020 (UTC)

UCP considerations

suppressredirect permission, UCP, and autopatrolled users

On UCP, regular users won't have the permission to move pages without leaving a redirect. This permission will become admin-only. Since there are valid use cases for non-admins using this permission, but concerns with all users having it, I propose to grant autopatrolled users and patrollers this right. Non-English Minecraft Wikis may have other custom groups that they feel should not lose this right and aren't going to cause much damage with it; if so, I encourage the users of these wikis to list these groups here. See also the Wikipedia group that inspired this proposal. --AttemptToCallNil (report bug, view backtrace) 12:40, 2 October 2020 (UTC)

Is moving without redirect vandalism (or in general bad edits) really common though? because if not, I see no reason to take that permission from anyone who may not have autopatroller rights. Dhranios (talk) 13:10, 2 October 2020 (UTC)
I couldn't get a conclusive answer on whether a configuration with suppressredirect for all registered users will be approved (there's no guarantee it will be, and from what I've heard, staff don't know either). I can't give a conclusive answer on whether such vandalism is common either, but I'd say we should expect disruptive users with accounts to be more common than before given that now having an account is much easier (no more Twitch requirement). --AttemptToCallNil (report bug, view backtrace) 13:26, 2 October 2020 (UTC)
If the privilege gets taken away from regular users, I'd definitely support allowing autopatrol and patrollers to retain it, for the reasons you described. I might actually support it otherwise as well, as currently any user who logs in essentially has the ability to delete a page (because that's literately what moving without a redirect does). If someone has the autopatrol or patroller right, they're presumably trusted enough to make constructive edits/moves, so imo they can be trusted to move without leaving a redirect.--Madminecrafter12 (Talk to me | View what I've done) 13:17, 2 October 2020 (UTC)
 Done I added the suppressredirect permission to the following groups:
--  HorseFace.png Gamepedia icon.png MarkusRost (talk) 22:50, 2 October 2020 (UTC)

Comparison of Lua-based templates and non-Lua counterparts

According to Template:SimpleNavbox/doc, Lua-based templates seem to be slower than their non-Lua counterparts, contrary to the situation on Wikipedia. This might change when the Minecraft Wiki is transferred to the UCP. I want someone to prove or disprove the statement that Lua runs slower than parser functions, before and after migration to the UCP. Fadyblok240 (talk) 02:26, 3 October 2020 (UTC)

That template is not a useful general judgement for Lua vs. wikitext. In fact, in many cases Lua-based templates are going to be faster. In addition, with UCP we are expected to eventually get LuaSandbox, an extension that makes Lua even faster. --AttemptToCallNil (report bug, view backtrace) 04:33, 3 October 2020 (UTC)

List of broken items

  • Protection icons
  • Some text that was centered is now left-aligned

Fadyblok240 (talk) 20:00, 5 October 2020 (UTC)

Revert war

Today, there was Minecon. That means many edits from IPs and vandals. But today, there is problem with diffrent thing - Planned Fixes and Planned changes.

There are 2 camps now for these 2 topics. First is that, which wants to have Planned fixes on page and Planned additions on Update page.

Second (in which i am) wants to have Planned additions on page and don't have Planned fixes on page.

So to solve this problem, we can vote, because Camp 1 is now (if i am correct) violating style guide. So we could change it and don't be scared, that we will have edit wars after Update annouced.

Here are options for Planned Additions

  1. Have Planned Additions on Caves & Cliffs page
  2. Have Planned Additions on Java Edition 1.17

Options for Planned Fixes

  1. Have it on update page
  2. Have it seperate page
  3. Don't have it

--TreeIsLife (talk) 19:16, 3 October 2020 (UTC)

With Planned additions, i  Support Option 2, and with Planned Fixes also  Supporting Option 2. --TreeIsLife (talk) 19:16, 3 October 2020 (UTC)
Planned additions go on the Caves & Cliffs page for now, and is transcluded on JE & BE 1.17, but fixes are edition-specific and should go on their respective pages.  Nixinova T  C   19:45, 3 October 2020 (UTC)
@Nixinova: Maximally, we could make subpage for entire update content, like Legacy Console Edition has. –Preceding unsigned comment was added by TreeIsLife (talkcontribs) at 19:51, 3 October 2020 (UTC). Please sign your posts with ~~~~
Well, LCE versions are pretty much exactly the same, running on the same codebase etc. Java/Bedrock are very much not that.  Nixinova T  C   03:41, 5 October 2020 (UTC)

Smash content

Hi hi. I'm not a regular editor of the Minecraft Wiki, but rather a visitor from SmashWiki, which—as you can imagine—has been busy with the reveal of Steve and company in SSBU. I was curious as to how you all are going to handle the Minecraft content in Smash. We're already linking to you on a few pages, and I've proposed making a formal partnership between wikis to higher-ups on SmashWiki, but it's still in discussion right now. I suppose right now I just want to ask and gauge interest, since there doesn't seem to be much about Smash on this wiki right now. Is Smash content something you would like to further elaborate on for the wiki, and if so, would partnership (being able to reference and cross-link us where necessary) be of any interest? DryKirby64 (talk) 00:50, 5 October 2020 (UTC)

There's some discussing over at Talk:Super Smash Bros., and personally I think we should indeed document it here. Not sure where exactly, though.  Nixinova T  C   00:53, 5 October 2020 (UTC)

Minecon Live!!

Mega-massive-ultra news for MCD!!!!

Okay that was too dramatic

1. A very important announcement was made for Minecraft: Dungeons at Minecon Live. First of all, we need renders for all of the new mobs in Howling Peaks. Second of all, we need names for the new DLC skins, we need to find out more about the new Armor, Weapons, and the Artifact.

2. They announced a Nether DLC in a Basalt Deltas Biome, Crimson Forest Biome, and more. Piglins, Blazes, and Wither Skeletons were all seen. Is there any more info?

3. They also announced an Ocean DLC. It contains tons of new mobs, but what about the special rolling mechanics? What about the other underwater features? How can the player breathe underwater? Will the Glow Squid be there?

4. End DLC. In the video, for an extremely short nano-time, I saw Archie, back in his Arch-Illager form, and still with the Orb once again, summoning mobs. Did the Ender Dragon secretly have power over the orb this whole time or something? Why is Archie evil again?

5. Obsidian Monstrosity. End or Nether DLC? If it's even going to be a mob....

So that's about it. Please answer my questions one at a time if you have answers, because my eyesight is poor. Howling Peaks (talk) 12:19, 5 October 2020 (UTC)

This notice would be better suited for the Dungeons wiki. Also, we probably don't need these renders until the DLC is actually released. -PancakeIdentity (talk) 23:58, 5 October 2020 (UTC)
Yea but i still cant wait. Also i would love it if they actually put the Obsidian Monstrosity as a boss, that would be dope. James Haydon (talk) 01:07, 6 October 2020 (UTC)

Standardizing NBT documentation tag order

Currently, NBT documentation is added in a rather arbitrary order in the tree, I'd suggest standardizing the order as much as possible.

My suggestions, either:

  1. Sort alphabetically, ignoring NBT type
  2. Sort by NBT type and then alphabetically

Opinions? Dhranios (talk) 10:13, 6 October 2020 (UTC)

 Support for suggestion #1. Seems cleaner to sort alphabetically as sometimes tags may be related in name and what they are used for in-game while having different NBT types. Suggestion #2 seems impractical. -- SizableShrimp🦐 (talk · contribs) 16:43, 7 October 2020 (UTC)
 Support for suggestion #1, SizableShrimp pretty much explained everything. Sagessylu (discuss | edits) 19:09, 15 October 2020 (UTC)
#1 makes the most sense.  Nixinova T  C   22:08, 15 October 2020 (UTC)

Minecraft dungeons on Xbox series x

Yesterday I went to JB Hi-Fi to get minecraft dungeons on Xbox one and on the cover of the disc holder is said compatibility for Xbox One|Xbox Series X. Can someone put the series X logo on the wiki so it can go on the dungeons page and main page. --Minecraft loot (talk) 22:04, 6 October 2020 (UTC)

Sounds Page

Should a sounds page be added, i realize all sounds are being added to pages they are caused from, but should a page with all the sounds from all versions of the game be made, as to have them all in one place, as well as on each page?-Robonate135 (T C) 17:25, 8 October 2020 (UTC)

In my opinion, no. The sound section is only marginally useful, it's just more data to expand the page. It's sufficient for each space (vanilla, Earth, Dungeons) to have their own sound files for things that may be common to all versions. Amatulic (talk) 06:09, 17 October 2020 (UTC)
I don't think this would be super useful and I'd worry about performance and load times with that many files on a single page. I'm not completely opposed to it if anyone has a good reason for it. -PancakeIdentity (talk) 18:16, 22 October 2020 (UTC)
Agreed, sound files take up a lot of space on pages and there is many of them on the wiki for mobs and blocks. I think having these on one page might be useful but it could be hundreds of thousands of bytes in size and could cause severe performance issues or could not load entirely. It would be useful somewhat but it would be too large and too laggy so we shouldn't. James Haydon (talk) 18:22, 22 October 2020 (UTC)
 Neutral, mainly what NineTreyBlud said but instead of creating 1 single page, we could split it into a few pages. 1 for subtitles, and 1 for other sounds.---Humiebee Discuss anything with me Look at my edits 20:11, 22 October 2020 (UTC)
It could be made the same way Block states is done, put the sounds to a subpage (e.g Block of Quartz/Sounds) and all the sound subpages would be transcluded to a page like Sounds. – Unavailablehoax (talk) 20:22, 22 October 2020 (UTC)
Ill agree on that one though, just make sure they are in separate tables. James Haydon (talk) 20:31, 22 October 2020 (UTC)

add certain rights to certain user groups

Can you add the autopatrol right to Directors and Patrollers?---Humiebee Discuss anything with me Look at my edits 17:29, 12 October 2020 (UTC)

Shouldn't they already have it by default? James Haydon (talk) 19:15, 11 November 2020 (UTC)
They don't for some odd reason, just go to Special:UserGroupRightsHumiebeetalk contribs 03:06, 25 November 2020 (UTC)

What happened to advanced search?

Advanced search has become useless. It used to show me search results up to 500 per page. Now it's this short paginated thing that doesn't even include all results, and the pagination links don't even work.

For example, try an advanced search for all articles containing the word "epic". Scroll down and go to page 2. You can't. It goes to the rarity article.

Try a search main space for the word "now". 90 results? Just about every article on the game has history sections that include the word "now". That's hundreds of articles, not 90.

Is there a user setting somewhere that gives me back the original search? The only "improvement" here is the ability to search other wikis, which isn't relevant to me. Amatulic (talk) 02:50, 13 October 2020 (UTC)

I think it has to do with the fact that UCP search doesn't use CirrusSearch, which legacy Gamepedia and Wikimedia had been using. The most advanced thing you can do is filter by namespace, which means we miss out on truly advanced search parameters like insource: and regular expressions. Also, the new search only considers articles by default. Fadyblok240 (talk) 02:55, 13 October 2020 (UTC)
And as I mentioned, it's broken. All search results are not shown, and pagination doesn't work.
Bring back the original Wikimedia search! Amatulic (talk) 22:36, 14 October 2020 (UTC)
I don't think they're switching away from the current search (apparently they believe the original search isn't scalable or performant). Some issues with the search are known and are likely to eventually end up fixed. --AttemptToCallNil (talk) 23:04, 14 October 2020 (UTC)
I don't understand how the Wikimedia search, used on the busiest website on the planet, is considered non-scalable and non-performant. This new mess is not an improvement. Amatulic (talk) 05:44, 15 October 2020 (UTC)
I'm not sure either, nor did I read any extensive explanation for why this change happened. It's possible that Fandom running some hundreds of thousands of wikis and having different hardware constraints are important factors, but I, of course, can't have any data on that either. --AttemptToCallNil (talk) 09:31, 15 October 2020 (UTC)
I agree, you can't even create pages using search function, it's horrible.---Humiebee Discuss anything with me Look at my edits 20:36, 15 October 2020 (UTC)
Yes how do you create pages now? It probably harder. James Haydon (talk) 21:15, 15 October 2020 (UTC)
You have to CREATE A REDLINK????? on a page such as MCW:Sandbox. This is torture.---Humiebee Discuss anything with me Look at my edits 21:20, 15 October 2020 (UTC)
Its easy to create a redlink if you use visual editor, i just go on a small page, add a link that doesnt exist yet, open it in a new tab, and discard my edit and create the page. It may also work with source editor but you have to use the page preview button. James Haydon (talk) 21:22, 15 October 2020 (UTC)
minecraft.gamepedia.com/<page name> – Unavailablehoax (talk) 21:24, 15 October 2020 (UTC)
Yes is suppose but that is the way i am used to creating them. James Haydon (talk) 21:26, 15 October 2020 (UTC)
I never use visual editor as it is ick, Unavailablehoax's idea is fine and easy though.---Humiebee Discuss anything with me Look at my edits 02:26, 16 October 2020 (UTC)
Another thing is that it doesn't suggest the redirect when typing in the search bar, but instead the target page of the redirect.
For example, typing 'Warden' doesn't suggest the redirect Warden, but instead Caves & Cliffs. This means a user trying to find information about the Warden would have to scroll to the Caves & Cliffs § Warden section, while the Warden redirect would have gone to that section automatically. – Unavailablehoax (talk) 21:47, 15 October 2020 (UTC)
 Comment Yes that is really not a good thing, it makes redirects useless unless it goes to an actual page instead of a section. James Haydon (talk) 21:50, 15 October 2020 (UTC)
A fix at least for the no new page link is expected to come. Other fixes are definitely considered. If you have specific feedback, please send it to Zendesk (like that redirect thing) so that staff take a look. But chances are, a lot of the issues you raise here are already known. (It's useful to tell us anyway even if they just answer, "This is known". Part of the reason I wrote that list on the Help Wiki is to present the community with a centralized, if unofficial, source of issue information in the absence of a public issue system.) --AttemptToCallNil (talk) 23:33, 15 October 2020 (UTC)
The redirect problem has been fixed, still waiting for the page creation issue, typing Caves and Cliffs worked.---Humiebee Discuss anything with me Look at my edits 22:54, 16 October 2020 (UTC)
The pagination bug I mentioned at the top of this thread is fixed too. Advanced search for "epic" and the page links at the bottom no longer take you to the rarity article. However, erroneous search results appear, like pickaxe and sea pickle, neither of which includes the word "epic" anywhere in the article. Amatulic (talk) 06:06, 17 October 2020 (UTC)
The redirect bug and the create new page bug has been fixed, however there are still many other bugs such as what Amatulic said, incorrect search results as well as a lack of results. Wikimedia search is not going to come back in a LONG time (most likely never)---Humiebee Discuss anything with me Look at my edits 01:15, 21 October 2020 (UTC)
Did they also stop advertising unrelated wikis in the corner, because that is annoying too. James Haydon (talk) 01:17, 21 October 2020 (UTC)
They did, it's still comepletly broken as when i search welcomee, it does not even show results for welcome, it just shows some random story mode episode page like ???????---Humiebee Discuss anything with me Look at my edits 01:22, 21 October 2020 (UTC)
I think it looks for those words in other pages and then recommends them above the actual pages. James Haydon (talk) 01:24, 21 October 2020 (UTC)
 Update, there is another bug with search. When you search a page that does not exist, it shows as a blue link but when you click on it, it says Creating Page <page name>.Humiebee (talk) 17:19, 16 February 2021 (UTC)

Spooky Fall

Make pages with content from the MCD:Spooky Fall MCD:Seasonal Trials. Minecraft Dungeons Howling Peaks (talk) 15:58, 16 October 2020 (UTC)

Okay i already have an image related to that on my computer. James Haydon (talk) 15:59, 16 October 2020 (UTC)
Like Pages for MCD:Hungry Horror and MCD:Haunted Bow. Minecraft Dungeons Howling Peaks (talk) 18:49, 16 October 2020 (UTC)
Yes, if those are the names i will create them. James Haydon (talk) 18:51, 16 October 2020 (UTC)
They are now created, give me any more items/mobs that will appear in these seasonal trials. James Haydon (talk) 18:55, 16 October 2020 (UTC)
Go to twitter.com/dungeonsgame and check daily for any new Spooky Fall-related Dungeons items or mobs, I need to catch up on online schoolwork so I won't be available to do so. I'm getting backlogged. Minecraft Dungeons Howling Peaks (talk) 14:26, 17 October 2020 (UTC)

Never received confirmation email

I keep getting a message at the top of most pages that my email address has not been confirmed. I've clicked the link to send me another email many times, but still have never received an email of any kind.

Can someone verify that the email sending process actually works?

(Yes, I checked my junk filters and other tabs of mail.)

Jim SirDaddicus (talk) 21:32, 17 October 2020 (UTC)

Same for me, but I signed up using twitch, so I somehow eventually got it in my twitch email, not my gamepedia account email. Blockofnetherite Talk Contributions 02:59, 18 October 2020 (UTC)
When i did it i had to wait many hours for it to come in, i even thought something was wrong with my email and i changed it. The UCP migration has kind of ruined gamepedia in some ways. James Haydon (talk) 18:51, 18 October 2020 (UTC)

Remove section on Mob page

There's a low-quality section "mobs to be added" on the Mob page, which also violated a comment on the page that explains to not add any mobs until they appear in a development version. I was simply going to delete this section, but was disallowed.

SweptThrone (talk) 01:01, 23 October 2020 (UTC)

I fixed some of the grammar and capitalization, but i am still disputing if it should be there. James Haydon (talk) 02:47, 23 October 2020 (UTC)
I commented out the section as a violation of MCW:FUTURE.  Nixinova T  C   04:37, 23 October 2020 (UTC)
Okay, i wasnt keen on keeping it, as it has been removed before for the same reason. James Haydon (talk) 12:43, 23 October 2020 (UTC)

bedrock or java?

i feel that the java and bedrock info is a bit outdated and me, a bedrock editon player have items, mobs, and blocks that you mark "java only" i think you shoud work on that-- 18:34, 5 November 2020 (UTC)

Which pages do you mean? – Unavailablehoax (talk) 18:57, 5 November 2020 (UTC)

Moving Minecraft Story Mode Wiki to this wiki

The following discussion of a proposed merger with Minecraft Story Mode Wiki is closed. Please do not modify it. Subsequent comments should be made in a new section.
Pausing merger, because MCSM Wiki editors are oppose for now. Till admins won't discuss with editors and readers, it has no sense to keep it open --TreeIsLife (talk) 13:44, 27 November 2020 (UTC)

Hi guys. I have an idea, which we partially discussed on Minecraft Wiki Crossover Discord. So, idea is creating Namespace for Minecraft Story Mode and moving there content from https://minecraftstorymode.fandom.com. Yes, it is an active wiki, with many content, which may help this wiki.

This is in a plan of entire crossosover of wikis.

We discussed, that there should be 3 big wikis - Minecraft Wiki (with all non-community content releated to MC), FTB Wiki (for mods) and Minecraft Community Wiki (Creepypastas, Servers, buildings, etc.)

So, what do you think about migrating Story Mode Wiki? --TreeIsLife (talk) 14:23, 11 November 2020 (UTC)

Having it be kept under a namespace is basically the only thing I'm bothered about. Otherwise, go ahead. - User-12316399 (talk) 14:25, 11 November 2020 (UTC)
Well, unfortunatly, it is not so easy as you think. So, there is need for both sides to agree. And as the Wiki has users, who are still contributing, i cannot just force users. I know that, because i already merged 1 community and it took 1 month, to just start it. And it compleated 1.5 months later, with wiki being locked.
And wiki is somewhat active. --TreeIsLife (talk) 15:52, 11 November 2020 (UTC)
So, when comparing to this number of content + users, it may take 2 or 3 months. But, if not using Discord, maybe just few weeks.--TreeIsLife (talk) 14:36, 11 November 2020 (UTC)
 Weak oppose, mainly for the reason that story mode is discontinued and it would take a lot of work, and I also  Strong oppose adding a separate namespace. Also, the pages themselves will probably gain no traction for readers and editors anyways.Humiebee (talk) 15:45, 11 November 2020 (UTC)
It is just merging for better SEO results, because all Gamepedia wikis will migrate to fandom.com domain early 2021. And this is reason, why i am making a subpage with project crossover. --TreeIsLife (talk) 15:50, 11 November 2020 (UTC)
Changed to  Weak support and  Neutral per below.Humiebeetalk contribs 21:28, 13 November 2020 (UTC)
 Comment There is already a project about adding minecraft story mode content i believe, but i dont think there is enough to constitute for its own namespace and sub wiki. I think it should have it content put on the main wiki marked with minecraft story mode in the title. James Haydon (talk) 19:03, 11 November 2020 (UTC)
(I think we are getting from the main path - theme). So, i am talking about Wiki, not sub-wiki, which is on Fandom! There are over 300 pages, which makes it big enough to have its own namespace. Next time, use pls term Main page, as main wiki is Minecraft Wiki, as a name, and you probably meant main page. Yes, now, we have like 3 articles, but with this, we can boost wiki with many content. --TreeIsLife (talk) 19:11, 11 November 2020 (UTC)
Okay so if we are going to make a namespace it should be MSM, the acronym for Minecraft Story Mode. James Haydon (talk) 19:13, 11 November 2020 (UTC)
No, we don't use shortcuts as namespaces, only aliases. It would be "Minecraft Story Mode" or "Story Mode" with alias MCSM or SM respectively, to match dungeons and earth (MCD MCE, not MD ME). Dhranios (talk) 19:35, 11 November 2020 (UTC)
I personally  Support, the reason being that it's a Minecraft game and should be on the Minecraft wiki. I don't know how many other people would want to contribute. Maybe if we contacted the people in the Fandom Wiki they would be up to helping. There is currently a request move on my user page for a Story Mode exclusive features for an official page. If nothing else, we could at least have that. https://minecraft.gamepedia.com/User:Yekulten/Story_mode_exclusive_features Yekulten (talk) 12:35, 12 November 2020 (UTC)
 Support moving Story Mode content to this wiki. This would improve the main Minecraft wiki by making it more comprehensive, and could even bring in new readers and editors. The move would also improve consistency, as all other official Minecraft games are already documented in this wiki. GrogTheGreatEvilGoblinWarlord (talk) 14:07, 12 November 2020 (UTC)
 Strong supportThomanski | t | c | 08:11, 13 November 2020 (UTC)
 Strong support. More editors, more pages, more relevance on Google and everything on its own namespace, which means nothing will change in vanilla documenting. --Dr03ramos (talk) 12:17, 13 November 2020 (UTC)
 Strong support The Great Spring (talk) 12:18, 13 November 2020 (UTC)
 Strong support DEJVOSS (talk) 12:45, 13 November 2020 (UTC)
 Supporting for above reasons Blockofnetherite Talk Contributions 16:59, 13 November 2020 (UTC)
 Strong support okay lets make it happen. James Haydon (talk) 18:18, 13 November 2020 (UTC)
 Strong support Just because story mode is discontinued doesn't mean we shoud treat it differently from Minecraft Earth and Dungeons. it should be given pages for the episodes and mobs, its own mainspace, and more contributors on the story mode wiki project --Minecraft loot (talk) 03:13, 15 November 2020 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.


So, i see great support, and first admin respond, and he has no concerns 🙂, except User groups changes. So, our questions are:

User groups

On MCW Crossover, it has been already discussed, and there was result of re-vote. That will mean, we will start vote about them.


We can use any bot


Well, best will be as soon, as possible


All it should in Minecraft Story Mode namespace. Its alias should be MCSM?

What do you think? And if there is something to add, add it!

--TreeIsLife (talk) 14:35, 16 November 2020 (UTC)

So basically, what are we doing? Is there a project page? If so, we should have one. Then what do we do? Basically copy paste the content from the fandom? I agree with the namespaces Minecraft Story Mode: and Minecraft Story Mode Talk: , but I am currently undecided on its alias. I personally believe MCSM and MCST are good, although they are 4 characters, but that shouldn't be a major problem at all. Can someone answer these questions, now that this proposal got massive amount of support? Blockofnetherite Talk Contributions 18:02, 17 November 2020 (UTC)
We will not copy paste, that'd lose edit history and alike, instead the pages will need to be exported. Also, IIRC, there's already a project for documenting story mode. Dhranios (talk) 20:23, 17 November 2020 (UTC)
About the user right thing. You said that we'll vote, so let's do it here then. I'd say to create a custom user right that gives content-moderator (read more here) but limited to the MCSM namespace. However, i'm not sure if we should do that. --Dr03ramos (talk) 10:54, 18 November 2020 (UTC)
We said we won't do user groups limited to one namespace, because it will be techically difficult. --TreeIsLife (talk) 12:37, 18 November 2020 (UTC)

Herobrine page

Hi guys. After suggestion from discussion on Discord about crossover, we ran to problem with a page Herobrine. As Herobrine is community made, but really noticed by Mojang Staff, it makes us thinking, if we should keep this page or not?

What do you think? Do you support deletion, or not? --TreeIsLife (talk) 19:38, 13 November 2020 (UTC)

 Support we already moved most of the mod related pages on this wiki to FTB, so making a wiki for fancontent and community content is a good ides. But it should be for more than just moving already existing pages. James Haydon (talk) 19:42, 13 November 2020 (UTC)
 Neutral, I do not have an opinion on this yet, however, could you supply a link to the discord message on the mcw server? Blockofnetherite Talk Contributions 18:04, 17 November 2020 (UTC)
Strikethroughed because I am no longer neutral and I have also seen the original discord converstationBlockofnetherite Talk Contributions 16:09, 19 November 2020 (UTC)
Switched to  Oppose, at least for now or any time soon, as a Herobrine page is actually useful as Mojang references it, and even references it in the code (no, I am not talking about implementing it), like "4J studios may have removed Herobrine" or things like that. Also opposing for below discussion. Blockofnetherite Talk Contributions 23:39, 18 November 2020 (UTC)
 Oppose for now. If we're making that three main wikis thing I've proposed on MC crossover Discord, we should first have the fan content wiki estabilished and only then move the Herobrine page. --Dr03ramos (talk) 10:57, 18 November 2020 (UTC)
Finally, you remember, that you proposed 3 wikis! --TreeIsLife (talk) 13:34, 18 November 2020 (UTC)
 Oppose deletion. Herobrine is a notable part of Minecraft's history and regularily mentioned in changelogs by Mojang. It shouldn't be removed from the wiki just because it's community-made. Violine1101 (talk) 16:31, 18 November 2020 (UTC)
 Oppose deleting the Herobrine page. The Great Spring (talk) 23:41, 18 November 2020 (UTC)
Seems like a lot of people are against this now. James Haydon (talk) 02:26, 19 November 2020 (UTC)
Yes, but it was not my idea. --TreeIsLife (talk) 06:56, 19 November 2020 (UTC)
Okay based on everyone's reaction i think we might have to re-discuss this over. James Haydon (talk) 05:13, 21 November 2020 (UTC)

Create List of entity textures?

List of block textures already exist, need to create List of entity textures.-- Xiaoyinface.png Duowan channelT&C) 23:29, 13 November 2020 (UTC)

An observation: "Random Page" is quite unlikely to get anything useful

Out of 10 tries, I observed exactly one that was about gameplay (Netherite Scrap), one about about a rule (Minecraft Dungeons:rarity), and one about a data file (level.dat) The remainder consisted of two short summaries of not-very-notable employees and FIVE short summaries of specific platform edition numbers. This suggests that there's a lot of room to clean up or combine near-useless pages so the average random page is likely to teach something interesting or spark an interesting session of following links; the cleanup of, especially, the specific platform versions ought to be accessible to a simple script to combine them all, depending on what tech underlies the wiki. --Realweregamer (talk) 03:57, 14 November 2020 (UTC)

I suggested it to be Special:Random, not SP:RandomRootPage, though it has mostly the same issues, probably ending in a /DV or some other technical page, possibly remove it?Humiebeetalk contribs 23:30, 16 November 2020 (UTC)
Yes, Special:Random does give version articles a lot, but that's not a bad thing, because there are a lot of version numbers. They shouldn't be combined because each version article can contain a lot of content. Special:Random isn't meant to be "useful", and there are index pages for them like Version history.  Nixinova T  C   23:45, 16 November 2020 (UTC)
The link uses Special:RandomRootPage which excludes subpages. Some of these subpages are considered to be articles e.g. Java Edition version history/Development versions but others are like templates (e.g.Dirt/BS) We should move all article subpages to root pages or move all non-article subpages into template namespace and reconfigure the link so that it could link to subpages. This won't fix the problem entirely, but it could help. Also, why is it called "Random page" instead of "Random article"? Fadyblok240 (talk) 00:56, 21 November 2020 (UTC)

Make some templates more reader-friendly

Some templates such as {{more images}} and {{infobox}} without an an image parameter cause unnecessary clutter for readers. Since only registered users can upload files, readers cannot address the problems presented by these templates. To provide a cleaner look for some articles, I propose moving templates like {{more images}} to talk pages or hiding them from readers by using a CSS class. For infoboxes, removing the placeholder image at least for readers would reduce whitespace. Also, the {{delete}} template has a "delete" link that only administrators can use, so I am considering hiding it from non-admins, which also requires a CSS class. Fadyblok240 (talk) 00:26, 22 November 2020 (UTC)

Hiding content with CSS is generally not a good idea and preferably avoided. For one, Google finds it anyway, and this might incur SEO penalties. While most readers never become editors, and it's unlikely such templates get a lot of readers make their first uploads, I feel it's not the best idea in terms of "wiki way" to hide content from unregistered users. In addition, I'm not sure there are easy CSS classes to do things based on group preferences, so that might need to be spread across multiple CSS files (MediaWiki:Group-sysop.css). (Note also delete links are useful for SOAP and maybe even WMs/staff, who also might need to act on deletion templates, but aren't necessarily local admins. This means the link would need to be hidden based on user rights, not group membership, which I'm not sure can be done easily.)
In other terms,  Oppose the presented solution, doesn't seem like a substantial problem, but incurs other problems and seems to require a rather complicated solution.
As an additional idea, maybe move editor-facing message boxes like {{more images}} to the bottom of pages? --AttemptToCallNil (talk) 01:25, 22 November 2020 (UTC)
 Oppose moving notice templates to the bottom of pages becuase then editors would not even see the notice template at all. If possible, notcie templates can be hidden from ip's as readers would probably not register an account without editing. What is the "wiki way" anyways? As for the orginal proposal, I am  Weak oppose per AttemptToCallNilHumiebeetalk contribs 02:36, 25 November 2020 (UTC)
By "wiki way" here I meant the idea that editing should be open to unregistered users, and they should be treated as potential editors instead of just readers. --AttemptToCallNil (talk) 02:57, 25 November 2020 (UTC)
True, though a possible solution is to do it based on edits. 1 edit means ips AND users are able to see notice templates. This shows that they are an editor.Humiebeetalk contribs 03:03, 25 November 2020 (UTC)

Convert some disambiguation pages into broad concept articles (again)

This got archved but I don't really feel like closing it. To continue, ai  Support doing this AND I have revamp the netherite article. Fadyblok240, you  Should start turning the pages into broad concept articles.Humiebeetalk contribs 01:59, 25 November 2020 (UTC)

Cleanup of the docs of Bedrock Edition add-ons articles: Request 1

I want to contribute by fixing up all the scripting and layouting of articles related to add-ons and the Bedrock Edition add-on/resource pack/behavior pack documentation. My first request is a page split of the Bedrock Edition scripting documentation as there is a lot of information there. I said the following on the talk page of that article:

I am suggesting that we split these into separate pages under the Bedrock Edition scripting documentation umbrella. This is because programming documentation has a lot of headings, subheadings and such, this page is really diving deep. So I suggest the following:

Feel free to share any thoughts on this.

Or maybe some other way to fix that particular article, as there is no style guide that is related to programming, let alone JavaScript documentation (according to my knowledge). YivanGamer (talk) 06:41, 3 December 2020 (UTC)

Readd Pi Edition history to pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Originally this was removed due to Pi Edition being discontinued. However, Console and 3DS editions have also been discontinued, yet history information for these is kept on pages, so should Pi Edition info make a return to pages it applies to? - User-12316399 (talk) 01:32, 4 December 2020 (UTC)

 Strong support yeah this makes no sense Oreli (talk) 01:40, 4 December 2020 (UTC)
I  Oppose because Pi Edition was just one, unlike Console and 3DS which had many more. All the info for Pi Edition can be seen on its main article, so this would be pointless. Thejoaqui777 (talk) 02:14, 4 December 2020 (UTC)
Agree with joaqui Nixinova T  C   05:19, 4 December 2020 (UTC)
Pi edition was literally just an adapted version of pocket edition alpha 6.1.0, so its not really even its own edition. James Haydon (talk) 05:24, 4 December 2020 (UTC)
 Oppose per Thejoaqui777. The Great Spring (talk | contribs) 05:28, 4 December 2020 (UTC)
 Weak Oppose for above reasons. I have Pi edition and know that there is barely anything there. Blockofnetherite Talk Contributions 17:22, 4 December 2020 (UTC)
 Stongest oppose that i have ever opposed
  1. It never got updated
  2. It would be extremely inconvenient
  3. All the info is on pi edition page
Just noHumiebeetalk contribs 17:28, 6 December 2020 (UTC)

Ray Tracing

  • Shouldn't we have a article on ray tracing.
  • It is a feature of more light and smooth light and all that sort of stuff.
  • For more information go to Minecraft.net and look at articles that have RTX or ray tracing in them.
  • to get started here is one. https://www.minecraft.net/en-us/updates/ray-tracing
  • from -- 18:12, 10 December 2020 (UTC)

Redirect capitalization

Currently, we are allowed to make lowercase redirects that point to their uppercase articles. However, it is unclear whether we should create uppercase redirects to articles with lowercase titles. Is it okay to create such uppercase redirects, since when someone tries to go to an uppercase form of the same article, they go to the search page instead of directly to the lowercase article. Blockofnetherite Talk Contributions 19:01, 8 December 2020 (UTC)

Per the style guide, alternate capitalization redirects are allowed. Dhranios (talk) (Join the wiki videos project!) 19:04, 8 December 2020 (UTC)
Okay thanks, but was there a time before UCP where "uppercase is redundant to lowercase," where uppercase was not needed because the system already redirected? I feel like that has changed since UCP. Blockofnetherite Talk Contributions 19:10, 8 December 2020 (UTC)

Inventory Template in Snapshot and releases Pages

I wanted to add to the snapshot pages some Images of all the things added in that snapshot, using the Inventory template, I already done that to a lot of pages, and it looks pretty good aesthetically, in the case I don't get the permission here to do that I will undo that, Am I allowed to do that? RondiMarco (talk) 18:13, 13 December 2020 (UTC)

Per this discussion,  Neutral. The Great Spring (talk | contribs) (Tagalog translation) 13:18, 14 December 2020 (UTC)
  • Seeing the discussion there the concensus wasn't reached, so it is worth to discuss this again. However that discussion used the same format of what we are doing currently at "Planned additions" on the Caves & Cliffs article, and what RondiMarco did is add just the inventory template. I  Support this because it's a little summary of additions with another format, so I don't find a problem there, because it's just visual, and for development versions the things there were just adittions, not changed ones. Thejoaqui777 (talk) 18:03, 15 December 2020 (UTC).
    Edit: Also with visual is that they don't make the page look cluttered and are an easy link to the blocks and items articles. Thejoaqui777 (talk) 18:07, 15 December 2020 (UTC)
Changed to  Support. TheGreatSpring (talk) 03:21, 27 December 2020 (UTC)

Moving the remaining orientable block renders to use the current naming system

Currently just about all blocks which can connect (e.g. iron bars, redstone wire) or be oriented (e.g. furnaces, pistons) directionally share a consistent naming system. However, a notable exception is blocks with log orientation, which still use an Axis orientation. I've marked all of these for moving but have been instructed to ask about this here.

Advantages of moving:

  • More consistent with other block files with directional placement
  • Considerably easier to memorise as a result (with few exceptions, all block renders have north-west as the upwards direction, meaning up-left is west and up-right is north; with the Axis naming you'd need to also consider which axis corresponds to which direction, which wastes time and also changed throughout the game's history)
  • Has allowed some remaining files which didn't follow the remaining parts of the naming scheme to be identified and fixed

Disadvantages of moving:

  • Not consistent with the block's actual block state naming (probably not relevant as if we were to keep to being completely consistent with block states, rails for example would have to be moved to names such as "Rail Shape North South JEx BEy")

Other things to note:

  • Some blocks had an "Axis None" orientation Chiseled Quartz Block Axis None BE1.png Chiseled Quartz Block Axis None BE2.png Quartz Pillar Axis None BE1.png Quartz Pillar Axis None BE2.png Purpur Pillar Axis None BE1.png Purpur Pillar Axis None BE2.png Hay Bale Axis None JE1 BE1.png Hay Bale Axis None BE2.png Bone Block Axis None BE1.png Bone Block Axis None BE2.png and their new file names after this unification may be unclear. However, this exact same thing affects some files which already use the intended new naming scheme Hexahedral Piston.png Hexahedral Sticky Piston.png Weird Piston.png, so this is likely worth a separate, smaller discussion.
  • Whether this move is or isn't worth the time/effort is effectively irrelevant, as the move templates will need to be deleted from several talk pages anyway, which would take roughly the same amount of time and both outcomes will likely be performed by a bot/other form of automation anyway

Are there any good enough reasons this move shouldn't go ahead? - User-12316399 (talk) 13:27, 30 December 2020 (UTC)

I personally think we should follow the block states. Writing them out fully is not needed (EG drop the "Axis" from the current files), but we should not change the naming completely. What bothers me right now, for example, is the cauldrons "Cauldron (moderately filled with water)" (instead of "Water Cauldron Level 2" (level can be dropped per previous sentence)), which is absolutely nothing like the actual state of the block. Your rail example (Rail Shape North South) could be simplified to Rail NS, that would still follow the block states, just using a shorter variation.
This "and also changed throughout the game's history" has never actually happened, it was correcting where the sun came from, the axis themselves weren't changed, and never will.
Keep in mind that being aligned to the north-south axis is not the same as facing north or south. Dhranios (talk) (Join the wiki videos project!) 19:38, 30 December 2020 (UTC)
Just got an issue with the naming system that you're trying to apply. For rails, is Ns ascending north, or ascending south? Changing the rail file links from Ns nS Ew and eW to A<letter> for "Ascending <direction>" it is a lot more clear which is which. Dhranios (talk) (Join the wiki videos project!) 21:41, 30 December 2020 (UTC)
Lowercase is the ascending direction - the same logic applies here for redstone dust. - User-12316399 (talk) 14:18, 31 December 2020 (UTC)
It's also logical to think "uppercase is where it does up". Dhranios (talk) (Join the wiki videos project!) 20:21, 31 December 2020 (UTC)
Wouldn't that still be the same thing? – Unavailablehoax (talk) 20:26, 31 December 2020 (UTC)
No, see the redstone dust, which he compared it to, uppercase is not up directions File:Active Redstone Wire (EW).png File:Active Redstone Wire (ew).png. Dhranios (talk) (Join the wiki videos project!) 20:28, 31 December 2020 (UTC)