Talk: Community portal/Archive 17

Autoconfirmed permission on all pages

Note: Some of the text seen below has been intentionally copied from an eariler discussion regarding anonymous users creating pages, seen here.

Can we just disable anonymous users editing pages? Sure, I have seen some "useful" contributions by anonymous users (mostly just grammar fixes), but most of the edits by anonymous users are just blatant vandalism, spam and advertising. We should still let them edit talk pages, but require making an account to edit pages, as if a user cares enough about the wiki to make an account, they are that much more likely to care about our policies.

I know a change like this has to be made by Curse, but I figure the community should decide before I suggest it. BDJP ^(t|c) 17:01, 8 July 2015 (UTC)

This is very unlikely to happen. You underestimate the value added by drive-by fixes from anon editors. Why do you think Wikipedia allows it, when they are such a huge target for vandalism?

Small wikis which can't keep up are the only cases where I could see this happening, of which we are not. This is better handled by better abuse filters, rather than preventing editing entirely. –Majr ᐸ Talk
Contribs 17:24, 8 July 2015 (UTC)

Curse requests

Please direct requests requiring Curse's attention (such as configuration changes) to me first to assess, and I will then pass them on. Thanks! –Majr ᐸ Talk
Contribs 17:14, 8 July 2015 (UTC)

Accepted, although I may still prefer contacting Game widow directly. Make sure to add her talk page into the watchlist if needed. — Agent NickTheRed37 (talk) 17:28, 8 July 2015 (UTC)

Notified Russian users. — Agent NickTheRed37 (talk) 17:39, 8 July 2015 (UTC)

Ouh, and does it apply to other wikis (like Terraria one) by chance? — Agent NickTheRed37 (talk) 17:42, 8 July 2015 (UTC)

Nope, only here. –Majr ᐸ Talk
Contribs 15:54, 11 July 2015 (UTC)

Nick, this has nothing to do with your preferences. Majr is an employee of Curse, and, presumably in that role, has stated that requests for Curse need to go through him. Unless he or another Curse employee clarifies otherwise, this means all requests need to go through him, regardless of your feelings on the matter. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:34, 9 July 2015 (UTC)

FYI, the reason that I should be contacted is I know the community better, so I am in a better position to vet the requests before passing them on. –Majr ᐸ Talk
Contribs 15:54, 11 July 2015 (UTC)

I will keep that in mind. Sorry if I overstepped a bit with contacting Game widow directly. –KnightMiner · (t) 03:48, 9 July 2015 (UTC)

No problem. I hadn't formed a strong opinion on the subject yet, so I hadn't replied, and so you didn't know. –Majr ᐸ Talk
Contribs 15:54, 11 July 2015 (UTC)

Sprite editor ready for testing

I have finally gotten this project in a state ready for testing. A page is available here, which you can feel free to play with. To get started hit the "Edit sprite" tab.

My main areas of interest are browser compatibility and bugs, but comments on performance and usability are useful too. I have created a repository here to keep track of bugs and feature improvements, which you may report to directly if you wish.

I haven't created any documentation on how to use it yet, as I'd like to first see if it is easy enough for people to figure most things out without requiring a manual. :)

–Majr ᐸ Talk
Contribs 16:48, 11 July 2015 (UTC)

Firefox 39.0. Works fine when editing, but nothing seems to happen when the Save button is clicked (except that the button changes its graphics; I have been waiting for at least 3 minutes). --GreenStone (talk) 17:20, 11 July 2015 (UTC)

Same browser here, unable to make it fail as you describe; can you provide steps we can follow? Maybe also hit F12, and report anything that happens in the network tab or console tab. – Sealbudsman (Aaron) frameless ^T/_C 18:41, 11 July 2015 (UTC)

All I get is sections of sprites, no editor. I use Firefox 39.0 but with a lot of things blocked. What was this supposed to run in (javascript, flash, etc.)? —munin · 16 px 16 px · 20:09, 11 July 2015 (UTC)

If you don't see the tab at all, you have JS disabled. If you do see the tab, but clicking it doesn't load the editor, then maybe you're blocking particular scripts. –Majr ᐸ Talk
Contribs 06:25, 12 July 2015 (UTC)

Reply to Sealbudsman: I added a new section and an entirely new sprite into that section. The sprite was loaded from a 16x16 .png image. --GreenStone (talk) 06:52, 12 July 2015 (UTC)

If it was an API error, a message would be displayed, so it sounds like you managed a JS error. Have your console open while editing and see if any errors come up. –Majr ᐸ Talk
Contribs 06:25, 12 July 2015 (UTC)

Reply to Majr: This is what I get in the console when opening the page (thought you might be interested in that as well) and when saving. The first four lines appear when loading the page in View mode, nothing new appears when switching to Edit sprites mode, and the last line appears when clicking Save after performing the changes described above. --GreenStone (talk) 06:52, 12 July 2015 (UTC)

Ah yeah, that's a problem. Curse keeps images on a different domain, so it is impossible to load the sprite sheet due to the same origin policy. I've disabled image editing for now. Maybe if CORS was enabled, it would allow it to work. –Majr ᐸ Talk
Contribs 10:05, 12 July 2015 (UTC)

CORS is now enabled (it was actually already enabled on the server side), so image editing should work now. –Majr ᐸ Talk
Contribs 11:48, 16 July 2015 (UTC)

Image editing seems to work now, but I am unable to view this diff properly. This is the entire returned page. --GreenStone (talk) 12:44, 16 July 2015 (UTC)

That's caused by the wiki not handling large diffs well. Because you added a new section, that incremented the section number for all the below sections, causing all 774 lines to be updated with the new section number. I could fix this by using a unique ID for each section, rather than a positional number. This would also make tidier diffs when re-arranging sections, as the section number for all images in those sections wouldn't need to be updated. –Majr ᐸ Talk
Contribs 17:07, 18 July 2015 (UTC)

If you click to edit the sprites, navigate away from the page without saving, and use your browser's back button to return to the edit sprite page, you don't return to the actual edit mode until you click "Edit sprite" again (in Chrome 45). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 22:40, 11 July 2015 (UTC)

Can't reproduce. Either from navigating to a different page, or fake navigating to the view page. Does the tab actually get selected, but the editor doesn't load? –Majr ᐸ Talk
Contribs 06:25, 12 July 2015 (UTC)

It's working for me now, must've been my browser being stupid (as is its wont). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:54, 12 July 2015 (UTC)

I think it might have been due to a race condition caused be mw.Api being called before it was loaded, which is why it only happened sometimes. –Majr ᐸ Talk
Contribs 10:05, 12 July 2015 (UTC)

Everything works fine for me on Chromium. The only issue I see is deleting sprites could be a bit more obvious, such as by having a little X button.

Now a question: is this ultimately intended for the sprite extension, or the sprite module? –KnightMiner · (t) 13:10, 12 July 2015 (UTC)

Normally you can click on an image to bring up the option to replace/delete it, however that is removed entirely when image editing is disabled. I probably did that because I was thinking deleting an image required removing it from the sprite sheet, but that doesn't happen anyway, so I could keep that option and just disable the replace button.

This is intended for the module. The extension doesn't have any benefit over the module aside from slightly easier name adding (which is now solved with the editor), and is lacking in features and sane HTML to be a replacement for the module. However, there is no particular reason (with some modifications) that the editor couldn't also be compatible with the extension. –Majr ᐸ Talk
Contribs 11:48, 16 July 2015 (UTC)

Works fine for me on Safari on iOS. The only issue that I have is that I can't see the snowfall sprite. Either its an issue with my brightness, or the background behind the sprite is too bright. :P -BDJP ^(t|c) 03:13, 14 July 2015 (UTC)

So you were able to use it on a phone? That is quite surprising, although I highly doubt the interface was at all optimal for a touch screen, correct? –Majr ᐸ Talk
Contribs 11:48, 16 July 2015 (UTC)

It’s working fine on my Firefox 30.0 (adding and removing (I assume) names, adding, replacing and removing images), but I still have to understand: what realization will we use in the end? I’m mostly sure the SpriteSheet wiki extension can offer more possibilities if made correctly, and it probably doesn’t use JS, which can be disallowed on one’s browser for obvious reasons or not supported altogether. — Agent NickTheRed37 (talk) 15:20, 16 July 2015 (UTC)

While supporting no JS for basic functionality and browsing is highly recommended, for more advanced features it is quite acceptable to require JS, especially since this is not going to be used by readers, and you still have the option to manually edit the sprite sheet and data module, just like with the VE and source editing situation. Anyway, the sprite sheet extension requires JS as well.

The extension just handles basic assigning of names to images in the sprite sheet. It does not handle the most difficult part of sprites, and that is the creation of the sprite sheet itself. The sprite editor is intended to handle sprites as if they were separate images, and you just assign names to those images and categorise them. Yes you could certainly develop an extension that handles constructing the sprite sheet from individual images, and I may indeed do that at some point to improve browser compatibility and performance (as well as providing a more convenient back-end for the editor to work with), but using JS was easier for me as I am more familiar with it, and I generally hate PHP. –Majr ᐸ Talk
Contribs 17:07, 18 July 2015 (UTC)

