Talk: Style guide/Archive 2

Future in history sections

Following up my previous topic (#Rule about upcoming features), 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)

 Agree. 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 #Undiscussed pages / sub-style guides and #Sub-style guides, I have proposed a rewrite to this page over at MCT:Community portal#Reform the style guide and wiki rules, 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,  Agree. — 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  Agree. Sorry for latency, it was due to metawikipedia:Oversight policy/ru. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 18:21, 7 March 2015 (UTC)

 Agree. –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)

Minigame notability

Moved to MCT:Community portal#Minigame notability

Redirects

The following is a closed discussion of a proposed addition to the style guide. Please do not modify it. Any editors wishing to make further comments should start a new topic.

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".
   1. Incorrect spelling, typos, and irregular formatting are not allowed.
2. Alternate or shortened name, provided the name is common usage, such as "Log" for "Wood". Previous in game names are also allowed.
   1. This includes first names or handles for Mojang employees, such as or "Nathan" or "Dinnerbone" for "Nathan Adams".
   2. This also includes names from alternate English language packs, with the exception of the joke language "Pirate Speak".
3. Previous article title, including if the article was moved to another wiki
   1. An exception is if the previous title was not commonly used
4. Alternate capitalization or form, including changing the title to plural case
5. A part of a merged or multi-topic article, such as a potion or a mentioned feature.
6. 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)

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

 Agree. Sounds good. —munin · 16 px 16 px · 00:03, 24 March 2015 (UTC)

 Agree. —「JEC⁶⁷⁸⁹」_{talk • contribs} 00:21, 24 March 2015 (UTC)

 Agree — 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]
   • The actual group names can be set to anything (this is done using pages in the MediaWiki namespace, such as {{static link|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"
   • Zombie pigmen spawn on the lowest level of nether portals^[A]
2. 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.
3. 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. —munin · 16 px 16 px · 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 {{notelist|global}}. If there are no notes, this section may be skipped.

While for the main style guide.

Notes

Articles should use <ref> 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)

 Support — NickTheRed37 ^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 Orthotope, 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 ^t/_c (f.k.a. Naista2002) 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#video. (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)

 Oppose {{dablink}} is for disambiguation notes only. — x18px NickTheRed37 (talk|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)

 Agree. –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

User GreenStone 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 clear: right rule from .notaninfobox.

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. — Orthotope^talk 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 .atfmrec { margin-bottom: 1em; } to MediaWiki:Common.css, which reduces the bottom margin just enough to let the quote see the infobox and adjust its width accordingly.

@NickTheRed37: 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)

 Strongly oppose 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|c) 16:12, 15 June 2015 (UTC)

 Neutral/Unsure. 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)

 Agree 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). —munin · 16 px 16 px · 18:10, 15 June 2015 (UTC)

 Neutral. –LauraFi - talk 18:18, 15 June 2015 (UTC)

 Agree 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) frameless ^T/_C 18:24, 15 June 2015 (UTC)

 Agree –Goandgoo ᐸ 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)

 Agree. –LauraFi - talk 00:09, 26 June 2015 (UTC)

 Agree as well. BDJP ^(t|c) 01:21, 26 June 2015 (UTC)

 Agree also. – Sealbudsman (Aaron) frameless ^T/_C 02:08, 26 June 2015 (UTC)

 Agree –Goandgoo ᐸ Talk
Contribs 03:49, 26 June 2015 (UTC)

 Not bad. — Agent NickTheRed37 (talk) 07:02, 26 June 2015 (UTC)

 Agree – JEC⁶⁷⁸⁹ _{talk•contribs} 11:44, 26 June 2015 (UTC)

Gameplay mechanic page titles

According to KnightMiner's comment in Minecraft Wiki talk:Community portal#Move pages to singular form titles, 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 Blobs^16px 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 following is a closed discussion of a proposed amendment to the style guide. Please do not modify it. Any editors wishing to make further comments should start a new topic.

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:

“

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.

„

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|c) 10:15, 19 October 2015 (UTC)

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

 Agree If a version has no development versions, then only Mojang can play the pre version. Upcoming features belong on the version page. The Blobs^16px 21:00, 21 October 2015 (UTC)

 Oppose: 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 ᐸ Talk
