Minecraft Wiki talk:Style guide

Future in history sections
Following up my previous topic, what about future changes in history sections? Does it make sense to add tweets of upcoming features before they get added, or would it be better to not state them incase it never gets added? – KnightMiner  · talk 21:17, 22 January 2015 (UTC)


 * . We shouldn't state future changes (like 1.9 things) in the history section. – LauraFi -  talk  21:31, 22 January 2015 (UTC)


 * I don't even really like tweets being in there at all, should just be version history. –Majr ᐸ Talk Contribs 02:54, 13 March 2015 (UTC)


 * I agree and disagree with that. On one hand, tweets and other relevant links are not part of its history, just because the idea was made public then does not mean it was any more than an idea. On the other hand, it is interesting to read how long went between the initial idea and the final change, and it moves the information from Mentioned features, rather than deleting it (overall though, it tends to just state features that were not added, rather than actual history of the item, so I would be fine with removing them). – KnightMiner  · (t) 22:27, 27 March 2015 (UTC)

Rewrite proposal
Following up and, I have proposed a rewrite to this page over at MCT:Community portal, which would include moving various rules to this page, and splitting out the article layout sections to allow more article layouts to be discussed. Please direct comments there. – KnightMiner  · talk 00:31, 10 February 2015 (UTC)

Following up
Following up that previous topic, there are four things I want to propose here.

First off, the style guide lacks information on formatting specific article titles, other than a few brief points in "Article titles and section headings". Also, the current style guide contractdicts standard policy when it comes to titles, and I doubt there will be agreement of making articles like "Stone Bricks" become "Stone bricks". A solution would be the addition of a new section called "Article titles", which is mostly general practice. If implemented, the section "Article titles and section headings" would become simply "Section headings"

Secondly, since the style guide now supports more article layouts, I would like to re-propose the versions style guide into the new system. You can read the proposed guide at User:KnightMiner/Workbench/Style guide/Versions

Third is something I noticed a lack of while rewriting the guide, which is guidelines relating to images for articles. Too many people think they need to upload all the screenshots they take because they relate to the article, when the image is really not needed. A few points I can think of are as follows, though I would advise more points to be added.
 * Articles should only have one image showcasing an individual attribute of the articles content. For example, a zombie wearing armor.
 * Do not add images whose sole purpose is showcasing a bug, instead report the issue on the bug tracker.
 * Images showcasing usage of specific features for decoration should be avoided.
 * Images should showcase the most up to date version of Minecraft available for the content.
 * Images that are outdated are subject to be removed.

Finally, we need to specifically state that language translations are unofficial, so they are not relevant trivia.

– KnightMiner  · (t) 17:38, 4 March 2015 (UTC)


 * So, yeah... I shall race to get Russian style guide up-to-date with English one as it becomes approved. :D
 * Offtop aside, . — NickTheRed37 t ⁄ c (f.k.a. Naista2002) 18:07, 4 March 2015 (UTC)
 * One more image point I thought of, based on the gallery on Villager:
 * Images should showcase an attribute of the articles topic.
 * Images should not show unintended strange or humorous behavior, such as mobs "sitting" on stairs.
 * The second point and maybe the third point from above could also become sub-points of this point.
 * – KnightMiner  · (t) 16:57, 7 March 2015 (UTC)
 * Also . Sorry for latency, it was due to Oversight policy/ru. —  NickTheRed37 t/c (f.k.a. Naista2002) 18:21, 7 March 2015 (UTC)


 * . –Majr ᐸ Talk Contribs 02:57, 13 March 2015 (UTC)


 * The changes proposed here have been implemented, as it has been just about a week since last revision to the proposal. – KnightMiner  · (t) 04:28, 14 March 2015 (UTC)

Article templates at the beginning
Isn’t the infobox→dablink→msgbox order looking weird? I think that infobox→msgbox→dablink is better (compare Zombie Pigman and Horse). —  NickTheRed37 t/c (f.k.a. Naista2002) 13:45, 9 March 2015 (UTC)


 * The reason I proposed that order was because I thought of dablinks as a subtitle to the title, rather than a header title to the content, thus that order made sense.
 * That being said though, I do agree it looks a little better on Horse, as keeping the text together seems to look better, although I generally do not like the look of combinations of dablinks and message boxes anyways – KnightMiner  · (t) 16:47, 9 March 2015 (UTC)
 * Thanks. LauraFi, JEC6789? —  NickTheRed37 t/c (f.k.a. Naista2002) 17:10, 9 March 2015 (UTC)

Redirects
The result of the discussion was added to the style guide.

Currently, redirects get created and deleted with no stated reason as to what belongs. I would like to propose the following section to be added either as a subsection of notability, or its own section/subpage (admittedly a little small for a sub page, though the wiki rules are not too big either.)

Redirects are exempt from the normal notability, but must redirect to an article that fits the notability guidelines. If a redirect leads to another wiki, it must use soft redirect.
 * 1) Alternate spelling of the title, such as "Armour" for "Armor".
 * 2) Incorrect spelling, typos, and irregular formatting are not allowed.
 * 3) Alternate or shortened name, provided the name is common usage, such as "Log" for "Wood". Previous in game names are also allowed.
 * 4) This includes first names or handles for Mojang employees, such as or "Nathan" or "Dinnerbone" for "Nathan Adams".
 * 5) This also includes names from alternate English language packs, with the exception of the joke language "Pirate Speak".
 * 6) Previous article title, including if the article was moved to another wiki
 * 7) An exception is if the previous title was not commonly used
 * 8) Alternate capitalization or form, including changing the title to plural case
 * 9) A part of a merged or multi-topic article, such as a potion or a mentioned feature.
 * 10) The parent version for pre-releases which became a pre-release for another version, such as "1.7" for "1.7.2", due to "1.7-pre" being a pre-release for "1.7.2".

