Minecraft Wiki talk:Community portal/Archive 15

Official Minecraft Wiki application for Android?
Hello ! I often use Wiki in my smartphone with Android. Unfortunately, the site on Android have many mistakes (eg. text is only at left side, images doesn't load or they disappear). It's really frustrating. So I have idea - application for Android wich can be downloaded from Google Play. But someone else must make it because I don't have enough time to make this project. How about you? Please write what are you thinking about that. Sorry for my English. -- 14:42, 2 January 2014 (UTC)


 * YES! and IOS app too, but it could be an offical Gamepedia android app, so every game in gamepedia has one. --- Tonkku107 (|) 14:45, 2 January 2014 (UTC)


 * See . An wiki app isn't practical, it is a far better use of resources to improve the mobile site. Post screenshots of things that are broken or need improvement. – ᐸ  ⎜ 14:49, 2 January 2014 (UTC)


 * I just use the desktop site instead of the mobile one on my Android.
 * 08:07, 13 March 2014 (UTC)


 * Have you tried the mobile site at all? And if so, what are your reasons for not using it? – ᐸ  ⎜ 11:08, 13 March 2014 (UTC)

Deleting images
Hiya, infrequent wiki-editor here. Apologies if this question has been asked before, or if this is the wrong place to ask it, but I'd like to know: If I think there's a reason for an image uploaded to the wiki to be deleted, what should I do? 09:52, 7 January 2014 (UTC)


 * Add  to the file's description page. You can also comment on its talk page, if you're less certain it needs to be deleted or feel more explanation would be helpful. -- undefined 10:00, 7 January 2014 (UTC)


 * Thank you very much.  10:47, 7 January 2014 (UTC)

Greek Minecraft Wiki
There are quite a few pages with /el subpages, so I would like to propose a Greek translation of this wiki. I have contacted Curse staff, and the staff member that replied says to ask the community. Opinions? ~ 23:28, 16 January 2014 (UTC)


 * Translation projects generally only get their own wiki when they are reasonably complete and active. There are currently only 25 pages in, most of which haven't been worked on for at least six months. At this point, it isn't ready for its own wiki; it needs to have active translators, and to have a lot more well-translated pages. (Note that running pages through Google Translate does not count as a good translation; a fluent human editor needs to be involved.) -- undefined 09:26, 17 January 2014 (UTC)


 * If I was to translate much more pages into Greek, would that be worthy of creating a new wiki? If I create a wiki, I edit it frequently, so it would be no problem to have at least half as many pages as the English wiki in maybe a day. About Google Translate: I do not use it. I may use it for a word I can't remember (single words usually translate more accurately than phrases or sentences), but that's about all. I can change the input of my keyboard so that it functions like a Greek keyboard (so I can type at normal speed and not have to go back and forth between the "Special Characters" tab of the toolbar and the edit window). ~ 10:52, 17 January 2014 (UTC)


 * First off, we don't vote, we discuss. Secondly, needs to have all the primary links translated before a subdomain will be created. And I mean, the pages that the links point to need to be fully translated. As it stands, most of those links point to the English pages. That is not resolving the links. If the Greek community wishes to have a subdomain, they need to get active in translating. I also won't create a subdomain if there is only one person working on it, because eventually, you will get burned out and stop, and we will end up with a dead wiki. --    13:42, 17 January 2014 (UTC)

Use of pronouns for player and Steve
I'm considering going through the pages and changing uses of "he" and "he/she" to "They" (I've already fixed the ocelot and player pages). After all, the player could be of a gender that doesnt use he or she pronouns, or simply doesnt use either. They is a catchall pronoun and commonly used as a singular gender-neutral pronoun. I think this would be a good idea so everyone is included; especially on articles which just refer to the player as "he". The wiki is intended for everyone, not just for people who are in the gender binary. Also, Steve was confirmed to be agender, so they shouldn't be referred to by male pronouns.


 * Notch himself, who named Steve (originally "Steve?") said that Steve is genderless. "They" or "it" would be the best pronoun to use in my opinion. ~ 01:09, 23 January 2014 (UTC)


 * The recommends using the Player. – ᐸ   ⎜ 01:28, 23 January 2014 (UTC)

Animated texture
How can I turn an animated texture into a .gif? -- «  » 18:31, 31 January 2014 (UTC)


 * Check the documentation for your image editing program; most competent ones can make animated gifs, but the exact process varies. -- undefined 19:53, 31 January 2014 (UTC)

