Minecraft Wiki
Register
Advertisement

Writing coordinates[]

Usage of coordinates is very inconsistent across the wiki. Single coordinates are written in either uppercase or lowercase and Y coordinate usage alternates between "Y-level 10", "Y=10" and "altitude 10". Complete coordinates are written "1,2,3" or "(1,2,3)" or "1/2/3" or "x=1,y=2,z=3" or whatever. There needs to be a consistent way of writing coordinates. For single coordinates, I think they should always be uppercase (as that's what's given on the F3 screen), but I'm not sure which complete format is better or if saying "altitude" instead of "Y=" is better. Nixinova T C 03:56, 17 April 2020 (UTC)

I think saying "Y" something is better as it ties it in to the in-game description better. Altitude could easily be interpreted as altitude from sea level, as that's how it's used in the real world. As for coordinate sets, I think "(1,2,3)" or "x=1, y=2, z=3" would be best. Maybe use one over the other depending on the context. Standardization would be nice but I don't feel strongly about the specifics. Count this as a support for any of the mentioned systems other than altitude. -PancakeIdentity (talk) 18:19, 22 April 2020 (UTC)
No strong opinion (except that I also disagree with "altitude" for the reasons that PancakeIdentity mentioned), but we should also standardize cases where volume dimensions are described (for example, "5×5×4" at Fishing#Junk_and_treasure). IMO the height should always be in the middle to be consistent with Y being the height coordinate in the game. –Sonicwave talk 18:38, 22 April 2020 (UTC)
I  Support standardizing volume this way. -PancakeIdentity (talk) 18:39, 22 April 2020 (UTC)
 Support specifying X, Y, and Z, to avoid confusion. The BlobsPaper 18:42, 22 April 2020 (UTC)
 Support writing coordinates capitalised as X, Y and Z for two reasons: firstly, this is how the coordinates are shown when the player presses F3 in Java Edition. Secondly, these translate to x, z and y respectively as in most coordinate systems: as someone who is familiar with the Cartesian coordinate system, understanding that Y = z and y = Z can be a little confusing at first. Even worse, −Z is north instead of south (−z), while −X is the same as −x (west). As per Wikipedia's Manual of Style for mathematics, variables should also be italicised; this includes coordinates.
As for 'level', 'layer', 'altitude'... in the context of Minecraft, all of these words are synonyms of the same concept: 'Y = ...' What actually needs to be standardised is the Y-coordinate where blocks and entities are located: is it the top face of the block (e.g. sea level is 62, clouds appear at 127), or the bottom face of the block (e.g. sea level is Y = 63, clouds appear at Y = 128)? I believe the Y-coordinate of a block should be its bottom face: if the player were to use commands to fill Y = 62 with a solid block in a biome with water at sea level, it would replace the topmost layer of water with this solid block. Conversely, the Y-coordinate of an entity should be the top face of a block they can teleport onto or spawn on.
Regarding coordinates with multiple variables, Cartesian coordinates are usually represented as '(x, y, z)' in three-dimensional space. With Minecraft being an odd exception in having a inverted north/south axis and (arguably) confusingly named axes, it would be better to represent coordinates as '(X, Y, Z)'. It helps to repeatedly use commands like /fill, /tp and /summon across different octants to have a better understanding of Minecraft's coordinate system, and its relation to blocks and entities within the in-game world. Pearlia (talk) 23:11, 24 February 2021 (UTC)
 Comment Writing coordinates as three dimensional points is a shorter way and it can be understood easily. In maths, points are represented as (0,3) in XY and points in a three dimensional grid should be represented as (-3,64,3) in XYZ order. Technically, Minecraft world is a three dimensional grid (don't care about names such as north, west etc., they will just confuse you) and it should be represented as this. Another reason that this method should be used is Commansds/spawnpoint uses that method + rotation.–The preceing unsigned comment was added by Umucraft (talk|contribs) 06:11, 29 January 2023. Please sign your posts with ~~~~!

Minecraft Dungeons style guide?[]

I have been adding a few new entries for Minecraft Dungeons (MCD) and realized that the style guide links over to this page. Most of the guide here is not applicable to MCD and some basic templates are very much needed to keep the new content neat.

--Touchportal (talk) 13:19, 30 May 2020 (UTC)

 Support Some of this style guide would apply to Dungeons, so we could create a subpage. Also, would a Minecraft Earth style guide make sense? The BlobsPaper 05:03, 1 June 2020 (UTC)
 Support I've made some basic templates such as navigations but not so much with infoboxes.
As of now the writing is very inconsistent. We should consider adding guides for capitalization, article layouts, file names, and perhaps image standardization. I've noticed several inconsistencies between editors, even for the most constructive one. So for the sake of keeping everything consistent, a new MCD-specific style guide would be very much needed. – ItsPlantseed|⟩ 13:13, 1 June 2020 (UTC)
 Support Someone can start drafting one at Minecraft Wiki:Style Guide/Minecraft Dungeons. I do have some opinions about this style guide/manual of style. I'll discuss that later.--skylord_wars (talk) 10:00, 11 June 2020 (UTC)
 Support subpage only. A style guide for Dungeons should not supersede anything already written for the main style guide, but address only situations not already covered. We don't need to add guides for capitalization and such; what we have is already fine. Amatulic (talk) 19:41, 21 May 2021 (UTC)
Changed to  Oppose as unnecessary. Based on the proposal below, I have made some small changes to the style guide to accommodate the differences in Minecraft Dungeons, particularly to the MCW:CAPS section. Most of the style guide can still apply, and there is no reason for exceptions. The only things that need addressing are features unique to Dungeons that don't exist in the base game, such as artifacts and missions. Amatulic (talk) 00:55, 25 September 2021 (UTC)

Standardized layout for Tutorials?[]

I request that tutorials should have their own standard layout. Thoughts? Fadyblok240 (talk) 22:22, 1 July 2020 (UTC)

I am not sure if this is practical. Tutorials are usually structured by having a bunch of designs, and sorting them into categories. The BlobsPaper 16:09, 3 July 2020 (UTC)
Ditto to what The Blobs said. Really not sure how this would be done. -PancakeIdentity (talk) 23:15, 29 July 2020 (UTC)
I disagree.
Farming tutorials could be standardized. Lead section, a section about mechanics (with subsections for Java and Bedrock), a section or two describing basic survival builds using text, images, and diagrams (not videos), and finally a section that includes carefully curated videos that don't duplicate any information elsewhere. Examples of this would be Tutorials/Turtle farming and Tutorials/Drowned farming, and possibly Tutorials/Iron golem farming.
Tutorials on defeating something could also be standardized: Lead section, with sections on strategies, each having subsections on preparation and execution.
Some sort of standardization would be good to prevent tutorials from being indiscriminate lists of youtube videos, most of which were placed there by the video authors for the purpose of attracting clicks and likes. Amatulic (talk) 19:47, 21 May 2021 (UTC)
 Support The proposal per Amatulic's comments. Also because they need some improvements too. Supeika (talk) 23:30, 1 October 2021 (UTC)

Screenshot sizes – unexpected and maybe unneeded de facto standard[]

Apparently some people insist screenshots must be 854x450. I don't see any reason to require any specific size beyond doing their job; consistency isn't a goal in itself, it's a means to organize content, and I don't see how a uniform image size here is needed or relevant.

Proposal: explicitly state there is no fundamental image size requirement that makes some sizes bad in themselves (beyond being excessive like 8K). --AttemptToCallNil (report bug, view backtrace) 18:12, 17 July 2020 (UTC)

 Agree. I'd also like to respond to a point seen on discord - aspect ratio requirements. While at face value this sounds reasonable, cropping images to help focus on what is actually being shows can be very helpful, especially for the smaller size of images in galleries and such. -PancakeIdentity (talk) 18:22, 17 July 2020 (UTC)
 Strongly Agree. Like some images have different shapes. Like things like non-isometric renders sometimes have really small sizes like the heart. this definatly saves space so YES –Preceding unsigned comment was added by Humiebees (talkcontribs) at 19:37, 17 July 2020 (UTC). Please sign your posts with ~~~~
 Agree with an exception. Screenshots containing UI elements (main menu, options) should have the default aspect ratio of 854x450 with the default GUI setting to keep the screenshots readable and consistent. Nixinova T C 20:11, 17 July 2020 (UTC)
 Agree. Only UI elements need to be 854x450. — Thomanski | t | c | 20:46, 17 July 2020 (UTC)

Compromise for message box / infobox order[]

In Wikipedia, message boxes should go before any infoboxes, but in many articles on the Minecraft Wiki, the infobox comes before anything else. However, applying Wikipedia's layout on Minecraft Wiki articles creates a lot of blank space. So I propose a compromise: Message boxes about article maintenance go before infoboxes, but other message boxes that describe the feature instead of the article itself (e.g. version exclusive, disclaimers) go after infoboxes. –Preceding unsigned comment was added by Fadyblok240 (talkcontribs) at 02:19, 18 July 2020 (UTC). Please sign your posts with ~~~~

That might be too complicated. Users will see the message boxes split, and they will move all of them to one side or the other. The BlobsPaper 17:43, 19 July 2020 (UTC)
I prefer the way Wikipedia does it; it makes the message boxes stand out rather than blending into the rest of the article. However, templates such as {{About}} should stay below the infobox. I think trying to differentiate between the two message boxes would be too much maintenance and not have enough benefit. — Godslayerchickennugget (talk | contribs) 17:50, 19 July 2020 (UTC)

A relevant article regarding native English speakers versus ESL speakers.[]

This article from the BBC seems somewhat relevant to the discussions of writing style. --MentalMouse42 (talk) 10:37, 4 October 2020 (UTC)

Category redirects[]

Recently, a template {{category redirect}} was create to mark categories where multiple names appear to fit. Notably, I see Category:Entity uses it to redirect to Category:Entities. Wanted to start this discussion about how to note them in the redirect notability. What makes a category redirect worth having it, and when should the category just be deleted instead? I don't have any ideas immediately as the idea is new to me. KnightMiner (t/c) 03:49, 7 October 2020 (UTC)

I personally don't see any sense in having category redirects — it's not like someone would benefit from them while searching categories, which is the first thing that gets into my head regarding their possible usage. — BabylonAS 04:26, 7 October 2020 (UTC)
I have seen some wiki's store actual content on category pages, though I don't personally think that is a good place for contennt. If users are saving bookmarks they really should bookmark the article for info, in that sense, you bookmark Entity instead of Category:Entities. Otherwise, maybe they want to bookmark the list of pages, where deleting it would break old bookmarks, so I guess that may be useful?
The other usecase I can think of is to prevent creation of redundant categories. If someone did not think the entity category existed they may accidently create a duplicate. That would mostly be addressed checking categories on similar pages though. KnightMiner (t/c) 22:30, 7 October 2020 (UTC)

About the article titles of Pocket Edition versions[]

The version pages have used the new title style, whether in the style guide needs to be corrected? --SkyE | Talk · Contributions · Logs 16:51, 22 October 2020 (UTC)

Adding external links[]

I would like to suggest adding an "External links" section to the Minecraft and variant pages. This section would only link to the game/subject's respective Wikipedia and Codex Gamicus page where available:

== $section_name ==
 * [[wikipedia:Minecraft|Minecraft]] on [[wikipedia:|Wikipedia]]
 * [link Minecraft] on [link Codex Gamicus]

This section could be above the Notes, Media or References section. TheLOLxd2 talk 13:27, 15 November 2020 (UTC)

Allow spellings suggested by spellcheckers for redirects[]

As a result of some names of blocks being made up but have similar spellings of dictionary words, such as the sculk sensor, end up being flagged by spellcheckers. Sculk, being a slight letter change to skulk, gets flagged, which suggests for it to be changed to skulk. Should this be added as a rule for redirects? – Unavailablehoax (talk) 08:54, 12 December 2020 (UTC)

 Support, granted the spell check is set to english, obviously. Dhranios (talk) (Join the wiki videos project!) 09:08, 12 December 2020 (UTC)

Plural page titles[]

See my argument on Talk:Java Edition data values, there is a standard the wiki uses that is not listed here: "pages listing a feature type should be plural" and nobody has ever bothered to bring it to the style guide and write it off as an exception instead. It is not an exception.

  • Data values
  • Mentioned/removed/unused features
  • Advancements/achievements (before I moved them)
  • Pages that consist of general concepts
    • (Actually some of them. This point needs discussion, as it should be specified which pages with this condition should use plural or not)
  • A bunch more

These pages were all in plural and written off as exceptions to the rule, but exceptions should not be this common.

If we are going to apply this reasoning, add it to the style guide....... Dhranios (talk) (Join the wiki videos project!) 05:58, 18 January 2021 (UTC)

I  Support this proposal. Specifying this would make the plural usage less confusing. Supeika (talk) 13:39, 18 March 2021 (UTC)
 Support Changing the plural title rules, only pages about one specific thing should be singular, general pages like those above should be plural. Nixinova T C 19:07, 18 March 2021 (UTC)
 Support I support listing feature types pages being plural. We might want to clarify the wording slightly from "feature type" though, as I don't think Sword should become Swords. Maybe something like "pages listing all of a feature type should be plural, this does not include cases where multiple features are combined into one article, such as sword" KnightMiner (t/c) 19:42, 18 March 2021 (UTC)

Proposal: a change to MCW:FUTURE[]

Right now there is no standard procedure for adding planned features to articles which are confirmed to be added in a known future update but have not yet appeared in development versions. MCW:FUTURE states that future content should only be included in articles if it is present in a snapshot or beta, but there are sometimes situations in which a planned future addition is signifigant enough within the context of the article to warrant inclusion. My opinion is that confirmed future features should be allowed to be included in the relevant articles within a "Planned" section, provided there is enough confirmed information to justify it.

Here's an example of a flaw in the current system, from the "Mobs" page:

=== Planned mobs ===

Planned mobs are mobs that are not yet in any publicly available version of the game, but have been announced to be added as part of a known upcoming update and have been visually confirmed.

WardenFace
Warden

Under the current rules, this example is not allowed to be added to the Mob page, because it refers to a feature not present in any playable version of the game. However, it is a confirmed feature that is planned to be added to a known update within a known time window. The Mob page also includes mobs with no known ETA, mobs confirmed to never be added in the foreseeable future, and mobs known only from 2D concept art, so for something with this level of confirmation to not be allowed a mention seems strange. And keep in mind that while the Warden will be released in a snapshot sometime soon, once the next major update is announced, there will inevitably be new mobs announced with it and this problem will arise again.

Of course, usually, if a feature doesn't yet exist in a development version, it's probably better off being listed only in the page for the update that will add it. However, in cases where it is warranted, the rules do not allow it. What I'm proposing is that MCW:FUTURE be slightly changed to allow more freedom in describing planned features in pages related to those features. AlienAgent124 (talk) 18:19, 27 January 2021 (UTC)

 Support, It's OK for me, I mean, we are sure that we are gonna get the Warden in the future, so, the article would feel more complete having informations like this. RondiMarco (talk) 22:13, 29 January 2021 (UTC)
 Oppose. While, yes, it is true that the mob is planned, it’s better to leave it off the article than the opposite. The rule states that a feature has to appear in a development version in order for it to be added, and that rule should remain as is. The Warden has not yet appeared in a development version, and as such, nothing should appear on the Wiki regarding said mob (the WIP page currently used as a redirect is the only exception). If such a section were added, then it would only fuel speculation further, and keep in mind that the mob could be scrapped at anytime during development, much like how changes to water physics were shown off at MINECON Earth 2017 that ended up not happening. BDJP (t|c) 23:49, 29 January 2021 (UTC)
 Oppose: The purpose of that rule was to prevent half baked features ending up on articles, you should have seen how many articles we had on things that were disucssed but never added before. Being in a development version means we have something concrete we can discuss. You can add it to Mentioned features until then, and I think the version articles are allowed a section for mentioned but not yet implemented. As a compromise, maybe have Mobs link "Mentioned features#Mobs" or "1.17#Planned mobs" in a "See also" section? That's about as far as I'd agree with adding it to the page. KnightMiner (t/c) 21:35, 30 January 2021 (UTC)
 Comment: I have an idea due to the comments above. The Warden could go to the "Mentioned mobs" section of the Mob article, as the Vulture, Meerkat, Ostrich, Frog and Termite are there, and they are on the same situation that the warden (confirmed to be added but not yet on any development version). Supeika (talk) 00:10, 8 February 2021 (UTC)
That sounds to me more like a case of removing those mobs from the mobs page to comply with the style guide. The style guide in its current wording disallows mentioned features on any other articles, so if they are to remain the style guide needs to be amended. I'm replying because you basically said you disagree with this change but agree with something this change would have allowed. KnightMiner (t/c) 00:00, 9 February 2021 (UTC)
Changing to a  Comment. Also explaining. The warden should go on that section as it is a mob that has been announced but isn't on any snapshot or beta. Supeika (talk) 05:56, 17 March 2021 (UTC)
Thats the whole reason MCW:FUTURE disallows it. That policy is about things that are announced that are not in any snapshot or beta. If you think that shouldn't be the case, then propose changing the style guide or agree with the given proposal. KnightMiner (t/c) 02:21, 17 March 2021 (UTC)
 Second comment: "The purpose of that rule was to prevent half baked features ending up on articles". --- It's true. If we allowed every page to have planned information then we would end with that. So, I made a proposal that would make a change on MCW:FUTURE, but without being too excessive:
  • "For announced elements that have not appeared in development versions, it is allowed to place them only in the "Planned features" sections in release articles (such as Village & Pillage) or in articles that encompass general characteristics (such as Mobs), in the Mentioned Features articles (of Java or Bedrock), and in the history section of articles as planned changes, only mentioning them there."
That way we can control where would end the planned features. Supeika (talk) 20:55, 31 March 2021 (UTC)
Per the comment below, I changed "planned" to "announced". Supeika (talk) 20:48, 1 April 2021 (UTC)
 Oppose relaxing the rule for articles. An "announced" feature isn't equivalent to a "planned" feature. If it isn't in a development version, it's basically vaporware. Addressing Supeika's proposed change, the history section of articles is for history, not future plans. I have no objection to such features being present in release articles, but that is the only place they should appear, and should not proliferate into any articles beyond the release article until the feature is seen in a development version. Amatulic (talk) 19:32, 1 April 2021 (UTC)
 Weak support. People search for more information on pages like Warden. It's one of the most popular pages on Fandom's Minecraft Wiki, look on the side rail. Also, Mojang has changed over the years its process to reveal new features to the game. I mean, Warden behavior was widely documented on Minecraft Live 2020 and by the developers on Twitter. Given that, I'd strongly support having information of what Mojang said on the Minecraft Wiki. That doesn't include what community try to measure like the HP of the mob etc.
But, i understand how hard and superficial is to document things like the Sculk Sensor block (when it wasn't released), when even devs didn't know how it would work. So, /shrug. --Dr03ramos (talk) 23:29, 12 April 2021 (UTC)

Amend the notability rule regarding minigames[]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The style guide has now been amended to no longer allow mini-games, with the sole exception of the mini games on the Legacy Console Edition. BDJP (t|c) 13:45, 17 August 2021 (UTC)

As of now, per the style guide:

Minigames are only allowed to be added if Mojang Studios claims to have played them.

However, as of recently, the minigames article has become much more of a cesspool of minigames that are notable to the community, and despite Mojang having played some of them, it is important to understand that most of them are mainly used on third-party servers, and even then, a good portion of them can all be done in the vanilla game. As such, I propose that the rule be changed to:

Articles about minigames are not allowed. Such information is better suited for the Minecraft Servers Wiki, which is designed for documenting such info. The only exception to this rule is the article about Mini games on Legacy Console Edition.

BDJP (t|c) 17:13, 2 February 2021 (UTC)

 Support as nominator. BDJP (t|c) 17:13, 2 February 2021 (UTC)
Support per nominator, but I don't think the notability guideline should be part of the style guide, especially because is unrelated to style. I would suggest splitting the notability guideline into a separate page or at least noting that the guideline does not have to do with style. Fadyblok240 (talk) 19:19, 2 February 2021 (UTC)
 Sure Nixinova T C 19:31, 2 February 2021 (UTC)
It is also worth mentioning that some subjects don't warrant their own articles, but deserve a mention, such as many of the lesser known Mojang Studios staff. The guideline should consider more of these cases. Fadyblok240 (talk) 19:33, 2 February 2021 (UTC)
 Comment: Spleef is honestly a pretty big moment in MC history as it was the first "official" minigame, so I don't especially like the idea of deleting that article (especially since its linked on Notch's old blog). Likewise, Ultra Hardcore has directly influenced features in some of the updates (golden apple tweaks, the natural regen gamerule). My opinion is instead of outright banning all minigame articles, to simply make the guideline more strict. The addition of realms makes "Mojang Studios" playing them be a lot less viable, so perhaps something like "Minigames are only allowed if they had a significant impact on Minecraft's development"? Might still be a bit open for interpretation, but in my opinion those two minigame articles are worth keeping (I don't see any other minigames I would consider notable). KnightMiner (t/c) 07:06, 3 February 2021 (UTC)
Tried to find a ref for UHC affecting the game because I know its true, and it seems 13w23a was basically the UHC update - spread players, natural regen gamerule, gapple changes, health changes. Doesn't explicitly mention UHC but has Docm77 in the banner which is proof enough. I should add this to some trivia entries. Nixinova T C 07:25, 3 February 2021 (UTC)
 Comment I would prefer to see things go in a different direction where more minigame articles (like Ultra Hardcore) are included simply because they provide pretty helpful information. –MJLTalk 03:28, 21 March 2021 (UTC)
 I agree. QuickWhitt7 (Talk | Contribs) 23:08, 1 October 2021 (UTC)
 Support I don't even know what "Mojang Studios claims to have played them" means. Who are we talking about here? Where are these claims supposed to come from? Does it count if they played it for fun during their free time? What if they hated it? Why does it make any difference that somebody at Mojang Studios played it anyway? And what even qualifies as a minigame in the first place? The current guidance is about as useful for screening out mediocrity as a participation award is for rewarding excellence. — Auldrick (talk · contribs) 05:51, 21 March 2021 (UTC)
That rule is from the early days of Minecraft. Back when Mojang AB was 5 people and would post on Twitter about collaborations with people from the community. It is far past being a good criteria, yes. KnightMiner (t/c) 04:09, 22 March 2021 (UTC)
The best part about Minecraft is actually its derivative contents.
Minecraft minigames.
They might don't directly related to "Minecraft", but it is a part of Minecraft for players.
It's a pity to delete them for MCWiki, "The Ultimate Resource for Minecraft" --Dahesor (talk) 05:41, 10 April 2021 (UTC)
 Strong support. This should go into a tutorials subpage. None of this shows content of the game and all of them are made by the community. If we allow this change, we need to allow things like servers, mods, etc.Humiebeetalk contribs 12:18, 17 April 2021 (UTC)
Servers and mods do change. But the ways to play game do not. I don't perfer to add servers stuff on MCWiki, but things like UHC is a very important part to Minecraft. They are already connected to the game. (Are you still playing the original Minecraft?) --Dahesor (talk) 03:57, 9 May 2021 (UTC)
 Comment That is not how to use {{c}} use like this {{c|oppose}} TheGreatFall (talk | contribs) (Tagalog translation) 04:07, 9 May 2021 (UTC)
 Relocate all minigame-related content to the Minecraft Servers Wiki and link to said wiki where applicable to further establish it as the official resource for such content, encourage its continued documentation and upkeep of existing documentation there, and make the bounds on what is accepted on this wiki clearer. - User-12316399 (talk) 16:24, 6 May 2021 (UTC)
 Support removing minigame (except Mini games) content from here. TheGreatFall (talk | contribs) (Tagalog translation) 04:07, 9 May 2021 (UTC)
Has a Consensus been reached yet? Litorom1 (talk) 15:41, 27 July 2021 (UTC)
I really don't want any of you people arguing, so I'm only going to say this once. Make the same pages on this wiki and the Minecraft Server Wiki. I know, I know, I used bad grammar, but hear me out! All you have to do is not move the pages here, and then recreate them on the Servers Wiki! Smart, right? Dooode12345 (talk) 23:36, 4 August 2021 (UTC)

MCW:LAYOUT needs updating[]

Currently MCW:LAYOUT lists these article components in order:

  1. Hatnotes
  2. Message boxes
  3. Infoboxes
  4. Introduction with a general description
  5. Article body
  6. See also
  7. Notes and references
  8. Applicable footer navboxes
  9. DEFAULTSORT
  10. Categories
  11. Interwikis

The problem is, many articles have a lot more than that: Sounds, History, Trivia, Gallery etc. Some have galleries included in the History section and before or after the Trivia section. There's no history section listed above even though almost every article has one.

And about Trivia, we really need some stern guidelines for trivia; many people consider that as a dumping ground for personal commentary, speculation, random tangential facts. I find myself removing something from a trivia section almost every day. But that's another issue. I want to discuss layout here.

So taking WP:LAYOUT from Wikipedia and modifying it to be more comprehensive for Minecraft articles, I propose something like this:

  1. Before the article content
    1. Hatnotes
    2. Deletion / protection tags
    3. Maintenance tags
    4. Message boxes
    5. Infoboxes
    6. Navigation header templates (sidebar templates)
  2. Article content
    1. Lead section; introduction with general description
    2. Table of contents (usually automatically included)
    3. Article body
  3. Appendices and footers
    1. Sounds
    2. Data values (if applicable)
      1. ID
      2. Block data / item data
    3. Video (if present for illustration)
    4. History
    5. Issues
    6. See also
    7. Trivia (avoid or minimize if possible)
    8. Gallery
    9. Notes and/or references (capture all citations from above sections; this can be two sections)
    10. External links
  4. End matter
    1. Applicable footer templates / navboxes
    2. DEFAULTSORT
    3. Categories
    4. Stub templates
    5. Interwikis

The "Appendices and footers" region doesn't have much consistency across articles on this wiki, at present. People are doing the best they can, but there isn't any guidance. Whatever order is most commonly used should be what we establish as guidance to minimize changes across the wiki. But I don't know how to conduct a study; I can find examples of different orderings but I am not sure what is most common. Amatulic (talk) 20:57, 28 February 2021 (UTC)

You know the layout section is just a summary, the sub pages are for specific requirements? MCW:Style guide/Features#Trivia contains those strict guidelines for trivia you wanted. If something is missing, propose updating that instead of adding something we already have. I'll agree the subpages can be made more prominent, but don't expect the summary list to be all encompassing. KnightMiner (t/c) 23:40, 28 February 2021 (UTC)
I see. Thanks. That summary, then, doesn't match the list in the Features page. I'll do some cleanup. Amatulic (talk) 03:56, 1 March 2021 (UTC)
Its not just the features page it should match, we have a few other layout guides. I am partially inclined to just ditch it. Alternatively, maybe The major categories from your proposal above could be kept and the minor categories that differ can be left out. KnightMiner (t/c) 04:29, 1 March 2021 (UTC)
 Comment: First, MCW:Style guide/Features explains what should be done on the sections, not how the layout should be done. Second, it was suggested on its talk page that the page needs to be split, and many people agree on that idea, meaning that if it is split it won't be (if it was) anymore a general layout guide.
So, I  Support the proposal here because it will work perfectly. If a specific point need to be noted, then create a subpage specifying things. The layout is the order where things should go, not how they should be written. Supeika (talk) 04:35, 12 March 2021 (UTC)
 Comment: I need to say that stub templates are maintenance templates too, so the layout would need to be like this:
  1. Before the article content
    1. Hatnotes
    2. Deletion / protection tags
    3. Maintenance tags/Stub templates
    4. Message boxes
    5. Infoboxes
    6. Navigation header templates (sidebar templates)
  2. Article content
    1. Lead section; introduction with general description
    2. Table of contents (usually automatically included)
    3. Article body
  3. Appendices and footers
    1. Sounds
    2. Data values (if applicable)
      1. ID
      2. Metadata
      3. Block states
      4. Item data
      5. Block data / entity data
    3. Advancements
    4. Achievements
    5. History
    6. Issues
    7. See also
    8. Trivia (avoid or minimize if possible)
    9. Gallery
    10. Video (if present for illustration)
    11. Notes and/or references (capture all citations from above sections; this can be two sections)
    12. External links
  4. End matter
    1. Applicable footer templates / navboxes
    2. DEFAULTSORT
    3. Categories
    4. Interwikis
What do you think? Supeika (talk) 18:32, 26 March 2021 (UTC)
@Supeika:, I support this but how is anybody going to remember like 40 different things? I don't want to go back and forth. Maybe add it to the editing message box? Also, maybe a project should be made to change the order of every single page as there is an enourmous inconsistancy, mixed up sections, hatnotes, infoboxes, message boxes, it's chaos.Humiebeetalk contribs 22:21, 1 April 2021 (UTC)
All suggestions so far are missing the advancement and achievement sections. Please add them.
Under data values, metadata, block states and entity data are also missing; I'd suggest the order ID, metadata, block states, item data, block data, entity data (which is already the order they should have right now). Dhranios (talk) (Join the wiki videos project!) 22:23, 26 March 2021 (UTC)
 Comment: You are right, I'll add them to my proposal. Supeika (talk) 23:39, 26 March 2021 (UTC)
I'd merge Achievements and Advancements. Call it "Advancements (if Java) or Achievements (if Bedrock)". They are the same section with the same function and essentially similar content, but with different names.
Also, on Wikipedia the practice is to put the stub template at the bottom, as it isn't really a maintenance template, but functions similar to a category. An experience Wikipedia editor coming here would get confused by a requirement to put it at the top. Amatulic (talk) 21:29, 1 April 2021 (UTC)
That's way too long for a header title, and helps almost no page, as almost every one that has one has the other too. We really don't need to change them, just make the order consistent. Dhranios (talk) (Join the wiki videos project!) 22:14, 1 April 2021 (UTC)

The proposed layout is fine for a general article framework, but what I see confusing some editors (me included) is how to arrange the sections under "Body". The layout is different depending on the article topic: Mobs, Items, Potions, Entities, Enchantments, Biomes, Blocks. The body part needs expansion. Amatulic (talk) 16:28, 1 June 2021 (UTC)

Not really keen on capitalization rules[]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
User has failed to make a valid point for their cause. And when asked to give an explanation, they responded with nonsense. This whole proposal contradicts English grammar rules as Dhranios said so it will never be implemented, even with support. James Haydon (talk) 16:02, 23 March 2021 (UTC)

Enchantment names and potion effects such as “silk touch” and “fire resistance” do not deserve to be proper nouns. If block & item, mob and structure names are common nouns, it would only make sense for names of potion effects and enchantments to be common nouns as well.

Names of gamemodes do not deserve to be proper nouns either due to English capitalization rules. Dimension names should be common nouns as well. —SeriousError 14:02, 19 March 2021 (UTC)

A proper noun is a specific (i.e., not generic) name for a particular person, place, or thing. Enchantments and effects are specific names for things, dimensions are specifuc nanes for places, gamemodes are specific names for things. Simple as that. "Sheep" is not a specific name for a being, "dirt" is not a specific name for a block, "stick" is not a specific name for an item.  Biggest oppose ever as this is directly contradicting English grammar rules. Dhranios (talk) (Join the wiki videos project!) 14:22, 19 March 2021 (UTC)
You don’t know how English works. It’s more complicated than that.—SeriousError 14:28, 19 March 2021 (UTC)
Mind to give a full explanation then? Because Dhranios' point seems pretty valid. James Haydon (talk) 14:30, 19 March 2021 (UTC)
By all means, explain it then. I literally just looked up the actual definition of when something is a proper noun. Prove me wrong. Dhranios (talk) (Join the wiki videos project!) 14:31, 19 March 2021 (UTC)
SYSTEM ALERT CODE: 871–SeriousError 14:39, 19 March 2021 (UTC)
Wow, not even a proper response, let alone arguments.
Proper nouns:
Names of people and pets, geographical locations and astronomical names/planets, months, days of the week and hollidays, publications, books, schools, nonprofit organizations, companies and brand names, cities, states, countries and continents, religions/faiths, places, titles, course names (eg Economics 101), historical periods, languages/nationalities, etc. it all boils down to the simple rule above "specific names, VS generic names". A specific gamemode, a specific enchantment, a specific effect. (edit after edit conflict resolve) Auldrick is right in the small correction that context matters, if there were multiple dimensions named "Nether", it would not be capitalized, but there is only one. Dhranios (talk) (Join the wiki videos project!) 14:48, 19 March 2021 (UTC)
"The Overworld" and "The Nether" are specific names for particular dimensions. Whether a noun is proper or common is not a characteristic of the word itself but of what it refers to. You can't just say "the overworld" is a common noun, you have to consider whether what it refers to in the surrounding context is generic or specific. In Minecraft, there are several dimensions but only one called the Overworld, so it's specific. Similar arguments apply to other things you've lowercased. "Manual of Style" refers to a specific set of guidelines or a specific page. If it were "a manual of style", that would be a common noun, but with the definite article or without an article it's a proper noun because of what it refers to. Also, please sign your contributions with "~~~~". — Auldrick (talk · contribs) 14:41, 19 March 2021 (UTC)
 Very strong strong strong oppose per Dhranios. TheGreatSpring (talk | contribs) (Tagalog translation) 00:51, 20 March 2021 (UTC)

Formatting filenames[]

Filenames on this wiki always seem to be formatted with <samp>, including in article titles. The <samp> tag is reserved for denoting sample output, but filenames are usually not outputs. I think we should avoid using any monospace formatting in headings and the bolded word, and use <span style="font-family: monospace, monospace;"> (which could be used in a new template) for other instances of filenames. Fadyblok240 (talk) 21:06, 27 March 2021 (UTC)

Wiki Rules[]

I think the Wiki Rules under Notability should be enumerated 1. 2. 3. to match the rest of the article or for the rest of the rules to be added. Starting the list with 4. seems messy. DeeFeeCee (talk) 21:33, 3 April 2021 (UTC)

Those numbers are referring to the wiki rules 4 5 and 6 directly. Numbering them 1 2 and 3 will be misleading as the rule numbers then don't correspond with the numbers on MCW:RULES Dhranios (talk) (Join the wiki videos project!) 21:55, 3 April 2021 (UTC)
Are the first 3 rules unnecessary to include then? DeeFeeCee (talk) 00:30, 5 April 2021 (UTC)

Capitalization of proper nouns in display names[]

Should proper nouns in item/block/structure names be capitalized? For example, should it be "a nether fortress" or "a Nether fortress", "an end portal frame" or "an End portal frame"? I think the later would make sense, that's applied somewhat in real life where location and demonyms are capitalised even if they're part of a bigger noun (i.e. "Asian elephant", "Portland cement"). Is there an in-game instance of either case where we can reference from? Pescavelho (talk) 09:47, 9 April 2021 (UTC)

Personally I've been writing "a Nether fortress" following normal English usage, so  Support standardizing this. Nixinova T C 02:57, 11 April 2021 (UTC)
It's already been standardized in MCW:CAPS: "Proper nouns, however, such as the Nether or the Overworld should always be capitalized." Is that not clear enough? — Auldrick (talk · contribs) 03:06, 11 April 2021 (UTC)
That could be read as 'the terms themselves' and exclude derivatives, however. Adding "and all derivative forms" would clear it up. Nixinova T C 03:12, 11 April 2021 (UTC)
 Support this – would clear up some ambiguity with stuff like "Enderman" (which used to be listed in lowercase as recent as this February). –Sonicwave talk 04:01, 11 April 2021 (UTC)
Some words like "netherrack" or "Enderman" (i.e. composite words which incorporate location names into the etymology) itself are inconsistently capitalised, I assume those would be addressed on a case by case basis or if there is any precedent from official sources to capitalise/uncapitalise. Pescavelho (talk) 17:19, 11 April 2021 (UTC)
 Comment: "Enderman" should be capitalized, however "netherrack" shouldn't be capitalized, as it talks about a fantasy element that it's common, making it a common noun and not a proper noun. For example, "blackstone" isn't capitalized, and it's a fantasy element. Supeika (talk) 18:19, 11 April 2021 (UTC)
Well, in the example provided in the article, "Blazes spawn in nether fortresses." would seem to contradict that notion, that should probably be cleared up then. Pescavelho (talk) 10:05, 11 April 2021 (UTC)
Ah, I'm surprised I didn't notice that, as I've been focused on MCW:CAPS several times lately. Looks like we need to discuss it after all. I personally feel that Nether, Overworld, and End should be capitalized in any context (except, of course, "end" when not referring to the dimension). — Auldrick (talk · contribs) 10:13, 11 April 2021 (UTC)

Some of my edits wherein I "corrected" articles by making all instances of "Nether" uppercase have been reversed, so I got reminded we still haven't fully standardized and cleared this up.

My proposal is: clarify in the style guide that all instances of specific locations, such as Overworld, Nether and Ender, as well as demonymics of those places (ex.: "Ender") should be capitalized even when as part of a noun. Examples:

- Nether quartz, not nether quartz

- Ender pearl, not ender pearl

This is consistent with real world English orthography (ex.: French fries, Asian elephant, Portland cement).

Specific cases: Ender Dragon, capitalized, it's a unique mob; Enderman I believe gets capitalized out of set precedence, as it is so in official Minecraft media; netherrack I believe is uncapitalized, we'd have to check if it's consistent with official sources and/or English grammar; we need to set a standard for these and maybe other specific instances I've missed if that's the case.

From what I've seen a lot of people have agreed with my base proposal, we just need to standardize those odd instances and clear out ambiguities, but feel free to disagree. Pescavelho (talk) 21:13, 20 January 2022 (UTC)

Article naming for items with edition conflicts[]

Auldrick recently changed the naming guideline to avoid preferring a specific edition where the name differs between Java and Bedrock. While I don't oppose this principle in general, I disagree with this change and have reverted it for several reasons. The current guideline clearly outlines the criteria to use in case of conflicts, and is consistent across the wiki as the Java name is used in most cases. The changed one (which just says to use any name) is vague and doesn't help resolve conflicts, and therefore might as well not be mentioned on the style guide at all.

In addition, I believe the reasoning for using Java names is because Java has undergone the Flattening which renamed many blocks and items, whereas Bedrock hasn't gone through such a large-scale change yet. I haven't yet found a source suggesting that Bedrock plans to update to the Flattening names, but if these name discrepancies will be resolved eventually, it'd make more sense for them to choose the newer post-Flattening names instead of reverting to the old ones.

In any case, the previous guideline has been the de facto behavior on the wiki for a while now (e.g. Spawner, Daylight Detector, Milk Bucket, Redstone Dust before Bedrock renamed it) and should be discussed first before changing. The discussions on MCT:Projects/Renaming are several years old (before the Flattening) and don't really focus on article titles, just the treatment of editions on the wiki in general; so I don't think they apply here. I would not be opposed to rephrasing the guidelines to keep the same spirit but be less Java-centric; e.g. "If the feature has different names in multiple editions, the more recently changed name should be used". –Sonicwave talk 23:43, 10 April 2021 (UTC)

I'm pretty sure Bedrock is confirmed to receive the flattening eventually, which I assume would include the names. -PancakeIdentity (talk) 07:38, 11 April 2021 (UTC)
I didn't follow how the Flattening was relevant in the first place. Doesn't it just change the namespaced IDs? We don't use those for article titles, so how does it have any effect? And anyway, I think Bedrock has already been flattened, at least partly. We have new alias names for variants that were identified by a name/DV pair, and you can now use either one in commands. (Backward compatibility for old command blocks.) I have no idea whether they've changed the identifiers in stored data, but I don't see any reason they would need to, either. — Auldrick (talk · contribs) 09:58, 11 April 2021 (UTC)
Java 1.13 changed the names of some blocks and items in addition to the IDs. –Sonicwave talk 23:25, 11 April 2021 (UTC)
I fully expected this reversion and made the edit deliberately with the intention of evoking discussion and consensus building. I take issue with almost everything you're saying, but in order not to monopolize the page I'll skip the blow-by-blow and just address what I see as a pattern of problematic behavior that this wiki has tolerated for 3 1/2 years.
The "current guideline" is the product of a single editor on 17 December 2020. It was a time when a large fraction of our English-fluent editors would likely have been preoccupied with preparations for the holidays, so it probably got very little scrutiny, if any. And it was done without discussion, with an edit summary claiming, "they've been used for years, just solidifying them in the style guide now". (As if elevating a simple habit to the level of a guideline, thereby imposing it on all editors, is a trivial matter.) This was an obvious attempt to deflect any objections to the way it evades the normal wiki process of building a consensus. But let's look at where this so-called "de facto behavior" originated.
In the summer of 2018, a group of people got together on Discord to discuss upcoming changes to some Java block names, which I guess was in support of the Flattening. Not long after, several of these pages were moved to the new Java names with edit summaries referring to "a consensus reached on Discord" and mentions that these blocks were scheduled to be renamed on Bedrock as well. This had the desired effect of forestalling objections to the name change, since it would benefit both editions equally. However, I have many concerns about how the situation.
  1. A live discussion off-wiki cannot possibly arrive at a consensus of the wiki's editors. Editors come from every time zone. Many would be working, sleeping, or eating at the meeting time. Some people can't install Discord or can't connect to the server. Some people just don't want to install it and can't be compelled to in order to preserve their right to participate. Maybe some people couldn't be present the whole time.
  2. Discord doesn't record anything. Anything that might have been concluded is simply hearsay, as there is no record of it. And I'm sure we all know how fallible human memory is. What's been called a consensus might have been an agreement among 5 people after everybody else left. That's not a consensus, it's a cabal. Who's to say what really happened? Only the messenger delivering the self-serving message.
  3. At the time of the Discord meeting, we already had an established consensus that no edition would be given priority. Yet somehow the meeting outcome was in direct contravention of it. Obviously, it was regarded as an inconvenience to be circumvented, or simply ignored.
  4. It was said that Bedrock would be changing its names too, but nobody can source that claim (and of course, there's no record of who said it or how they knew it). It was plausible enough to be believed, but in fact it has so far not turned out to be true. Thus there is no evidence to refute a belief that it was a pure invention designed to blunt complaints from the Bedrock side that Java was being given priority.
So now the argument is that this illegitimate "consensus" has become a de facto guideline through long use and shouldn't be modified without discussion. And by the way, it's been a guideline for three months so it's already canon. Never mind that there's no hard evidence that it was ever really discussed at all. Never mind that it conflicts with an established and documented consensus. Granted that MCW:Projects/Renaming was a year or so old at the time, but at least it was on the record. And it still is, though that doesn't seem to mean anything to some people.
My reversion was reverted for failure to discuss it first. Ok, then where was this insistence on formality when the December edit was done? Or any of the dozen other edits, some of them rule changes, since then? Isn't it curious how formality only seems to matter when Java stands to lose some of its undeserved privilege. — Auldrick (talk · contribs) 09:58, 11 April 2021 (UTC)
I agree that important decisions like these should be made on-wiki and not based solely on Discord, it's even one of the server rules. My impression was that this was discussed on-wiki as well, but I could be misremembering the extent of discussion. To be honest I would be fine with removing the current guideline until we come to a conclusion, but not replacing it with something that contradicts current behavior (for the reasons stated in my previous comment). Regarding your last point, I went through most of the unique blocks/items on Java Edition 1.13/Flattening#Names, and for roughly 1/3 of them that had name conflicts after Update Aquatic (JE 1.13 and BE 1.6.0), Bedrock changed to Java's name at some point while Java's have largely stayed unchanged; so it seems like a reasonable assumption to make. –Sonicwave talk 23:25, 11 April 2021 (UTC)
Auldrick is referring to this undiscussed change], subsequent and proper revert, and then the nonsensical restoration of the change with an admonition about making undiscussed changes!
Can we just remove it? The editor who added it (Dhranios) was apparently having other problems around that time which led to his disappearance.
I also strongly oppose this change because if we are to give naming priority to one edition, it should be Bedrock because that has the larger installed base, so it's likely that most of the readers are coming from Bedrock anyway. I'd rather not give priority to either one and revert it back to the previous version that has consensus. Amatulic (talk) 20:00, 21 May 2021 (UTC)
I feel like I need to clarify some things:
The edit was the consensus for years (yes, years, not some short timespan) based on moves, splits, merges and new creations; that is why I felt fine ammending the style guide to propperly adress it based on said consensus.
Bedrock has a lot more conflicting and older names (with conflicting, I mean both reused names and names that are just inconsistent with one another), this is why it is objectively better to follow the java names where possible, which (SonicWave) are all the newest names in the game, so "newest name first" would have the same result.
The other edit issue, and me leaving should not be an argument to revert things.
I did not "choose to edit at this specific time to hide it", better yet, I didn't care for when I did this, nor is hiding edits possible. You are interested in this page, so you should be watching it in the first place. You get notifications and emails of edits to pages you watch, and it is listed in recent changes too, both on wiki and the discord. Do not use your own incompetence as an argument to villainize me, this is exactly the kind of crap I've received all over the community, and THAT is why I deleted my wiki account.
As for the flattening naming changes coming to bedrock source, that was Helen. And don't go pull that "things may have changed" crap, as with that logic, every single mentioned but not implemented idea may also just be removed from the wiki, even if shared seconds ago, because a decision to not do that may've come seconds after. The message proving this is (IIRC) somewhere in the discord, but I'm not going to look for it, as I quit.
This message is not me coming back, it is me defending myself from the horror that is the Minecraft community. I'm not going to help you anymore. I used to help the community with a smile from 2012 to 2021, but that's over. I've received way to much crap from it in return, everywhere I went. Mojira, the Minecraft discord, the wiki, the various subreddits (and corresponding discords)... I'm done! I'm no longer on the public end of the community, and will never return. This choice was not an easy one, but also not one I had to think about for long. Severe self-hatred, feeling of uselessness, giving up on my own future and more hit right after making it. So don't go thinking I just left just to flee from responsibility, because that's the furthest from the truth you can be. 86.90.184.130 06:49, 25 May 2021 (UTC)
I wasn't trying to imply that just because you've left, your edit can be undone. Rather, I was underscoring the point that your edit should be undone because it was an undiscussed change that had no consensus whatsoever evident on this talk page. If consensus was implied by moves, creations, etc., that certainly wasn't evident in the edit summary -- and again, it wasn't discussed. Stuff that happens off-wiki isn't really relevant to the community here that has an interest in maintaining this page. A unilateral change made without evidence, just hand-waving take-my-word-for-it rationale, isn't adequate.
That said, you make a case for following the newest name first, which happens to be the java name. That's fine, one has to name articles something. I would still prefer that once the feature exists in Bedrock, that the Bedrock name be adopted, and the java name made into a redirect, simply because the user base is larger for Bedrock Edition, and by consequence, so would be the readership of this wiki.
Until we get an actual consensus on this talk page, the edit should be undone. So far I haven't seen strong support for the change from anyone but the person who added it. Amatulic (talk) 08:19, 25 May 2021 (UTC)
Responding to Dhranios editing (presumably) as IP 86.90.184.130. (1) You said: The edit was the consensus for years (yes, years, not some short timespan) based on moves, splits, merges and new creations. But de facto editing practices, no matter how long-standing they may be, don't establish consensus; only discussion can do that. It's like matters of fact: Something doesn't become a fact because people believe it, it has to be tested and proven. So claiming you were only documenting an existing consensus seems disingenuous: In my view, you were trying to declare a consensus, without discussion and in direct contradiction (as was the prior practice) to an actual, documented consensus established years ago. Some, perhaps most, of the edits you claim as a basis for your putative consensus predate its establishment, so obviously they can't lend support to your argument. Others occurred after the consensus was reached, and violate it, but just as in law, the failure to enforce a rule in one instance does not per se constitute a repeal of that rule.
(2) You said: Bedrock has a lot more conflicting and older names...this is why it is objectively better to follow the java names where possible, which...are all the newest names in the game. First, I'm not certain what you mean by "conflicting" names. If you mean they're different from Java's names, then Java is conflicting in the same sense and to the same degree, so there's no support for calling either one "objectively better". Perhaps give examples of what you mean? Second, Java's conflicting names are not the "newest names in the game" unless by "the game" you mean the Minecraft franchise as a whole, but the majority of players only play Bedrock. To them, the Bedrock names are the "newest" ones and you appear to be ignoring your own rule. The wiki should be just as easy (if not easier) for them to read and edit as it is for Java players. I understand that you expected Bedrock to adopt the new names rapidly, and it was plausibly true even though I found no official statement from Mojang so at the time I didn't object. But that hasn't been realized, and in some cases likely never will be as the old names are increasingly being baked into the Bedrock add-on interface. So some Bedrock names are different from Java names, and it's a disservice to Bedrock players that the wiki pretends otherwise just because some Java editors wish Bedrock would conform to what they think of as the prestige version.
(3) You said: I did not "choose to edit at this specific time to hide it".... Those quotes don't belong there, as nobody said those words, they're entirely yours. In fact, I don't see that anybody said anything very much like that, and I'm not even sure who you're addressing yourself to here. The whole rest of your contribution appears to be a play for sympathy over one or more unfair attacks that you've imagined, so I'm just going to ignore it. — Auldrick (talk · contribs) 21:41, 7 June 2021 (UTC)
Is there a full list of articles with conflicting names somewhere? If nothing else, it could be useful to send to Mojang as they have a goal of unifying the editions. In any case, it would help this discussion so its clear to me how big of a problem this is. It could also help clarify if one edition tends to have "old names" from the other edition if we make note of which when a current name was an old name in the other edition. I want to hold off on my opinion on this until I see such a list for context. KnightMiner (t/c) 00:04, 8 June 2021 (UTC)
We could make up Category:Topics with conflicting names. It wouldn't be a long list. Steak, jungle pyramid, and swamp hut come to mind. Amatulic (talk) 05:24, 5 August 2021 (UTC)
The de facto defaulting to Java names comes from the long time where Java was the default edition, with Bedrock having played catch up for the majority of the last decade. As is symbolised by the now-equal version numbers Bedrock is on an equal status and as such no version should be preferred. However we have to pick something; Java has been the natural fit not because of its default status but because Bedrock had been changing names to fit Java before. If this is no longer the case and the current names are being entrenched in add-on data as stated above then both editions should be treated equally. In response to the actual question I have no preference, just make sure the lead presents them as equal, and I think having the names decided on a case-by-case basis is good enough.
This can all probably be cleared up by just asking a dev on Twitter which names should be preferred, maybe try that route. Nixinova T C 06:46, 5 August 2021 (UTC)

Are we allowed to use the oxford comma?[]

Aka, the comma between y & and in "x, y, and z"

Are we allowed to or is it against the style guide – Unsigned comment added by ‎Broken7133 (talkcontribs) at 13:56, 15 July 2021 (UTC). Sign comments with ~~~~

There is no requirement for either one. I prefer oxford commas, and I include them when I see them missing. Omitting the comma makes it look like "y and z" are part of a group rather than individual things in a list. Amatulic (talk) 15:14, 27 July 2021 (UTC)

Additions needed to MCW:CAPS for Dungeons[]

The Minecraft Dungeons articles are generally inconsistent in their conformance to this style guide, particularly MCW:CAPS. Part of the problem is lack of familiarity by many of the contributors (who are fairly new and unaware of this style guide), and part of the problem is that there are elements of Minecraft Dungeons that are simply not covered here.

I have made a few small changes to MCW:CAPS:

  • Organized sections into "do not capitalize" and "do capitalize" for clarity.
  • Added MCD:Artifacts as something that should be capitalized, as these are special items that seem to have magical effects (conceivably enchantments or status effects to give them special abilities), which would be capitalized; this change I made to the guideline should be non-controversial as it follows a practice already established in the MCD articles.
  • Added some examples to illustrate non-capitalization of items.

None of my changes so far actually change our guidance. And nothing about Minecraft Dungeons articles should change the existing guidance either. The guideline just needs to be expanded to cover some things that the base game doesn't have, such as:

  • Unique MCD:Locations in the game (should probably be capitalized unless they are descriptive or same as the base game, like "desert temple" even if unique).
  • MCD:Artifacts (which I already added as should be capitalized).
  • Weapons, armor, and tools found only in Dungeons (should not be capitalized unless they are artifacts).
  • Mobs found only in Dungeons (should remain uncapitalized, including all passive mobs, NPCs, and mini-boss mobs).
    • Possible exception of certain singular big-boss mobs that don't have descriptive names but more proper-noun-ish names, but keep in mind that the final boss "Ender dragon" in the base game, is not capitalized except for Ender, referring to the dimension, which should always be capitalized.
    • Need to decide whether the "ancient" mob variants deserve an exception.
  • Mobs referred to by an aristocratic title (e.g. "Arch-Illager" should be capitalized, although not sure about the "illager" part).
  • Several hostile mobs have named attacks that seem to have been invented by the person who wrote the article; these shouldn't be capitalized. In fact, these made-up attack names should be removed completely, just listing the attack descriptions in a bullet list is sufficient. These made-up attack names never seem to be referenced elsewhere, even in other sections of the same article.
  • Mission names (should be capitalized).

We could tack a supplement onto the end of MCW:CAPS to cover Minecraft Dungeons cases, but I prefer simply to include more examples in the existing sections to cover Minecraft Dungeons instances. In-game locations could have their own subsection like artifacts now has, although examples of this could be merged into "Structures and biomes" too. Amatulic (talk) 19:31, 4 August 2021 (UTC)

Nobody has objected to any of this in nearly 2 months so I have added to MCW:CAPS artifacts, ancient mobs, primary boss mobs, and locations to a section about Dungeons features that should be capitalized, and added uniques and attacks to a section about features that shouldn't be capitalized. Amatulic (talk) 05:55, 26 September 2021 (UTC)
Because the Dungeons Wiki usually tends to get overlooked. James Haydon (talk) 20:24, 6 September 2022 (UTC)
I do think that uniques should be considered as singular items as I elaborated further down this talk page.Drour1234 (talk) 12:45, 7 September 2022 (UTC)

Overlinking guideline proposal[]

I noticed a tendency for some editors to turn sentences or paragraphs into a "sea of blue", linking every possible word that can be linked. I've reverted some of these. While Wikipedia has mind-numbingly extensive guidelines on this, we don't have anything at all, so I've been just using my judgment gained from over a decade of Wikipedia experience. I propose something short and simple:

To avoid a "sea of blue", avoid repeating a link that has already been used in the same section or subsection of prose, although it may be repeated as a list item, or if it is critical to the context of a sentence. When possible, avoid placing links next to each other so that they look like a single link, as in dungeon chest loot (coded as [[dungeon]] [[chest]] [[loot]]). Consider rephrasing the sentence, omitting one of the links, or using a single, more specific link instead; for example dungeon chest loot (coded as [[Chest loot|dungeon chest loot]]).

Thoughts? Amatulic (talk) 15:41, 22 May 2022 (UTC)

There are guidelines at MCW:Style guide#Linking, though I would be in favor of making some of them less specific and more like your example. E.g. I doubt "No more than 10 percent of the words in an article are contained in links." is something that anyone follows, or would be appropriate for all articles. –Sonicwave talk 20:10, 22 May 2022 (UTC)
 Comment: I think it's kind of common sense to not overload pages with long sentences of blue links, and even more that links like [[dungeon]] [[chest]] [[loot]] aren't nice to see. Related to our policies, they are kind of confusing, and even we have this message saying "For a complete guide to linking, please refer to Wikipedia's Manual of Style for links, although do note that some of the policies about linking listed there are different than many here.", which I find wrong not because the wikipedia mention, but rather because it explicitly says that there will be inconsistencies between versions and makes an editor get confused because of that. I think we should improve their readability, while also taking what better fit us. Whether it becomes a list of rules, a paraghraph, or a combination of both, will be a result of what we'll get at the end, but in general I do agree that we need more examples, but I wouldn't like to overcomplicate things (which is one of the reasons I don't like to link to wikipedia, because their rules are too extensive for the regular minecraft wiki editor). Edit: I've made a sandbox page (original version) with a proposal for these rules, if you want to see them. Supeika (talk) 04:20, 23 May 2022 (UTC)
I like your draft. I revised two of the bullets with information I felt was missing and needed to be said. I also agree with your view on referring to Wikipedia guidelines. This is appropriate if we have none of our own, but if we have our own, then we don't need Wikipedia's, although we can use Wikipedia's as a basis (which makes sense for giving editors a consistent experience using the wiki software). Amatulic (talk) 17:29, 23 May 2022 (UTC)
Looking at it again, I think bullets 2 and 3 could be merged, as they are both about multiple links of the same term. Amatulic (talk) 17:35, 23 May 2022 (UTC)
One of the reasons I separated them was because one is duplication of useful links, and the another is repetition of non-relevant links. Another one is because it's easier to read and remember these guidelines if they are short. And also thanks :D. Edit: I misread and thought it was just bullet 3 and 5, my error. Yeah, they can be merged, oops :c Supeika (talk) 17:42, 23 May 2022 (UTC)

Splitting notability out[]

Someone tagged the notability section with a proposal to split it out to MCW:Notability, which is currently a redirect.

I  Support this move. Notability has nothing to do with style considerations. Notability is all about determining the content of articles. Amatulic (talk) 23:55, 4 June 2022 (UTC)

 Comment: While notability is something that has more to do with article content, wouldn't we be splitting too much pages? I currently like how the current page is because it's concise and in the same place, and going through many pages to find just a small piece of a policy doesn't really feel like something we should do, and it would just add one more page to any reader who wants to read these policy pages. Supeika (talk) 14:56, 6 June 2022 (UTC)
It isn't concise, it's a big unwieldy page. I still think we shouldn't be combining a content guideline with a style guideline. Notability has nothing to do with style. For a compact everything-in-one-place page, we could create a page MCW:Policies and guidelines as a table of contents, or append a list of policy and guideline pages to the existing MCW:RULES page. Amatulic (talk) 17:18, 6 June 2022 (UTC)
I as a regular reader and editor don't get why the difference here is that important. It would create just another page when the current style guide isn't really a long page compared to how other sites do their policies. Supeika (talk) 19:42, 6 June 2022 (UTC)
 Oppose Just a notice that we're not on Wikipedia. Gamepedia wikis had historically more relaxed policies. And having dozens of pages to look for won't be the best for newcomer. On other side, I see the Style guide should be rewritten (or at least there should be a more user-friendly version of it), so users won't give up faster than they even make their 5th edit. --TreeIsLife (talk) 20:13, 6 June 2022 (UTC)
 Comment – The notability guidelines are used as actual deletion rationales and in that regard do feel out of place compared to most of the style guide. But there are other parts of the style guide that also refer to content, such as the trivia and image guidelines (the latter of which is cited as reasons to delete images themselves). MCW:FEATURES itself describes both the content to include (any content not listed there is likely to be deleted) and the way it should be organized. I don't see a good way to split all of the content and style guidelines especially where article layout is concerned. I think it would make sense to rename these pages to a more general "MCW:Content guidelines", since they clearly refer to more than just formatting and style. –Sonicwave talk 05:07, 7 June 2022 (UTC)
I'd support renaming the style guide to "content guidelines" as well, because that name is a lot clearer than what we have now, and newer users/editors would be able to understand better what's the purpose of the page, as well as representing its intention in a beter way. Supeika (talk) 13:18, 9 June 2022 (UTC)
Content and style are two different topics. Content does not encompass style. I have no objection to creating MCW:Content guidelines and putting all the content-related stuff in there. Style determines how an article looks, and content determines what the article says
BTW, this is exactly the philosophy behind web page design also. HTML and CSS are separate. The HTML markup is the content of the page, while the CSS (Cascaded Style Sheet) defines the style, or how the content is displayed. Amatulic (talk) 20:01, 9 June 2022 (UTC)
Then I'd support the page being renamed to "Article writing guidelines" or "Article page guidelines" as alternatives, since the current style guide isn't really worth to be split into even more pages. It actually would be the opposite, it being that the style guide could get simplified instead, as TreeIsLife said above. Supeika (talk) 20:53, 9 June 2022 (UTC)
I'm still having trouble figuring out how the content and style guidelines should be split. Would MCW:FEATURES be considered content or style, and if the former, what about the Article layout guidelines (which is similar but only covers the layout, not what goes in each section)? What about the article and image naming formats, or MCW:UPTODATE which is more content than style, but relevant to the rest of the "Writing" section? –Sonicwave talk 22:39, 12 June 2022 (UTC)
I was the one who placed the template. If we're not going to split notability out, at least move it further down the page, since it is of little concern to newcomers. Also, MCW:FEATURES and the article layout guidelines would both be considered style, since it merely involves how information is presented within a page, not if entire pages need to exist or not. Fadyblok240 (talk) 03:04, 24 June 2022 (UTC)
 Support - Notability is not about style, but it is also not specifically about the contents of an article, it is about deciding which articles can and cannot exist. The style guide is quite long, so I think shortening it by moving notability would help readers digest the page more easily. -  Harristic | Talk | Contributions 08:29, 8 July 2023 (UTC)
 Support — Notability requirements have a higher mandate level, so to speak: if something is deemed unnotable, the rest of the style guide won't even matter as the article in question would simply be deleted. It's not a matter of “how to write”, it's a matter of “should you write or not”. — BabylonAS 08:43, 8 July 2023 (UTC)

Icons in prose[]

I have seen folks (and participated myself) removing icons from prose. I generally think this is a good thing as it enhances readability. I am wondering if there should be some guidelines over when to use them and when not to. For example, I think they are good when used for xp or hearts, but otherwise, I think it is probably not needed. I think an exception is certainly tables, etc. So do we have guidelines around this? If not, should we? - AD OffKilter (talk) 22:17, 18 July 2022 (UTC)

 Comment - I agree to create some guidelines about when to use them in general, but I don't think that removing them from prose would be helpful. Sometimes sprites are useful to give readers a visual indicator of what is something about, since plain text may not be enough. I know that using too many sprites is a problem that may clutter a page, so these are my guidelines:
  • Sprites on article body are allowed if:
    • On bullet and numbered lists, if they are closely related to the article contents.
    • On table headers and cells, if they are related to the article contents.
    • On article prose, if they are closely related to the article contents.
    • On "History" sections, if they are closely related to the article contents.
    • On "See also" sections, they can be more flexible, but still need to be related.
These are just my comments and proposals, and I say this from what I see on pages like Minecraft Dungeons:Mission Select or Ore, though these are just my thoughts. Anyone is free to give more comments. Supeika (talk) 22:47, 18 July 2022 (UTC)
 Comment Thanks for the response. I agree with you on most everything you said. My main concern is mostly on the prose because I think especially on the Dungeons pages, folks have gone full-in on the icon+link template. Even the Mission Select page you mention has probably more icons than it necessary. It would be good to at least limit it much like we do for links, or at least focus on ones that convey info perhaps more quickly than text, such as 50 or 600♥ × 300. Super curious what others think. - AD OffKilter (talk) 02:24, 19 July 2022 (UTC)
 Oppose including icons in prose, except perhaps at the beginning of a sentence. I  Support including icons at the beginning of lists, and in table headers and cells provided that the icon doesn't appear in the middle of a line. I have been removing what I call "icon pollution" from prose and history sections also; it's been a particular problem in Minecraft Dungeons articles. Amatulic (talk) 17:34, 22 July 2022 (UTC)
 Comment Does that include the two I show above for xp and health? I find them quicker to grok than the words. I know it's a bit of an inconsistent rule if so, but ¯\_(ツ)_/¯ - AD OffKilter (talk) 18:34, 22 July 2022 (UTC)
I'm fine with XP and health. While it does interrupt the flow of prose, that negative is neutralized by the usefulness of seeing the heart graph icons. Amatulic (talk) 20:59, 22 July 2022 (UTC)
 Comment Just as a comment, I don't oppose icons in prose because it helps with accessibility if used properly, such as very specific linking cases or the XP and health usages, where using them can give a faster visual interpretation. Remember that this is a wiki for a game, and having visual indicators help readers to understand the context of the text. Supeika (talk) 20:38, 22 July 2022 (UTC)
I have no objection to icons for visual quantity indications such as health. Otherwise they are simply unnecessary in prose. Amatulic (talk) 20:59, 22 July 2022 (UTC)

Capitalization tweak[]

I propose a couple of small changes to the guidance of capitalization on mob names to avoid some confusion I've seen due to ambiguity. My proposed changes are in boldface:

  • Any instance of a mob (including mini-boss mobs) should be treated as a common noun, except where the mob is referred to using a proper noun. If the word "the" is used before the mob name, it should not be capitalized unless it is at the beginning of the sentence. If the mob name includes a world name in isolation, the world name should be capitalized.
    Examples to add might be "watcher of the End", "End crystal", and "Nether portal", but not "netherrack", "enderman", or "eye of ender". The word "ender" may need some additional discussion, however.
  • Remove ancient mobs and primary boss mobs from the exceptions. Currently these exceptions are listed under Minecraft Wiki:Style guide § Do capitalize in the "Minecraft Dungeons" subsection. I propose this because I've noticed that singling out some classes of Minecraft Dungeons mobs has resulted in confusion among editors. All mobs should be treated the same. If a mob is a proper name (like "Archie") it would still be capitalized. Mobs encountered once in the game (like ender dragon) would remain lowercase.

Any objections? The existing guidance was added by me after no one objected to my proposal last year, but based on what I've seen since then, I think these tweaks are needed. Amatulic (talk) 17:54, 22 July 2022 (UTC)

 Strong support for both proposed changes.BDJP (t|c) 18:38, 22 July 2022 (UTC)
 Support – the first change is actually something I've been wanting to propose for a while as I frequently see confusion over it and I believe the capitalized versions to be grammatically correct; though it should be put in a more general area as it affects more than just mobs. I also thought that "Netherrack", "Enderman" and "eye of Ender" should also be capitalized to match real-world examples like "Dutchman", though I can't think of other examples. –Sonicwave talk 20:30, 22 July 2022 (UTC)
Good point about Dutchman being analogous to capitalized Enderman. Extending that analogy, I think nonliving entities that include a place name shouldn't be capitalized; for example, "netherrack" would be more analogous to "chinaware", not capitalized. Amatulic (talk) 20:49, 22 July 2022 (UTC)
 OpposeIn Minecraft Dungeons, there is only one of each boss and ancient mob. I know that it could be argued that there are more than one of each boss mob since you can replay missions, but there is only one of them in the game. It would be like saying that the Arch-Illager or the Nameless One are not proper nouns because they can be fought more than once by replaying missions. The same exact thing applies to ancient hunts. From a lore perspective, ancient mobs are clearly proper nouns, but from a gameplay perspective, they are just as numerous as any other mini-boss mob. Due to viewing the boss mobs of Dungeons from a lore perspective, we should keep the same perspective with ancient mobs. Also, in the original Minecraft game, the Ender dragon, wither, and warden are not actually singular mobs. The Ender dragon is not even named in game. Withers are not singular mobs since they are constructed like iron and snow golems. Finally, wardens are really powerful mobs, but are not individual characters. In Minecraft Dungeons, all of the bosses, npcs, and ancient mobs are individual characters in their own right. There are no two of the same NPC in the game. The bosses are only able to be fought more than once because missions can be replayed. The same goes for ancient mobs since they can only be fought more than once because ancient hunts can be played more than once. The missions should all be capitalized since they are the name of levels in the game, not necessarily locations. The only exception I think there could be should apply to the Tower, as many of the game’s previous bosses can be fought in it. The bosses that are fought within the Tower should be lowercase. Drour1234 (talk), 22 July 2022 (UTC)
I can understand your rationale, but I am not seeing any reason to go against existing precedent. You're saying the ender dragon has no lore? And that it isn't a singular mob? It certainly is, and isn't capitalized. You can contrive to fight it twice, just as you can contrive to fight any of the MCD bosses twice. Some ancient mobs and bosses have names that lend themselves well to usage as a proper noun (such as "the Nameless One" and "Arch-Illager", one being a singular name and one being a title). Others don't, like the "monstrosity" mobs. Not capitalizing them, while leaving the obvious proper nouns capitalized, would not create exceptions to existing guidance. Amatulic (talk) 02:51, 23 July 2022 (UTC)
 Question In all of this, items such as "The Beginning and the End" are named uniques. What is our stance on them? In my mind these are named items as should be treated as proper nouns, like Excalibur. Is that the case? - AD OffKilter (talk) 03:42, 23 July 2022 (UTC)
We've been treating uniques in MCD as common nouns. They all have names but they use common words. I proposed capitalizing uniques before, but that isn't what editors were doing with them for the most part, so we're treating them as common nouns. Amatulic (talk) 04:39, 23 July 2022 (UTC)
 Comment These rules are a bit confusing (to me, at least). I just noticed we are diverging from what the game itself does with some of the rules above. We say to use "eyes of ender", but the game says "Eyes of Ender" in their messages to users. See Minecraft_Dungeons:The_Stronghold for an example of quotes from the game iself. - AD OffKilter (talk) 17:03, 23 July 2022 (UTC)
The game capitalizes everything regardless of what it is: Block of Coal, Poppy, Dirt, Iron Ingot, Zombie Villager, etc. So do the developers when they tweet about game features, and we retain their caps when quoting them.
However, when writing prose, the style guide is a reminder to follow accepted English writing rules. The purpose of this discussion is to gain a consensus on making the guideline more consistent. The first proposal to capitalize world names when included in mob names seems to have consensus, but the second proposal about not making exceptions for Minecraft Dungeons seems to be what we're debating at the moment. Certain mobs in MCD can be treated as proper nouns. Names of the form "X of Y" like "Eye of Ender" might be one of them. Amatulic (talk) 17:51, 23 July 2022 (UTC)
 Support both changes. TheGreatSpring (talk | contribs) 21:50, 29 July 2022 (UTC)
I do think that uniques should be proper nouns since many of them seem to be proper nouns with a few exceptions. I do not mind not capitalizing them, but they should be considered as singular rather than plural. Many pages treated uniques as plural yet it looks so weird sometimes.Drour1234 (talk) 12:45, 7 September 2022 (UTC)
I have changed my mind on this proposal.
I now  Oppose the first change. Item/block/structure/mob names with "nether" or "end" in their name should remain lowercase, with no exceptions (excluding the usual sentence rationale; e.g. "nether portal" or "ender dragon"). The dimension name mentioned by itself should remain capitalized.
I still  Support the second proposal that ancient mobs and primary boss mobs from MCD should not retain their capitalization. It doesn’t matter as to whether there is one or many, and we shouldn’t treat these from a lore perspective. BDJP (t|c) 05:58, 11 November 2022 (UTC)
It is not clear to me why you oppose the first point. To me, it feels odd to say "I endered the End through the end portal." It feels more consistent to always capitalize the name of the dimension, or never capitalize it. So my basis for wanting to let the dimension name have precedence is exactly that: consistency. - AD OffKilter (talk) 06:07, 11 November 2022 (UTC)
 Support the first change, it's proper grammar to capitalise proper nouns even when they're part of a compound.
 Oppose the second proposal since ancient and primary boss mobs are singular mobs and as such they're proper names that should be capitalised. Pescavelho (talk) 19:43, 20 November 2022 (UTC)

Regarding Headings (and things that look like headings)[]

I just had an edit reverted here where I removed a link from what visually looks like a heading. While I can understand that headings might literally always use the equals signs, the bolded heading-like thing still _reads_ like a heading, so I am questioning whether the rule is meant to be the word of the law vs the spirit of the law, so to speak. And if the former, can someone explain why we need to do it there and not in a situation where it looks almost identical to the reader? Is it anchor-related? Something else? If we do really believe the non-heading thing is not part of the rule, it might be worth calling that out in the guide so people like me don't make mistakes, as I had assumed it was due to readability, etc. Thanks! - AD OffKilter (talk) 15:21, 11 August 2022 (UTC)

If you're referring to the heading that start with a semicolon, as in
;Sample heading
those are converted to standard HTML boldface text that doesn't have a heading tag. This wiki has been rampant about including links in those, especially for articles about new releases (see Caves & Cliffs for example). The headings with equal signs in wiki-markup are converted to actual HTML headings.
Wrapping an actual heading (one that uses the <h2> or <h3> HTML tag) inside a link is just bad web page design practice. Amatulic (talk) 01:20, 16 September 2022 (UTC)

Italicize "Minecraft: Bedrock Edition"[]

See the following from the style guide:

Official Minecraft edition names used as subtitles, such as "Java Edition" and "Education Edition" should be in italics; other edition names, such as "Bedrock Edition" and "Legacy Console Edition", should not.

Style guide

However, as June 7th, 2022, "Bedrock" is used officially as a title for the Minecraft: Java & Bedrock bundle. As this is now an official edition name used as a subtitle, it should be changed to have Bedrock Edition also be italicized. -IllagerCaptain (talk | contribs | website) 22:11, 13 August 2022 (UTC)

I think if we were going to put that specific bundle name in the wiki, then sure, it might be in italic, but there is still no title called "Bedrock Edition" anywhere that I can find. My Windows launcher just says "Minecraft". So I don't know that it's appropriate for us to put it in italic unless it's in the real title of the product (at least, that's been my interpretation of the rule) - AD OffKilter (talk) 22:52, 13 August 2022 (UTC)
I agree. The specific title Minecraft: Java & Bedrock may be official, but I don't see anything suggesting that "Bedrock Edition" is an official title. That may change in the future, but for now it's too soon to make this change. Amatulic (talk) 20:51, 15 August 2022 (UTC)

Structures that have dimension names[]

Two rules seem to be at odds with one another. On one hand you have a rule stating that the names of dimensions are to be capitalized. So we get Nether, End, etc. But the names of structures are to be lowercased, so desert pyramid, jungle temple, etc. I'm on board with all of that. However, when it's a structure that has the name of the dimension, I feel it is more correct to type Nether fortress, or End city. What do others think about this? - AD OffKilter (talk) 20:22, 6 September 2022 (UTC)

There's some discussion about this in the section #Capitalization tweak above. I agree, a dimension that is part of the name should be capitalized. There is no contradiction in the rules. Structures are lowercase unless they include a proper noun, so in "Nether fortress", "Nether" is a proper noun while "fortress" is a lowercase common noun.
We get some ambiguity when the dimension name is mashed into another name, such as netherrack and enderman. My position is that these should be lowercase, although it's ambiguous in normal English too; for example "Dutchman" (uppercase) and "chinaware" (lowercase), as analogous to enderman and netherrack. The distinction may be whether it's about a living entity or just a material or object. Amatulic (talk) 17:33, 16 September 2022 (UTC)
Thanks. Yes, I saw the mention above but wanted to call it out here explicitly for extra clarity. I agree that names with the dimension combined should probably remain lowercase at least for the time being as it gets more fuzzy as your examples show. I may start to adjust case in some places based on this discussion. - AD OffKilter (talk) 20:44, 16 September 2022 (UTC)
In light of all this, can we perhaps codify this in the guide to show examples? "an End city", but "an ender chest", etc.? It would resolve disputes easily if we can point to the examples. - AD OffKilter (talk) 15:11, 19 September 2022 (UTC)

Change heading level[]

Can I change the heading level of the "Do not capitalize" and "Do capitalize" sections? Because they are under the "Capitalization" section. Windwend (talk) 19:10, 25 November 2022 (UTC)

I did it, thank you for repoting it. You are free to make these fixes because they are format changes and not content changes, :D --Supeika (talk) 00:33, 26 November 2022 (UTC)

Treatment of numbers[]

I find things like number of drops with some inconsistencies. Cow for example has "1 to 3 raw beef", but also "1–3 experience orbs". Zombie says "two rotten flesh", but later "maximum drop is increased by 1 per level of Looting". Other examples can be found by looking at other mob pages. This also applies with things like statistics and the currently being discussed coordinate system. Wikipedia's style guide has its own recommendations on numbers, but I don't mind having a special case in this wiki. The point is that should we have a section dealing with numbers? ManyOursOfFun (talk) 17:37, 6 April 2023 (UTC)

Article titles: name changes[]

At time of writing, a the name of pottery shards have been changed to pottery sherds in the latest Java snapshot. According to the style guide, the name should be changed to the Java name. Nevertheless, pottery shards are already present in a Bedrock release version under a different name. I  Suggest and  Support adding the following rule to MCW:TITLE, overriding the "If the feature has different names in Java and Bedrock Edition, the Java Edition name should be used." rule:

  • If the feature has different names in release and development versions, then the release name should be used, regardless of the edition.

I believe will make naming clearer, even if it's a name change on both editions in a development version. --MetalManiacMc, French Minecraft Wiki Administrator 06:32, 22 April 2023 (UTC)

 Support. I think that's the guideline we've been following in the past but it'd be nice to codify it here. –Sonicwave talk 18:01, 29 April 2023 (UTC)
 Weak Support It is a clarification, so that's a needed thing. However, I'd like to have the names changed before the release (likely during RCs), so we won't be doing mess during the release (that may greatly hurt SEO of these pages). Additionally, since I don't want to have a mess renaming stuff back to "Shard" (as now everything but page is "Pottery Sherd" already), it should be in-effect beginning on 1.20's release date.
So my rule would be:
  • If the feature has different names in release and development versions, then the release name should be used, regardless of the edition.
    • The development version name may be used once the feature with a new name is in the version which is currently in the "Release Candidate" stage of development.
--TreeIsLife (talk) 18:50, 29 April 2023 (UTC)
 Support This seems perfectly fair to me, we are going to need time to change things around. --MetalManiacMc, French Minecraft Wiki Administrator 08:09, 30 April 2023 (UTC)
As a point of fact, that "rule" (that if a feature has different names, the Java name should be used to title the article) was added with no consensus discussion, and is a violation of the overriding principle that preference should not be given to one version over another. Unfortunately, when I tried to revert it, it caused a big stink so everybody just left it in there. I suppose you could argue that the fact that it hasn't been changed since then amounts to an implicit consensus, but it still violates the principle and in my opinion it shouldn't stand. And besides that, if it were actually discussed I'm convinced it would be revised. — Auldrick (talk · contribs) 13:43, 27 August 2023 (UTC)
Auldrick, the only guy who raised a big stink, as I recall, was the guy who unilaterally made up that rule out of thin air, and he is no longer here. I think we should revisit this, or simply remove that rule and discuss it as should have been done prior to adding it earlier. Bedrock Edition has the larger installed user base, more people coming to this wiki are likely to be Bedrock Edition users, so it makes sense that article titles be biased toward Bedrock when there is a difference between editions. Amatulic (talk) 16:37, 28 August 2023 (UTC)
I think more rephrasing could be made to this statement. What about this one:
  • If the feature has different names across editions, the latest release (candidate) version should be used regardless of edition.
    • If a rename of an existing or newly added feature occurred in one edition, the new version of the name should be used once said edition makes a full release, regardless of other editions.
Since after a renaming occurred in an edition, it's safe to assume all other editions will be following said change afterwards. - Jack McKalling (talk) 14:15, 27 August 2023 (UTC)
As I stated earlier, preference should be given to Bedrock due to the larger size of that audience. Amatulic (talk) 16:37, 28 August 2023 (UTC)
 Support BDJP (t|c) 16:53, 28 August 2023 (UTC)
 Strong oppose. The naming convention proposed would bias heavily toward Java Edition because those releases typically occur first. Our convention to name things based on Java edition was a rule added unilaterally to the style guide by one admin (no longer here) with zero discussion a few years ago, as Auldrick pointed out above. Recent data is hard to come by, but the last time I looked into it, Bedrock Edition has the larger installed user base, therefore the larger audience of this wiki would be Bedrock players who would expect articles to be written more from a Bedrock Edition perspective. Amatulic (talk) 01:18, 29 August 2023 (UTC)
 Oppose Jack, I don't think you can make that assumption. You might not know this, but there's a gray area around names. For example, Java changed lots of biome names in 1.13 and even more in 1.18, but it's not really clear that Bedrock ever renamed any biomes because it doesn't display their names anywhere in-game and the Bedrock devs, when they refer to them, use old and new names inconsistently, as do long-time Bedrock players. To the extent that there's any hard evidence at all of "official" Bedrock biome names, it's the JSON files used to customize add-ons, and those still use the original biome names ported from Java 1.7.2. Another example of a gray area is Monster Spawner, which Java 1.13 renamed (for some reason) to Spawner. Surprisingly, given the legacy-driven bias toward Java here, the article is still named Monster Spawner, and six years later there's no sign that Bedrock intends to rename it. There are a number of other examples, not all of them name changes. Such as the bug tracker vanilla-parity reports that get denied as invalid. (For those who might not know, Jack and I are on the Mojira staff.)
Amatulic, I  Oppose your suggestion as well. I think it's reasonable and I might agree if the wiki were just starting out, but not now when it would require actively taking away a privilege Java players have long enjoyed and giving it to someone else. That would just be a slap in the face. It was Java players who created most of the articles, after all, and they deserve more respect than that. As Bedrock players, we have the right to give pride of place to our preferred edition when writing new text or making a major revision, so we have the means to assert our equality in a civil way; I can settle for that. The last thing we need is to ignite endless controversies (read: edit wars) over what are essentially petty differences. Oh BTW, larger user base doesn't necessarily translate to a larger wiki audience; it could just as well mean it's easier for Bedrock players to find other players with the answers they need. (I heard recently that many younger players don't even know the wiki exists, though I can't vouch for the claim.) — Auldrick (talk · contribs) 05:31, 29 August 2023 (UTC)
(lol we so often seem to end up on opposite ends of arguments) Regarding the biome names. I know a lot were changed and that Bedrock didn't follow. But what's the case in this example is that those biome names don't actually show up in the Bedrock game, and the style guide sentence this discussion is about, sets the premise that the name differs "between editions", which here implies it would need to show up in game. So I guess the rule just doesn't cover json files. That's covered by the next bullet point in the list (which might need a similar rephrasing). So in my honest opinion your opposing argument against my suggestion in case of biome names I think doesn't apply. In the case of the Monster Spawner, that in-game rename in Java edition has been reverted and so the wiki page title is now reflecting both editions with "Monster Spawner", so there you have no argument anymore either (no offence). I don't know what you're saying about vanilla parity reports getting closed as invalid though, without examples. But anyway, I'm suggesting above that the latest release be used for the in-game name regardless of edition, which means no edition gets favoured at all since they could override each other this way. If a situation occurs where the game reverts a name, we'll just have to follow and see what happens, I don't think we can generalize all situations or need to specify how to handle them, other than what I suggested to follow the latest released changes of whatever edition comes last. - Jack McKalling (talk) 10:12, 31 August 2023 (UTC)
I wasn't making any arguments about how biome articles or Monster Spawner should be named: Those were just examples of why your reasoning "it's safe to assume all other editions will be following said change afterwards" is on shaky ground. I will admit, though, that having slithered down the rabbit hole to find examples, I lost track of the fact that your proposal wasn't necessarily dependent on that reasoning. In fact, after reconsideration I've revoked my opposition, but I'm withholding my support to make the following countersuggestion. — Auldrick (talk · contribs) 18:13, 31 August 2023 (UTC)
Countersuggestion:
  • If an existing feature is renamed in a full release of some but not all editions, the new name should be used to create a redirect page to the existing article. Once all editions have renamed the feature, the redirect page should be deleted and the article moved to the new name, leaving redirects from the old names.
This rule would avoid controversy by not favoring any edition; it simply persists a choice that was made before any controversy existed. It's essentially the same protocol we used in Minecraft_Wiki:Projects/Renaming: Avoid controversy by retaining pre-controvery choices. Until now, this protocol has resulted in giving Java more prestige and Bedrock being shoehorned in as an afterthought, because most articles were originally written for Java Edition. But we haven't been observing this egalitarian principle in how we handle renamed features, and Java has gained even more prominence as a result. What I'm suggesting would extend the principle a little more broadly, and if that means some Java players end up on a page with an unexpected title, well, that's fair isn't it? Bedrock players have been enduring these quirks for years now, and still will if Bedrock renames a feature first, so there's no favoritism toward one edition over another. — Auldrick (talk · contribs) 18:13, 31 August 2023 (UTC)
Is this a full replace of both my bullet points, or just my second? Because I was under the assumption we need to differentiate situations where something had been renamed, versus simply start out with different names across editions. Or is that also considered a "rename"? - Jack McKalling (talk) 19:29, 31 August 2023 (UTC)
I was only thinking of it in terms of future renames, since applying the rule retroactively would itself be controversial. So it would replace both your points, but perhaps the wording should be revised to make it clearly non-retroactive. — Auldrick (talk · contribs) 12:01, 13 September 2023 (UTC)

Style guide for Blueprints[]

Blueprints have a well-established format. However, there have been a few attempts to discuss changes to the format and there wasn't a response in the blueprints talk page. Documenting the blueprint style guide more explicitly may allow discussion to flow more readily, or at least ensure that the discussion is highly visible. Further, there isn't a 'root' blueprint page, as they are all included in the Village/Structures article. A draft Minecraft_Wiki:Style_guide/Village/Structure/Blueprints article has been created for consideration. --Limestonebuilder (talk) 03:12, 3 May 2023 (UTC)

Adding an exception to one of the rules outlined in MCW:IMAGES[]

Recently, an image showcasing a missing Java Edition version was deleted due to the screenshot using a resource pack which changed a cow's appearance. Although MCW:IMAGES outlines this to be a valid deletion, it was generally agreed up via discord that the deletion should be undone. It was undone, however later (today, August 14) the image was deleted again, along with a large amount of other screenshots of missing Java Edition versions, all for the same reason (resource packs). Bear in mind that consensus about the situation had not shifted and no further discussion was had before these deletions happened again. This situation is the reason for my proposal.

Why should these images be an exception? Due their nature as screenshots of missing versions, a limited number of them exist, and therefore they should preserved. We already agree on the importance of their preservation, as we have an entire page dedicated to keeping these screenshots. The rule that disallows images using resource packs should not be so strict that it allows the deletion of these scarce images, their existence does not negatively impact the wiki, and their deletion does nothing but remove information.

My proposal is that an exception is made to the resource pack rule, this exception would simply include images that are too significant to delete, which includes (but should not be limited to) screenshots of missing versions. However, it should be made clear that the image is using a resource pack, for example: the image with a retextured cow would have its gallery caption make it clear that the cow has been retextured using a resource pack.

I say that the exception "should not be limited to screenshots of missing versions" in case there is consensus for this exception to apply to other types of images and not just missing version screenshots. However, my proposal is largely about the missing versions screenshots. -  Harristic | Talk | Contributions 22:20, 14 August 2023 (UTC)

 Strong oppose. This is simply a last-ditch effort to change the rules around before the wiki is ultimately forked. If at all, the rule as is should remain in place and all further discussion should occur on the forked wiki.
In regards to the images themselves, there is simply no need for them regardless of supposed significance. The articles which had the screenshots in question also already have screenshots that do not have any texture changes or modified content. BDJP (t|c) 22:32, 14 August 2023 (UTC)
I find it incredibly strange that you would wait until right before the fork to enforce these deletions that we agreed should not happen, and then accuse me of a "last-ditch effort rule change" when I choose to respond quickly instead of letting it happen and waiting.
Multiple versions have over ten images for them, these are not necessarily needed and we would never have this many screenshots for regular versions, but these types of images are obviously the exception. They can be the exception in this case as well. Quite frankly, the images having resource packs is utterly insignificant and not deserving of a deletion. -  Harristic | Talk | Contributions 22:51, 14 August 2023 (UTC)
The images having resource packs is of significance because its pretty obvious that the textures are not vanilla whatsoever. I stand my ground in that there should be no exceptions to this rule. BDJP (t|c) 07:55, 15 August 2023 (UTC)
What does forking have to do with anything? Does that mean we all have to stop contributing until it's forked? Would it be any different if we started communicating later? We should have started discussion earlier if anything. In fact it should have been considered before going against precedence and intentionally removing information by strict adherence to a rule made years ago that was intended for different circumstances. They didn't know the stuff we know now. To me this just seems like bureaucracy to a fault. I can name one individual who got so fed up with the rigid environment that he quit for good. That shouldn't have happened. The wiki just gets worse if we prioritize rules over people. – Unavailablehoax (talk) 07:29, 15 August 2023 (UTC)
and the rule in question should still apply as is today, but it seems no one here gets that. BDJP (t|c) 07:55, 15 August 2023 (UTC)
Hey, I've just read how you've decided to continue editing for Fandom. You can continue to represent the least representative and for profit monopoly. But please don't start acting like the rest of us are lower than you while we're still here. Though, I know that's not what you want. Something tells me you want to take this wiki as your own. To that I have only one thing to say: you no longer align with the wider MCW community. But I think you already knew that. If you go through with your decision, good luck. – Unavailablehoax (talk) 08:20, 15 August 2023 (UTC)
Please don't turn this into a personal attack like you're doing right now. wp:Assume good faith and that BDJP wants what's best for our wiki. I think both parties here have provided good arguments, so there is room for middle ground. And to be frank, I think BDJP is already looking for one by trying to replace said images with ones that do use original textures. I think the focus should be on cooperating, rather than antagonizing each other. - Jack McKalling (talk) 09:21, 15 August 2023 (UTC)
 Support Saving images with historical significance, especially images that are one of a kind and cannot be duplicated or re-mde (in the image that sparked this debate, of a missing version). I've said before on discord that having a special library or place to put these images (sorted so random ones don't get in there, ofc) is probably better solution. There is a certain obligation by a wiki to document it's game in full, and thats what should be done here.
And as for the notion of this just being a way to cause chaos and change random rules before the fork, it's absolutely not. This was started by a user with some frustration after a page had been deleted, restored and then deleted again and this is a proposal to amend the rules so it doesn't happen again, and clear guidelines can be set. IiConsumed (talk) 22:46, 14 August 2023 (UTC)
There is also a certain obligation by the wiki to make sure that images are in conformance with the current style guide, of which the images in question obviously weren’t. BDJP (t|c) 07:55, 15 August 2023 (UTC)
 Support Agree with Harristic and iiConsumed, I just see absolutely no benefit in deleting screenshots of lost versions, even if they use custom textures.--Capopanzo (talk) 23:30, 14 August 2023 (UTC)
The benefit in this case is simply put: conformance with the current style guide. BDJP (t|c) 07:55, 15 August 2023 (UTC)
The current style guide can be adjusted at any time, especially if there is strong support from multiple editors.--Capopanzo (talk) 15:34, 15 August 2023 (UTC)
Obviously any change to the style guide means the new rules will not be in conformance with the previous version of the style guide. The style guide was not written with the intention that it never be altered. -  Harristic | Talk | Contributions 19:30, 15 August 2023 (UTC)
 Support While less official than the style guide, the screenshot fixing project clearly shows an intention that exceptions be made for images with a reasonable explanation. The images in question are of enough historical significance that they could be considered worth keeping, and I see no harm in doing so. The rule to remove images with resource packs was never meant to gatekeep certain images from existing on wiki, but to prevent confusion from readers looking to learn about the game. Marking these images as non-vanilla is an important part of maintaining clarity, but removing them entirely goes against the wiki's goal of preserving and presenting information. Ishbosheth (talk) 00:17, 15 August 2023 (UTC)
The screenshot fixing project is completely separate from what is being discussed. I do see harm in keeping the images as they would not be in conformance with the current style guide. BDJP (t|c) 07:55, 15 August 2023 (UTC)
While the screenshot fixing project is separate from this discussion, it shows the attitude that editors have taken in the past in regards to issues like this. To your second point, I would also take issue with keeping the images if the style guide was not changed, but changing the style guide is what the content of this discussion is about. You seem to care very deeply about keeping the rules of the wiki, which I appreciate, but I have not seen much about why you believe the rules should not be changed. This is the process by which the style guide should be changed, is it not?
You say that the images in question are useless, but I would have to disagree. While yes one or two images are sufficient to prove the existence of a version, are not more images more helpful in providing more information about a version? Of course, the impact of a singular image decreases as the total number of screenshots of a particular subject increases (this is what allows us to be strict about the style of certain images and not others), but in the cases where images are not easily obtained (as is the case with missing versions) the impact of a singular image is fairly great. Why do you oppose changes to the style guide that would allow these kinds of images to be displayed on the wiki? Ishbosheth (talk) 20:30, 15 August 2023 (UTC)
The answer is simple. The images in question would not conform with other images that use vanilla textures. Having images that use a texture/resource pack combined with images that do not makes them feel out of place, so to speak. BDJP (t|c) 22:12, 15 August 2023 (UTC)
 Support In addition to these missing version screenshots, there's already a lot of images that don't fit the style guide requirements of not having UI or player builds, but are used on pages nonetheless without issue, because they are mojang screenshots from official developer sources. In these cases it is the origins of the image, rather than just the contents of the image, that are of importance. These original screenshots of versions you can't play anymore (at least until someone finds them on an old hard drive) are in a similar situation, where the image itself, and its source, is more important than its exact contents. There has generally been a consensus that both types of images belong on the wiki, and shouldn't get deleted or replaced on account of not fitting the criteria that editor-created screenshots are supposed to adhere to, because they're not editor-created screenshots, and their purpose doesn't require them to adhere to those criteria. The only dissent against this consensus so far has been the recent deletion of these particular images based on a justification that no one else seems to agree with. AlienAgent124 (talk) 04:00, 15 August 2023 (UTC)
and in some cases, like this one, it is the exact contents of the image that are of importance. The source shouldn’t matter, nor should the origins. I am currently planning on replacing the images with screenshots that conform with the current style guide. BDJP (t|c) 07:55, 15 August 2023 (UTC)
How do you intend on obtaining these new images? The crux of the issue seems to be that these images can't be replaced. At the very least the intention of this proposal would be to allow images that can't be replaced. Ishbosheth (talk) 20:30, 15 August 2023 (UTC)
 Strong support Some of these images are the only proof these versions ever existed. Why should they get removed? --TreeIsLife (talk) 07:12, 15 August 2023 (UTC)
and yet, listen to this, the articles that had the images deleted in question also have images that are in conformance with the current style guide. BDJP (t|c) 07:55, 15 August 2023 (UTC)
I don't know enough about the subject matter to give an opinion, although I do believe that this discussion came out of valid concerns. I'd just advise against ascribing ill intent to anyone's actions. That said, MCW:IMAGES is not a deletion policy (though it's sometimes been used as such), but guidelines for adding images to articles. With that in mind, I believe that we can afford some leeway in special situations; whether or not this applies here should be discussed as is being done now. If we want to codify it as a hard policy that does not take exceptions, then that deserves a separate discussion, since I don't believe that was the intent behind it and it's not obvious as it is. –Sonicwave talk 18:44, 15 August 2023 (UTC)
Kinda wish Majr was still here, because he probably would’ve explained why he added the style guide violation regarding images using non-vanilla textures to the list of deletion reasons in the first place. BDJP (t|c) 19:06, 15 August 2023 (UTC)

BDJP, when you deleted the images, they did not comply with the style guide and you could delete them, fine. But we wan't to change the rules so that they do conform with the style guide. You have not actually given a reason to oppose this change the guide besides, very literally, "The images do not conform to the style guide" , every single response..... The logic, "they don't conform to the rules right now so they cannot be changed", seems backwards and rediculous. Im also slightly confused that you immediately wen't to accuse of of sabotaging this wiki, I can only see this as helping, as does every one here. After the fork, if you and the remaining community decide to reverse this proposal, thats your prerogative. IiConsumed (talk) 20:01, 15 August 2023 (UTC)

Advertisement