Redirects in the user namespace may lead anywhere, except to an article that does not exist or another redirect.

– KnightMiner  · (t) 23:24, 23 March 2015 (UTC)


 * . – LauraFi -  talk  23:29, 23 March 2015 (UTC)


 * . Sounds good. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:03, 24 March 2015 (UTC)


 * . —「 JEC  6789  」talk • contribs 00:21, 24 March 2015 (UTC)
 * — NickTheRed37 t/c (f.k.a. Naista2002) 06:24, 24 March 2015 (UTC)

Notelists
First off, I'd like to add a section to the article layouts right above references called "Notes". The idea is to use that section to replace some of the HTML notes that may be relevant to the reader, rather than just the editor (for example, the reader might be interested in the formula used to calculate numbers, or for points where the scope is survival, so a command trick is left out).

Secondly, to go along with the first one, I would like to use consistent note groups for in section notes and global article notes, to avoid conflict, especially when a template uses either type. For those groups, we have two choices:


 * 1) My preferred method is using custom label, similarly to Wikipedia. I think in section notes could use "lower-alpha",[a][b][c][d] while global could use "upper-roman"[I][II][III][IV] or "upper-alpha"[A][B][C][D]
 * 2) * The actual group names can be set to anything (this is done using pages in the MediaWiki namespace, such as MediaWiki:Cite link label group-note for the group "note"), as the labels are attached to a group name, and the list style in the notelist is controlled by the template (with a bit of css), so I would simply go with "note" and "global"
 * 3) * Zombie pigmen spawn on the lowest level of nether portals<sup style="color:#0645ad">[A]
 * 4) Slightly less preferred is using specific note names, in which case common ones tend to be "note", "fn", and "n", although applicable might be be "n" for sectional and "gn" for global.
 * 5) A third option would be mixing the two, using only the "lower-alpha" group and letting global use something like "n", or vice-versa. This option might also be relevant considering how few articles use both lists.

– KnightMiner  · (t) 19:58, 27 March 2015 (UTC)


 * I like option 1, using upper-alpha not upper-roman (or any roman). But I'd like to have actual proposed text for what will go in the style guide before agreeing. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:50, 27 March 2015 (UTC)


 * Well, there would not be a whole lot to state, but here are the specific texts to add. Note that the specific group names can change.
 * Here is the section for the layout pages:

 Notes 

This section contains only global. If there are no notes, this section may be skipped.
 * While for the main style guide.

 Notes 

Articles should use  notes to contain information that is relevant to the reader, but does not fit well within the article content. If the information is only relevant to the editor, HTML notes should be used instead. Examples of relevant notes include the formula used to obtain a number state in an article, or behavioral differences when elements that are required in Survival are removed.

Notes should also be used for exceptions in the case of information stated in tables.

To keep names consistent, avoid conflict between groups, and apply the custom labels, notes within sections should use the group "note", while notes within article content should use the group "global".
 * – KnightMiner  · (t) 21:42, 27 March 2015 (UTC)
 * — NickTheRed37</b> t/c (f.k.a. Naista2002) 07:12, 28 March 2015 (UTC)

Achievements related to an article
What achievements are considered related to an article, thus making them belong on that article? Specifically, are achievements related to crafting in the 3x3 grid considered related to the crafting table? Likewise, are achievements that require smelting an item related to the furnace? – KnightMiner  · (t) 22:00, 14 April 2015 (UTC)


 * Seeing as the edit in question was reverted by, I would like to ask what is the specific description on what is not "related" so it can be stated on the style guide, both as a reference for reverting and for users to learn which are relevant. Currently, it seems achievements are not related if it requires using a block interface, but it is still in some cases related when using other things as tools, such as saddles. There is also the question of if mobs should state achievement related to their drops, as both cow and blaze do, despite not being required for the achievement. – KnightMiner  · (t) 20:07, 16 April 2015 (UTC)

Double space after references
I don’t see the point in having the double spacing after references. It appears as excessive spacing, which is the reason I’ve made [ this revert]. —  NickTheRed37</b> t/c (f.k.a. Naista2002) </i> 13:48, 24 April 2015 (UTC)


 * The reason is it better shows that the navboxes are not part of the article's content, but rather additional navigation links after the content. That being said, I find that it reads better to have the double linebreak. – KnightMiner  · (t) 15:12, 24 April 2015 (UTC)