Moving transcludable metadata, video etc into their own namespaces

These transcludables (examples 1, 2) for now are named as Main article/Name, as subpages, in main namespace. It was a long time since subarticles are now counted as normal articles (note the article count jumping at around February 4–5), and as such these transcludables also go under their definition and, including but not limited to, mess up the shown amount of articles.

Thus I propose introducing new namespaces for these pages (like Metadata:, Video:) to fix all of that. I anticipate a wave of opposes due to being a huge change with probable little benefits, but anyway...

— Agent NickTheRed37 (talk) 18:16, 15 July 2015 (UTC)

Both methods have pros and cons. The multiple-namespace approach has been used for years on the Yu-Gi-Oh! wiki for such things as galleries and rulings, but in spite of that, I don't have much of an opinion on which I prefer. I will point out, though, that one of the cons for that approach is that renaming an article doesn't provide the option to automatically rename the related pages, since they are no longer subpages of that article, though this probably isn't a significant concern here given that pages are so infrequently renamed. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:06, 15 July 2015 (UTC)

 Agree. Even though I'm okay with it, the Video namespace is already used in Wikia. --MCPEplayer2 20px ^{Talk to me!} 22:48, 15 July 2015 (UTC)

The Video: namespace on Wikia was deprecated a little while back and no longer works; all videos uploaded to Wikia are instead in the File: namespace (as they were originally). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 08:07, 16 July 2015 (UTC)

Keeping data pages in an alternate namespace makes some sense (though it should really be "data" rather than "metadata", mainly since shorter is usually better). The video namespace could also be helpful, especially if we set the namespace to only allow administrator edits (like "MediaWiki" does, and "Project" accidentally did for a bit.)

The main issue I see with this is loss of convenience: not only the moving of pages stuff, but also the convenience of transclusion. Subpage templates (or templates only used on a single page) would basically lose their purpose if they are moved into another namespace, as they no longer have a quick way to be called (thus, they might as well be in the "template" namespace).

I am mostly neutral on this topic, basically I am against it as it seems like a lot of work for seemingly little gain (yep, as said above), but like it for the idea of a namespace to contain all extra page data, basically to keep the main namespace for articles. Though for one last thought, if the main point of this is to fix errors with them acting as articles, wouldn't it be easier to develop a simple extension to get the root article count instead? Most related problems can be solved in a similar way, such as using something like mw:Extension:Randomrootpage to solve related issues with the random button. –KnightMiner · (t) 04:08, 16 July 2015 (UTC)

There are “subarticles” that are actually articles, most notably tutorials and ones about game modifications. Oh wait, can we rather implement a __NOTARTICLE__ “magic word”? If yes, then the idea can be scrapped in favor of that. — Agent NickTheRed37 (talk) 05:50, 16 July 2015 (UTC)