Armor Page Split
First suggested by admin Majr, he suggested that the Armor page should be split up into 5 pages - 1 for each armour part, and one for a basic overview of armour/properties etc. The individual armour parts (i.e. , , , will detail information specific to those items, e.g. crafting recipe, statistics, etc. Also, the armor page is very long, as you can tell by the massive info box on the side. Splitting it should allow the page to load faster for all devices.

I will collate these pages on my user page, then transfer it over if there is enough support. Please comment below whether you support this change. – ᐸ   09:18, 2 February 2014 (UTC)


 * I think it makes sense to move item info box(es), crafting recipes, item history, etc. to item-specific articles, but much of the rest of the info is useful to have in a compare-against-each-other format, so I wouldn't want to see that split up (they might be reproduced on individual pages, but should also be on the armor page). &mdash; &middot;  &middot; 11:14, 2 February 2014 (UTC)


 * I would actually suggest a sixth page as well, for "Armor mechanics". The basic armor point and durability tables would be on the main Armor page, while the detailed analysis, formulas, and enchantment information, would be on the "mechanics" page.  Also, I'd suggest keeping the grand list of recipes on Armor, but make it default-collapsed (and perhaps loadfiled). --  14:19, 2 February 2014 (UTC)


 * It seems like no-one is objecting to creating separate pages for each of the armor types, so I will go ahead with doing that. However, I am unsure how much material should be left on the Armor page, and whether an Armor mechanics page is a good idea. – ᐸ    07:00, 4 February 2014 (UTC)

PS3 acknowledgement under Upcoming Features
I know this may be trivial but it would be nice if under upcoming feature the PS3 version would be linked as it should even if it is a replica of the Xbox 360 version.

Random page
I think there should be a random page option for the wiki. All the other wikis have one and I enjoy randomly finding pages.


 * . – ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 16:52, 10 February 2014 (UTC)

Merging Cook-able Food Articles
I noticed the fish article was all merged, including Cooked Fish, and I would suggest the same with chicken, beef, pork, and potatos. When looking over raw and cooked steak, I noticed the articles had basically the same information, except each one had it's own hunger information and data value. -- ( 15:16, 15 February 2014 (UTC)
 * My personal opinion is that as many items should have their own pages to avoid confusion. --▶ ◀ ( 14:05, 21 February 2014 (UTC)


 * Then I would suggest splitting Fish into normal and cooked, to keep it the same. -- ( 18:25, 21 February 2014 (UTC)


 * --▶ ◀ ( 21:59, 21 February 2014 (UTC)

blurry minetips
Here on my Mac, running Chrome 32, the (minetips) have a blurry font, unlike the reference image. This is pretty annoying, does anyone know why this happens? — 11:06, 19 February 2014 (UTC)


 * I don't know about Mac, but on Windows if you use DirectWrite it seems to apply a blur to all text. This looks fine for normal font where sub-pixels make the font look smoother and easier to read, but not for font where the pixels line up exactly. This doesn't happen on any Linux distribution I've used, whatever font rendering used looks identical to DirectWrite's superb quality, but doesn't unnecessarily blur things.
 * Until browsers add a way to specify which font rendering to use, the only way to fix it on Windows is to go back to GDI (disabling hardware acceleration seems the easiest way), which then makes all font not so smooth. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 12:19, 19 February 2014 (UTC)

Finding Translation Projects
I've realized that most Translation Projects doesn't have that many active users. I'm in the and it took me ages after ive created my wiki account to discover the Translation Project. I think that if there was an easier way than just randomly finding them, the translation projects would have more recruits. Best Regards ▶ ◀ ( 14:15, 21 February 2014 (UTC)


 * Hello, I have just started in the and I cant find any project leader. In fact very little have been done in several years. The users seem inactive too.

I guess I then may decide by myself how to translate words that can't be translated directly? And edit the other articles to fit to the style I use on my articles. And change layouts that I think I can do better. I mean, if it isn't anyone there to ask if my edits are okay, and if I do what I can to make it look more tidy, then I can just go on? :)  14:13, 24 March 2014 (UTC)


 * By the way, most of the articles that are done, have grammar with frustrating low quality, and are completely outdated. It looks like it will be a one-man-project for a while, and that I should clean up from scratch even before I start translate more myself. I had a sneak peak on the Swedish projects, and there it was some equally poorly translated swedish. ( I cant write swedish very good but its very similar to norwegian and Danish) Alas :P  12:07, 25 March 2014 (UTC)

¨
 * Yeah I've also seen that the translation projects arent that active at all, and also most of them are outdated and poorly translated. And that I think is caused by just translating the english version instead of freely writing and get information from the english Minecraft Wiki. Also, I don't really enjoy translating the articles themselves, I like translating templates more. But again if we could find a good way to recruit people to the Translation Projects they would probably be more active and more users can fix grammar-issues and keep the articles up-to-date. ▶◀ ( 08:12, 14 April 2014 (UTC)

Awards on minecraft wiki?
Is this something to be considerated? Maybe not that huge amount of different awards, and preferably a minecraft inspired award system. But minecraft wiki should definitively have an award system ^^   23:11, 24 March 2014 (UTC)
 * It's probably a great idea to give people motivation to continue contributing but the what should the prizes consist of? ▶◀ ( 08:15, 14 April 2014 (UTC)

How do i know if I have vanilla minecraft or not
well i see many people saying that they have vanilla minecraft or bukkit but i am not sure what mine is, i have 1.7.5 version of minecraft and i have done everything i could to find out if it was vanilla or not? i really have no idea and i am guessing that its something super obvious and im just not getting it-- 22:21, 26 March 2014 (UTC)
 * Most people consider vanilla to if you've installed mods or not. The solution is pretty easy; If you've installed mods, you are not playing vanilla. ▶◀ ( 08:17, 14 April 2014 (UTC)

I should've done it earlier, but....
I just merged my account today, because I haven't had any time then and I just... forgot about it, so I did it today. Why is it telling me my account name wasn't able to be merged, and why do I have this login name with random numbers at the end? And where is my profile? 03:13, 27 March 2014 (UTC)

Why does my character keep talking as i walk?
My character keep talks or saying things as i walk and didnt before? if i walk on stone he just keeps going " stone stone stone stone" lol how do i stop this?

Check your calendar :-) -- 17:44, 1 April 2014 (UTC)


 * Exactly, today is April Fools' Day!   <span style="color: #CC0000">es.Wiki Admin ''' (') 18:00, 1 April 2014 (UTC)

the villager prank :/

Font changing on user talk
Just a question, am I allowed to change the font on my talk page? ▶◀ ( 13:30, 15 April 2014 (UTC)


 * Yes, within reason. As long as it's still easily readable, I don't have a problem with it. -- undefined 14:26, 15 April 2014 (UTC)

color write
How do Write in chat color???
 * There's a nice list of you can use to change text colour. I hope this helps!   12:56, 17 April 2014 (UTC)

No Captcha
I found a security problem about editing pages. I found a missing thing in the page's history (Console Edition TU14) When i fixed that, no captcha appeared to confirm that i wasn't a spam bot. Without captchas even a bot can randomly edit the page, damaging its integrity. Please fix this! (sorry for my english) –Preceding unsigned comment was added by ( • )&#32;12:42, 25 April 2014‎&#32;(UTC). Please sign your posts with


 * In general, Curse wikis allow editing by anonymous (unregistered) users. Captchas are used in some situations, but have a tendency to be glitchy and not work well for some users. However, there are other filters in place that block the majority of the attempted spam and vandalism. -- undefined 15:57, 25 April 2014 (UTC)

What happened?
I haven't been on the wiki for about a week until today, and I was just wondering... what the heck happened? <span style="color:#4372aa;font-family:times">~ 22:54, 10 May 2014 (UTC)


 * Are you asking about the profiles? or just a general list of events? or what is new in minecraft? -- ( 02:16, 11 May 2014 (UTC)


 * Profiles, friends, why I'm getting notification emails every few seconds when I've specified not to send any. <span style="color:#4372aa;font-family:times">~ 10:43, 11 May 2014 (UTC)


 * For profiles, they are a new way to show a bit about yourself, and apparently it stretches across gamepedia accounts. See here for a bit more information. I think friends are along the same line. And as for the notification thing, there is a new notification tab in the preferences to turn it all off (if you haven't tried that yet) -- ( 13:32, 11 May 2014 (UTC)


 * Thanks. <span style="color:#4372aa;font-family:times">~ 00:45, 12 May 2014 (UTC)

Annoying spam filter blocks my site
I tried adding my map reader program to, but the edit failed because your spam filter blocked my url http://mapreader.at [NOT SPAM] space.co.uk/. This makes no sense, there's nothing wrong with my page and it is not spam. In fact, I asked more than 6 months ago on the Talk page if I could just add my program. Since nobody replied all that time, I just went ahead and added it anyway. Also, nowhere in the progress was I ever told that some web hosts were blocked. The url posted fine in the description of the accompanying image, and there were no warnings or errors on 'Preview'ing my edit. Anyway, someone, please add the url (remove the " [NOT SPAM] " message, it wouldn't even let me ask this question), it doesn't make sense for an online tool to not have a url associated with it, thank you. And someone, PLEASE kick the spam filter very hard, it is stupid. 16:36, 31 May 2014 (UTC)


 * I don't see a mention of this in the filter logs. It's probably an automatic restriction based on the number of edits you've made; once you're in the autoconfirmed user group, this should no longer be a problem. -- undefined 20:00, 31 May 2014 (UTC)


 * That's not the error I'm getting, see attached image. It clearly says that url triggered the spam filter. If it was based on the number of edits, then the error message is wrong. Also, that would mean that, if finally I'd get my url on that page, every time someone tries to edit the page, the spam filter will find the offending link and stop the user from posting, right?  16:17, 1 June 2014 (UTC)


 * Should be fixed now; sorry about the inconvenience. -- undefined 01:11, 2 June 2014 (UTC)


 * Thanks a lot, that works! :)  17:30, 3 June 2014 (UTC)

Transferring content from wiki.vg
We have been contacted by the people from wiki.vg about transferring their content to here. Their wiki hosts information about minecraft development, which could augment the we already have.

We will also need to decide where to put the content. It has been suggested to put it in a Development: namespace, however I'm always wary of namespaces being used simply as a category, so we should decide if there is value in having this namespace. For instance: could there be a lot of naming collisions between development related pages, and other types of pages; and is there enough of a separation between development related content and other content to justify a namespace?

Please leave your comments below. If transferring the content is decided to be favourable, it will be imported by their admin. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 02:16, 4 June 2014 (UTC)


 * Interesting, looks like a lot of it is documenting the network protocol, while we have more on file structures. Might be useful for developers to have all the documentation in one wiki. Looking at wiki.vg/Special:AllPages, it doesn't look like there'd be many collisions with existing pages. If it's really needed for naming disambiguation, we could use a pseudo-namespace like we do with tutorials. -- undefined 02:42, 4 June 2014 (UTC)


 * Some interesting stuff there. And I agree with Orthotope that subpages of Development might be a good place for them, or use development as a hub article linking to the various ones. Would just the information be imported or the entire wiki (users, edit history, ect.)? -- 15:06, 4 June 2014 (UTC)

New Feature?
I was playing some survival single player on the 14w29b 1.8 snapshot and I noticed my lily pad spread like a vine! I am not sure this is an intended feature or if it is a bug?

Image Guidelines
Hi there. I asked about this on the talk page for the a while ago, but I guess that page isn't very busy. I can't find any guidelines for images, and what they should and shouldn't contain. Can anyone offer any information? 22:21, 27 June 2014 (UTC)

Can no longer log in / account does not exist?
I used to be LB, then LB725C when merged with Curse, and then via Curse I changed my account to LB_ with an underscore at the end. My 30 days of being logged in expired and now I cannot log in again, and it seems my account doesn't exist because it tries to ignore the underscore. When I click on my username via one of my contributions (e.g. this one) it says that user is not registered. I have no idea what I should do, can anyone help me? I can still log into Curse just fine. 21:39, 12 July 2014 (UTC)
 * OK, so when I log in with my email address, it says the supplied username is invalid. I am pretty sure it has to do with the underscore because all the links initially have the underscore but it gets stripped when the page loads. Still no idea what I should do. 21:48, 12 July 2014 (UTC)


 * Yeah, the underscore could be the problem. I'd try contacting, see if someone at Curse can get your account straightened out. -- undefined 22:29, 12 July 2014 (UTC)
 * I'm quite sure that is the issue, but I don't know the solution (yet). I have kicked this up the chain and should hopefully have a fix soon —  00:49, 13 July 2014 (UTC)


 * Thanks guys, I appreciate it. Let me know if there's anything I have to do. 00:56, 13 July 2014 (UTC)
 * I've issued LB_ a global rename credit for now. The Gamepedia platform doesn't support leading or trailing underscores for the time being, so you'll need to choose something without either of those. We'll be looking into putting a block in place so that people don't experience this issue inadvertently with renames in the future! Sorry for the trouble. -   00:57, 13 July 2014 (UTC)


 * Thanks for the help! I'm able to log in with my new username now. <font color="green" style="text-shadow: 0px 0px 8px #0f0;">( 02:32, 13 July 2014 (UTC)

I think we must have a discussion about these filters
Firstly,there is a filter which disallows new users to remove sections.But there are lots of reasons to remove a section.(For example,Removing spam/nonsense,etc.) Secondly,new users may not add external links.I saw a discussion at .I disagree because useful links is much,much more common then spam.Thanks.Please share your thoughts below. 07:04, 17 July 2014 (UTC)


 * The filters mostly prevent nonsense sections from being added, and you only need to have 10 edits to not be considered a "new" user, so most editors will have no problem removing the small amount of vandalism that gets though. Anyone can add external links, only spam links and URL shorteners are on the . <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 07:20, 17 July 2014 (UTC)

Minecraft Splash Messages
I started up Minecraft and saw the splash message "Oh man!" and decided to look up what it may be a reference to. Turns out on the Minecraft wiki page it doesn't have anything linked to it, nor does the splash message "Octagonal!". I just want to make a quick suggestion that those may be a reference to the episode on sesame street when jack black taught the shape octagon, or it could just be referencing the meme. Change the wiki page if you believe this is true.

There's also another splash message I found on the wiki page, "Mmmph, mmph!" needs to be given a description, it's from Team Fortress 2, there is a character named the Pyro who can only mumble because of his suit.

14:31, 22 July 2014 (UTC)

Adding images to wikis in other languages
Hey everybody! I've been working a bit on the Dutch wiki and since there are no active admins at the moment, I want to ask here: what's the way to transfer images from the English wiki to the Dutch? Some are already there and some just don't appear if I try. Thanks in advance 08:51, 27 July 2014 (UTC)


 * Just download the images you want from here and upload them on the Dutch wiki. -- undefined 09:18, 27 July 2014 (UTC)


 * There is an active admin. But just to do some checking after edits by people. :).
 * Don't forget to download the highest quality image, not the resized one. \
 * -  NL Admin  09:33, 27 July 2014 (UTC)

New texture for blue bars and boxes?
Hi! The german wiki community discussed a new style for the main page and some templates. The idea is to replace all blue bars with the dirt-texture of Minecraft. It would fit better to the new wiki logo and the top bar. For a draft please visit this page: https://minecraft-de.gamepedia.com/Benutzer:Oliver_Scholz/Minecraft_Wiki

To match this new style we would change the blue boxes, too (For example the one at the community portal). You can see a example here:https://minecraft-de.gamepedia.com/Diskussion:Minecraft_Wiki#Video_auf_der_Startseite (You have to scroll down a little bit). What do you think? -- de.MinecraftWiki-Admin 11:42, 30 July 2014 (UTC)


 * On the light gray background of the main page, it looks much too dark. On the blue content background it's not as bad, but I still don't think it looks very good. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 13:46, 30 July 2014 (UTC)


 * I like the new style. In my opinion, the blue boxes look a bit old-fashioned and does not fit so well with the rest of the wiki as the new boxes. The main page indeed looks a bit dark, but I do not find this bad. I think it is a nice contrast between the title and the content. -- undefined 14:19, 11 August 2014 (UTC)
 * In my opinion, the Minecraft Wiki is not "minecrafty" enough. On the main page, there is not really much (style) reference to Minecraft exept the logo and these Item icons like "Community Portal", "Admin noticeboard" etc. I'd like to see more Minecraft textures on the main page. Also, if you don't like these "dark" dirt bars, why don't use grass bars which reduce the contrast a little bit and also have, in my opinion, more reference to Minecraft? | 14:07, 23 November 2014 (UTC)


 * Why not use a lighter stone color? It would would contrast well with the dark stone background. <span class=nowrap>– · 02:21, 24 November 2014 (UTC)
 * That also is a good idea! Another option would be to take the default Minecraft button texture. | 21:54, 24 November 2014 (UTC)

Updating All 'Computer Versions' Pages To Match 1.8 Format
The current way version history works is a mess. For the 1.8 snapshots it works great, but trying to go back to the 1.7pre snapshots and earlier leads to a mess of confusing pages, with inconsistent navigation and duplicate / inaccurate information. All snapshots and releases since Minecraft 1.0, at the latest, should have their own pages, with the same navagation as in the 1.8 snapshots. Ideally, the old unified 'version history' page should go away completely. For versions released before 1.0, it gets trickier, but at the very least there should be consistent navigation between each consecutive release.

05:20, 31 July 2014 (UTC)


 * Yes, the original plan was to use 1.8 as the testing group, but then someone started making pages for the new 1.7 versions that came out while 1.8 was being developed and didn't even convert the existing 1.7 versions, making a confusing mess for that set of versions. Since 1.8 is taking so long we really should just start converting the old pages, there doesn't seem to be any issues with the new format, aside from a few people wanting all the snapshots on a single page, which is impractical for 1.8, but not so for versions with only a few snapshots, so I'm going to make a way to have it as an option. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 05:37, 31 July 2014 (UTC)
 * Great! glad to here there's a plan in place. 05:54, 1 August 2014 (UTC)

Bot - Request
Hello! is a new bot run by, an admin on the French Minecraft wiki. The bot is using Pywikibot to work on interwiki links. We have tested it on the French Minecraft Wiki. Can you change the status of this user? Thanks. — undefined 19:29, 31 July 2014 (UTC)


 * . <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 00:48, 1 August 2014 (UTC)

xbox 360 edition of minecraft wiki
Please add a page or refer me to the minecraft page(s) dedicated to xbox edition. PC edition has many things xbox doesnt seem to be able to do and is extremely frustrating. please help –Preceding unsigned comment was added by ( • ) at 23:48, 3 August 2014 (UTC). Please sign your posts with

My Ocean image
Hello, guys! I'm GnomeCustomer, I started my account just yesterday and I would like to know how to upload images into pages. I tried to put my "dry Ocean" image in the World types page, following every single step from the help pages and the 2 other image examples in it, but when I uploaded it, the image wasn't there, only it's name: "Mineshaft_No_Ocean". Can someone help me explainig why this happened or fixing the image for me? Thanks for reading! :)

P.S.: Please don't rage at me, I'm just a newbie... –Preceding unsigned comment was added by ( • ) at 11:01, 10 August 2014 (UTC). Please sign your posts with


 * Hi there, it looks like you haven't actually uploaded the file. On the tools in the left sidebar, ensure you have properly uploaded the image and it should work. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   11:49, 10 August 2014 (UTC)

Template needed
There is a template needed for the * whatever that is, and it is needed now in the show red stone section 07:04, 18 August 2014 (UTC)Shooter1166


 * No, you just didn't put the vertical bar between BlockLink and . Although a clock requires redstone to craft, it doesn't actually interact with redstone power, which is what the is about, so I removed the link. &mdash; &middot;   &middot; 07:38, 18 August 2014 (UTC)

Thank you &mdash; –Preceding unsigned comment was added by ( • ) at 20:09, 18 August 2014 (UTC). Please sign your posts with

Preview problems!

 * I'm posting here because there was no other place to post here.

When editing a page, there is a Preview tab AND a Preview button. Seems counter-intuitive, don't you think?

, Technology and Gaming Freelancer 20:06, 19 August 2014 (UTC)


 * That's maybe just in case the either fails. ♦   09:23, 3 October 2014 (UTC)


 * The preview button is the standard MediaWiki preview. The preview tab is from the WikiEditor extension, and loads the preview in place rather than reloading the page, which is much faster and doesn't loose textarea history. Disable the "side-by-side preview" option to get rid of the tabs. – ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>
 * –Preceding undated comment was added at 09:37, 3 October 2014‎ (UTC). Please sign your posts with
 * Matt, you accidentally missed a tilde when signing. ♦   09:47, 3 October 2014 (UTC)


 * Yeah it's going to take awhile to get used to having to do a full signature again, as I used to have the date as part of the signature. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:49, 3 October 2014 (UTC)

Update articles to use style guide
I have noticed many articles, including several new ones, currently do not follow the style guide. I have been working to rewrite articles as I find them, but I was wondering what the best way to actually clean up the articles would be. Basically, should I make it a or should I just keep cleaning up articles as I randomly find them? -- 17:35, 25 August 2014 (UTC)


 * I've been doing it randomly. If a project was made, I would contribute to it.


 * I think it's often better to tackle groups of articles at a time that share a common theme, to ensure that similar content is being written in a consistent way, inappropriate content is being moved to tutorials consistently, etc. &mdash; &middot;  &middot; 21:52, 25 August 2014 (UTC)


 * . It divides the pages needing to be finished into sub-groups of blocks, items, and entities. -- 17:57, 26 August 2014 (UTC)

Creating Structure Renders
Hello! I'm interesting how do you create images, like, i want to update it, because from , pyramids generates with colored stained glass, not with cloth. P.S I recommend you to rename image, I've linked to "Desert Temple", because it violate wiki rules calling files. -- 04:49, 5 September 2014 (UTC)
 * to . – ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  14:14, 26 September 2014 (UTC)

Talk page interwikis to translations
Just a question: How can I add an interwiki in a talk page?

Sorry for unnecessary edits on.

–Regards, ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  14:13, 12 September 2014 (UTC)


 * The first edit you made to that talk page added the interwiki link. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 04:40, 13 September 2014 (UTC)
 * Majr, I'm talking about interwikis that add a specific translation page to the "In other languages" list. They shouldn't appear on the page itself. That's what I'm talking about. What was going on with my mind that day... – ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  16:37, 22 September 2014 (UTC)

CSS
Not sure where to put this, so I'm going to ask here. What can I put in my commons.css to add another link under the "tools" section in the left sidebar? <span style="color:#4372aa;font-family:times">~ 23:36, 22 September 2014 (UTC)
 * From what I've found, you will actually will need something in your commons.js. I am not sure exactly how it is done, but in one of user scripts, there was an additional link added to the tool box. -- 23:44, 26 September 2014 (UTC)
 * Can no longer relevant, but I will answer.

addPortletLink ('p-tb', '/Special:PrefixIndex/'+wgPageName+'/', 'Subpages'); In. (Google translate) — ' ru.Wiki Admin ''' 15:14, 21 January 2015 (UTC)
 * : in which block to insert
 * : page
 * : description

Unimplemented, mentioned, and upcoming features
I've noticed the wiki currently contains a major mess of features that are not in the game. We really need to have official policies to organize them.

First off, there are many pages floating around saying "Notch tweeted he wanted blah in the game, but it has not been added yet" or "Dinnerbone showed off this feature, but it may have been a command visuals instead". Secondly, many articles are littered with "In the future, this may also do blah". Finally, the page about is a complete mess of features in the game that do nothing, features that were removed, and features either mentioned or dropped in development, and part of it's information is given a spotlight on.

I came up with a solution, although it requires a new, a revision to the , and a rewrite of both and all versions. The main reason I am mentioning it here rather than on the other pages is any of those changes by themselves would be in vain if the others were not added.

The new rule would be in the style of the rule about tutorials and would state as follows: I know this rule would remove the article, but really there is no reason any of those features may not be delayed for a later update, as most of them are listed as 1.9?. Some are simply what a dev wants to do in the update, while some may be actually be being coded.
 * 1) Features that are not currently in the game should be in the versions  article.
 * 2) This excludes features with have been removed, which may be noted in either their own article or in the proper articles history section.
 * 3) This also excludes features from development versions, which may be noted on articles affected by the feature and the relevant upcoming version article.

The style guide will need a rewrite of its section on future features, as it overall works better to use templates like upcoming to note features not currently in the game. It would state that any features that have appeared in development versions should be noted using upcoming and the development version it was added in.

and all versions would be rewritten as follows. would contain any features that are in the game, but do not currently have any use, such as the quiver sprite. would have three major sections.
 * 1) Features planned for the next update, except features already noted on a upcoming version page, which will be linked to.
 * 2) Features mentioned by mojang as upcoming. These are less likely to get added soon, so the section will be smaller.
 * 3) Features dropped in development. These features had valid sources that they were upcoming, but were canceled for various reasons. This section may be better stated as the article.