Video notes
So, this is a minor thing, but I personally think it looks better to add notes about videos being incorrect or outdated using dablink, as seen on Resource pack. (which is still valid under the current guideline, as "Note:" is italic) Does anyone have any objections to that, or a preference for the current method? – KnightMiner  · (t) 04:09, 5 May 2015 (UTC)


 * dablink is for disambiguation notes only. &mdash; Grid Command Block.png NickTheRed37</b> (talk&#124;contributions) 05:50, 5 May 2015 (UTC)


 * Says who? The documentation simply says "usually for disambiguation purposes", and that formatting is not universally accepted to mean "disambig", but rather is a "hatnote", or any note at the top of an article or section. The Wikipedia version even specifically says "Often, but not always, this is a disambiguation link at the top of article pages.", and is title "hatnote" to prevent the assumption it must be a link. So unless you have something else against using it, I see no reason for you to oppose. – KnightMiner  · (t) 13:44, 5 May 2015 (UTC)


 * . – LauraFi -  talk  16:20, 5 May 2015 (UTC)


 * I've made a proposal to add a template for video notes on the community portal, which also has the advantage of adding categories for those notes. That template would standardize the formatting, so please direct later comments about formatting there. – KnightMiner  · (t) 16:14, 19 May 2015 (UTC)

Soft redirects
Apparently, redirects to other wikis don't actually redirect. Why are users supposed to use Soft redirect? 71.212.10.80 20:40, 2 June 2015 (UTC)


 * They work for me. Click the link to follow the redirect? – LauraFi -  talk  20:47, 2 June 2015 (UTC)
 * After editing a redirect, you won't be redirected. Only if you directly come to the page via a link, you'll be redirected. Soft redirects should for example be used if you have a userpage which redirects to a correspodent wiki (for example, let's say, the Dutch one), the unaware user suddenly is in another wiki in a language he probably doesn't know. Let's say the page "Feed the Beast" would lead to the main page of the Feed the Beast wiki. Many unaware wiki readers would be surprised then. That's why the template "soft redirect" exists. Normal redirect for internal links, soft redirect for external ones. | violine1101(Talk) 21:14, 2 June 2015 (UTC)
 * This is not the case actually. When a page redirects to a nonexistent page or a page on another wiki, readers will not be redirected; it resembles the interface for any redirect page not redirecting (like just after you create or edit a redirect). 71.212.10.80 01:39, 3 June 2015 (UTC)
 * Are you sure? A redirect works as long as the interwiki allows "forward links", which can be determined using Special:Interwiki. The interwiki you tested (wp) does not allow forward links. – KnightMiner  · (t) 03:09, 3 June 2015 (UTC)
 * I love how you selected a redirect page of a Russian wiki admin :) — Agent NickTheRed37 (talk) 13:32, 3 June 2015 (UTC)
 * No, I saw your red sandbox. Apparently, I missed something when I was using Minecraft wiki:Sandbox. 71.212.10.80 15:01, 3 June 2015 (UTC)

Quote template usage
recently made an edit changing the order of the infobox and the quote, and I noticed we have nothing about them in the template order information. I was wondering what are the opinions regarding the location of quote compared to the infobox, message boxes, or dablinks? In my opinion, it does not look bad with a longer quote, but shorter ones cause the same problem as message boxes where the infobox is pushed down with only an ugly whitespace above it. – KnightMiner  · (t) 14:36, 8 June 2015 (UTC)


 * Actually, message boxes are status boxes. They have more important information than infoboxes, so I would put them at the very top. Either way, quotes should be located before dablinks (if any). And GreenStone should be referred to as just GreenStone, not User GreenStone. — Agent NickTheRed37 (talk) 14:50, 8 June 2015 (UTC)


 * NickTheRed37, I did it for technical reasons which were stated in the edit summary (Also, don't tell other people how should they call me.)
 * I can reproduce the bug in my Alpha sandbox, but the bug is there only when the page is viewed directly rather that previewed. The quote also displays normally on diff and old revision pages... as well as if I remove the  rule from.
 * And I think that the order should be: 1) message boxes, 2) dablinks, 3) quotes and infoboxes. I would not have had a preference for placing quotes before infoboxed if not for the bug.
 * Also noting that on low resolutions even smaller quotes overlap with infoboxes. --GreenStone (talk) 15:10, 8 June 2015 (UTC)


 * I can only reproduce this bug in Opera; it works fine in Chrome, Firefox, and Safari. I don’t know if we should change the formatting of the wiki for everyone just to work around a browser-specific bug. — Orthotopetalk 16:20, 8 June 2015 (UTC)
 * And I can reproduce the bug in Firefox. --GreenStone (talk) 16:23, 8 June 2015 (UTC)


 * For some reason I did not think the overlap was a literal element overlap, just the elements were next to each other, as on chrome it looks fine... The issue with the overlaping is actually an opera/firebox adblock issue. Adblock only seems to remove the ad elements content, not its styles, causing the HTML to see a zero width element before seeing the infobox and allow 100% width for the quote expansion. It seems to be fixed fixed by adding the css  to MediaWiki:Common.css, which reduces the bottom margin just enough to let the quote see the infobox and adjust its width accordingly.
 * NickTheRed37@undefined Yes, message boxes should be at the top, but the infobox does not lower the content of a message box (causing it to still be at the top), but the message box will lower the infobox (causing ugly whitespace). – KnightMiner  · (t) 00:37, 9 June 2015 (UTC)

Page versions
Realatively recently, someone created 0.12.0, even though it is used to mean Pocket Edition. Would others agree that pages like this should be disapproved? 71.212.10.80 02:00, 12 June 2015 (UTC)


 * I see no reason to keep it. Why break from the title style just for the sake of what would become a misleading redirect?
 * Also, version nav relies on there being no pages at the same title under a different prefix. Should the page "Pocket Edition 0.12.0" be created in the future, it would claim 0.12.0 as the PC version of the same number. – KnightMiner  · (t) 02:11, 12 June 2015 (UTC)


 * My point is that not specifying the edition is generally used for the PC version, and this is not only true for the Minecraft wiki. We need to enforce this. 71.212.10.80 02:37, 12 June 2015 (UTC)