The tutorials have generally been considered as poor quality non-articles (I like to pretend the whole tutorial section doesn't exist), and mods are not officially supported by the wiki, so those sections not being considered "real" articles would be kind-of fitting. However, the quality of tutorials has been improving a lot, so maybe we could consider them real articles and give them their own namespace, or include our pseudo-namespace subpages in our article definition.

As for the magic word, it is likely the easiest solution (and an extension may already exist for it), but feels messy to me. –Majr ᐸ Talk
Contribs 17:51, 18 July 2015 (UTC)

I feel that sub-pages are a good way to associate data with a page, which really should be on the page itself, but only isn't to avoid duplicating the data on other pages. With single-page templates, it is just to avoid wikitext clutter in the article, so those could just be moved the template namespace. And for videos it is just for protection reasons.

I don't see it at all being worthwhile to lose the convenience of these pages being associated with their parent pages just for more accurate statistics. I would rather do as KnightMiner says and try to fix the definition of "article". –Majr ᐸ Talk
Contribs 17:51, 18 July 2015 (UTC)

Template:Grid/Dispenser

There should be a template for the dispenser GUI. The Blobs^16px 15:54, 22 July 2015 (UTC)

Why? There's no difference between the dispenser and the player's inventory or a chest, as far as item interaction mechanics go. There's nothing that would require using a template for that that couldn't be served with a simple screenshot. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 16:47, 22 July 2015 (UTC)

Well, the dispenser can store LESS items than the inventory or chest. --MCPEplayer2 20px ^{Talk to me!} 18:27, 22 July 2015 (UTC)

Okay? How does it storing less items make it be required as a template? The reason there is no chest or inventory template is it is not needed, not there are too many slots.–KnightMiner · (t) 19:05, 22 July 2015 (UTC)

The purpose of the grid templates is to provide a simple, modular, and easily extendable method of displaying interfaces that interact with items, or that enable items to interact with each other, without requiring a separate image uploaded for each possible interaction. The player's inventory, chests, dispensers, and other such interfaces do not interact with items stored in them, nor do they enable those items to interact with each other; they are purely storage interfaces, distinguished from each other in the way they interact with the player and the environment rather than items. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:43, 23 July 2015 (UTC)

By using a template, it is easier to create GUI's because you don't have to upload a new image each time. The Blobs^16px 15:33, 23 July 2015 (UTC)

That doesn't say why one is needed for dispensers. What exactly are you trying to do that requires a template instead of being able to just take a screenshot? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:25, 23 July 2015 (UTC)

I don't know, though it could be created later (if necessary) The Blobs^16px 18:04, 24 July 2015 (UTC)

This is true, but my entire argument is that it is not necessary, and no one else has been able to present an argument as to why it actually is. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 21:07, 24 July 2015 (UTC)

Splitting Windows 10 only updates into their separate pages.

Portal blocks

Error on mobile w/ desktop view on?

Apparently I cannot view the desktop view of the entire wiki on my phone, instead, it links to the main Gamepedia page.. Is this an error/bug/data failure or something? MarioProtIV (talk) 16:44, 5 August 2015 (UTC)

I would really appreciate any response if this is a bug or not D: MarioProtIV (talk) 20:39, 5 August 2015 (UTC)

@Majr, can you try and see if this occurs on your mobile device? I'm not sure if it's just me that's having the issue. MarioProtIV (talk) 01:11, 6 August 2015 (UTC)

I don't have one. –Majr ᐸ Talk
Contribs 04:25, 6 August 2015 (UTC)

Seems to be working fine for me (Chrome on Android). -- Orthotope^talk 04:45, 6 August 2015 (UTC)

Works on Wikipedia (Safari on iOS). The Blobs^16px 22:38, 15 September 2015 (UTC)

Beta 1.9 page

I think it may be a good idea to add more info to the Beta 1.9 article to make it more consistent with the other pages. It will also include some info on why it was never released. I've written a draft here. --MarioProtIV (talk) 21:08, 7 August 2015 (UTC)

It was released, it was just called 1.0.0. Any other content you can add is either redundant or states that first sentence. Your draft article only proves this, with all its content either being fan nicknames (a forum thread is not a valid source for a name) or stuff that can easily be described on 1.0.0. It would also be less consistent to split it, as all other updates which changed their number are covered on the new number (for example, 1.7 on 1.7.2). –KnightMiner · (t) 21:24, 7 August 2015 (UTC)

Ah ok. I'll just add a trivia note to the 1.0.0 article saying that it was originally planned to be released as Beta 1.9. --MarioProtIV (talk) 22:01, 7 August 2015 (UTC)

Module:LoadArchives

On talk pages with more than one archive, it is impractical to manually create archive boxes for each talk page. There should be a module that creates archives for you. Parameters would be stored in Module:LoadArchives/Discussions. The code would be as follows:

local p={}
p.archives=expandTemplate{title='Archive box',args=mw.loadData('Module:LoadArchives/Discussions')[mw.getCurrentTitle().prefinedText:gsub('/Archive %d+$',)]}
return p

The Blobs^16px 00:45, 10 August 2015 (UTC)

You don't need to create an archive box for each page if one is required on the archive pages, just create a subpage and transclude it (see my talk page for an example). Usually though we only add the box on the main talk page. –KnightMiner · (t) 01:47, 10 August 2015 (UTC)

Phasing away from Mojang avatars to real life pictures + Expanding biographies on current and former employees

I feel like these are the stupidest ideas I've ever conceived, but here goes nothing... (I literally had to rethink this about 20 times before finally getting an idea)

I think that the Mojang avatars on Mojang AB need to be replaced by real life pictures of the employees (in fact, the last avatar ever made by Jnkboy was almost three years ago). A perfect example would be this picture of Daniel Wustenhoff. To me, I feel like these pictures look cleaner and more "professional" than the official avatars.

The biographies of the employees at Mojang clearly need some major expanding, and I feel like using LinkedIn would be a fine choice, as no one has even bothered to touch those pages (except for Tomas Alaeus of course) when it comes to information about where they graduated, what they graduated for, what jobs did they have before joining Mojang, etc. -BDJP ^(t|c) 01:39, 10 August 2015 (UTC)

While I do like the Mojang avatars, I do agree the real life pictures often look better when available, though I am not so sure such pictures are required on the Mojang article anyways (if one is required, I am neutral on which to use).

As for LinkedIn, that seems like a pretty good source for information on the users, though I am currently having issues getting the site to display in English. (I take it the subdomain made the site think I am Swedish...). I think it looks like a reliable enough source to start adding to articles, though it couldn't hurt to make sure the profiles were made by the actual employees. –KnightMiner · (t) 02:37, 10 August 2015 (UTC)

I don't have much of an opinion on using the Mojavatars versus actual photos, but would like to point out that getting new Mojavatars is a simple matter of asking Jnkboy for them (assuming he still works with Mojang); this is literally the method I used to get the last version of them.

Of course, now that I think about it, it would be really awesome if we could get photos of the Mojangstas all wearing shirts with their Mojavatars printed on them, though that would probably be hard as hell to have done for several reasons. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:10, 10 August 2015 (UTC)

As for expanding their articles with more details of their lives and careers, two important factors need to be kept in mind: verifiability and desire for privacy. Verifiability should be simple enough; either ask each Mojangsta for some details to flesh out their article, or ask them to confirm if a given source has it right. Desire for privacy is a bit trickier but just as important; if a given Mojangsta prefers some detail not be included in their article here, we should respect that (note we made this concession for ez). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:22, 10 August 2015 (UTC)

Welp, I just got confirmation that Jnkboy is going to get back to making Mojang avatars; didn't say when though, so that takes the phasing away part out of the picture. Don't even read the rest of the tweets I sent him. Its very hush-hush. -BDJP ^(t|c) 11:58, 10 August 2015 (UTC)

Pocket Edition Alpha 0.12

Can we please decide what we're actually doing with these versions already? I've lost track of the various pagemoves and redirects by this point, and the situation doesn't seem to be getting any simpler from the perspective of the releases themselves; these are also part of what resulted in the editing restrictions currently in place on several editors.

This is my understanding of the version situation as it stands (note that I am pointedly ignoring the hot mess that is our article(s)):

• Pocket Edition Alpha 0.12.0 was released exclusively for Windows 10, with the version number "0.12.0"
• Pocket Edition Alpha 0.12.1 was released for mobile devices, incorporating the changes and bugfixes from 0.12.0, and adding/fixing a few more things (?)
• Windows 10 devices received 0.12.0.1

(If I missed anything or am mistaken in any details, please call me on it, or feel free to fix the summary directly.) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:16, 12 August 2015 (UTC)

Just to be clear, this is what I want out of this discussion:

• A clear and concise summary of the version/release situation
• A summary, with links, of any relevant statements by the developers
• Summaries of any relevant discussions that have already taken place, with links to those discussions
  • Where necessary, harmonization of the results of those discussions, and extension of those results to cover any details that weren't already handled
• A single, central location for any and all further discussion on this topic (meaning any currently-in-progress discussions should be summarized here and then pointers to this topic should be posted on them)

I don't care about the minutiae of implementing the decisions; that can be left to new discussions on the article talk pages themselves; what I want to see is a final decision on what those articles will be in the first place. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:27, 12 August 2015 (UTC)

You are correct, but 0.12.1 on mobile also adds the additions from 0.12.0. Here is my theory on what I want to do with these pages:

• Split them into separate articles, and while I know Win10 is MCPE, it can prevent this from happening again if 0.13 happens to be 0.13.0 (then 0.13.0.1 and so on) on Win10, then 0.13.1 on mobile devices. I've also discussed how the template for MCPE versions can be sorted out here.
• We can keep the pages as is and just add the template that I explained before.

--MarioProtIV (talk) 00:41, 12 August 2015 (UTC)

The current situation is basically Windows 10 got 0.12.0 released early, and now got a bug fix update called 0.12.0.1 (which is likely to fix incompatibilities with the new platform). The rest of the editions meanwhile are developing 0.12.1, which contains basically the same feature set.

As for developer statements, Tommaso says it is the same edition, and that most exclusive features are planned for the other MCPE versions, along with supporting co-op play between the two. He also stated that they will be developed together.

As for relevant past discussions: There is the first discussion, which was about merging the windows 10 edition article with the pocket edition article, which end undecided, leading to no action. The second discussion about splitting Windows 10 to its own articles, which ended with 0.12.0 being merged into 0.12.1. The last discussion I know of was about dealing with the later bug fix updates for the windows 10 edition, which lead to MarioProtIV moving all the articles, despite Illidicia disagreeing with separating the two editions.

As for a final solution, I suggest the Windows 10 Edition should be treated as another platform for the Pocket Edition. This means it will share a spot in the history section, the same version articles, same navigation templates, and same features articles (mentioned, removed, etc.). We have all the other pocket editions merged already, and have merged all the console editions, so I see no reason to split the windows 10 edition. (And a response to the likely argument of "they have slightly different features", I will say so do current and next gen console when it comes to the console edition, and I do not see that split.)

@MarioProtIV: I highly doubt the developers are going to not release the same builds on Windows 10 in future update, those have proven a much more stable method of releasing updates. In any case, I don't think we should completely split everything based on an assumption of the developer's plans. If it actually happens, then I might agree to split. –KnightMiner · (t) 20:09, 12 August 2015 (UTC)

For the template, this may be a good example: [snip] --MarioProtIV (talk) 20:36, 12 August 2015 (UTC)

@MarioProtIV  Agree I agree, except I believe the top should be like this: [snip] Note Windows 10 being under AlphaTySkyo (talk) 21:12, 12 August 2015 (UTC)

To quote Dinoguy above: "I don't care about the minutiae of implementing the decisions; that can be left to new discussions on the article talk pages themselves; what I want to see is a final decision on what those articles will be in the first place." This discussion is only about whether we should treat windows 10 as a separate edition. If and only if we agree to treat it as a separate version should we start discussing how we perform the split.

You both have already stated what you think should be done, but for the sake of a resolution, instead state why you think it should be done, give me direct reasons as to why we should split. As it stands, I still disagree with the split, and showing me another way to implement it will not change my mind. –KnightMiner · (t) 21:44, 12 August 2015 (UTC)

I think they should be split because of the following:

• Splitting would prevent a huge clutter on the version pages (this is for my sake apparently). It would also make the original 0.12.1 page more consistent with the other major update pages for the original MCPE.
• Splitting would also make it consistent with the other editions of Minecraft, just like how Pi Edition has its versions split into separate pages, even though it is based/built of off PE Alpha 0.5.0.
• It would create less clutter in the template as well, as listing the Windows 10 Edition versions in the original MCPE versions template, which just creates arguments/confusion.

Alas, if we decide not to split at all, we could do the following:

• Pocket Edition Alpha 0.12.0 would be restored to the revision before it was merged with the 0.12.1 page.
• Pocket Edition Alpha 0.12.1 would remain unchanged, just with the removal of the 0.12.0 release early for Win10 and the removal of the Windows 10 stuff.
• Pocket Edition Alpha 0.12.0.1 can be recreated.
• The template I explained above could be implemented.

Keep in mind if we decide to do the second option, on the 0.11.0 page (and sub-pages), it should still be necessary to have the nextparent thing link to 0.12.1 as it is the next major update to the original MCPE platform. But this is where people say "0.12.0 comes before 0.12.1 so it should be the parent version instead of 0.12.1." I have a solution for this. We can treat 0.12.0 and 0.12.0.1 as "pre-releases" (NOT OFFICIAL ONES), and we could add that to the version navbox. --MarioProtIV (talk) 22:16, 12 August 2015 (UTC)

As for the clutter on version pages, I think the only case of that would be on 0.12.1, which I agree should have the Windows 10 exclusive updates split from, basically as it was before 0.12.0 and 0.12.1 were merged.

As for the consistency part, I will point out that we have all the console editions merged, along with all the other pocket editions. The pi edition is an exception, as when it was released, it was never stated as part of the pocket edition, and did not contain all features from PE. In contrast, the console editions and all other pocket editions always received an exact or slightly better version of the relevant edition, and the Windows 10 edition is no exception.

With the navbox, it is not really cluttered from two exclusive versions; clutter would more likely be five to seven exclusive versions with no common releases. I would agree to split if 0.13.x/beta 1.0 keep the same format, but overall I think it would be easier to split at a later date if the update format changes, then to merge it the versions again if it does not.

Lastly, as a response to nextparent, it technically was an official release, but since most of the main update stuff would be covered on 0.12.1, I would agree to just linking 0.12.0 in the "next" field on 0.11.2 and calling 0.12.1 the next parent release. (I would still leave it first in the navbox though, as the parent release is already highlighted there pretty good.) –KnightMiner · (t) 00:01, 13 August 2015 (UTC)

I believe that Pocket Edition and Windows 10 Edition should be seperated and considered different versions as:

1. Mojang brands the Windows 10 Edition as a separate edition from Pocket Edition unlike Android, iOS, and Windows Phone
2. They already have different versions (ex: 0.12.0.1) and separating the versions would cause less confusion for readers and editors
3. While Windows 10 Edition is basically Pocket Edition is is still different in some ways:

• Uses a Xbox Live/Microsoft Account
• Has Multiplayer over Xbox Live
• Multiple control schemes (Touch, Controller, Keyboard)
• Has a built in GameDVR
• Has a player feedback mechanism

This basically means that there would be a seperate template for the Windows 10 Edition versions, seperate version pages for Pocket Edition and Windows 10 Edition(even if there are some versions that are the same, others still might differ) a seperate box for the Windows 10 Edition on the main screen ect.

I also think this should apply for the future HoloLens Edition as it will have some differences from Pocket Edition and Windows 10 Edition and is branded as a seperate edition like the Windows 10 Edition. Wolffillms (talk) 20:26, 13 August 2015 (UTC)

While this is conceiving and a good reason, I feel I need to reiterate this again: Windows 10 is Pocket Edition, because they can play with PE players in the release that co-launches with 0.12.1 on mobile. Also, this should be in the discussion above, since it regards the 0.12 issue. --MarioProtIV (talk) 21:49, 13 August 2015 (UTC)

I am aware the two versions are pretty much the same, but it is still branded as a different version, has some different versions, and is slightly different in some ways. Wolffillms (talk) 22:55, 13 August 2015 (UTC)

Please read the discussion above and direct all discussion on this topic to it. There is no point in having the same discussion in multiple places. –KnightMiner · (t) 22:29, 13 August 2015 (UTC)

I have read the discussion above, however all it is, Is going back and forth if the version article 0.12.0 should be split or not. I am talking about how Pocket Edition and Windows 10 Edition should be split. Wolffillms (talk) 22:55, 13 August 2015 (UTC)

Then this should be added to the discussion above for precisely those reasons. No split has been decided upon, so it is pointless to add to the same controversy in a seperate section. -Illidicia (t+c) 03:08, 14 August 2015 (UTC)

I think just simply having it the way it is now, while a bit cluttered, is the best solution. Ultimately future versions are most likely to be the same as on the Pocket Edition, and I think separating out these two Windows 10 versions will lead to more confusion. –Goandgoo ᐸ Talk
Contribs 07:28, 14 August 2015 (UTC)

 Agree, and those two pages (0.12.0 and 0.12.0.1) can be re-added if we go through with this. --MarioProtIV (talk) 13:07, 14 August 2015 (UTC)

 Disagree While the major updates will probably be the same, they will probably have different bug fix/minor updates (ex: 0.12.0.1) and there is still a chance of major updates being released on different dates (ex: 0.12.0). Also all of the above still applies "it is branded as a different version, has some different versions, and is slightly different in some ways". Also I fail to see how having them separate will cause more confusion, wouldn't having it less clustered be less confusing? Wolffillms (talk) 13:45, 14 August 2015 (UTC)

 Disagree 0.12.0 as well as 0.12.0.1 are separate updates from 0.12.1 and in the style guide it specifically says under article creation that each update gets a page. Also, this very similar to 0.11.2, and while this update was for only one platform it still got it's own page; this update is no different. Ergo, it should get it's own page.

22px TySkyo (Talk•Contribs) 01:13, 15 August 2015 (UTC)

Would any other admins like to state their opinions on whether we're going through with splitting or keeping as is? --MarioProtIV (talk) 13:55, 16 August 2015 (UTC)

@MarioProtIV:  Agree Admins should approve this. 22px TySkyo (Talk•Contribs) 22:18, 16 August 2015 (UTC)

I'm gonna take a guess everyone is siding with keeping as is now, if this is the case I can re-create the PE 0.12.0/0.12.0.1 pages. @Dinoguy1000: is this going to be the conclusion on what we're doing with the 0.12 pages? --MarioProtIV (talk) 17:29, 17 August 2015 (UTC)

Tagalog code

The Tagalog translation project currently uses the "ph" code. As stated on the project talk page, this is a bit... strange, as the Tagalog language uses the ISO 639-1 code of "tl", which is what is used on Wikipedia as well as my wiki, the Feed The Beast Wiki. Anyway, I'm proposing Tagalog translations should be moved to reflect the ISO standard, rather then what it is currently using (there aren't many Tagalog translations, so it should be easy to patch em' up without bots). -Xbony2 (talk) 00:46, 14 August 2015 (UTC)

 Agree, assuming your information is correct. The Blobs^16px 01:35, 14 August 2015 (UTC)

I'm guessing whoever started the project mistakenly used the ISO 3166 country code for the Philippines, whose official language, Filipino, is basically a formalized version of Tagalog. Needless to say, I  Support this, and honestly don't think you need to wait to make sure there's consensus for this change, since it's a purely procedural one to bring the project into line with SOP. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:01, 14 August 2015 (UTC)

Welp, I'll give it a day unless anyone has objections to say, and start moving stuff then. -Xbony2 (talk) 21:03, 16 August 2015 (UTC)

Moving complete :) I left behind the redirects, just in case- since "ph" isn't used as a language code, it shouldn't be in the way of anything. -Xbony2 (talk) 16:15, 17 August 2015 (UTC)