Contribs 10:07, 22 October 2015 (UTC)

 Oppose 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|c) 12:25, 21 November 2015 (UTC)

 Disagree: 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:

“

Yes, there is a source that it is upcoming, though the thing is such sources also exist for the PC edition

„

You just disproved your own statement.

“

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

„

That's the reason why I'm making this exception...

“

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?

„

I said nothing about sources for PC or PE, so why bring that up? -BDJP ^(t|c) 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)

 Agree. –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".  Agree. -BDJP ^(t|c) 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)

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

 Agree, 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 ~~~~

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

 Agree 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 Blobs^16px 02:49, 5 January 2016 (UTC)

 Agree. –Goandgoo ᐸ 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)

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

 Agree. – Sealbudsman ^talk/_contr 01:49, 7 January 2016 (UTC)

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

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

 Agree Some things are hard to explain in words. Allowing images in history would make them easier to explain. The Blobs^16px 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)

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

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

tiles' titles

I've noticed, that some images have titles like "{{static link|:File:2011-01-22 18.38.25.png|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. -- Orthotope^talk 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. -- Orthotope^talk 03:33, 25 May 2016 (UTC)

Okay, thanks :-) -- 27px Yaouoay (Talk) 18:14, 25 May 2016 (UTC)

Blobs2 changes those pictures. @Blobs2: Do you want me to help you? (In the past I'd done that three times and then I'd stopped. I may continue ...) :-) -- 27px Yaouoay (Talk) 21:28, 21 January 2017 (UTC)

Anyone may help with the task. I created a DPL of these badly-named files in my sandbox. The difficulty is that many of them are only used on translation pages. The Blobs^16px 21:52, 21 January 2017 (UTC)

I just looked on your sandbox ... Is that all? Where are the files of 2013 and 2010?

Are we authorized to move files, which are only used on user pages? :-) -- 27px Yaouoay (Talk) 09:19, 22 January 2017 (UTC)

It is not a full list, it only shows 35. However, I sometimes change the order to put in new ones.

As for images that only appear on user pages, they shouldn't be listed because it leaves out anything in :Category:User images. The Blobs^16px 17:49, 22 January 2017 (UTC)

Two mistakes

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"

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)

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

Roman numerals as single Unicode characters?

Some replacements have been identified as made by Fenhl 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 ^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)
• {{static link|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 ^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. -- Orthotope^talk 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) File:User_Wynthyst_sig_icon.png 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.

1. What is wrong with the placement now, and what problem are you trying to address?
2. 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 ^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)

See below for the diffs of the actual changes to be made. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 22:04, 7 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)

See below for the diffs of the actual changes to be made. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 22:04, 7 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 ^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. -- Orthotope^talk 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). —munin · 16 px 16 px · 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. -- Orthotope^talk 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)

I still believe that people who want YouTube-style videos will be looking on YouTube, not here. And YouTube has a better UI, for that matter (e.g. increased playback speed). Anomie x (talk) 12:40, 6 November 2016 (UTC)

Maybe so for the majority, however speaking from personal experience, the spotlight type videos can be very useful. When I first started playing Minecraft I'd regularly come here to learn about particular game features. In most cases I started by watching the spotlight video(s), and then looked elsewhere on the relevant page for answers to any questions I had afterwards. I personally found having both the video and details together on the same page very convenient.

However, I did find it rather frustrating if the video was out-dated, and therefore misleading. So I'm very glad we'll be able to get rid of those. – DelboyDylan ^{(talk|contribs)} 13:07, 6 November 2016 (UTC)

Something like this may work, depending on the page. I've made sure that its included in the policy (see below) as a potential placement. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 22:04, 7 November 2016 (UTC)

I've created the exact changes I'm proposing, in the form of diffs on copies of the relevant pages. Here are the changes to Minecraft_Wiki:Style_guide/Features that allow for the removal of old MC Spotlight videos added prior to these policy changes and here is the new policy for Curse Videos. After exploring the various relevant Project namespace pages, I felt that this was the best place for this to be spelled out, rather than on the Style Guide or /Features page. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 22:04, 7 November 2016 (UTC)

“

No action should be taken to remove or alter the placement of a video until Curse staff has participated in the discussion and consensus has been reached with them.

„