I know this is a lot to read, but hopefully this plan can solve the problem. Even if this plan is not used, I do believe either a revision to the style guide or the rules is necessary to sort all the excess of planned features, otherwise it is simply hard to read and leaves many stub and inaccurate articles.

-- 03:50, 28 September 2014 (UTC)


 * I definitely agree that we need to remove potential future information from articles - listing that Notch/Dinnerbone etc may add something is not helpful as it may never enter fruition. I also like the idea of using unimplemented features for features which appear in game but have no use. What I am currently not sure about is the changes to the Upcoming features page that you mentioned. Upcoming implies that those features will most likely eventually make it into the game, but listing features there that were initially stated to be planned for a version but have not made it into the actual version seems rather counterintuitive as those features ar no longer upcoming, even if they were at some point. Hence I think makes more sense.
 * Just for clarification, where would a page like go? There were plans for it but it was dropped, so what that be in ?
 * What about features that were in the game, but are now not? E.g. obsidian walls, brick pyramids
 * What happens to features that were mentioned as upcoming, but seem unlikely to be added due to context/time elapsed. e.g. Capture the flag was mentioned way back by Notch, but now since Notch is no longer developing Minecraft and command blocks etc can replicate this functionality it seems unneeded as a stand alone game mode. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   05:47, 28 September 2014 (UTC)


 * Also, one of the problems with the other planned features on the upcoming features page is that many of those features seem like they will never actually be added because of time elapsed. For example, back in 2012 Dinnerbone tweeted that buckets will be fillable from cauldrons. It seems likely that this has been forgotten by now and therefore may not really be upcoming at all. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   05:53, 28 September 2014 (UTC)


 * The way I see it, there are three main categories of unimplemented features:
 * Upcoming features: Things that are in snapshots, but not yet in release versions.
 * Unimplemented features: Things that have been mentioned by Mojang, but aren't in snapshots. They may have been cancelled (publicly or not), abandoned, forgotten about, or maybe they just haven't started releasing snapshots for the next version yet. Either way, they've been mentioned, but not implemented in any version available to players.
 * Removed features: Things that were in the game at one point, but have since been removed, and aren't in the current release or dev version.
 * Arguably, things that are mentioned as being planned for a specific version could be considered Upcoming, but once snapshots for that version are released, they should be moved back to Unimplemented if they aren't in a snapshot. -- undefined 06:52, 28 September 2014 (UTC)


 * Goandgoo@undefined Lantern would be placed on canceled features, with a note that lanterns have been added.
 * Features that are in the game but are not longer would either be in the proper history section (eg. obsidian, brick), or a article.
 * As for capture the flag, we really don't know whether it was dropped in dev or is still planned, so it might work best on a new article, or on upcoming features which would list features mojang suggested, but are not currently adding.
 * Orthotope@undefined What about the features that are in the game, but currently do nothing? Such as we really don't need a on a single sprite in the items folder.
 * As for upcoming features in general, we will already have a version article listing all those features, and simply transcluding it really looked bad. It may be better to list "upcoming updates" with a link to the proper version then "features planned for upcoming updates", rather than all the features in the new update.
 * Features planned for an update that might not make it are often very few, which is why I think they should be merged with the features mentioned, but not in development.
 * -- 15:14, 28 September 2014 (UTC)


 * I would like to see upcoming features removed entirely. The first half of it is content from the individual upcoming version pages, which should instead be linked to on something like, and the second half is just random things that have been mentioned at some point and we have no evidence to suggest that they are "upcoming", so they belong on.
 * I agree with having a article. Individual pages on things like  (which was just an unused texture in a file for a couple of versions) are really unnecessary. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  ⎜ 02:53, 30 September 2014 (UTC)


 * The problem that I see with simply stuffing everything into the unimplemented features article is that they imply that the features are there but simply not implemented, which is not always the case - many of the features were just mentioned at some point in time, with potentially no hope of implementation. But I agree that perhaps upcoming features page is not necessary. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   03:07, 30 September 2014 (UTC)


 * Does unimplemented imply that the feature is there (aka... implemented, just not fully)? Surely it implies the opposite? But either way, I'd be fine having a separate mentioned features page. Anything is better than what we have now. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 04:41, 30 September 2014 (UTC)


 * Unimplemented does sort of imply it exists, but is not implemented, although it could also refer to an unimplemented idea. I think a separate page would be best, and simply use about to help readers searching for those, or renaming it to . The title "Mentioned features" could also cover the features that were implemented, but never made a development version or release, such as lanterns or custom cloud height. -- 04:48, 30 September 2014 (UTC)