Thank button

Hey neat, when did we get a 'thank' button on the revision-difference page? – Sealbudsman (Aaron) frameless ^T/_C 19:24, 19 August 2015 (UTC)

ObelusPA2 requested it for the French wiki, and I also stated in that topic that I'd wanted to use it every once in a while. –KnightMiner · (t) 20:02, 19 August 2015 (UTC)

Well then thanks, you two! I always liked the atmosphere of friendliness that button can foster. – Sealbudsman (Aaron) frameless ^T/_C 20:24, 19 August 2015 (UTC)

How does it even work? The Blobs^16px 02:17, 21 August 2015 (UTC)

If you see an edit that you really appreciate, simply click the "Thank" button and it will notify the user that you appreciate their edit. See mw:Extension:Thanks for more information. –KnightMiner · (t) 02:25, 21 August 2015 (UTC)

I thanked Majr for this edit, it seemed appropriate. =D 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:36, 21 August 2015 (UTC)

Such a good idea, thanks:)-Swawesome75.76.97.188 23:47, 27 February 2016 (UTC)

Move pages to singular form titles

At the moment, the wiki is slightly inconsistent when it comes to pluralisation of page titles. The majority pages are singular (e.g. Redstone circuit, Attribute, Skin, Texture pack), however many are pluralised. I suggest changing the following: (pages with strikethrough have been moved)

• Achievements --> Achievement
• Languages --> Language
• Status effects --> Status effect
• Renewable resources --> Renewable resource
• Chunks --> Chunk
• Mobs --> Mob
• Blocks --> Block
• Items --> Item
• Commands --> Command
• Formatting codes --> Formatting code
• Key codes --> Key code
• Screenshots --> Screenshot
• Models --> Model
• Capes --> Cape
• Mods --> Mod

I am currently unsure of the following:

• Materials --> Material
• Data values --> Data value
• Statistics --> Statistic
• Drops --> Drop

It would be great to get feedback and a community consensus for these changes. –Goandgoo ᐸ Talk
Contribs

I absolutely disagree. In some situations, referring to something in plural form as a whole in a title can be useful. — Agent NickTheRed37 (talk) 13:18, 21 August 2015 (UTC)

I understand where you're coming from, which is why there are pages in the "I'm currently unsure" category. However, the problem lies in that we have inconsistencies between certain pages being singular, and others that could equally be singular but are plural (e.g. why is attribute singular but status effects plural, why is skin singular but capes plural, etc). –Goandgoo ᐸ Talk
Contribs 13:24, 21 August 2015 (UTC)

 Oppose per NickTheRed37. -BDJP ^(t|c) 13:29, 21 August 2015 (UTC)

#1, Is there precedent for this on other wikis?

#2, What about the opposite: moving them all to plural? Most of the ones you suggest seem more natural to state as plural. (personal opinion.) Do the other ones (you say most are singular) read well as plural? – Sealbudsman ^talk/_contr 14:36, 21 August 2015 (UTC)

I vehemently oppose any general proposal to move pages to plural names; it is wholly unnecessary and leads to increased complexity in linking, due to the inevitable impulse many editors have to avoid redirects where possible (and before anyone tries to say "that won't happen here", I have seen it happen on a wiki that decided to use plural page names; it continues to happen now, and every time I see an edit making that change, I cringe). And there absolutely is precedent for using singular page names: Wikipedia calls for singular page names as the norm, not the exception. Specifically, I support moving to a singular title the following pages: Status effects, Chunks, Mobs, Blocks, Items, Screenshots, Models, Capes, Mods; I am uncertain of Drops, but I feel the rest of them fall under one of the exceptions listed on Wikipedia's naming guideline, which I see no reason for us to diverge from (though if you think you have a compelling reason, you're welcome to try to persuade me). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:59, 21 August 2015 (UTC)