Does this include the addition of {{Video note}}s? —Fenhl 22:26, 7 November 2016 (UTC)

Addition of video notes for existing MC Spotlight videos would be fine. If there was an issue with a more recent video, we'd like to have a discussion first. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 19:15, 8 November 2016 (UTC)

 Oppose. Regardless of other improvements, forcing us to keep outdated videos around with no indication is problematic to say the least. Sure, we would get rid of the old videos once while switching over to the new system, but then we will have the same situation as before where we are not allowed to remove outdated videos, except now we can't even warn readers/viewers about inaccuracies.

I would like to see the proposal extended with a mechanism which allows us to add video notes until Curse staff responds, and to remove the video if and when they fail to respond for a clearly-defined amount of time. —Fenhl 20:15, 8 November 2016 (UTC)

We can look into adding some provision for that. I really don't anticipate a time where there's any length of time before a response to a discussion that's started though. What about a video note that indicated the video was under discussion and linked to that discussion? CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 20:18, 8 November 2016 (UTC)

I believe you when you say that you intend to keep the videos up to date, but as I have said earlier, I don't think that you will be able to keep up. For example, 1.11#Video is already outdated even though 1.11 isn't even released yet.

Simply including a link to the discussion sounds reasonable, and is similar to what I had in mind. However, another point that hasn't been discussed is that since we would need consensus with Curse, you can unilaterally decide that a video is not outdated or perhaps not outdated enough. What happens in that case? Do we have to remove the note with the link to the discussion and pretend everything is in perfect order? Or can we at least add a {{video note}} in the current format if and when this happens? —Fenhl 20:35, 8 November 2016 (UTC)

So, I don't think our plan is necessarily to churn out videos constantly, but more to remove videos when they're no longer relevant or become out-dated. If there was a case where we wanted to keep a video that was partially out of date on the wiki I think we'd absolutely allow a video note. This would generally be something we'd be trying to avoid (the out-dated part) and would only be in cases where we had some strong internal reason for a video to remain and I don't expect that we'd ever mandate a video remain permanently or if it was seriously out-dated. I'd like to hope that generally speaking we've been found to be fairly reasonable in our discussions with the community on topics like this. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 20:57, 8 November 2016 (UTC)

In my experience, Curse staff has been consistently unresponsive in matters where wiki editors have requested their involvement. I'd love for that to change, and this discussion is certainly a start, but I am not yet convinced, which is why I'm requesting these fallbacks. —Fenhl 21:16, 8 November 2016 (UTC)

I've added some more language to allow for that video note and to add a specific timeline for response expectations and an alternate means of reporting a new discussion that is more fool-proof (that e-mail triggers a support ticket, which are subject to resolution timelines from that team). I will be honest and say that, in terms of videos, there was a lack of understanding on our team. The original MC Spotlights discussion took place some time ago before most of our current team was here, and the main staff member who liaised with MCW is no longer with us (Wynthyst). While we did know that many Spotlight videos were outdated, we were unaware that the community was operating under the impression that there was no recourse for removing them from pages. That's part of what spurred this discussion. This is a project I'm now overseeing for the time being, and we'll be tracking things more closely. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 21:41, 8 November 2016 (UTC)

It isn't a good idea to require people to contact the person who posted the video — they may have quit/fired/vacation/reassigned/whatever and we'll have no idea why we're not getting an answer. It would be better (the "wiki way") to allow any wiki editor to immediately state in the video's caption what has become outdated (so that readers are not getting incorrect information, and other editors know the situation has been addressed) and mark it with a category such as "Outdated Video". Then any Curse staff can patrol the category page daily (or whatever) to see if any videos have been marked as outdated. There probably won't be any need to use the talk page — Curse will either update the video or they won't, and editors will find a consensus on the video's caption. —munin · 16 px 16 px · 22:02, 8 November 2016 (UTC)

 Agree. – Sealbudsman ^talk/_contr 22:53, 8 November 2016 (UTC)

In this case, we just don't feel like its possible for us to be that pro-active and so we're asking for your assistance with this to help make sure things are tackled as quickly as possible. While folks here deal with a single wiki, our (relatively small) staff is responsible for hundreds of active projects as well as other duties. I feel like its hardly a big ask that someone drops a comment onto my user profile when they add a video note. As I've said, right now we have less than half a dozen videos we're even looking to apply this to. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 22:59, 8 November 2016 (UTC)