If no one is against it, I will start rewriting the and  pages soon as follows: – 03:18, 23 October 2014 (UTC)
 * Upcoming features: features that are not in the game, but have been confirmed to be in a future update. It will links to upcoming updates and lists upcoming updates that have not had development versions. Will be either be renamed to upcoming versions and link to any updates with development versions.
 * Mentioned features: Features ideas from mojang members that are not in the game,. It will also contain features that have not appeared in a development version.
 * Unused features: features in the game that currently do nothing, such as the unused potions or sprites in minecraft.jar. Will also mention features that were removed and did nothing.
 * Removed features: Features that were removed from the game, such as generated structures, blocks, ect.


 * I'm not sure about upcoming features. Until a feature actually appears in a development version, I don't think we can count anything as being "confirmed" for a future update. And once it appears in a development version, then it'll be on that version's page, so there will be no need to duplicate it on upcoming features. I say redirect upcoming features to upcoming versions.
 * As for unused features mentioning features that were removed and did nothing, shouldn't that go on removed features? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 03:29, 23 October 2014 (UTC)


 * That sentence I forgot to remove when finalizing the plan...
 * Yeah, I guess I agree they would go well on mentioned features. Upcoming features could simply list an link to upcoming updates, or be removed as the links on the main page do well. (would not have a lot of content).
 * – 03:46, 23 October 2014 (UTC)


 * The pages are finished within my sandbox. I can import them into the actual pages if the consensus is to use them. I am really not sure about, as there really is no content to put on it. But other than that, there is , , and . These pages will ultimately replace the various pages that simply described an idea of a developer or a sprite in the game.
 * Opinions? – 17:16, 25 October 2014 (UTC)


 * Looks good. Pages such as, etc and anything in the Unimplemented category can also get redirected to these pages.  <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   00:47, 26 October 2014 (UTC)


 * Agree with Goandgoo, looks good. ( / )  01:11, 26 October 2014 (UTC)


 * Upcoming versions is very much dependent on Mojang's activity, so it's the sort of page where I'd consider a lack of content to be acceptable. The main page only displays versions that have come out (development or otherwise), so I wouldn't consider it a replacement. We could try to extend the amount of information on the page by also including upcoming versions for other editions, and maybe include versions that are coming in the future (1.9), although then we may want to call the page "planned versions" to make it seem less immediate.
 * I don't like the duplication of version content in the "planned for an upcoming update" section in mentioned features. I think removing the fixes section would help (fixes aren't really features, anyway) and if we expand upcoming versions to include planned versions, then I think the section should be removed entirely as planned versions would replace it. Otherwise, I'd say link to the version pages themselves and just provide a basic list of features, without the descriptions (the version pages already have that extra information).
 * As for the other pages, aside from a few minor spelling/sentence errors, they look good and I would support replacing and moving existing pages with them or moving them to the mainspace and redirecting any pages they supersede, as appropriate. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 06:41, 26 October 2014 (UTC)


 * What is going to happen to the upcoming features page for Pocket Edition and the Console Edition? Where would information on that regard go (perhaps, and ).  <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   09:18, 26 October 2014 (UTC)


 * Put them on the same page and use pocket, etc.? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:21, 26 October 2014 (UTC)


 * with the proposed structure, but,, maybe make this project located where it belongs (say, at ), not in userspace? This would make more sense. -- ♦   09:42, 26 October 2014 (UTC) (with edits at 09:43, 26 October 2014 (UTC))


 * Projects are for larger, more widespread things involving multiple users, not just a quick rewrite of a couple of pages as a demo. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 12:29, 26 October 2014 (UTC)

I was originally planning on the other versions getting their own page, such as we did with "upcoming features", although I wouldn't be against it being on the same page.

The "Planned for an upcoming update" was intended to replace pages such as (which have no development versions), since all its major sources are either mentioned features or a bug tracker to do list. It would make sense as merged with upcoming versions under the title planned versions, or we could just leave it as its own page and clearly mark which features are added upon development version release, then simply link to it (brief summary would not really be needed).

– 03:26, 27 October 2014 (UTC)


 * . --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  17:45, 27 October 2014 (UTC)


 * I have changed "Upcoming versions" to "", and it now covers features planned for an upcoming update, but not yet included. Should we add features planned for a update with development version on the article itself? We did that with, and it stopped most of the IPs from adding mentioned features as current features.
 * I also split the alternate editions into separate pages, as the PC has a lot of stuff and drowns the pocket/console editions. See, , and . I think this is now ready to be moved to replace the main namespace pages. Any final objections/changes?
 * – 15:54, 28 October 2014 (UTC)

Post page rewrite
So, I imported the pages from my sandbox. The redirects may need to be adjusted a bit still. I still have a few questions as well:
 * 1) How does the  page look holding all different versions of the game?
 * 2) Should  go in Version history nav?
 * 3) Should we disallow pages on upcoming features that don't have development versions?

– 19:37, 30 October 2014 (UTC)


 * It looks alright. We probably need to work on having individual pages for the other editions next so we're not copy-pasting the content from that page to its version page when it does eventually get released. I'll need to fix the version nav template to work properly with other editions.
 * I'm thinking we might be able to just get rid of that template. All the links it has should be in the navbox, so do we need it? We also have the disambiguation page to point people to.
 * Maybe a feature where there is some actual information about it and it seems certain that it will actually get into the game could get a page. Otherwise, I'd say a redirect to the appropriate place at most.
 * <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 10:20, 1 November 2014 (UTC)


 * You mean removing the edition name from the version title, without having to change the link? Basially what was done in history
 * The disambiguation page would be sufficent, although it should likely link to to.
 * But what is defined as actual information? A signal screenshot was considered sufficient for, but even with all the information given on lanterns those never got added. We would need to define something as to what is declared sufficient information, such as what has - we know it is upcoming, and not simply an idea, as recent changes were directed towards making it possible; although, it still has yet to release.
 * – 02:31, 3 November 2014 (UTC)


 * I'm not sure if mentioned features really belongs on a disambig page for version history. It's not a version or history (in regards to it being added to the game).
 * I suppose you could base it on if the article would be considered a stub. But maybe it would just be easier to disallow them entirely until a (development) version contains them. We could even get rid of Plugin API. While we know that progress has been made towards it (and maybe you could consider that progress a partial implementation) and it is most likely going to be implemented at some point, Mojang could easily drop it or keep delaying it for a long time. It was originally going to come out in, which was released over two years ago. It can hardly be considered "upcoming".
 * <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 03:45, 5 November 2014 (UTC)


 * Yeah, that makes sense. Would removed be relevant on the version history disambig? Otherwise it can be left to current versions.
 * Yeah, we have no garentee it will be released, and there is not too much content on the article to move into . Although we do need a good place to place the policy should we make it official, as simply referring to this discussion anytime a future feature page is created would not go over easily. I proposed something on, since that was where the rule about tutorial existed; although, it may be a better idea to create something similar to , only describing required locations of content (mentioned on , tutorial as subpages )
 * – 04:19, 5 November 2014 (UTC)