What you have listed makes sense to me. Several of the plural titles just sound odd as singular, and I think the reason is because they focus on the list rather than focusing on the title topic and simply providing a list.

As for Drops, I also am unsure about it, and even with my above definition it could go either way. –KnightMiner · (t) 01:41, 22 August 2015 (UTC)

What are the objections with moving renewable resources to its singular form? Also should particles stay plural or become singular? –Goandgoo ᐸ Talk
Contribs 02:56, 22 August 2015 (UTC)

With Renewable resources, my main issue is that the article is mainly about listing all the renewable resources, rather than describing to the player what is a renewable resource. It is sorta like a category in the end.

As for particles, while most of the article does contain the list of particles, its focus is describing a particle to the player, similarly to blocks. I may be getting a little nit-picky here though, as my requirement is basically me attempting to explain why one title sounds weird to me as singular and others do not, so it could use improvements... –KnightMiner · (t) 03:57, 22 August 2015 (UTC)

If you read between the lines of Wikipedia's policy page, it's basically saying that nouns that are always used as plural or mass nouns should have a plural title. With that much more straightforward definition in mind, it doesn't make sense to move Particles to Particle, since they are always talked about in plural (no one ever talks about a single particle, because the game never produces one particle at a time). But that particular case is still a bit hairy, and I'm kind of expecting someone to disagree with me on it. =) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 05:18, 22 August 2015 (UTC)

Ok, seeing we are simply following wiki naming conventions, I think I can safely move those pages that you mentioned. We can continue to discuss some of the other pages which are slightly more contentious. I think drop should be singular as drop is often referred to as singular. –Goandgoo ᐸ Talk
Contribs 07:46, 22 August 2015 (UTC)

I've moved the pages suggested above with the exception of Mods, because it has around 1000 subarticles which would probably be a nightmare to move. –Goandgoo ᐸ Talk
Contribs 08:08, 22 August 2015 (UTC)

I should be able to get my bot to do that, but since it is such a major change (due to the thousands of articles, plus the style guide requiring mod articles as subpages of mods), I want to wait until we are sure people agree with the move, even if the move is to reflect naming conventions. As a start though, I agree with the move. –KnightMiner · (t) 14:33, 22 August 2015 (UTC)

That does sound more reasonable then what I had, and I don't disagree with keeping particles under the current title. –KnightMiner · (t) 14:33, 22 August 2015 (UTC)

 Strong oppose These pages are about mechanics that have multiple types. Moving them would mislead. I think Renewable resource should be moved to Renewable resources. The Blobs^16px 23:03, 22 August 2015 (UTC)

Can you specify which proposed moves you're opposed to, or whether you're opposed to all of them? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:10, 23 August 2015 (UTC)

All of them. The Blobs^16px 02:15, 25 August 2015 (UTC)

There honestly hasn't been any good counterarguments for these page moves. I think we should discuss whether Renewable resource should be moved to its plural title (I was unaware of it already being singular), whether we should move Mods to Mod and Drops to Drop. –Goandgoo ᐸ Talk
Contribs 08:12, 25 August 2015 (UTC)

@Blobs2: Before you disagree with all of them, please note the style guide requires all titles to be singular, so unless you have a proposed amendment to the style guide to cover a common trait of those pages, they are just going to have to be moved to a singular title later to comply with the style guide. That being said, I think the criteria that Dinoguy proposed of "nouns that are always used as plural or mass nouns should have a plural title" sounds good.

@Goandgoo: Renewable resource and Drops both make sense as plural since they are almost always referenced in plural; you rarely see reference to a renewable resource outside of the category of renewable resources, or a drop without other drops present. And I have already stated my opinion on the mods article above. –KnightMiner · (t) 14:20, 25 August 2015 (UTC)

There are some articles which refer to the item being a renewable resource, and while it may not appear often, it still does make sense when used in context. Therefore I still think Renewable resource should remain as is. Drops should definitely stay plural as it is basically always used in the plural form. –Goandgoo ᐸ Talk
Contribs 08:30, 28 August 2015 (UTC)

In that case, I would agree with keeping the current renewable resource title. –KnightMiner · (t) 14:40, 28 August 2015 (UTC)

Actually, I  Agree because that is how it is done with other articles (such as Spider). The Blobs^16px 22:01, 29 August 2015 (UTC)

Alex skin variations

Can someone please upload the variations of the Alex skin from the default skin pack onto Skin? - MinecraftPhotos4U (talk) 19:09, 2 September 2015 (UTC)

I'm pretty sure there's already an image called Alex.png. Also, I'm not sure what you mean by uploading a file to a page. The Blobs^16px 14:21, 3 September 2015 (UTC)

The console edition has the default skin pack, which includes seven differently dressed variants of the default skin. They've been out for a while and have not been uploaded to the wiki. If you look at the skin page and lick Show next to Default Skin Pack you'll see what I mean. - MinecraftPhotos4U (talk) 19:56, 3 September 2015 (UTC)

Catalan Wiki

Hello,

I would like to open a Minecraft Wiki in catalan language. I know this project, but if we don't have an own wiki we won't get new contributors. My question is, what I have to do or how many pages must the catalan project have on this wiki to obtain the subdomain? Cheers, --NeoMahler (talk) 11:30, 8 September 2015 (UTC) edit: When I try to create a page in catalan, it appears a message that says:

An automated filter has detected that you are attempting to create a possibly unwanted page. As a new user, your action has been    disallowed.
If you believe your edit was constructive, please post a message on the admin noticeboard or notify an admin directly.

But I'm not doing anything wrong! --NeoMahler (talk) 11:42, 8 September 2015 (UTC)

There are a few requirements, but most notably is you must have a large enough community interest and create articles for redlinks from the main page and major navboxes. It is also worth mentioning that nearly all of the other languages started as a project here, and managed to get enough contributors before getting their subdomain.

Game widow could also likely offer a little more insight on getting a subdomain than I know.

As for that issue you are having, it means you are a non-autoconfirmed user adding things to a new article such as external links. After making a few edits (such as improving/updating earlier translated pages), that should stop. –KnightMiner · (t) 14:47, 8 September 2015 (UTC)

Well, now I was creating the Markus Persson page in catalan with only one sentence and no links, and I couldn't make it. Anyway, I will wat until I'm 4 days old and I have 10 edits. Thenks for commenting! --NeoMahler (talk) 10:50, 9 September 2015 (UTC)

There's not really enough Catalan translations to go independent, but it is possible to get that point in the future like many other projects have done. You'd probably need at least one other main editor with you as well, so if you disappeared there'd still be staff around to maintain the wiki. -Xbony2 (talk) 11:38, 9 September 2015 (UTC)

“Staff”? There’s no “editorial staff” as such on Minecraft Wiki, Xbony2! — Agent NickTheRed37 (talk) 16:35, 9 September 2015 (UTC)

"Directors", "Bureaucrats", "Administrators". Btw Nick, I can confirm mentioning via {{static link|}} does work, as debated on my user talk page on the FTB Wiki. -Xbony2 (talk) 20:54, 9 September 2015 (UTC)

Importing data from other article

Hi. I have a some problem with one of templates, but on my other wiki about other game (non-gamepedia). I ask here, because many of you have enough experience (I hope so) to help me with my problem.

I have a 'translating' template. There is a main code http://pastebin.com/WzuDenxz, where {{{1}}} is word to translate. Translating can be bilateral (?duplex?) (it depends on second parameter in other piece of template). Example:

This is a tree, and this is a sky. This is a drzewo, and this is a niebo.

When cursor is hover bold words, translate is show up in formatted tooltip, e.g. for tree will display "pol. drzewo", and for drzewo will display "ang. tree". Everything allright? Not exactly. To add new words, you need to edit sensitive template. One small mistake = many big troubles for almost every articles.

So my question is: how I can import phrases from external source (other template/article or optionally other website)? What addon I need install? And how I can implement it to main template? Sorry for my bad English :/ Lewandowski^{pl.Wiki Admin} talk 19:19, 18 September 2015 (UTC)

Impossible. The Blobs^16px 01:48, 19 September 2015 (UTC)

PE boats

There should be an image called Boats.gif. It would be used to show the boats in Pocket Edition on the boat page. The Blobs^16px 17:19, 19 September 2015 (UTC)

An animated gif that cycles thru the boats like the crafting recipe on the boat page? – Sealbudsman ^talk/_contr 19:20, 19 September 2015 (UTC)

I mean in the infobox. The Blobs^16px 22:17, 19 September 2015 (UTC)

Infoboxes support animation of multiple images, so GIF image is not necessary, all you need is just several separate images for each kind of boat. — Agent NickTheRed37 (talk) 14:51, 20 September 2015 (UTC)

We don't have all the images. It would be easier to upload one image than to upload six. The Blobs^16px 15:05, 20 September 2015 (UTC)

What do you mean by “easier”? Do you mean quicker? Then we have MsUpload and patience. And, using separates can be more flexible, since when using a single GIF only, you would need to upload a separate image for a single kind of boat when it is needed. — Agent NickTheRed37 (talk) 15:16, 20 September 2015 (UTC)