Better references
Recently on the articles Seecret Friday and 1.9, some better references were added which actually contain a bit about the reference (quote, date, etc), rather then just dropping a link in. This has the benefit of adding a bit of a quote to help manage sources (as no one is going to memorize the ID numbers), and it requires the user to visit less sites when they want to know what we are referencing.

What are the opinions on doing this for more articles and more types of links? – KnightMiner  · (t) 16:06, 15 June 2015 (UTC)


 * due to the fact that I just attempted to add a reference to 1.9 and its really hard to point out what is and what is not wiki text. BDJP (t 16:12, 15 June 2015 (UTC)
 * . Such references have their good and bad sides. Yes, this allows for more accurate references, but for some users it may get complicated. BDJP007301, I didn’t quite get your point; and also see Template:Comment/doc. — Agent NickTheRed37 (talk) 16:25, 15 June 2015 (UTC)
 * The problem with naked links is that links can go stale and expire. If there is other information in the reference, it makes it easier to find where the content has moved and fix the reference. I've tried to use full references in the redstone circuit articles where possible (for example). &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 18:10, 15 June 2015 (UTC)
 * . – LauraFi -  talk  18:18, 15 June 2015 (UTC)
 * because it would have the effect of keeping the user on the page, and making an editor's job easier due to easily seeing on-page how the references justify the text. At least with Twitter. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 18:24, 15 June 2015 (UTC)
 * –Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 00:38, 28 November 2015 (UTC)

Expand obtaining to allow creative/commands in select cases
The obtaining section could really use a bit more information on the exceptions to the "only state survival methods" rule, since on some mobs like the giant, and on some blocks like the barrier, it is important to state commands work. Also, on mobs such as the ender dragon and with items such as mushroom blocks, it is worth stating that they cannot be obtained or spawned using just creative. I would like to add something like the following text:

This section should may only state information on using creative mode or commands to obtain the block or item or to spawn the mob if one of the following is met:
 * The block or item cannot be obtained in creative or with commands, or the mob cannot be spawned with a spawn egg. In this case, the exception may be stated.
 * This does not apply to non-mob entities.
 * The block, item, or entity cannot be obtained or spawned in Survival. In this case, the section may state if it can be obtained or spawned in Creative or using commands.

– KnightMiner  · (t) 23:45, 25 June 2015 (UTC)


 * . – LauraFi -  talk  00:09, 26 June 2015 (UTC)
 * as well. BDJP (t 01:21, 26 June 2015 (UTC)
 * also. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 02:08, 26 June 2015 (UTC)
 * –Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 03:49, 26 June 2015 (UTC)
 * . &mdash; Agent NickTheRed37 (talk) 07:02, 26 June 2015 (UTC)
 * – JEC</b><sup style='color:#FA0'>6789 talk•contribs 11:44, 26 June 2015 (UTC)

Gameplay mechanic page titles
According to 's comment in Minecraft Wiki talk:Community portal, this page recommends singular titles. However, singular titles imply that the page is more specific than it actually is (for example "Renewable resource" implies a specific renewable resource). Please state your opinion. The BlobsPaper.png 15:01, 27 August 2015 (UTC)


 * The community portal does have jurisdiction over the style guide, and we were already discussing an amendment to the style guide there in the discussion you linked, so there is really no need to start an additional discussion. Just propose your amendment on the already going discussion.
 * As for my opinion on this proposal, I don't think using the criteria of gameplay pages is a good idea, as there are a lot of pages in Category:Gameplay that don't need to be plural. Such as chest loot, damage, difficulty, experience, heads-up display, inventory, item durability, scoreboard, south-east rule, spawn, third person view, transportation, and zombie siege. = – KnightMiner  · (t) 15:15, 27 August 2015 (UTC)

Amend console edition from MCW:FUTURE
The result of the discussion was withdrawn by nominator.

In the midst of the recent slow edit war on Mob, I'm currently proposing that console edition be amend from MCW:FUTURE. The rule is currently stated as follows:

However, there is only one problem. Console Edition does not have development versions, whatsoever.

I'm not trying to push out this exception to all articles; just Mob in general. -BDJP (t 10:15, 19 October 2015 (UTC)


 * The reason the rule was added was because articles were getting flooded with "this might happen later" posts, and the easiest defining mark for things definitely being in the game (thus worth stating on articles) is them actually being in the game, plus it makes more sense to only describe features that currently exist on articles about current features.
 * The console edition's lack of development versions simply says it lacks a good enough source that those features are definitely being added, not that we need an alternative way to use upcoming. – KnightMiner  · (t) 14:22, 19 October 2015 (UTC)
 * If a version has no development versions, then only Mojang can play the pre version. Upcoming features belong on the version page. The BlobsPaper.png 21:00, 21 October 2015 (UTC)


 * Until a feature is actually in the game, we can't be sure it will be added, and thus it is speculation. If the console edition doesn't have development versions, then there's no way to be certain what will actually be in it until the version is released. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 10:07, 22 October 2015 (UTC)


 * per KnightMiner and Majr. – 107.207.65.250 – 11:55, 22 October 2015 (UTC)

Reboot
There is not a "lack of a good source" as Knight claimed. Did you look at the source I added for guardians coming to the console edition? Clearly, they only way we can be sure that a mob is "upcoming" is through images posted by 4J Studios' twitter account.

With that, I also propose changing the rule to something that allows console edition as such with this "new evidence".

Content added in future updates may be added to the article in the main content, provided the features are marked using upcoming and have appeared in development versions. If the update contains major changes to the article, then the content may be noted as a subsection of a main section, or as its own section called Upcoming. Upcoming features must be noted as well in the history section using the proper upcoming header.

Upon the release of the update, all content that is now outdated must either be moved to the history section or removed, and any usage of upcoming may be removed.

The Console Edition is exempt from this rule as the only evidence for upcoming features is through images posted by the twitter account for 4J Studios. -BDJP (t 12:25, 21 November 2015 (UTC)


 * Yes, there is a source that it is upcoming, though the thing is such sources also exist for the PC edition and were the exact thing the original discussion was having issues with. It was determined that the best way to determine if something should be marked as going to be in the game is it actually being in the game, thus articles about game content were limited to actual game content (whether dev versions or full releases). As an example, what is to stop 4J from deciding guardians should wait a few updates to be released along side another feature, such as if they don't finish ocean monuments soon enough?
 * The other issue is if we make an exception for the console edition, why are equal or greater sources for the PC or pocket edition not allowed? It just adds an inconsistency with our sources so we can have a single table say "upcoming" under the console edition.
 * We already have several articles about planned and mentioned features, why does mob have to cover the tweets as well? – KnightMiner  · (t) 15:11, 21 November 2015 (UTC)


 * Mob will have to cover the tweets for the new rule that I'm proposing. Also:
 * You just disproved your own statement.
 * That's the reason why I'm making this exception...
 * I said nothing about sources for PC or PE, so why bring that up? -BDJP (t 05:04, 27 November 2015 (UTC)
 * That's the reason why I'm making this exception...
 * I said nothing about sources for PC or PE, so why bring that up? -BDJP (t 05:04, 27 November 2015 (UTC)
 * I said nothing about sources for PC or PE, so why bring that up? -BDJP (t 05:04, 27 November 2015 (UTC)


 * Firstly, my point is Mob does not need to and shouldn't cover tweets. You new rule may change that, but that does not make me change my stance on whether they actually are needed there.
 * Secondly, I did not disprove my own statement. My earlier statement said there was "not a good enough source", there still is a source, it just is not a unique enough type of source to isolate for CE. So while you did not mention PC or PE, the fact that in the proposal we would allow such sources on console but not the exact same type of source on PC or PE is just an unneeded inconsistency. The source is not made more valid by the lack of dev versions, if anything it would just be made less valid.
 * Lastly, I understand you want to make an exception, by my point is an exception is not needed and the previous discussion had the goal of removing such sources for all versions (I know that because I started the previous discussion). Dev versions are the only way we can know for certain that a feature will be in game, hence my earlier statement you did not reply to: "As an example, what is to stop 4J from deciding guardians should wait a few updates to be released along side another feature, such as if they don't finish ocean monuments soon enough?" – KnightMiner  · (t) 15:25, 27 November 2015 (UTC)

Minecraft developers
Since we use Minecraft developers as sources, and apparently not all Minecraft developers are with Mojang (though I believe it still fits under "closely related to"), can we specifically state that Minecraft developers are notable as well? – KnightMiner  · (t) 19:13, 24 December 2015 (UTC)


 * . – LauraFi -  talk  19:19, 24 December 2015 (UTC)


 * sigh... - Blame Wolf. Brainwashed me with this diff that I can't revert due to my "interaction ban". . -BDJP (t 19:45, 24 December 2015 (UTC)


 * If what you are trying to say is that you are confused, as Mojang is a subsidiary of Microsoft, the people who work for Mojang which is part of Microsoft are Mojang employees and the people who work for Microsoft and are currently working on Mojang products are Microsoft employees. Wolffillms (talk) 21:53, 24 December 2015 (UTC)


 * It would make much more sense to have Minecraft Microsoft workers on a Microsoft page rather than the Mojang page as the whole page is specificly about Mojang. Wolffillms (talk) 21:53, 24 December 2015 (UTC)


 * I said nothing about the Mojang article, that I agree should have developers either be separate or have something similar to the contract employees section. I am suggesting an amendment to the notability guidelines allowing the article Jason Major, as currently the article is only allowed under an interpretation of the guideline. – KnightMiner  · (t) 00:15, 25 December 2015 (UTC)


 * I do believe that there should be an article on Jason Major and a change in the rules to allow for this, however I do not believe he should be included on the Moajng article as he is not a Mojang employee. Wolffillms (talk) 14:29, 25 December 2015 (UTC)


 * , it makes sense to me to specifically include both employees of Mojang, AB and developers of Minecraft. –Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 0:31, 25 December 2015 (UTC). Please sign your posts with


 * . — Agent NickTheRed37 (talk) 14:37, 25 December 2015 (UTC)


 * Anyone who helps make Minecraft probably works with Mojang, even if they are part of Microsoft. Because of this, they would know what is going on, so any references from them should be accurate. The BlobsPaper.png 02:49, 5 January 2016 (UTC)


 * . –Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 06:47, 5 January 2016 (UTC)

Outdated images in history sections
Seeing as images can be useful in history sections to illustrate things, but currently are stated against in the guideline requiring outdated image to be removed, I propose amending the guideline "Images that are outdated are subject to be removed." to "Images that are outdated are subject to be removed unless its usage is in a history section or historical article." – KnightMiner  · (t) 01:02, 7 January 2016 (UTC)


 * . – LauraFi -  talk  01:08, 7 January 2016 (UTC)


 * . – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 01:49, 7 January 2016 (UTC)


 * , makes sense. —Fenhl 02:54, 7 January 2016 (UTC)


 * . — Agent NickTheRed37 (talk) 14:22, 7 January 2016 (UTC)


 * Some things are hard to explain in words. Allowing images in history would make them easier to explain. The BlobsPaper.png 03:23, 12 January 2016 (UTC)

What does "a list of miscellaneous builds the user can make" means?
Does it means "buildings that the user can build" or "things that the user can achieve" ?(Original words:Pages containing a list of miscellaneous builds the user can make are not to be considered a tutorial. They are to be kept in the userspace. This includes user-created activities and challenges.) - Kakagou12341 (talk) 15:56, 10 February 2016 (UTC)


 * I am not exactly sure the intent behind the rule as it was added before my time here, but I assume it has to do with pages only containing a list of ideas for the reader to build, rather than describing how to actually build the things. It is a very old rule, so it might be worth revisiting as the wiki has changed quite a bit since 2012. – KnightMiner  · (t) 23:24, 10 February 2016 (UTC)

More joke languages were added
Seeing as more joke languages now exist, the part of the redirect notability should be changed from with the exception of the joke language "Pirate Speak". to with the exception of the joke languages, such as "Pirate Speak". Additional joke language names could be added, but this is mainly to future proof it. – KnightMiner  · (t) 04:59, 19 March 2016 (UTC)


 * , though perhaps it should be worded as with the exception of joke languages such as “Pirate Speak”. —Fenhl 16:01, 19 March 2016 (UTC)


 * . – LauraFi - talk  20:24, 8 May 2016 (UTC)

tiles' titles
I've noticed, that some images have titles like "2011-01-22 18.38.25" (with the date, you took the photograph). In our Wiki we haven't titles like that. Only four - I've counted :-) It isn't handsome (in my opinion). I know, it isn't so important, but I am kind of obsessive - those titles aren't nice and I'd change the pictures' names - If you want :-) Yaouoay (talk) 16:38, 24 May 2016 (UTC)


 * We no longer allow files with generic names like this (it shouldn't be possible to upload new ones). I see no problem with moving them to more descriptive titles, as long as all the pages that use them are updated. -- Orthotopetalk 19:15, 24 May 2016 (UTC)
 * How will we make sure that no more "poorly-named files" get uploaded? –Preceding unsigned comment was added by Blobs2 (talk • contribs) at 3:12, 25 May 2016 (UTC). Please sign your posts with


 * MediaWiki:Titleblacklist. -- Orthotopetalk 03:33, 25 May 2016 (UTC)
 * Okay, thanks :-) -- Blaze Face.png Yaouoay (Talk) 18:14, 25 May 2016 (UTC)

Two mistakes
I don't know whether the usage of that date is intended. But it cause a inconsistency anyway.Kakagou12341 (talk) 01:42, 7 June 2016 (UTC)
 * 1) In the section Keeping articles concise and up to date: "...players to exchange emeralds for other items.""." (two more symbol)
 * 2) According to the section Date formatting, the example "Minecraft officially came out of Beta on November 18th, 2011" in Editions of Capitalization section should be changed to "November 18, 2011"


 * . – KnightMiner  · (t) 03:24, 7 June 2016 (UTC)

Roman numerals as single Unicode characters?
Some replacements have been identified as made by in 2014. No on-site information found about this style preference: 1) no mentions or explanation found in edit summaries, 2) no mentions found in the style guide, 3) no mentions found on any talk pages.

