Minecraft Wiki
Advertisement

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

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 · Grid Book and Quill Grid Stone Pickaxe · 00:03, 24 March 2015 (UTC)
 Agree. —「JEC6789talkcontribs 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 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 · Grid Book and Quill Grid Stone Pickaxe · 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. — Grid Command Block 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. — 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 .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 · Grid Book and Quill Grid Stone Pickaxe · 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) SealbudsmanFace T/C 18:24, 15 June 2015 (UTC)
 Agree GoandgooTalk
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) SealbudsmanFace T/C 02:08, 26 June 2015 (UTC)
 Agree GoandgooTalk
Contribs
03:49, 26 June 2015 (UTC)
 Not bad. — Agent NickTheRed37 (talk) 07:02, 26 June 2015 (UTC)
 AgreeJEC6789 talkcontribs 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 BlobsPaper 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 BlobsPaper 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. MajrTalk
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 (talkcontribs) 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 BlobsPaper 02:49, 5 January 2016 (UTC)
 Agree. GoandgooTalk
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 BlobsPaper 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 "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 (talkcontribs) 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 Yaouoay (Talk) 18:14, 25 May 2016 (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):
--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.

Advertisement