And if another type of wood ever gets added, it is a lot harder to update as you need someone with both modeling and gif knowledge. Thus the easiest way is separate images animated like we have done almost all the other pages. –KnightMiner · (t) 20:42, 20 September 2015 (UTC)

What is the MsUpload? The Blobs^16px 01:46, 22 September 2015 (UTC)

The "Drop files here" header on the editing screen. –KnightMiner · (t) 15:30, 22 September 2015 (UTC)

How do I make a list of pages in a category that the page is in?

I want to know how to make a list of pages in a category at the end of a page. What template would do that? Kivitoe (talk) –Preceding undated comment was added at 01:49, 21 September 2015‎ (UTC). Please sign your posts with ~~~~

{{#categorytree:Category|mode=all|hideroot}} –Majr ᐸ Talk
Contribs 03:09, 21 September 2015 (UTC)

How to make a template or make a list at the end of a page?

1). How do you make a template?

2). How do you make a list of pages in a category like at the end of this page, End City? –Preceding unsigned comment was added by Kivitoe (talk • contribs) at 3:12, 30 September 2015 (UTC). Please sign your posts with ~~~~

1. Writing a template can be complicated, depending on what you want it to do. wikipedia:Help:Template is a good place to start.
2. The list of categories a page belongs to is automatically added. See also wikipedia:Help:Category. -- Orthotope^talk 03:18, 30 September 2015 (UTC)

Replace x50px with x50px

I believe that the red Windows logo should be replaced with the purple one, as the purple logo is for the Windows Phone in general, while the red logo is for a specific model, which changes all the time and all the other OS's logos are the general image, rather that the current model/OS version. Wolffillms (talk) 22:53, 6 October 2015 (UTC)

 Agree Apparently, the red logo doesn't even exist. The Blobs^16px 20:58, 7 October 2015 (UTC)

 Agree Red logo was the Windows Phone 8 logo (going off of the wikipedia entry), but yes, they've retained the purple branding on the top of https://www.windowsphone.com/en-us and the bottom of https://www.microsoft.com/en-us/windows/phones – even though the current phone is the Windows 10 phone with sky blue branding. Is that where you are getting the idea for purple? The only thing I would add is that the purple logo is at slightly the wrong angle and doesn't match the angle from Microsoft; probably a new image should be captured. – Sealbudsman ^talk/_contr 21:42, 7 October 2015 (UTC)

I got the idea for the purple logo, as it is the general Windows Phone logo, rather than a specific model (red for Wondows 8 and blue for Windows 10). Also suppose a different version of the image would be better. Wolffillms (talk) 12:57, 9 October 2015 (UTC)

It requires Windows Phone 8.1, same as the Windows 10 edition require Windows 10. Should we change the windows 10 logo to a generic one too? –Majr ᐸ Talk
Contribs 13:01, 9 October 2015 (UTC)

I believe we shouldn't change the Windows 10 Edition logo, so it is not confused with the regular Windows version. Wolffillms (talk) 19:55, 9 October 2015 (UTC)

Nether Fortress in Minecraft PE

I have been looking for a fortress in the nether for over 3 weeks. Do the fortress's exist in PE?

Thanks, Garry –Preceding unsigned comment was added by Getw (talk • contribs) at 1:35, 10 October 2015 (UTC). Please sign your posts with ~~~~

Yes, they do. See Nether fortress. –KnightMiner · (t) 13:50, 10 October 2015 (UTC)

Try going east or west. You can figure out your direction in the overworked by the sun movement. Portals in the nether face the same direction as the version in the overworld. The Blobs^16px 22:50, 15 October 2015 (UTC)

Recent guideline updates

I have noticed with the large amount of different pages on guidelines that there is no easy way for a user to keep track of what new guidelines are added, so I would like to propose adding a list of recent guideline changes to the community portal article. It would basically just be a brief summary of what changed, a link to the relevant discussion, a link to the guideline, and a timestamp, and it would contain the last five or so changes.

So the main thing I am wondering is if anyone would actually use this, or if this is just some random idea that isn't needed. –KnightMiner · (t) 22:24, 25 October 2015 (UTC)

Personally I would appreciate it. As it stands I am not usually aware of changes. – Sealbudsman ^talk/_contr 02:46, 26 October 2015 (UTC)

We can add a box for all wiki news altogether. Russian wiki has it, but it is not much used. — Agent NickTheRed37 (talk) 14:46, 27 October 2015 (UTC)

Stating historical information when a block/item is used in a new crafting recipe

Should historical information be stated for when existing blocks/items are used in a crafting recipe for a new block/item? I've noticed that the wiki is quite inconsistent in this regard, for example the iron ingot page's history table lists when iron was used to craft anvils, weighted pressure plates and iron trapdoors, but not any of the other other items/blocks listed in the Usage section. If we decide to ensure consistency, it would be a matter of looking at the Crafting ingredient subsection of Usage and ensuring that when those blocks/items received a crafting recipe, they are listed in the history table and add the relevant information to the history table. It may be worth setting up a project (just like the Rewrite for Style project) so that pages aren't missed.

I know it may seem like a minor thing, but I believe there should be consistency over the wiki's pages either way. Thoughts? Opinions? –Goandgoo ᐸ Talk
Contribs 01:40, 31 October 2015 (UTC)

I  Support this. – Sealbudsman ^talk/_contr 03:43, 31 October 2015 (UTC)

 Neutral I personally see it as somewhat useful information, but mainly for crafting ingredients, and overall a lot of effort would be required to add it. So overall I just vote for a consistent approach across articles, whether it be either way. –KnightMiner · (t) 03:11, 1 November 2015 (UTC)

Yeah I see you've been going to town on this. Any estimate on how far along you are? Good job by the way. – Sealbudsman ^talk/_contr 03:27, 1 November 2015 (UTC)

I've actually finished it all - I've gone through all blocks and items and it should all be up to date now. Some pages were certainly longer to do than others (e.g. wood plank, diamond, stick, redstone, iron ingot etc). But at least there's now consistency over the wiki on this though. –Goandgoo ᐸ Talk
Contribs 04:37, 1 November 2015 (UTC)

Applause! – Sealbudsman ^talk/_contr 16:42, 1 November 2015 (UTC)

 Agree The Blobs^16px 01:36, 6 November 2015 (UTC)

Quotes on snapshot pages

I was wondering what people's thoughts were on putting developer quotes on snapshot pages. For reference there's a project whose aim it is to put developer quotes on pages, and I personally like the idea. I know there was a matter of whether it was consistent or not, but I guess "consistent with what" is my question. Consistent with the status quo would lead you to remove quotes, whereas consistent with the project would lead you to add them. Depends how you look at it. I see it like the snapshot images: if there is one, put one, if not, don't put one. Same with quotes. What do you all think? – Sealbudsman ^talk/_contr 04:45, 31 October 2015 (UTC)

 Agree I like the idea, it would certainly give some more interesting content to snapshots with are only bug fixes, and can help a few articles seem less like stubs. –KnightMiner · (t) 03:11, 1 November 2015 (UTC)

 Agree, makes rather boring pages more interesting. –Majr ᐸ Talk
Contribs 12:53, 2 November 2015 (UTC)

 Agree, added to the style guide. –Goandgoo ᐸ Talk
Contribs 07:06, 5 January 2016 (UTC)

Notch videos

We have some pages, like Version_history/Classic#References, that use youtube videos by Notch – but apparently he's recently removed minecraft videos from his account. I saw somewhere (reddit maybe?) that some other youtube user had mirrored them. What should we do; is it fine to link to the mirrored account, if we find it? – Sealbudsman ^talk/_contr 20:50, 13 November 2015 (UTC)

While a youtube account mirroring them can be useful for the references, we have no way to guarantee that they did not change any of the footage to add false references (thus every video would have to be independently checked by those who saw the original). I really don't know what the easiest way to go about doing that is, other than finding someone we know is trustworthy who uploads some of the videos, such as MCSpotlights who uploaded the first Cave Game video as an archive. (There also is the question of video copyright). –KnightMiner · (t) 00:57, 15 November 2015 (UTC)