With regard to your recent updated proposal, "If necessary, a {{Video note}} can be added to indicate the video is under discussion (and linking to that discussion).", does that video note permit us to state what is out-of-date about the video, as is the current practice, or are we limited to indicating that the video is under discussion? – Sealbudsman ^talk/_contr 23:17, 8 November 2016 (UTC)

Having a specific note would be fine. In the end, I don't mean for these to be overly strict laws, but more a set of guidelines so that you guys can operate smoothly and we can achieve what we need to from our perspective. If a month from now it turns out that this procedure doesn't work well at all, we can re-visit it! CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 00:07, 9 November 2016 (UTC)

Following the discussion, it seems like we've been able to tweak the policy to a point where its workable. I'm going to go ahead and make the proposed changes. CrsBenjamin - (talk) File:User_Wynthyst_sig_icon.png 19:37, 11 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)

Dablinks and message boxes

On some pages, they appear above the infobox, while on other pages, they appear below. This is likely due to a missing guideline. If we were to add a new guideline, what should it be? Personally, I would lean towards putting dablinks and message boxes after infoboxes, as that is where the rest of the introduction is. However, I would like to hear what other users think. The Blobs^16px 17:31, 18 December 2016 (UTC)

Already is one: Minecraft_Wiki:Style guide#Article layout, second bullet. –KnightMiner · (t) 20:21, 18 December 2016 (UTC)

Concerning the use of references and punctuation

Recently, I've noticed that there is a lack of conformity in articles - more specifically pertaining to reference placement at the end of sentences. For example, in one sentence, the reference may be placed before the puncuation, but in other cases after the punctuation. I would consider the addition of a sentence or two in the section concerning writing and citation that further explains proper reference placement, whether inside or outside punctuation marks, etc. Thanks, Maethoredhel (t • c • 15px) 16:21, 22 December 2016 (UTC)

I would think the reference should be placed before the punctuation, as the source and the content are part of the same sentence. The Blobs^16px 16:25, 22 December 2016 (UTC)

There is a guideline in the Wikipedia manual of style which addresses this; it indicates that "Any punctuation (see exceptions below) must precede the ref tags." – Sealbudsman ^talk/_contr 17:04, 22 December 2016 (UTC)

Agreed. Therefore, since Wikipedia's Manual of Style has indicated this, should we also mention this in the style guide? As far as I know, not too many people would check this talk page for guidelines on the matter - some articles already have the reference inside the punctuation (as stated above). Maethoredhel (t • c • 15px) 19:25, 22 December 2016 (UTC)

On the top of the MCW style guide, it says: "Although Wikipedia already provides a more general style guide, a more specific one is necessary for Minecraft specific guidelines. As such, only guidelines pertaining to the Minecraft Wiki and its basic formatting rules should be included here."

I think that precludes adding, for instance, general punctuation and referencing guidelines to the MCW style guide.

Typically we follow the Wikipedia style guide except where superseded by the MCW style guide, because it's sort of implied in that paragraph I quoted there, although I don't think it's ever explicitly stated that we should do so. On the other hand, there is ample precedent, at least within these talk pages and their archives, that the Wikipedia style guide is looked-to and adhered-to. To move to make this explicit, it's probably worth raising as its own discussion. – Sealbudsman ^talk/_contr 20:08, 22 December 2016 (UTC)

In the meantime, my opinion is that the precedents are clear that using the Wikipedia style guide is acceptable. – Sealbudsman ^talk/_contr 20:09, 22 December 2016 (UTC)

 Agree I now realize that doing it this way would look better. Otherwise, the source would create an awkward space between the sentence and the period. The Blobs^16px 04:40, 23 December 2016 (UTC)

Editions name

The writing of game editions should be improved even further, I've seen lots of difference in a few pages. For instance:

• Minecraft: Pocket Edition
• Minecraft Pocket Edition
• Minecraft: Pocket Edition
• Minecraft Pocket Edition
• Pocket Edition
• Pocket Edition

---

And the abbreviation:

• Minecraft: PE
• Minecraft PE
• MC:PE
• MCPE
• Minecraft: PE
• Minecraft PE
• MC:PE
• MCPE