Random Page Button
I think there should be a Random Page button (Doesn't go to Talk pages, only goes to Wiki pages) on the main page. If someone is bored, they can click it then learn all about Villagers, for instance. It might take someone to a page they never would've visited before, or it might expand their Minecraft knowledge. I know this is a suggestion and not General Discussion, but there's no way else to tell everyone.

-- 00:24, 30 September 2014 (UTC)


 * We have one, . You can reach it from the special pages link in the tools section. It is not directly on the sidebar because of an excess of language translation, mod pages, and other pages you would not need to be directed to. -- 01:55, 30 September 2014 (UTC)


 * If we install we could have a useful random page link again. ? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  ⎜ 02:25, 30 September 2014 (UTC)

Still receiving emails although I specified not to
This is my notifications settings: http://imgur.com/HyPEE5D This is my email: http://imgur.com/LeITtwQ I have not changed my settings in weeks, but the reality contradicts the settings. Is there a way to fix this? <font color="green" style="text-shadow: 0px 0px 8px #0f0;">( 04:31, 30 September 2014 (UTC)


 * Those emails come from the general email settings section of the main preferences tab (which was enabled by default in MW1.23), not from Echo. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> ⎜ 04:34, 30 September 2014 (UTC)


 * Woah, thanks! Why are there two different places for email settings? Oh well, problem solved. <font color="green" style="text-shadow: 0px 0px 8px #0f0;">( 04:56, 30 September 2014 (UTC)


 * It seems curse disabled the location from echo, it is only in the profile now. -- 04:59, 30 September 2014 (UTC)

Page merging and splitting policy
As brought up on, we really need some form of standard of what pages should be merged and split. For example, we currently have various pages of blocks that are separate or merged simply because of data values.

We should likely come up with a system of merging based on usage. For example, and  have a different function, while the different types of  are all fundamentally the same. , Coarse Dirt, and are also rather inconsistent when it comes to merging.

<span class=nowrap>— 15:01, 30 September 2014 (UTC)


 * If we put in sub-headers, we can talk about individual criteria, and have votes.. I'll start with one, though I know there should be others too – , , b 17:52, 30 September 2014 (UTC)

How likely that readers interested in page A will need to visit page B
I advocated for this just now on. In my opinion, if blocks A and B are closely-enough related that a reader visiting either page A or B will mostly likely need to move to the other page to complete some crucial understanding of a topic – then that the reader would be better served with a single page.

I do not mean to imply this as a comprehensive criteria.

Examples: A reader of will almost surely also want to read the contents of, and vice versa, because of the relationship between the two blocks and how they are used. A reader of would not really need much information from, if any, so this particular criteria would not apply (Though other criteria might).

Pick this apart?

– , , b 17:52, 30 September 2014 (UTC)


 * That seems valid. While rewriting articles, one of my main goals was to avoid sending people to another page just to get the information. Such as magma cubes claiming to behave like slimes. Pages should definitelly be merged if their only usage requires each other. <span class=nowrap>— 18:02, 30 September 2014 (UTC)


 * . --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  14:11, 17 November 2014 (UTC)

Same usage
As I have mentioned a few times, if two pages contain the same primary usage, they should be merged. Examples include different types of flowers (all simply are decoration and create dyes) or all the types of fences (all have the same basic behavior, and noting connections between nether brick and wood is better done on one page). <span class=nowrap>— 18:02, 30 September 2014 (UTC)


 * Mossy and normal Cobblestone Walls would meet this criteria. They might even meet this criteria so far as to merge with Fences – not to open a can of worms, just to say maybe we could try to articulate some other rule why Walls might not merge with Fences.
 * I think Cobblestone and Moss Stone themselves would not meet this criteria; Podzol, Dirt and Coarse Dirt would not; The Stone Brick types I think would (all decorative); Stairs merge with this rule, so do Slabs.
 * What do you think about doors, trapdoors? – , , b 18:19, 30 September 2014 (UTC)


 * Doors/trapdoors are all the same, except iron cannot be opened by hand, everything else would be redundant to mention on two pages. With the dirts, each one just has one unique trait (podzol requires silk touch to collect, dirt allows grass/mycelium spread, coarse dirt hoes into dirt).
 * Although I would agree that if the obtaining is still significantly different, they should not be merged, such as with most building blocks, and the various types of dirt.
 * <span class=nowrap>— 18:25, 30 September 2014 (UTC)


 * . --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  14:12, 17 November 2014 (UTC) (crossed out by <span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">   on 16:01, 17 November 2014 (UTC) due to not being really sure)

Block data
As I've recently (and briefly) said on, if blocks with different block IDs use block data/block states for minor things like orientation, their pages are allowed to merge (e.g. s and s). But if they use them for many different block variations (like and ), they are not to be merged. The only exception is when variations of a single object deplete one block ID's data and require another block ID, like in case of.

--<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  13:17, 20 November 2014 (UTC)


 * Really if they share the same origination/rotation, they either have the same usage (see above), such as fences or doors, or are rather different in most other aspects, such as droppers and dispensers. <span class=nowrap>– · 21:55, 20 November 2014 (UTC)

Reverting consecutive edits
How can I revert consecutive edits without editing text manually? — ♦  06:15, 6 October 2014 (UTC)


 * Press edit on the revision you want to revert to, then save. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 06:16, 6 October 2014 (UTC)


 * Thanks, let me ... — ♦  06:34, 6 October 2014 (UTC)


 * Then, how the message like this can automatically appear in the edit summary?

"Revert consecutive edits by ..."


 * — ♦  06:38, 6 October 2014 (UTC)


 * You'd have to type it manually. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 06:58, 6 October 2014 (UTC)

Minecraft Wiki namespace shortcuts
Names of pages in Minecraft Wiki name-space tend to be big. So I suggest making short-cuts to these pages, similar to Wikipedia. (Use Comment for answers.) --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  07:47, 29 October 2014 (UTC)


 * Can you give examples of what kinds of shortcut you're looking for? The Project: and Project talk: namespace aliases redirect to Minecraft Wiki: and Minecraft Wiki talk: respectively. There are also specific redirects for and . -- undefined 09:42, 29 October 2014 (UTC)


 * For example, on Wikipedia, "WP:MOS" redirects to, "WP:BLOCK" redirects to , and "WP:CRAT" redirects to . Similarly "MCW:P" may redirect to (and "MCW:P/RFS" and "MCW:RFS" may redirect to ), "MCW:D" →  and so on. --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">   10:48, 29 October 2014 (UTC)


 * Redirecting to specific projects is not really needed, but a namespace shortcut may be helpful. Such as "MCW", "MC", or "MW". (also, we have ) <span class=nowrap>– 14:26, 29 October 2014 (UTC)


 * This has been proposed, but nothing has happened with it. It's a pretty simple setting change, so I don't see any reason it can't be done, so I'll follow up on it. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:29, 5 November 2014 (UTC)


 * and namespace aliases can now be used. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  06:02, 26 November 2014 (UTC)


 * What about redirects to individual pages, such as or  for ? Any reason I should not create them? <span class=nowrap>– ·  22:39, 26 November 2014 (UTC)


 * One of those isn't a shortcut, but yes some common page shortcuts would be good. We should agree on which pages need shortcuts and what those shortcuts should be. The shortcuts should remain in the project namespace, the shortcut is an exception as it is already in use and was made before we had the namespace shortcut. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  05:21, 27 November 2014 (UTC)


 * There are some long names for project names. We can make a shortcut for, and then  for ;  for  (if it does not conflict with other shortcuts!) and so on. --<i class=nowrap> (&#124;)</i> 16:57, 27 November 2014 (UTC)

<span style="color:#4372aa;font-family:times">~ 21:06, 27 November 2014 (UTC)

Unite and
I suggest unite them, because they have not big difference, only texture. -- 12:03, 31 October 2014 (UTC)


 * these pages are big and the resulting single page will be messy. And, remember, when requesting a merge, post about it on a talk of one of the pages to be merged. --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  12:22, 31 October 2014 (UTC)

Community portal content page redesign
The community portal content page is really lacking in usefulness, as most of its current content either outdated, random requests with no followup, or sends you to another page.
 * Hot discussions really never happen, or at least there is no guideline on what to add here. The occasional discussions that have wiki breaking changes already tend to be on the talk page.
 * Current wiki news really needs some form of a guideline as to what is defined as "current" and "news", as its only item is an very old item about the gamepedia merge.
 * Wanted pages is random requests for pages that normally are not followed up.
 * Requests for comment needs a better system to propose requests, and a better format for such requests. We also should remove requests that are at least six months old, unless they are still active, in which case it may be relevant in Hot discussions

Really a redesign of the page may be in the best interest, such as follows:
 * Merging Other perennially useful pages and Style guidelines into one section at the top called Useful pages.
 * A section called Active projects might be helpful for users to know about current projects, otherwise the projects page should be linked in Useful pages
 * Current wiki news could really be removed, or we need some way to add content to that section (maybe results of Hot discussions?)
 * Hot discussions should be expanded to contain any discussions that are rather active, such as the merge proposal on . It could even link to active community portal discussions that are active.
 * Then we have Requests for comment, which will be contain a list made using a template to format requests. Each request contains a page, section, a description, and a date. Requests that are over six months old without any action should really be removed.
 * Wanted pages should either be removed, or maybe moved to its own page. If it is to remain on this page, I would place it near the bottom. Many of those are single person requests, and a lot of them are either not descriptive, or better suited elsewhere than a wiki (like maybe a forum).

– 01:41, 8 November 2014 (UTC)


 * I agree that a redesign of the page is necessary. I think wiki news should go altogether. The only problem with your plan is that there may be some overlap between hot discussions and request for comment - when does a request for comment become a hot discussion etc. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   23:55, 15 November 2014 (UTC)


 * My idea was to move the page link from requests for comment to hot discussions if it is very active, especially if it is out of time for a request for comment. It would basically be request for comment, only it would contain places many people are posting at the time (maybe as a subsection, as any hot discussions we would request comment anyways). A request for comment would upgrade to hot discussion if three or more people are actively posting/debating (active could be defined as four or more replies within a week maybe), although that definition may need a bit of work.
 * I would agree to removing wiki news, the only uses I can think of are wiki breaking changes (which rarely happen) and updates (which would do better as a ) <span class=nowrap>– 01:51, 16 November 2014 (UTC)

Obtainable Items page
I have an idea for a page, though I'm not sure if it would be welcome or not. In addition to the ever-so-useful renewable resource page, I personally would really like to have a list of every obtainable item/block, whether or not they're renewable. Being a completist, I'd really like to develop a world that has established regions for quick and easy access to every resource in the game (and I'm reasonably sure I'm not the only one). Most players have a designated mine area, and some survival servers deliberately try to position areas for harvesting useful resources (like the Mesa biome's collection of Hardened Clays) such that they minimize interference with the natural landscape).

As it stands, a player working on this kind of project has to either already know what's available (a list that grows significantly on every update, these days), or has to dig through the full list of blocks and the list of items, and sort through which blocks are just the placed form of an item (for example - the 2 types of door block, vs a door in your inventory).

If the table is made sortable, it could potentially contain all the information from the renewable resource table, too - A column could tell us if it was non-renewable, or renewable through farming, trading, mob grinding, or craftable from renewable resources, etc.

I would be willing to lay the foundations for such a page, but I don't want to do so if moderators will immediately dismiss the idea as superfluous and delete it again. (It might be an interesting project for me, anyway - I really should devote the time to learning how to do things in wikis other than display words and sign things.)  18:27, 8 November 2014 (UTC)


 * I really don't see the point of such a page, as if you refer to, the text for blocks and items is colored based on if you can obtain the item. Methods for obtaining also also best discussed on the individual page, as most items have many methods from crafting to generation to drops. <span class=nowrap>– 18:54, 8 November 2014 (UTC)


 * While this information does already exist elsewhere, the sortable table idea is interesting. You could create it in your userspace (for example, at ) and use it to experiment with learning MediaWiki syntax. If people like the results, it could be moved into the mainspace. -- undefined 21:58, 8 November 2014 (UTC)

Long infoboxes
It has come to many of our attentions that the infoboxes are becoming excessively long, and as much of its information is now being placed in other sections, we should really decided which content still belongs in the infobox. I am starting this discussion here, as it affects all our infoboxes, rather than just the blocks.

Really the infobox should be a brief summary of general attributes, based on how useful it is to the player. Some rows have a few problems, for example:
 * Requirements does not help much, especially since it has not worked properly for over a year. Even assuming it did work, all it states is dirt/sand and sunlight or darkness.
 * Spawn on entities is rather long in many cases, as it must state several methods of spawn, as well as dimensional requirements (and in some cases, block type), either it needs to be slimmed down, or we simply refer to the spawn section.
 * The first version really does not affect game play much, and when playing older versions you really should use the entire history section anyways.
 * Is data values (and the entity's variant) really required in the infobox? We have a more descriptive data values section it could be moved into, and people looking to quickly grab a block by value could much more easily check.
 * Do sounds really belong in the infobox? Really where would sounds belong?

Also, what about sectional links that replace content? For example, with many block hub articles it makes sense to move data values to a section, but does drops really need a sectional link as well?

– 18:36, 14 November 2014 (UTC)


 * I agree that Requirements, Spawn, firstver/multiplevers, and data values should be removed in favor of just discussing the material in the article. I'd also remove gravity/Physics since it only applies to a few blocks and should be discussed in Usage. Even block's type and transparent are questionable, since both solidity and opacity can be complicated. Tool and hardness are now discussed in Obtaining, and renewable probably should be discussed in Obtaining (providing a brief summary of how it's renewable). Flammable is actually a little more complicated than Yes/No (some blocks, like doors, allow fire to spread but don't burn themselves).


 * I would also suggest even putting all of the remaining entries in a collapsed table, so that it would just be the pictures, then "Details [show]" or something. &mdash; &middot;  &middot; 19:03, 14 November 2014 (UTC)


 * I also agree on removing Spawn, Requirements, firstver/multiplevers and firstdev. For Drops, mobs which have a lot of drops like s and s make infoboxes really long. (chicken jockeys have 14 possible drops). undefined 21:16, 14 November 2014 (UTC)


 * I generally agree, more specifically:
 * Requirements can be stated in Spawning/Usage/Behavior (if ever!), depending on in which sense it is used, and the infobox can have a link to that section.
 * Collapsible tables don't always work, so I don't think it's a reliable way.
 * Firstver/multiplevers can be rerouted to History; however Firstver is quite short, so it may be kept.
 * Same with Firstdev. It is short, so in normal situations can be kept.
 * with drops. If too long, a link is useful.
 * --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  07:33, 15 November 2014 (UTC)


 * The problem is firstver and firstdev cannot still be short when we include editions other than the PC, and really does not help the reader much as most readers play the latest version, and those who don't should already be reading the history section for differences. <span class=nowrap>– 15:21, 15 November 2014 (UTC)


 * Regarding drops: I think that they should be renamed common drops (as on the page) and only include the common drops (eg. bones & arrows for skeletons, and rotten flesh for zombies). This allows for quick info while keeping the info box short. For mobs such as chicken jockeys, perhaps we could just put something like "regular zombie/chicken drops", with a link to the Drops section?  -   03:13, 18 November 2014 (UTC)


 * When collapsible tables "don't work", do they fail gracefully? If they fail by not collapsing, then that's fine -- most people will have a collapsed table, and the rest will still be able to see the info. But if they fail by collapsing but not allowing uncollapse, then I agree that would not be acceptable (though that would mean we shouldn't use them ever). &mdash; &middot;  &middot; 15:33, 15 November 2014 (UTC)


 * Only problem I see with collapsible tables is the infobox size changes at the press of a button, the rest I can find would be visual preference (I like uncollapsed a little better too) <span class=nowrap>– 15:39, 15 November 2014 (UTC)


 * I agree with moving requirements to usage or behaviour.
 * Spawn could perhaps be reduced to a "Spawns in" section, which only lists the dimension, with further spawning defaults in the spawning section.
 * First (dev) version used to make sense before all the other editions came along. It was useful for people not playing on the latest version so they could see straight away if the feature doesn't exist for them yet. But with other editions adding all these features, the section is always going to get a bit lengthy, so I think getting rid of it and just using the history is best.
 * Data values also used to be simpler and so a single entry in the infobox was usually enough, now that's not the case, and we also have some really nice data values sections, which are much better to direct people to.
 * Nuke sounds entirely. What's the point?
 * Long drop sections should be replaced with a section link, but small ones with just a few (3 at the most?) should remain. I'd also like to see the drops section be an improvement over the infobox section it is replacing, rather than worse, as it is now (unstructured and lack of images).
 * Section links should remain for all migrated information for a transition period (at least until all pages are done). Past that, drops is probably the only one that should keep a section link as only the long sections will be moved out of the infobox. Section links shouldn't be duplicated, for example only put a section link in, leave , and  empty.
 * Naista2002@undefined Can you clarify when collapsible tables don't work? I've only seen a single edge case where it wasn't working (single cell table with only images, and no text), which was fixed. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:34, 17 November 2014 (UTC)


 * nameid also gets very long when there are multiple blocks/items on the same page. As for sounds, I don't know where to put them. undefined 01:59, 18 November 2014 (UTC)


 * All sounds are already documented at, along with the in-game events which trigger them. If there's a need to put playable sounds on the wiki, we can just put them there? &mdash; &middot;  &middot; 02:10, 18 November 2014 (UTC)


 * that is a good idea, if we don't have any place to put sounds in block/item/entity pages. undefined 02:29, 18 November 2014 (UTC)


 * I personally see the sounds.json page as a page describing the sounds.json file (a file which basically links sounds to sound events, used for resource packs) rather than describing sounds itself (and besides that article is long enough already). However, I'm considering expanding the (disambig) page to include all of the sounds (as well as basic info such as sound range/distance, etc). -   03:05, 18 November 2014 (UTC)


 * Or just create a page. undefined 03:15, 18 November 2014 (UTC)


 * Some of the drops sections look decent, although the problem of a lack of images is not easy to solve without placing images within the text, which would just end up looking bad. A table could be a solution.
 * I would prefer to list all of the drops in the infobox, though on jockeys and witch it would be to long. Although, with the rest of the infobox slimming it would fit well in most other cases.
 * As for migration, couldn't we start that with history now (via hardcoded see history)? On almost every article it is already incorporated into the history section. <span class=nowrap>– · 05:36, 18 November 2014 (UTC)


 * For clarification: firstver and firstdev condense into one line when viewing the page (even though they are 2 lines in the editor), so linking it to history doesn't actually save infobox space :). Although for old versions we could leave only the firstver or even get rid of the section altogether (instead of linking to history).
 * I agree that data values could be removed (especially since we use name ids now). -  05:10, 20 November 2014 (UTC)


 * Linking to history was for the sake of transition, and because adding pocket, console, pi, and multiple items on a page caused it to get rather long. <span class=nowrap>– · 05:26, 20 November 2014 (UTC)

HESI Project
Hi,

The Highlighting_Edition-Specific_Information (HESI) project was recently confirmed discontinued by its owner Augurnz (IP only). So I was wondering, would anyone be willing to take this project over? (Or change or even delete it). - 05:52, 14 November 2014 (UTC)


 * It may be better rather than simply bringing back the project to revamp it, as it is a little vague as to how to accomplish its goal (or at some points what its goal is). <span class=nowrap>– ( 17:47, 14 November 2014 (UTC)
 * As for some specific ideas, the infobox could use a parameter denoting version, as pocket and alike look really bad along side the infobox.
 * Really it comes down to one decision, do we describe features from all versions, then say "In the PC edition" and alike, or do we describe the PC edition, then state "But this is not in the Y edition"? <span class=nowrap>– 04:29, 15 November 2014 (UTC)


 * I definitely believe that version specific information needs to be highlighted more in articles through a project with clear and comprehensive guidelines. I think using the PC version as the standard and mentioning what is different in other versions (much like what is already happening on much of the wiki) is how the wiki's information should be organised. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   12:53, 15 November 2014 (UTC)

Outdated info in tutorials
I see that sometimes have obsolete information (as well as a few pages about the game features such as blocks), since I don't see people paying attention to that. I think that a project could be made here, so to get rid of obsolete information in tutorials.

Nobody protests?

--<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  16:08, 15 November 2014 (UTC)


 * An example . undefined 16:21, 15 November 2014 (UTC)


 * Yes, like that. Another example: at some point states that s aren't flammable, while they were made so in 1.7, more than 1 year ago. I saw even more obsolete content: on Russian wiki, there were articles saying Beta 1.9-pre instead of Beta 1.9-pre1; it was only actual more than 3 years ago. However, I did launched a project there.
 * Now, more to the project: When I receive approval, I'll immediately launch this project.
 * --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  17:00, 15 November 2014 (UTC)


 * A project of this nature is a good idea, marking pages with Rewritten tutorial or something like that. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   23:53, 15 November 2014 (UTC)


 * We need more admins to accept this. ? --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  15:37, 20 November 2014 (UTC)


 * I don't think something like this actually needs admin approval, just the agreement of several regular editors. If pages are outdated, you can go ahead and update them even without a formal project. -- undefined 23:33, 20 November 2014 (UTC)


 * The project allows to keep track of done pages and manage them.
 * . --<i class=nowrap> (&#124;)</i> 16:42, 22 November 2014 (UTC)

Extremely Outdated Mods
This has been moved here from .

It seems that a lot of the mods listed in the Mods Category are very outdated (for example is still in Beta 1.6.6). Also I don't know if people are actually updating these pages anymore, meaning that some mods that have updated to 1.6/1.7 haven't been updated for quite a while on this wiki. Many of these pages also seem very disorganized.

Many of the better known mods already have their own wikis; and besides I have yet to hear someone on the MC Forums refer to this wiki for mod information.

So the question is: should we still include pages on specific mods? 09:28, 12 November 2014 (UTC)


 * I personally do not find the mod pages very useful, as very few people actually work on the pages, and most mods should be documented on their download site anyways, otherwise who would download them? The main reason we have them might have come from the earlier days of Minecraft Wiki when there were fewer mods, and the most popular mods got documented here. We also declare at the beginning of the pages that we do not support the mods, yet we host information about them...
 * Largely out of date mods and mods that have had little backing on the wiki I believe should be removed. Really linking to the website, forum thread, or even mod's wiki would be better, as those would all be updated more. <span class=nowrap>– ( 01:00, 13 November 2014 (UTC)


 * I agree with . undefined 20:20, 15 November 2014 (UTC)


 * In addition, I archived the modlists that were on the Mods page a while ago, so I think that the wiki should even go as far as not hosting any mod pages. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   23:52, 15 November 2014 (UTC)


 * Not every mod developer has the time/resources/etc. to set up and admin their own wiki, so I think it can be beneficial to the Minecraft community to allow documentation of mods here. If the mod pages aren't being updated, it's probably because the page no longer provides links to them, making them harder to discover. I would vote for adding a list to the mods page saying "This wiki provides some documentation for the following mods:" and see if that helps.


 * If we do decide to take the drastic step of deleting information from the wiki, we should at least put a notice on the pages saying that they are being considered for deletion so that anyone who might still be using them can raise objections and discuss alternatives. I know was working on the  articles this summer -- he might want to save them to his userspace or something. &mdash; &middot;   &middot; 00:21, 16 November 2014 (UTC)


 * I mostly agree with . Thankfully, there are wikis on Wikia about Minecraft mods, e.g. . Wikia is more maintained than this wiki, so there it might be more up-to-date. For listing mods, one could look into . --<span class=nowrap> ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  12:41, 16 November 2014 (UTC)
 * The reason the mod articles are poorly supported is because this Wiki is pretty hostile to mods, it's pretty discouraging. You've got aggressive disclaimers, and a ban on mod discussion or modded-game images outside the Mods/ articles themselves.  In Thaumcraft's case, I've been saving info here because the alternatives were generally in poor shape, and I had trouble logging into some.  I'll check out Wikia.  And yeah, I'd want to copy the pages to my userspace before a deletion.  I don't know how much would be useful, but there's at least a few bits. --  01:59, 8 January 2015 (UTC)


 * One thing that may be worth mentioning for many mods is the official feed the beast wiki, which has recently moved to gamepedia. (link). It seems to cover all the mods we cover best, although it does need expansion.
 * As for hostility, the disclaimers are really not necessary on every page, a general mod disclaimer could do a lot better, but the ban on mods in the main pages makes all to much sense. <span class=nowrap>– · 03:40, 8 January 2015 (UTC)
 * Having looked around, Wikia's Thaumcraft4 wiki and FTB are both semi-abandoned, and what's there is from a older version. If you do decide to nuke the mods, you can move the Thaumcraft tree to my userspace -- I and whoever else can salvage stuff to one of them as time and energy allows.  (I'll start copying some pages, but I can't seem to find a "copy" option on the menu, so I'll be C&Ping and will lose history. --  20:24, 10 January 2015 (UTC)


 * To maintain compliance with the Creative Commons license that the wiki content is released under, you can't simply copy-paste pages like that; you have to preserve the page history. You should be able to move the pages to your userspace by using the page rename functionality. <span class="nowrap">「」· 20:27, 10 January 2015 (UTC)


 * I wouldn't worry too much about pages being deleted in the near future. If there is a consensus to get rid of mod pages at some point, it would probably start with the old, outdated ones; I'd keep anything that's being actively maintained/worked on, at least until it's documented better elsewhere. -- undefined 20:59, 10 January 2015 (UTC)


 * I think moving mods the Official FTB Wiki would be great, I'd support it for sure. I use that wiki as an official wiki for all my mods.  22:59, 17 January 2015 (UTC)

Some mods are being moved over, such as ones done by. <span class=nowrap>– · 23:41, 17 January 2015 (UTC)


 * I would agree that moving any mods that are in the FTB pack to the FTB wiki would make sense, they're going to document them anyway, no point in duplicating the effort. However, I don't think we can or at least should be copy-pasting the content and loosing its history, assuming there is actual history. If there's just a few edits by one person who agrees to copy-pasting it, or does it themselves, then it should be fine, otherwise the mod pages should be with full history from here then  on the FTB wiki. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  00:22, 18 January 2015 (UTC)


 * I agree with Majr, although we document more then the mods just in the FTB modpacks. Btw, Mr. Guru has already moved a couple pages over :)  22:43, 18 January 2015 (UTC)
 * In my opinion all mods that are in FTB should only be documented there, apart from one main page as an intro to the mod on the Minecraft wiki. If we choose to do it like this, we could have this one intro article about a mod in the main space as there won't be that many, and it's very unlikely there will be mods that are called "stone" for example, which would mean it has to be placed at "stone (mod)".—  undefined NL Admin  20:27, 19 January 2015 (UTC)


 * Stone mod. Heh, I looked it up. I found a New Stone Mod if that counts :P  22:13, 19 January 2015 (UTC)


 * Hey guys, FTB Wiki administrator here. I'm just coming to say that we allow and love for documentation of all Minecraft mods. Whether they are in an FTB pack does not matter, unless you are a staff member, which would restrict you from documenting non-FTB pack mods. If you guys want to legally (that is, doing necessary things that your and our license require) transfer content over and convert it to our syntax and templates, that would be lovely. And just to avoid confusion, we are talking about the FTB Gamepedia Wiki, not ftbwiki.org.  22:22, 19 January 2015 (UTC)


 * I'll be happy to help moving/converting templates over if anyone needs any help. Just to note though, the FTB Wiki doesn't like videos; stuff like spotlights need to be moved out when converted over.  22:36, 19 January 2015 (UTC)


 * The problem with still maintaining an info page on mods that now have been migrated is that the people who look after the mod pages will now be on another wiki. We also have to separately create notability guidelines for mods, as most policies on one wiki will not apply to the other.
 * As for the mods page, the tables of available mods should be removed if we remove the pages, as there are better lists on the forums, curse.com, or . The page will then discuss what mods are, and link to . <span class=nowrap>– · 23:04, 19 January 2015 (UTC)
 * Linking them to another wiki isn't a problem as far as I'm concerned. Just link them to a special page that tells them they are being redirected or that tells them to click somewhere to redirect. Just like FTB does. —  undefined NL Admin  14:27, 20 January 2015 (UTC)


 * Like ? <span class=nowrap>– · 15:25, 20 January 2015 (UTC)

Kind of, like Stone on FTB. it would be nice to make this possible:. (Which I now see is already possible) —  undefined NL Admin  15:41, 20 January 2015 (UTC)


 * And just for the record, us at the FTB Wiki our much easier to contact on EsperNet at #FTB-Wiki :)  03:11, 21 January 2015 (UTC)


 * There’s an oppose on Russian wiki, led by GreenStone, against having FTB mods having an official wiki outside Minecraft Wiki, after mentioning that wiki. See also, amd . <b class=nowrap>I’m   , f.k.a. Naista2002 </b> 16:15, 24 January 2015 (UTC)


 * Aside from that being a rather hostile attitude toward everyone who's contributed to the FTB wiki, the Russian wiki can keep mod pages if they want to. -- undefined 18:51, 24 January 2015 (UTC)


 * I am sorry if I was interpreted as excessively hostile. What I want to say is that I object against the Russian translation on FTB being considered official, and I object against removal of modification pages from the Russian wiki. I do not mind if the FTB translation exists.
 * Sorry again for being unable to post properly and without any hostility. I currently am in an unfriendly environment IRL, and that affects online behavior.
 * If you want to talk about demoting or blocking me, please do that on my talk page. -- 23:43, 24 January 2015 (UTC)
 * As an admin on the FTB wiki, I personally don't mind if the Russian wiki wants to retain its pages on mods. You're free to call yourself the official wiki for all things Minecraft in Russian. However we will continue to allow people to translate our pages into Russian if they want to. Considering we have custom extensions and templates made specifically to handle the massive amounts of items and their complex recipes in modded Minecraft, I'm saddened that you don't want to take advantage of what we have, although I understand that you want to retain the linguistic freedom to write articles your own way specifically catered towards Russians. To the English Minepedia: We welcome all mods, regardless of their affiliation to FTB. Feel free to export any mod pages we don't have yet and import them over at our wiki. Just try to fix the pages so they match our style guidelines and use our system of templates.  07:04, 25 January 2015 (UTC)

2 questions

 * 1) What does right   do and what extension added it?
 * 2) "Real name" field in preferences saids that it will be used for "giving me attribution for my work". What does it mean? Does it mean that it will be used to show entered name in differnces pages etc.? If yes, it does not work.   07:51, 20 November 2014 (UTC)


 * The group rights are from, though it's not currently installed here.
 * There's a MediaWiki option to show the most recent editors of a page in the footer; I believe the real name option is used there. It's disabled by default, though, as it's somewhat resource-intensive. -- undefined 15:27, 20 November 2014 (UTC)

Suggestion: tab infobox images
Currently, having two images of monsters, like uncharged/charged creeper, normal/baby zombie etc. and gifs of different types of blocks, like stairs, stained clay etc. takes quite a lot of space and waiting for a specific frame of a gif is a nuisance too. How about making tabs, like this: or this: ? Please consider this, it would improve aesthetics of pages. 15:30, 22 November 2014 (UTC)


 * That would make some infoboxes very long. – · 15:50, 22 November 2014 (UTC)


 * The thing is, with most blocks there will be no more than 4 frames of unique designs, so it is not a long wait (especially with only 2 seconds between frames). The ones with more frames tend to be simply color swaps, such as wool or types of wood, so each specific image does not change much. We also frequency use the animated images elsewhere, causing an inconsistency when we do not have that many images to begin with. Both of those had at least 10 to 20 images that all had between minor and major differences, causing some necessary time to figure out what is different. <span class=nowrap>– · 15:50, 22 November 2014 (UTC)


 * I've been thinking about asking for tab boxes too, as a way to flip between redstone circuit screenshots and schematics compactly. I don't think I would use them for infoboxes though. &mdash; &middot;  &middot; 16:29, 22 November 2014 (UTC)

Entity data
Can we add NBT data trees to pages about entities? Since we have them for block entities, why not have them for actual entities too? --<i class=nowrap> (&#124;)</i> 14:01, 25 November 2014 (UTC)


 * From what I heard, allowing the values to sync is in progress, see . are working on it, though not much progress recently has been made. If you want you could start adding trees without the sync, you could, otherwise you could wait for or help out the project there. <span class=nowrap>– ·  16:31, 25 November 2014 (UTC)


 * The main issues I see are article length (the tree to fully describe a mob is about five screens long on my monitor; less on large displays, but way too long on mobile) and maintainability. If a tag in the generic Entity class changes, some 70 pages in would need to be updated. There's a proposal at  that would solve both problems, but I don't know if it's ready to implement yet. -- undefined 16:33, 25 November 2014 (UTC)


 * I think we've stalled on working on it, if someone else wants to take up the torch… But if LoadBox is used for common field groups, then changes shouldn't propagate, right?


 * I think there were some problems trying to make LoadBox play nice with the treelist view. Until that's resolved, maybe the articles could just list their specific fields with links to the common fields. &mdash; &middot;  &middot; 17:57, 25 November 2014 (UTC)


 * I agree with Munin. Until LoadBox is fixed, we can use links. --<i class=nowrap> (&#124;)</i> 07:51, 26 November 2014 (UTC)

1.6.1, 1.7.2 and 1.8 snapshot downloads
I just found where the 1.6.1, 1.7.2 and 1.8 snapshots are stored. They are stored in s3.amazonaws.com/Minecraft.Download/versions/[version here]/[version here].jar/json. Shall we provide links to the jar and json downloads in the 1.6.1, 1.7.2 and 1.8 snapshot pages or just leave as it is? -- 23:57, 5 December 2014 (UTC)


 * I don't see any need to, since you can get all of them more easily through the launcher. -- undefined 01:15, 6 December 2014 (UTC)


 * But 1.6.1 and 1.7.2 snapshots aren't available trough the launcher, and only some 1.8 snapshots are available trough the launcher, so I think we should put the links. -- 01:21, 6 December 2014 (UTC)


 * Hmm, looks like they've been removing older dev versions from the launcher. If they're no longer available there, adding links makes more sense. -- undefined 01:35, 6 December 2014 (UTC)


 * So are the 1.6.1, 1.7.2 and 1.8 development version downloads being linked? -- 01:54, 6 December 2014 (UTC)


 * No response recieved since my last response, so i'm taking that as a yes. -- 01:27, 7 December 2014 (UTC)


 * I would agree to linking them, as only the latest few tend to be in the launcher. Version nav already supports adding them, via its parameter . <span class=nowrap>– ·  01:45, 7 December 2014 (UTC)


 * Well, maybe a  parameter should be added, as the json files are also stored there. --  01:54, 7 December 2014 (UTC)


 * Nevermind, I'm just going to put the .json links in brackets in the  parameter. --  17:40, 7 December 2014 (UTC)


 * Looks good. <span class=nowrap>– · 23:07, 7 December 2014 (UTC)

Curse host broken
The Curse host is broken. I wanted to edit my userpage but I couldn't because the host always threw me an error. The edit only succedeed 2 times, but both times the edit refused to get saved. My internet connection is perfect, so that can't be it. -- 22:05, 13 December 2014 (UTC)


 * Apparently, the error is also there when attempting to get to the Recent Change page or to backtrack. -- 22:08, 13 December 2014 (UTC)

Protected edit request template
I would like to propose a template, along with a few categories, to aid users in requesting edits to protect pages, as well as aid people with proper rights in finding those requests. I personally have made requests on a few pages that were never found, so it would be nice to have an easier way to bring them up without spamming the or this page.

I am mainly wondering if people would use the template, and if users/admins would check the semi/fully protected request categories to actually answer the requests.

For design I was thinking something.

Also, what would be a good way to tell users about the templates? I know a link in the admin noticeboard may help for the sake of fully protected pages (similar to the delete link).

– · 21:02, 17 December 2014 (UTC), edited at 23:13, 17 December 2014 (UTC)


 * I don't think this wiki is anywhere near big enough to require such a template. The admin noticeboard isn't being spammed at all, there's not even a post per day. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 10:00, 23 December 2014 (UTC)


 * In that case, I'd assume you would advise posting unanswered requests on the admin noticeboard? <span class=nowrap>– · 14:42, 23 December 2014 (UTC)


 * If it requires admin attention, it goes on the admin noticeboard. That's what it's there for. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:43, 24 December 2014 (UTC)

2015
<div style='text-align:center'> <div style='text-align:center'><span style='font:25pt Courier'>00:00, 1 January 2015 (UTC) <div style='text-align:center'><span style='font:25pt Courier'>Happy new year, Minecraft Wiki!

– - 00:00, 1 January 2015 (UTC)


 * Well, by UTC time. Still have a few hours to go where I live.
 * Happy New Years! <span class=nowrap>– · 00:08, 1 January 2015 (UTC)


 * Same with me, my GMT is +04:00, meaning I have to wait 2,50 hours more. Well, anyways, happy new year! :D -- 00:33, 1 January 2015 (UTC)


 * I have to wait 35 minutes :) – - 02:25, 1 January 2015 (UTC)


 * Oh shoot, just 9 minutes left and the host goes down. For some reason everytime I try to view a page the host goes down. -- 02:41, 1 January 2015 (UTC)


 * Happy New Year :) I celebrated it on 21:00 of UTC, since I use UTC+3. Also, at the actual begin of the new year in my region (Vladimir oblast, Russia), I wrote a . There, I was some 27 minutes late because I didn't started to write the message before the actual new year. When it became 00:00 as of UTC, I was already sleeping. -- 09:40, 1 January 2015 (UTC)

Translation issues...
Hello! I'm new to this community. I'm italian, but I can speak/understand english pretty well. Yesterday, I was searching some information on this Wiki in my language, italian, and I realized that the translation isn't good at all. Luckly, I can understand english, so I started to search information in english. But there's a problem not all people can understand english in my country.

Can I translate some articles or pages to italian???

This can help the community a lot, in my opinion.

Sorry if I made some mistake, but like I said I'm italian. –Preceding unsigned comment was added by ( • ) at 10:41, 03 January 2015 (UTC). Please sign your posts with


 * This is the English wiki, the Italian wiki is . The whole point of a wiki is anyone can edit it, you don't need to ask to get started. --– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 10:46, 3 January 2015 (UTC)

British English translation
A UK english version of the wiki would be fairly better for UK users, if unnecessary. Just a suggestion. -  18:16, 7 January 2015 (UTC)


 * The main problem would be getting support. If you can already under stand the American English wiki, why use the British English one which lacks content?
 * Also, the wikis would be mostly identical, except minor spelling and slightly different vocabulary. The languages are too similar to require a separate wiki. <span class=nowrap>– · 18:48, 7 January 2015 (UTC)


 * That was the main problem I was actually thinking about, and I still haven't thought of a workaround -  20:51, 7 January 2015 (UTC)


 * As a point of comparison, consider the fact that there is only of Wikipedia (plus, but that's not really a language variant). This suggestion has been made for Wikipedia in the past, and was rejected for largely the same reasons. One potential solution would be some sort of variant selector, like is used on the , but I suspect developing that would be a very involved affair, and even after extensive development would have a lot of problems. <span class="nowrap">「」· 22:22, 7 January 2015 (UTC)

Usage of categories
I've noticed many of the main Minecraft Wiki categories are also containing both user pages and translation projects, and as neither of those are helpful when using the category, that proposes a problem. The thing is, though, there is no stated rule or policy in place that translation pages and user pages cannot use those categories (instead, users who have been on the wiki longer remove them, and new users may simply copy/paste them onto their page)). What I'm proposing is creating such a stated policy on this wiki, something along the lines of "Categories not designed for project pages or user pages should not contain project pages or user pages."

– · 23:28, 10 January 2015 (UTC)


 * I'd agree with that. Feel free to remove those misplaced categories from people's userpages. "Don't touch my stuff" rules don't apply when that stuff is disrupting the usage of the wiki. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 10:34, 11 January 2015 (UTC)


 * Userpages are useless in content categories, remove them on sight. <span class="nowrap">「」· 11:31, 11 January 2015 (UTC)


 * And I assume translation project pages should use the /lang version of categories instead of the main ones? <span class=nowrap>– · 20:13, 11 January 2015 (UTC)


 * If you were asking me specifically, I don't really have an opinion; if it's SOP to create language-specific categories then keep doing that and switch articles to them as needed. <span class="nowrap">「」· 23:10, 11 January 2015 (UTC)


 * It was a general question to both of you, stating it twice would end up a bit redundant (though I could have used @...).
 * For the most part it has been practice, but never stated, and I wanted to at least have a bit of stated backing before I changed dozens of pages, rather than going based on unstated practice. It also helps the usability of the categories. <span class=nowrap>– · 16:52, 12 January 2015 (UTC)

Infobox usage with version exclusive templates
We really need to adjust the infoboxes to include some sort of parameter to state edition, as this really looks bad. It would be nice to only use those templates when there is no infobox, as there is no nice looking way to implement them together, especially if the article's content exists in multiple non-pc editions.

Also, it is currently impossible to find out something does not exist in an edition without scrolling all the way to the history section. If there was an infobox row stating as such, a user can then instantly find out something like "Iron golems are not in PE".

The main problem would be adding this parameter so it is not intrusive, yet gets the point across, and preventing it from. Maybe within the blue infobox title using OS and titles?

– · 16:48, 12 January 2015 (UTC)


 * . Maybe like this? Place the list of edition the feature is exclusive to along the first infobox rows:

Stonecutter


 * <span class=nowrap>– — ru.wiki moderator 17:05, 12 January 2015 (UTC)


 * , but with a minor change to 's version:

Stonecutter


 * – - 17:12, 12 January 2015 (UTC)


 * I’m developing the new infobox at (note the typographical quotes!). <span class=nowrap>– — ru.wiki moderator  17:24, 12 January 2015 (UTC)


 * Done. I also have made a separate template for editions. It allows you to show or hide the textual link to the edition too. <span class=nowrap>– — ru.wiki moderator 17:39, 12 January 2015 (UTC)


 * The icons look decent, still needs a bit of work on the sizing. I personally prefer it without the text, as not only is it more similar to the current column "required tool(s)", but it will be a consistent size whether there is one or all four versions. <span class=nowrap>– · 02:28, 13 January 2015 (UTC)


 * As an alternative here, Wikipedia has had a system for years that is used for denoting e.g. featured articles and page protection levels; as long as the version icons are still easily identifiable after being scaled down to an appropriate size (or can be replaced by appropriate such icons), implementing that system would allow us to keep the current template transclusions untouched (other than adding icons to denote the versions a given object appears in where they are absent) while solving the presentation issue. <span class="nowrap">「」· 23:35, 12 January 2015 (UTC)


 * I've always liked the look of those icons. I'm taking it they are controlled directly using absolute positioning? I'd love to see what it would look like here. <span class=nowrap>– · 02:09, 13 January 2015 (UTC)


 * I've made an early version of the top icons in my, it was based off the wikipedia version, although I could drop half the code using variables and one quarter since we only use one skin for styling. <span class=nowrap>– · 03:20, 13 January 2015 (UTC)


 * There may or may not be CSS in Wikipedia's file specific to top icons, and there is (or was) work being done to add similar functionality to core or in an extension, but (as you noticed) Wikipedia's current implementation is entirely contained in the ((top icon)) template. There's zero reason for us to not use variables (or a Lua module if Majr or someone else feels like coding one up, and if it would be less overhead than a template) or trim the code to account for our single skin, though. <span class="nowrap">「」· 05:10, 13 January 2015 (UTC)
 * Top icons don't work on mobile, while there are many players playing Pocket Edition. <span class=nowrap> — ru.wiki moderator 06:44, 13 January 2015 (UTC)


 * Something in the mobile CSS is setting, which might be the issue, but I can't figure out why without access to LocalSettings.php; it's not in . Upgrading to MediaWiki 1.25 would add , which might work on mobile, but who knows when that will happen.


 * Technical issues aside, I have a couple of concerns with using top icons. One, the icons are relatively small and easy to miss, so we'll still need to mention version exclusivity elsewhere in articles. Two, sometimes version exclusivity only applies to part of an article (such as or ), so a single set of icons for the whole page doesn't make sense. -- undefined 09:47, 13 January 2015 (UTC)


 * I have fixed the mobile error as a temporary preview, by adjusting the top positioning and forcing a display (to override display none). Can someone with a mobile check that on my sandbox? You have to have the top icon section open for it to appear. If used in the future, they would all be in the main section, and the positing would be controlled through the main css files.
 * Dinoguy1000@undefined There was some code, only it was in each different skin file, so I took the code from the skin most similar to ours (vector.css) and modified it from there.
 * Orthotope@undefined They are a little small, especially unnoticed on larger screens. No matter what we should keep the individual version notes within articles, as there are always going to be differences between versions.
 * As for applying to only part of the article, there really is no fix for that other than an infobox parameter, but since the main article that is affected by that is, and that already uses , that would be an easy fix. The rest multiblock should already note which are in each version.
 * – · 15:27, 13 January 2015 (UTC)


 * The top icon does appear on mobile (but in the same place as the page title’s text), but it becomes hidden when the ad box is shown. Tested with mobile version of Google Chrome 28.0.1500.94 on Sony Xperia E1 with Android 4.3. <span class=nowrap>– — ru.wiki moderator 15:52, 13 January 2015 (UTC)

I'm not sure about the ad part, but the icon should no longer appear within the title (I moved it to the line with the edit and watch icons) <span class=nowrap>– · 16:16, 13 January 2015 (UTC)


 * Months before this discussion started, of Russian Minecraft Wiki made a template that fulfills the same goal: . . Aside from icon size, there are problems with, but I think that it can be used as a convenient alternative to top icons (can be used multiple times) and infobox icons (can be used outside of infoboxes). I may create a fork of it in my  and do necessary fixes. <b class=nowrap>I’m   , f.k.a. Naista2002 </b> 17:15, 30 January 2015 (UTC)
 * I’ve made a test fork of it . Sorry for Russian text, but, for reference, parameters for it are  (, computer edition),   ,   ( , s) and   . <b class=nowrap>I’m   , f.k.a. Naista2002 </b> 17:38, 30 January 2015 (UTC)


 * It looks decent. I'm unsure if it has it already, but some tooltip text would be nice to describe the icon. The main question would be whether to use it per section or per page.
 * It may also work to have two versions of the template to fix the spacing issues, that is one called by the infobox (like [ this] maybe?, and one used when there is no infobox, which would appear similar to the one shown before. <span class=nowrap>– · 20:29, 30 January 2015 (UTC)
 * I've adjusted that template to use a div box, so it works fine on mobile and in the infobox title. I shall later add a switch to don't show the box around it. <b class=nowrap>I’m , f.k.a. Naista2002 </b> 09:36, 31 January 2015 (UTC)