Only use sources that are directly from Mojang (YouTube videos don't work). The Blobs^16px 02:47, 17 November 2015 (UTC)

Bug descriptions "controversy" Part II

Well, what a nice day for a fresh start on this topic that layed dormant for over five months.

Renewing the "controversy-that's-still-eating-away-at-me-due-to-my-condition" discussion from the twenty-sixth section in archive sixteen, I'm still  Opposed to changing the bug description in any shape or form. As what Munin said six months ago, rewriting titles are heavily subject to further and further rewriting by a generation of editors to this wiki. Keeping the titles as they should be can cause less edit wars and makes referencing easier. As they are quoted from mojang.com, they are immune to the grammar rules from the style guide, and per WP:MOSQUOTE, they should be quoted precisely. Those are the reasons why I opposed any changes to the bug description six months ago, with the exception of html formatting. -BDJP ^(t|c) 15:21, 14 November 2015 (UTC)

It is a nice day. What brings this up again? – Sealbudsman ^talk/_contr 15:31, 14 November 2015 (UTC)

1. Bug titles are no more subject to rewriting than many other types of wiki content, such as tutorials. If we make bug titles compliant with the style guide, we will either keep the revision as a better one, revert it for reduction of quality, or, which is less likely than the other two (and less likely than in tutorials or other places), have an edit war and a discussion about whether this edit is improvement or degradation.

2. Bug titles are no more official quotes than a Reddit post which is quoted by a developer when they write a reply to it. That this particular title is present as a quote on mojang.com does not mean (if we disregard implied rules) that we should use this particular spelling. Also, what if there is a bug fixed in this version but not written on mojang.com? Are you going to tell that an editor needs to figure out for each single title whether it can be rewritten?

3. Since when are Wikipedia manuals and rules in effect here without explicit references from local rules and guidelines (correct me if I am wrong, but I don't recall a reference to MOSQUOTE from MCW:STYLE)?

Also, if it will be decided that bug titles should not be changed, how are we going to reference that from articles which include bug fix lists? --GreenStone (judge me) 15:59, 14 November 2015 (UTC)

1. See the archived discussion, particularly Munin's response.
2. You clearly didn't read WP:MOSQUOTE, didn't you?
3. This edit.

-BDJP ^(t|c) 16:29, 14 November 2015 (UTC)

If we're treating the fixes as quotes, and applying WP:MOSQUOTE, that would require the use of attribution, sic for significant errors, quotation marks, "trivial spelling and typographic errors should simply be corrected without comment", and dispensing with typographical conformity – if that wiki rule is a rule we are explicitly applying in this case. MOSQUOTE doesn't seem to require as strict a character-for-character adherence as you have been advocating, if I understand you correctly, BDJP. For the record I think the standards of quoting in MOSQUOTE are better than a standard of precise quoting, as it would allow us to clean up garbage grammar, spelling, vagueness, etc. – though I'm not convinced that treating the fixes as quotes is the best idea. – Sealbudsman ^talk/_contr 17:01, 14 November 2015 (UTC)

Adding to User Greenstone's first point: there is no precedent on this wiki for locking down editing on a particular type of content with the purpose of pre-emptively preventing edit wars. Our method of preventing edit wars is the same as on all wikis, as UG alluded to.

Adding to UG's last point, I agree that if we're going to apply a new rule to lock down titles, we ought to have a disclaimer in the page itself: "Titles and bug lists are quoted from the bugtracker which has separate editorial standards and workflow, and are not to be taken as accurate lists or descriptions of what was actually fixed in this version the game" or some such. Because as it stands, I can easily imagine that a person could put an unwarranted level of trust in what the 'fixes' section says. A person who understands to what level to trust a wiki, that it is a self-improving collection of community-edited articles, is not going to immediately understand that we have chosen to not improve this content, and there is a danger there.

As for referenceability, no-one is going to change the actual reference number of the bug. Problem solved.

As for the discussion about quotations, I think that is probably the strongest point of BDJP's in my mind, because of the lack of relevant guidelines on this wiki, though my solution would be this: Put a disclaimer at the top of the fixes section that makes it explicit that the titles are descriptions and not quotes from mojang.com. That would make it easier to add explanatory comments like, "this was partially fixed but only for birch trees" or whatever. That would be a way of getting around the 'quotes' thing: declare them as not quotes. – Sealbudsman ^talk/_contr 16:33, 14 November 2015 (UTC)

Why is it bad for the wiki to be continually improved? If we lock down this, then why not just lock down the whole wiki from fixing grammar and spelling? That will really stop all those pesky edit wars we're apparently plagued with. This attitude seems generally anti-wiki.

Who says they're quoted from mojang.com anyway? There's no requirement to even use the issue tracker titles in the first place, they're just a good starting point and easier than writing your own. –Majr ᐸ Talk
Contribs 00:43, 15 November 2015 (UTC)

“	Who says they're quoted from mojang.com anyway?	„
	— Majr

Apparently, Munin.

“	@Sealbudsman, to put forth the argument you pointed out was missing: Bug titles should be immune to the normal grammar rules because they are quotes from an official website (even if the titles were originally proposed by random people, they appear now on a Mojang news post). Quotes should be quoted precisely	„
	— Munin295 on Minecraft_Wiki_talk:Community_portal/Archive_16#Bug_descriptions_controversy

-BDJP ^(t|c) 01:14, 15 November 2015 (UTC)

Well you did a good job of avoiding actually answering me. "Who says X?" is a rhetorical question. If you're going to take it as an actual question, it requires an authoritative source, of which Munin sadly isn't. –Majr ᐸ Talk
Contribs 11:34, 15 November 2015 (UTC)

No more than anyone else! Frankly, I assumed they were direct quotes because it boggles my mind that someone would not quote them precisely. On the other hand, while I stand by my previous argument, I don't actually care about this specific issue very much. —munin · 16 px 16 px · 21:03, 15 November 2015 (UTC)

(edit conflict)Snapshot posts often have a list of fixed bugs. However, we don't leave the rest of the release notes unedited, especially when they're unclear or nonsensical. The Mojang blog posts are a good basis for version articles, but I don't see any reason to treat that text as sacrosanct and uneditable; I'd rather have the wiki be as accurate, complete, and understandable as possible. If someone wants to see the text of the original blog post, there's a link in the references. -- Orthotope^talk 01:17, 15 November 2015 (UTC)

The majority of the users who change the title's after their addition are either new users or IPs, basically the type who would be discouraged from editing from a revert of them correcting grammar, or don't really have plans for editing beyond that quick fix. The main edit wars I do see over this topic always start with someone reverting grammar changes, then it being reverted back, each time with summaries that make no sense to a new user as they have no idea why worse grammar is preferred.

Other than that and beyond echoing what Sealbudsman or Orthotope said, I only have two other things to state. Firstly, the titles don't always properly respect the issue. A great example if this is MC-51447, where the title originally did not include "on smooth lighting", but was later changed as it was fixed on standard lighting. Then later it was closed in favor of separating the smooth lighting part to a separate issue, but the title never was reverted thus making it seem to a reader of the page that the smooth lighting issue was fixed.

Secondly, I think the titles are better off as a description than as a quote. A lot of times I read the snapshot pages wondering what was fixed, and I'd rather not have to click on every single bug report link just to understand what was actually fixed, instead just clicking on ones I want more information about. –KnightMiner · (t) 03:36, 15 November 2015 (UTC)

I don't believe that fixes need to be quotes. Some users (like me) notice features while playing and do not use additional research, in which case there would be no quote. The Blobs^16px 02:54, 17 November 2015 (UTC)

GreenStone's analysis

As of now (15:25, 18 November 2015 (UTC)), I have analyzed the following approaches to the bug description problem:

1. Disallow any modifications to bug descriptions. Mark all sections containing bug fix lists with a template which says that bug descriptions should not be edited.

   Advantages:

   • This system requires minimal initial work for editors. Just copy the descriptions from the bug tracker or mojang.com, and mark the section with a "do not edit the descriptions" template.
   • This system allows to immediately identify any edit which modifies any descriptions as a violation of the style guide and revert it. If my understanding of the term "edit war" is correct, this will exclude edit wars as correctness of an edit can be immediately determined.

   Disadvantages:

   • This system does not handle that bug descriptions on the bug tracker can be modified (they can be modified there, right?). Every edit which modifies descriptions must be verified by checking the bug tracker. See also: Rejected approaches, 1
   • The descriptions on the bug tracker are of various quality, ranging from perfectly fine to garbage. If we implement this approach, we'd be essentially telling editors "These titles may be garbage, but even if that is the case, you mustn't edit them anyway". How is that a good resolution to the problem? Also note that bad bug descriptions may force a visitor to read the bug tracker page in order to get an idea of what's fixed.

2. Allow only minor edits to bug descriptions (such as trivial typo and spelling fixes as defined in MOSQUOTE), mark all significant errors with sic, and (probably) mark all sections containing bug fix lists with a template which says that major edits to bug descriptions should not be performed.

   Advantages:

   • As rules of a language are not as dynamic as generations of wiki editors, this system is capable to both require a rather small amount of work while creating little opportunity for edit warring.

   Disadvantages:

   • This still doesn't do much in cases of descriptions which are of very low quality and would in theory require major edits.

3. Allow minor edits to bug descriptions, also allow major edits if and only if the description contains an insufficient amount of information useful to editors (so, for instance, "Redstone BUg" [sic] would be edited, but "1.5 Odd Mob 'Magnetized Attraction' behavior" would not be). Also probably a message template (yes, again).

   Advantages:

   • This minimizes the number of major edits so that the edit war potential is minimal while the worst titles would be replaced.

   Disadvantages:

   • Some rather mediocre descriptions remain and cannot be edited. Potential problems may occur when interpreting "insufficient" (and I have trouble finding words that would be less ambiguous).

4. Full style guide compliance (so all minor edits are allowed and encouraged), and major edits may be performed whenever a description can be significantly improved. It may (not certain about this) be stated in the style guide that major edits are somewhat discouraged.

   Advantages:

   • This is the approach which is closest to how the wiki generally operates. This solution also does not require any templates in the top part of bug fix sections.
   • This maximizes potential quality of bug fix descriptions.

   Disadvantages:

   • This solution also maximizes the edit warring potential. I do not find it to be a significant problem. After all, have there been any wording edit wars on this wiki within the last 2.5 years?
   • This solution requires more work for editors than the other solutions.

My preferences are (in descending order) as follows: 4, 3, 2, 1.

Rejected approaches:

1. Same as approach 1, but without updating bug descriptions. While even easier for editors, this is far less constructive in terms of "garbage that shouldn't be edited".

Please do not edit this analysis (if it needs to be edited, I will do that myself) and post your feedback below the horizontal rule.

--GreenStone (judge me) 15:25, 18 November 2015 (UTC)

---

This doesn’t look as good as the final analysis of the Shulker problem, but  I agree with the results. — Agent NickTheRed37 (talk) 17:13, 18 November 2015 (UTC)

Whether it looks as good as that discussion or not, thanks for linking it, it was enlightening and diverting. – Sealbudsman ^talk/_contr 18:16, 18 November 2015 (UTC)

 Strongly agree with approach 1 and  Strongly oppose approaches 2, 3 and 4. -BDJP ^(t|c) 17:52, 18 November 2015 (UTC)

Any specific reason why you agree with 1 and disagree with all others? Is it just based on the advantages of the first and disadvantages of the rest? –KnightMiner · (t) 23:27, 18 November 2015 (UTC)

"Is it just based on the advantages of the first and disadvantages of the rest?" Yes. -BDJP ^(t|c) 23:56, 18 November 2015 (UTC)

Per my above comment, I  Agree with approach 4 (thus disagreeing with the rest). I see no reason the titles should be treated as quotes, as the only benefit to treating them as quotes is that they are the same as another website, of which the titles used on that site have no value as a quote (as said quotes are from members of the community just like the editors here). The titles may help slightly with identification, but that is really what the number should be used for. And yes, it is easier to start with the tracker's titles, but no one is forced to fix them when adding them, and there is no good reason to revert someone else's work if they decide to fix the titles up. This is a wiki after all, where the goal is to improve constantly.
On a couple more specific points, the typos and formatting used there serve no benefit to the issue, so why keep them the same? Why preserve the mistakes? Also, the title is suppose to be a description of the bug or a summary of the issue, and if the description fails to describe the issue, what is the point of adding the title here at all? –KnightMiner · (t) 23:27, 18 November 2015 (UTC)

 Agree with 4. I don't see any reasons why the bugs should be immune from the style guide/general wiki convention in favour of correct capitalisation/readability. Titles like "minecart name lost" and "shulker collision box" are incredibly vague and would benefit from some proper rewording and explaining further what the bug actually is. –Goandgoo ᐸ Talk
Contribs 05:35, 19 November 2015 (UTC)

 Agree completely with 4, for all the previously stated reasons. –Majr ᐸ Talk
Contribs 05:44, 19 November 2015 (UTC)

 Agree with 4. –LauraFi - talk 19:05, 25 November 2015 (UTC)

 Agree most with 4. I don't remember edit wars in this section ever having been a problem – people usually appreciate a constructive edit when they see it, and in case of difference of opinion there's no reason not to just figure it out on talk pages, that's always been the way. – Sealbudsman ^talk/_contr 07:30, 28 November 2015 (UTC)

Currently there are 5 people in agreement with approach 4 and BDJP007301 siding with approach 1. If there are no more responses opinions from new contributors, I think we can safely side with approach 4 at the start of the new month. BDJP007301, is your objection to approach 4 purely due to your condition rather than its merits? –Goandgoo ᐸ Talk
Contribs 03:53, 26 November 2015 (UTC)

Clearly, I would say it is due to the following disadvantages given in approach 2, 3, and 4:

1. Edit warring
2. Edit warring
3. Even more edit warring.

If you don't feel like you need to see my user page, let me just say that effective December 1, 2015, I will no longer be working on Fixes sections in protest of this unanimous decision to comply with the style guide in terms of "tracker titles". Personally, I feel like a couple of Mojang employees should also get involved in this discussion. I'll see if I can contact them on Friday. -BDJP ^(t|c) 04:28, 26 November 2015 (UTC)

Then, in turn, why are you worrying about edit warring? If you are tired of it, then it is just a personal matter. — Agent NickTheRed37 (talk) 16:32, 26 November 2015 (UTC)

The date is 2015-12-03. Do we need to wait a bit more? If not, can we start working on a draft? --GreenStone (judge me) 14:49, 3 December 2015 (UTC)

I feel like there is now adequate agreement among the majority of users. Would someone care to draft something for the style guide on this matter? –Goandgoo ᐸ Talk
Contribs 07:02, 5 January 2016 (UTC)

I've written up a draft below in #Proposed style guide addition. I figure it is best to be kept in the same discussion rather than branching off to a little seen talk page. –KnightMiner · (t) 15:38, 5 January 2016 (UTC)

Mojang's response

So, it appears Erik Broes has responded firsthand:

	“	I do not think we edit them a lot, we can shorten/make them 'understandable'. In reality only the ticketnumber matters.	„
		— Erik "Grum" Broes on rewriting bug descriptions

-BDJP ^(t|c) 05:56, 27 November 2015 (UTC)

A couple things in response to this:

1. I don't really see the need to get Mojang employees involved in this - the wiki is independent of Mojang and as such its editors should be the ones making the decisions. Other changes to the style guide have been made without Mojang intervention, so I don't really see why this needs to be an exception. Nonetheless, it is nice to see Mojangsters responding to the community and taking the time to potentially engage in wiki discussions.
2. Grum's response here essentially agrees with approach 4 - "In reality only the ticketnumber matters." This implies that as long as the ticket number is same, edits can be made to clear up confusion and to "make them "understandable". –Goandgoo ᐸ Talk
   Contribs 00:36, 28 November 2015 (UTC)

Proposed style guide addition

Seeing as most people agreed with GreenStone's fourth approach, here is it written up as a style guide draft, with a few related things added from earlier discussions. Feel free to suggest improvements. This text would be added to MCW:Style guide/Versions#Fixes:

It basically saying you don't need to go to every article and fix the issue titles or rewrite the titles as you add them, but don't stop someone else if they are doing it. It also says if you are rewriting to try and make the original wording work, but don't avoid rewording if the original title has problems. –KnightMiner · (t) 15:38, 5 January 2016 (UTC)

 I support this addition. — Agent NickTheRed37 (talk) 15:56, 5 January 2016 (UTC)

 Support. –LauraFi - talk 18:55, 5 January 2016 (UTC)

 Support. – Sealbudsman ^talk/_contr 05:06, 6 January 2016 (UTC)

 Support. –Goandgoo ᐸ Talk
Contribs 03:42, 18 January 2016 (UTC)

Sigh...  Support. *Cries away in a corner* -BDJP ^(t|c) 01:07, 7 February 2016 (UTC)

Name over player's head

Is there an article that covers this, including at what range can you see the name, what affects its visibility, etc? It didn't seem to be in player. – Sealbudsman ^talk/_contr 18:09, 25 November 2015 (UTC)

I don't think any article covers this at the moment, perhaps it might be useful to state this on player. –Goandgoo ᐸ Talk
Contribs 03:49, 26 November 2015 (UTC)

It's mentioned briefly in sneaking, but a more thorough description would be worth adding. -- Orthotope^talk 04:22, 26 November 2015 (UTC)

Someone else would have to contribute the info; I don't have the opportunity to play multiplayer much, to figure it out myself. I remember being able to sneak to hide, but I don't remember all the fiddly details. – Sealbudsman ^talk/_contr 07:34, 28 November 2015 (UTC)

MinecraftEdu

1.8.8 -> 1.8.x

Could someone get a bot to change the version nav prevparent on 1.9 snapshot pages from 1.8.8 to 1.8.x? – Sealbudsman ^talk/_contr 16:28, 9 December 2015 (UTC)

 Done. –KnightMiner · (t) 02:06, 10 December 2015 (UTC)

Thanks! – Sealbudsman ^talk/_contr 05:10, 10 December 2015 (UTC)

Possible bug with my userbox

Hello. Why my userbox wrote that I had the experience of 0 days, but I'm here 0.9 years. Fix this bug, please. 16px Happy New Year! Regards, GRAND RADION (talk) 13:30, 26 December 2015 (UTC)

You are incorrectly calling {{gsd}}. All template parameters names must be lowercase, not capitalized at the start. Though really you don't need a userpage template for the age in days part when we have {{age in days}} which does the exact same thing. –KnightMiner · (t) 15:36, 26 December 2015 (UTC)