Current usage is inconsistent. I would prefer to see a standard written in the style guide. Any suggestions? --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 16:16, 24 September 2016 (UTC)


 * What pages have you been seeing this on? – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 16:56, 24 September 2016 (UTC)


 * Listing every single page I could find (U+2160 to U+2169, site search of all namespaces):
 * Drops/vi (this page probably requires attention for other reasons as well)
 * Pufferfish/cz
 * User:Fenhl/Inventory
 * Drops
 * Lapis Lazuli
 * --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 17:12, 24 September 2016 (UTC)


 * The Unicode Consortium actually gives a recommendation on this: "For most purposes, it is preferable to compose the Roman numerals from sequences of the appropriate Latin letters." (meaning, use three I's, III, instead of unicode Ⅲ) – http://www.unicode.org/versions/Unicode7.0.0/ch22.pdf (Page 754) It goes on to give a couple of exceptions, neither of which are applicable here. –  Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 17:30, 25 September 2016 (UTC)

Why American English?
I agree that it makes sense to have a standard, but why choose American English? Why not British, South African, Canadian or Australian? Is there some good reason for this bias? The game is Swedish, not American. –Preceding unsigned comment was added by Uberken (talk • contribs) at 13:58, 12 October 2016 (UTC). Please sign your posts with


 * The only language in Minecraft produced by Mojang is US English; all the others are made by fans on crowdin.net . Also, the majority of wiki editors are based in the US. -- Orthotopetalk 14:05, 12 October 2016 (UTC)

Video Policy/Style Guide Change
Currently the Style Guide for videos details the placement of Minecraft Spotlight videos on pages. We’ve come to realize that many (or even most) of these videos are very out of date and often no longer relevant. We’d like to make some changes to the way Curse-produced videos are presented on the wikis to ensure that videos are relevant and placed in a way that’s beneficial for both the community and Curse.

As people may know, Curse was recently acquired by Twitch. We are excited to be part of this new organization and to be working with their teams to bring more visibility and integration between all of the great content on Gamepedia’s wikis and the content created on their platform. One of the initial ways we’re aiming to move forward on this front is by integrating relevant and up to date videos into wiki pages in highly visible locations. Our aim is not to push videos that are not current and relevant to the pages they’re placed on, nor to disrupt content (particularly infoboxes) with video placements. With this plan, we also want to work with the community to remove and/or replace video content that is out of date or irrelevant.

Over the years that Gamepedia/Curse has hosted the Minecraft wiki, we have always aimed to avoid making sweeping changes without community input whenever possible. We ARE a business, but we’re also in the business of fostering communities and our content creators. Moving forward, we’re hopeful that we will be able to work with the teams at Twitch to bring even more visibility and users to Minecraft and other wikis on our network. This project of incorporating VODs (Videos on Demand) is the start of our work on that path.

Therefore, we would like to remove the video section from Minecraft_Wiki:Style_guide/Features, or alter it to make it clear that out-dated MC Spotlight videos do not need to remain on pages where they no longer contribute useful information for players. We’d also like to add a section to the general Minecraft_Wiki:Style_guide allowing for Curse Staff members to add relevant and up-to-date videos to pages with placement near or at the top of the page (depending on page content and layout). With this change to the Style Guide, we also want to definitely allow for feedback about any placements that other editors think are either not relevant or interfere too much with existing content. In those cases, we would ask that editors start a discussion on the talk page for the article and leave a message for the staff member who added that video placement before making any changes to the video. This process would be explicitly laid out in the style guide policy.

Pending an open discussion of these plans, we’d like to get started with these changes next week (Thurs Nov 10th).

A link to this discussion has also been posted on the Community Portal Talk page. CrsBenjamin - (talk) 15:54, 3 November 2016 (UTC)


 * It makes sense to be able to remove outdated videos, sure. I'd be on board with that piece.
 * I also appreciate the initiative in creating new videos, which I've seen Curse staff put on the 1.11 page for example. I feel videos, when up to date / correct, can be a useful complement to the wiki content.
 * In general though, I oppose putting videos near the top of the page, it doesn't seem very wiki to me. It seems by their very nature they are supplemental material, as opposed to the primary material we provide. This objection I would raise from anybody suggesting this, not just Curse.
 * Taking into account also, that these new videos so far are heavily curse/twitch branded, it doesn't seem like a community-centered move to raise them to the top of the page.
 * So I have questions.
 * What is wrong with the placement now, and what problem are you trying to address?
 * Do you have a specific draft proposal we can talk about? You mention "We’d also like to add a section" and "This process would be explicitly laid out in the style guide policy".  It would be easier to talk about this in useful detail if we had something written that we could refer to.  I suppose you must have something written up, if you'd like it to be ready to go next week.
 * – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 16:16, 3 November 2016 (UTC)
 * Sealbudsman already said what I'd have said. In particular, videos don't belong at the top of pages displacing actual editable content (particularly since people who want videos rather than text probably just go straight to YouTube). Anomie x (talk) 11:20, 4 November 2016 (UTC)
 * Our goal is to definitely produce relevant and up to date content for the wiki, but also to drive views for the videos themselves because that is what allows us to invest greater resources into production of quality content. Placement of videos makes a dramatic difference in the number of views they receive, which is why the placement near the top is what we're aiming for here. I should also note that we're talking about a much smaller number of videos, rather than the hundreds of MC Spotlight videos that exist now. So, its balancing the removal of lots of old and outdated content with the addition of a few newer and more relevant videos but with placement that helps us to best meet the objectives we have. I do not have exact text for the change, but I will work on it. CrsBenjamin - (talk) [[File:User_Wynthyst_sig_icon.png]] 14:20, 4 November 2016 (UTC)


 * A process for removing or replacing outdated videos is long overdue, considering that at least 120 of the 458 videos (edit: make that 121) contain incorrect information due to their age or for other reasons. I also believe that this is an inherent flaw of the format, and no reasonable amount of work would be enough to keep the videos up to date with the changes in Minecraft. Watching a video also takes longer than looking up the relevant section of a hypertext article. For these reasons, I am opposed to placing videos anywhere near the top of an article.


 * Other than this, I would welcome these changes, though as someone who has made major contributions to what is now Minecraft Wiki:Style guide/Features I would also be interested in seeing the proposal before it is implemented. —Fenhl 16:46, 3 November 2016 (UTC)
 * Exact proposal in the works. CrsBenjamin - (talk) [[File:User_Wynthyst_sig_icon.png]] 14:20, 4 November 2016 (UTC)


 * I think an important concept that Fenhl has touched upon (which I would like to echo and say more about) is our keep the wiki up to date policy. The only reason we currently tolerate out-of-date information in the videos in our pages -- as opposed to the entire rest of the wiki -- is a Curse-imposed exception mandating that their videos be present. If it were up to us, these videos would be gone/replaced/brought up to date already. As it is, I don't see how the current Curse video requirements are anything more than enforcing a sort of brand presence, frankly at the expense of quality. So any change in that would be welcome, as this discussion is welcome.
 * Think of it from a QA perspective. It would be better to treat out-of-date videos as equally as important to update as the rest of the content is. If there is a commitment from Curse to be sure their videos are up-to-date with every major Minecraft release, that would be a good sign.  If there is not, then I'd like to stress that increasing the prominence of an out-of-date video is harmful to the wiki's quality as a whole, and by extension, the Curse brand. I think this is something we both -- the community here and the Curse staff -- all care about. –  Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 17:44, 3 November 2016 (UTC)
 * As I've said, the goal here is to create a system where out of date videos are not featured on pages, but where videos that are relevant and not outdated, to have them featured in a placement that will help us meet our viewing goals. CrsBenjamin - (talk) [[File:User_Wynthyst_sig_icon.png]] 14:20, 4 November 2016 (UTC)


 * In addition to what our other valued editors have said, the issue I have with an exception to our usual policy for 'up-to-date' videos is that all of the videos Fenhl mentioned were up-to-date when they were posted. One of the key ideas of a wiki is that it can be easily edited and updated; videos cannot. If Curse is willing to commit to updating their videos promptly when new versions of Minecraft are released, this might be acceptable, though I don't really like the requirement that we get Curse approval before making any changes. -- Orthotopetalk 01:31, 4 November 2016 (UTC)
 * We feel like this would be a major step towards the ideal situation though. Not only will this allow for the removal of many out-dated videos, it creates an explicit pathway for having discussions about videos that the community identifies as out-dated. CrsBenjamin - (talk) [[File:User_Wynthyst_sig_icon.png]] 14:20, 4 November 2016 (UTC)


 * Obviously, I have no problem with removing outdated videos. My knee-jerk reaction is to oppose videos at the top of the page, but I realize Curse is a business and videos can earn money on YouTube. I think I could live with a single video embedded between the article introduction and the TOC (i.e., just before the first heading while editing), if it was germane to the entire article. If you place the video above the intro text, then it will just be seen as another ad. I could also live with "section" videos being integrated into the article if it were done the way image thumbs are now (for articles which are perhaps too long or complicated for a single video to cover the entire article, a "section" video would cover a smaller topic) — that might actually be more useful to readers than delegating videos to their own section far down the page. For both of those, it would be important for the embedded videos to have a caption explaining what topics they cover (and, inevitably, how they've become outdated). &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 16:59, 4 November 2016 (UTC)


 * I agree with Munin. I'm more amenable to moving the videos up the page (perhaps to just below the lead and TOC) than to having them at the very top. In addition to looking less like an ad, I think the article layout would flow better, while still making them more prominent and increasing the number of views. -- Orthotopetalk 20:40, 4 November 2016 (UTC)


 * I'll look into that idea. Its possible that would work, the major goal is having them appear on the page without having to scroll. CrsBenjamin - (talk) [[File:User_Wynthyst_sig_icon.png]] 21:01, 4 November 2016 (UTC)


 * I'm with most here, and think that having the videos at the very top of the page would break the article flow. Also, as Munin mentioned, this positioning feels more like an advert, rather than page content, and could therefore be counter-productive.


 * If it helps to visualise this, User:Alianin did attempt to make this change on the Enchanting page last week, so here's the diff for reference. Based on this I've put together a mock-up of a possible layout in this instance that could work for everyone; placing the video below the page intro, and to the opposite side as the TOC (User:DelboyDylan/Enchanting). This way, the video is still near the top of page, but feels more integrated into the page contents. However, I haven't been able to figure out the ideal layout on pages with info boxes yet. I'm thinking maybe in the blank space in between the TOC and infobox, but still below the intro text. DelboyDylan (talk) 11:05, 5 November 2016 (UTC)
 * Um, Alianin != Alexia, they're different people. -Xbony2 (talk) 11:11, 5 November 2016 (UTC)
 * Oops, fixed. Thanks DelboyDylan (talk) 11:16, 5 November 2016 (UTC)
 * Anyway, I like User:DelboyDylan/Enchanting more, although it would be nice if the video was a little bit more centralized. -Xbony2 (talk) 11:14, 5 November 2016 (UTC)
 * Personally, I don't like it much: big useless video to scroll past in between the intro and the actual content. And it would work even worse on a page like Brewing that has useful media at the top-right instead of floating the TOC there. Anomie x (talk) 12:02, 5 November 2016 (UTC)


 * I certainly agree with your comment on the Brewing page (as well as any pages like it). Placing a video above or around the top of that page would be problematic. However, I don't agree that the video would be useless. In fact, in some cases these could enhance the user experience, provided they are dealt with properly.


 * My view is that the very top of the page should be used to confirm to the user that they are on the correct page for what they are looking for. This would be in the form of the intro text, disambiguation and the top section (in particular, the image) of the infobox (where applicable). Once the user has confirmed that they are where they want to be, then they have a decision to make. Do they want (A) specific information, or (B) a general overview of the subject of the page? For those in the (A) group, the natural place to go is the TOC, and will likely consist primarily of existing or long-term Minecraft players. For those in the (B) group, an overview video might well be ideal, and would in my eyes be useful for newer players of the game, or those with little or no knowledge of the page subject. Therefore, having the TOC and video in a similar location, but below the summary information seems to make sense. DelboyDylan (talk) 12:47, 5 November 2016 (UTC)

Upcoming versions
Ok, so there may be some debate on this, but i think that instead of putting "?" for the release date of updates with an unknown date, we should put "Unknown". RedRooey (talk) 14:31, 4 November 2016 (UTC) (i really do not know if this belongs in style guide, but this seemed like the most reasonable place to put it.


 * Well, both result in the same information being conveyed. So I'd personally stick with using a, simply because it's slightly more efficient. DelboyDylan (talk) 11:13, 5 November 2016 (UTC)