Minecraft Wiki talk:Style guide

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). 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 standardizing volume this way. -PancakeIdentity (talk) 18:39, 22 April 2020 (UTC)


 * specifying X, Y, and Z, to avoid confusion. The BlobsPaper.png 18:42, 22 April 2020 (UTC)


 * writing coordinates capitalised as X, Y and Z for two reasons: firstly, this is how the coordinates are shown when the player presses 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, and  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)

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)
 * 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.png 05:03, 1 June 2020 (UTC)
 * 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)
 * 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)

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

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)


 * . 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)
 * . 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 (talk • contribs) at 19:37, 17 July 2020 (UTC). Please sign your posts with
 * . 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 </b>  20:11, 17 July 2020 (UTC)
 * . 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 (talk • contribs) 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.png 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. —  Babylon A S </b> 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? --  |  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 == * Minecraft on Wikipedia * [link Minecraft] on [link Codex Gamicus]

This section could be above the Notes, Media or References section. 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)
 * , 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 this proposal. Specifying this would make the plural usage less confusing. Thejoaqui777 (talk) 13:39, 18 March 2021 (UTC)
 * Changing the plural title rules, only pages about one specific thing should be singular, general pages like those above should be plural.  Nixinova </b>  T </b>  C </b></b>  19:07, 18 March 2021 (UTC)
 * 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.

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


 * . 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 23:49, 29 January 2021 (UTC)


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


 * : 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). Thejoaqui777 (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 . 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. Thejoaqui777 (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)


 * : "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 planned 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. Thejoaqui777 (talk) 20:55, 31 March 2021 (UTC)
 * 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 Thejoaqui777'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)

Amend the notability rule regarding minigames
As of now, per the style guide:

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:

BDJP (t 17:13, 2 February 2021 (UTC)
 * as nominator. BDJP (t 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)
 *  Nixinova </b>  T </b>  C </b></b>  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)


 * : 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 </b>  T </b>  C </b></b>  07:25, 3 February 2021 (UTC)
 * 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. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 03:28, 21 March 2021 (UTC)
 * 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 &middot; 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)

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
 * 2) Hatnotes
 * 3) Deletion / protection tags
 * 4) Maintenance tags
 * 5) Message boxes
 * 6) Infoboxes
 * 7) Navigation header templates (sidebar templates)
 * 8) Article content
 * 9) Lead section; introduction with general description
 * 10) Table of contents (usually automatically included)
 * 11) Article body
 * 12) Appendices and footers
 * 13) Sounds
 * 14) Data values (if applicable)
 * 15) ID
 * 16) Block data / item data
 * 17) Video (if present for illustration)
 * 18) History
 * 19) Issues
 * 20) See also
 * 21) Trivia (avoid or minimize if possible)
 * 22) Gallery
 * 23) Notes and/or references (capture all citations from above sections; this can be two sections)
 * 24) External links
 * 25) End matter
 * 26) Applicable footer templates / navboxes
 * 27) DEFAULTSORT
 * 28) Categories
 * 29) Stub templates
 * 30) 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 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)
 * 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 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. Thejoaqui777 (talk) 04:35, 12 March 2021 (UTC)
 * I need to say that stub templates are maintenance templates too, so the layout would need to be like this:
 * Before the article content
 * Hatnotes
 * Deletion / protection tags
 * Maintenance tags/Stub templates
 * Message boxes
 * Infoboxes
 * Navigation header templates (sidebar templates)
 * Article content
 * Lead section; introduction with general description
 * Table of contents (usually automatically included)
 * Article body
 * Appendices and footers
 * Achievements
 * Advancements
 * Sounds
 * Data values (if applicable)
 * ID
 * Metadata
 * Block states
 * Item data
 * Block data / entity data
 * Video (if present for illustration)
 * History
 * Issues
 * See also
 * Trivia (avoid or minimize if possible)
 * Gallery
 * Notes and/or references (capture all citations from above sections; this can be two sections)
 * External links
 * End matter
 * Applicable footer templates / navboxes
 * DEFAULTSORT
 * Categories
 * Interwikis
 * What do you think? Thejoaqui777 (talk) 18:32, 26 March 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)
 * You are right, I'll add them to my proposal. Thejoaqui777 (talk) 23:39, 26 March 2021 (UTC)

Not really keen on capitalization rules
<div class="boilerplate discussion-archived" style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * 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. . 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 &middot; contribs) 14:41, 19 March 2021 (UTC)
 * 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, including in article titles. The  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  (which could be used in a new template) for other instances of filenames. Fadyblok240 (talk) 21:06, 27 March 2021 (UTC)