I'd think that some of them need to be avoided from the writing. - 20px ItsPlantseed | 20px 03:07, 9 April 2017 (UTC)

There are definitely too many names. I would support Pocket Edition and MCPE, and no italics. The Blobs^16px 18:02, 16 April 2017 (UTC)

Continuation of Talk:Pigman

@KnightMiner: Thank you for your long reply. You say "It was never more than than a potential feature with a texture." But pigman's model is different from Steve in tuxedo, there is a clear history and a past planned to be implemented as a mob. This is a noteworthy point that is different from other player models. In addition, pigman pages is in other three wikis. Do not you think that it is strange that this wiki of has not created it?--{{User:Beans1512/Sign}} 09:26, 20 April 2017 (UTC)

Is this a discussion about the particular case of the Pigman page, or about a specific proposal for how to change the style guide? – Sealbudsman ^talk/_contr 11:45, 20 April 2017 (UTC)

I can not judge it. KnightMiner advised I to discuss in the style guide so I followed it.--{{User:Beans1512/Sign}} 11:52, 20 April 2017 (UTC)

He meant that since the Pigman page violates the style guide, you would need to propose a change to the style guide. – Sealbudsman ^talk/_contr 13:14, 20 April 2017 (UTC)

I see, copy that.--{{User:Beans1512/Sign}} 13:34, 20 April 2017 (UTC)

No one has reacted to this talk even after nine days have elapsed. Does this mean that I can make pigman's page or I can't this?--Beans1512_{Talk/Contribs} 10:00, 29 April 2017 (UTC)

Just because no one responded to the thread does not mean that a consensus has been reached. In this case I agree with Knightminer, there is not nearly enough information to warrant its own page. –Goandgoo ᐸ Talk
Contribs 13:28, 29 April 2017 (UTC)

Just because no one responded to the thread does not mean that a consensus has been reached: I know that rule. So I prepared two choices.--Beans1512_{Talk/Contribs} 13:31, 29 April 2017 (UTC)

A concensus requires responses, especially for changing wiki rules.

The reason I referred you to the style guide was because pigman existing as a page violates the rule about pages being about features that existed at one time. If you want the page, propose a change to that rule and get people to agree with the change (which given the state of all the articles that that rule was put in place to remove, I doubt it will get consensus to be added).

Pigmen simply are a feature that was an idea, but was never added. Sure its texture existed, but many other features had a texture and information about what it would do without being added so it is not worth highlighting this one. –KnightMiner · (t) 16:43, 29 April 2017 (UTC)

Full stops

When and where should we use full stops in update lists? Because I see them dotted randomly through out sentences. I just changed 1.12 to remove the random full stops. Should we add a section on here where to add full stops? — Nixinova (talk|edits) 04:52, 9 May 2017 (UTC)

Looking at a few manuals of style, out on the internet, I'm getting the feeling that one uses a full stop if it's a full sentence, and no full stop if it's a fragment, just a phrase, just a word, etc. – Sealbudsman ^talk/_contr 21:54, 13 May 2017 (UTC)

Bugs

Since this wiki is not a bug tracker, I am inclined to remove all information about bugs, except fixes in version pages. Would other users support this? The Blobs^16px 16:54, 13 May 2017 (UTC)

I believe that mentioning buggy behavior is alright, if not mentioning the bug means the wiki is wrong, or will mislead a reader. The spirit is that the wiki should ultimately document game behavior as it is. This approach doesn't lead to that many bugs being mentioned. – Sealbudsman ^talk/_contr 17:09, 13 May 2017 (UTC)

Per Seal, our objective here is to document reality, not an ideal world. Since in reality there exist bugs that affect gameplay, documenting only the ideal behavior is counterproductive, misleading, and confusing for readers. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:28, 13 May 2017 (UTC)

Allow header2 style for subheaders

I think that header2 style should be used for subheaders such as the command names at Commands because the lack of instantly recognizable headers makes the page difficult to read.

Two questions about screenshots

1. Are rendering quality enhancements from mods like OptiFine allowed in screenshots? If a screenshot is taken with vanilla UI and resource pack, and at the same time uses e. g. anti-aliasing, is such a screenshot permissible in vanilla articles?

2. Should we define lower and/or upper limits on screenshot resolution? 200×160 is most likely too small for most purposes, and 4K .png screenshots barely within the site's file size limit are probably overkill.

--AttemptToCallNil (report bug, view backtrace) 18:02, 22 July 2017 (UTC)

Screenshots with big resolution should not be a problem as all, as MediaWiki automatically scales the image down to the needed size. The full size image is loaded only if you view the image directly when clicking on it at the file description page. | violine1101^(Talk) 18:16, 22 July 2017 (UTC)

Optifine should be fine, as long as features such as Better Grass, Connected Textures, Clear Water and Better Snow are turned off. But be sure to use Optifines anisotropic filtering (off by default), because without it there is a noticeable difference when taking screenshots of certain objects. (take a look at the sugar cane in this image, most recent version is with anisotropic filtering enabled, the version before that has it disabled) Anti-aliasing is a vanilla thing, although they removed the possibility to set an individual value in 1.8, anti-aliasing itself is still in the game. Fusseel (talk) 18:54, 22 July 2017 (UTC)

Noted about big screenshots and AA/AF. (Is it also possible to set AA and AF for Minecraft in the GPU settings program?) The features not to enable in OptiFine were also what I initially thought would be disallowed.

That 200x160 screenshot (and I may have seen smaller ones) remains an open question to me. --AttemptToCallNil (report bug, view backtrace) 07:09, 23 July 2017 (UTC)

Screenshots should be large enough to demonstrate whatever they're trying to show, and beyond that it should be up to the uploader how large to make them. f a screenshot can adequately show its subject in just 200x140 pixels (or whatever), then there's no reason to artificially require the uploader to make a larger image (this is most obvious with the various sprite images - while they're compiled into sprite sheets, individual sprites are presented at their native resolutions of just a few pixels instead of being expanded). Similarly, while we definitely shouldn't encourage people to try uploading 10k x 10k images or whatever, having somewhat larger images than is strictly necessary, doesn't hurt anything; as Violine pointed out, MediaWiki automatically scales images as needed. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 03:22, 30 July 2017 (UTC)

Another minor question. A Russian wiki user recently uploaded an 8K screenshot, and the engine couldn't display a thumbnail on the file page due to the image being larger than 25 megapixels. A minute later, that same user reuploaded the image with a more typical resolution. Would a thumbnail of the 8K version of the image on an article page fail just like the thumbnail on the file page? --AttemptToCallNil (report bug, view backtrace) 11:31, 19 August 2017 (UTC)

AFAIK all the thumbnailing is done by the same routine, so if thumbnailing fails on an image's upload history, it's also going to fail on articles. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 04:25, 4 September 2017 (UTC)

JE / PE

In infoboxes, we use PC: xx PE: xx. Lately, they have started to be updated to JE. The problem is, there doesn't seem to be a proper way to do this. Should they be done as JE: xx, JE: xx, or JE: xx? – Nixinova 16 px 16 px 16 px 04:32, 1 August 2017 (UTC)

Abbreviation and linking can be done together: JE: xx (other than that, I have no particular opinion on what might be preferable here). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:35, 1 August 2017 (UTC)

{{static link|Java Edition|JE}}: xx → JE: xx. The tooltip for links is added automatically by the wiki engine, there’s no need to use additional tags. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 07:57, 2 August 2017 (UTC)

The additional tag would primarily be to improve semantics (and as such, it might be better placed inside the link, directly surrounding JE), but in any case this isn't something I'm going to push particularly hard. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 09:09, 2 August 2017 (UTC)

So the tooltip tag is just for OCD? — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 11:24, 3 August 2017 (UTC)

On section "Keeping articles consise and up to date"

An example of a bad article is shown in the MCW:UPTODATE section. I found some capitaization errors in that example article, such as "These wood blocks still produce 4 Wooden Planks when crafted."

However, MCW:UPTODATE section does not contain discussion about capitaization style, so I think the demonstration should focus on the designated topic only, and capitaization errors should be cleared from the example article. JackAlpha26 (talk) 07:02, 24 August 2017 (UTC)

I think that section was written quite awhile ago as that was the preferred style several years back. I don't have a problem with updating it to the correct capitalization. –KnightMiner · (t) 21:35, 24 August 2017 (UTC)