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. --Mccv13 (talk) 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 (User Page|Talk) 14:45, 2 January 2014 (UTC)
See Talk:Minecraft Wiki#Minecraft wiki app. 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. –Matt ᐸ Talk Contribs ⎜ 14:49, 2 January 2014 (UTC)
I just use the desktop site instead of the mobile one on my Android.
Have you tried the mobile site at all? And if so, what are your reasons for not using it? –Matt ᐸ Talk Contribs ⎜ 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? A Moon (talk) 09:52, 7 January 2014 (UTC)
Add {{delete|reason}} 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. -- Orthotopetalk 10:00, 7 January 2014 (UTC)
Thank you very much. A Moon (talk) 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? Meeples10t ~ c 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 Category:Greek translation, 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.) -- Orthotopetalk 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). Meeples10t ~ c 10:52, 17 January 2014 (UTC)
First off, we don't vote, we discuss. Secondly, Minecraft Wiki/el 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. -- Wynthysttalk 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. Meeples10t ~ c 01:09, 23 January 2014 (UTC)
How can I turn an animated texture into a .gif? --tonkku107 «Talk Contribs» 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. -- Orthotopetalk 19:53, 31 January 2014 (UTC)
Armor Page Split
First suggested by admin Majr April last year, 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. Helmet, Chestplate, Leggings, Boots 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. –Goandgoo ᐸ Talk Contribs Edit count 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). —munin · · 11:14, 2 February 2014 (UTC)
Yes 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). --MentalMouse42 (talk) 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. –Goandgoo ᐸ Talk Contribs Edit count 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.
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. --KnightMiner(talk|contribs) 15:16, 15 February 2014 (UTC)
My personal opinion is that as many items should have their own pages to avoid confusion. --▶ ZlingerZZ◀ (talk | contribs) 14:05, 21 February 2014 (UTC)
Then I would suggest splitting Fish into normal and cooked, to keep it the same. --KnightMiner(talk|contribs) 18:25, 21 February 2014 (UTC)
Here on my Mac, running Chrome 32, the Minecraft style tooltips (minetips) have a blurry font, unlike the reference image. This is pretty annoying, does anyone know why this happens? —Fenhl 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. –Matt ᐸ Talk Contribs ⎜ 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 Swedish Translation project 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 ▶ ZlingerZZ◀ (talk | contribs) 14:15, 21 February 2014 (UTC)
Hello, I have just started in the Norwegian translation project 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? :) Powerminerdude (talk) 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 Powerminerdude (talk) 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. ▶ZlingerZZ◀ ( talk | contribs| edits) 08:12, 14 April 2014 (UTC)
Awards on minecraft wiki?
Is this [[1]] 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 ^^ Powerminerdude (talk) 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? ▶ZlingerZZ◀ ( talk | contribs| edits) 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--107.222.205.198 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. ▶ZlingerZZ◀ ( talk | contribs| edits) 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? Creepergoboom64 (talk) 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? 24.144.251.110
Check your calendar :-) --217.81.252.60 17:44, 1 April 2014 (UTC)
Exactly, today is April Fools' Day! Kingpowl~es.Wiki Admin (talk) 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? ▶ZlingerZZ◀ ( talk | contribs | edits ) 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. -- Orthotopetalk 14:26, 15 April 2014 (UTC)
color write
How do Write in chat color???
There's a nice list of formatting codes you can use to change text colour. I hope this helps! EthanCentaurai (talk) 12:56, 17 April 2014 (UTC)
No Captcha
I found a security problem about editing pages.
I found a missing thing in the String 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 Sbarza (talk • contribs) 12:42, 25 April 2014 (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. -- Orthotopetalk 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? Meeples10t ~ c 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? --KnightMiner(talk|contribs) 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. Meeples10t ~ c 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) --KnightMiner(talk|contribs) 13:32, 11 May 2014 (UTC)
I tried adding my map reader program to Programs_and_editors/Specialized_programs, 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. DaedalusYoung (talk) 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. -- Orthotopetalk 20:00, 31 May 2014 (UTC)
File:Spamfilter.pngThat'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? DaedalusYoung (talk) 16:17, 1 June 2014 (UTC)
Should be fixed now; sorry about the inconvenience. -- Orthotopetalk 01:11, 2 June 2014 (UTC)
Thanks a lot, that works! :) DaedalusYoung (talk) 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 development information 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. –Matt ᐸ Talk Contribs ⎜ 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. -- Orthotopetalk 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.)? --KnightMiner 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 Style Guide 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? A Moon (talk) 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. 99.164.78.31 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. 99.164.78.31 21:48, 12 July 2014 (UTC)
Yeah, the underscore could be the problem. I'd try contacting Game widow, see if someone at Curse can get your account straightened out. -- Orthotopetalk 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 — Game widow(talk) 00:49, 13 July 2014 (UTC)
Thanks guys, I appreciate it. Let me know if there's anything I have to do. 99.164.78.31 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. CrsBenjamin - (talk) 00:57, 13 July 2014 (UTC)
Thanks for the help! I'm able to log in with my new username now. LB(T|C) 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 Minecraft_Wiki:Admin_noticeboard#Delete_the_external_links_filter.I disagree because useful links is much,much more common then spam.Thanks.Please share your thoughts below.Crep987 (talk) 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 blacklist. –Matt ᐸ Talk Contribs ⎜ 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.
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
Herkio (talk) 08:51, 27 July 2014 (UTC)
Just download the images you want from here and upload them on the Dutch wiki. -- Orthotopetalk 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. \
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
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. –Majr ᐸ Talk Contribs ⎜ 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. --Elike98talk 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? | violine1101(Talk) 14:07, 23 November 2014 (UTC)
Why not use a lighter stone color? It would would contrast well with the dark stone background. –KnightMiner · talk 02:21, 24 November 2014 (UTC)
That also is a good idea! Another option would be to take the default Minecraft button texture. | violine1101(Talk) 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.
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. –Majr ᐸ Talk Contribs ⎜ 05:37, 31 July 2014 (UTC)
Great! glad to here there's a plan in place.Tinaun (talk) 05:54, 1 August 2014 (UTC)
Bot - Request
Hello! IdefixBot is a new bot run by ObelusPA2, 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. — Itouchmasterprodc 19:29, 31 July 2014 (UTC)
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 10.64.180.41 (talk • contribs) 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 GnomeCustomer (talk • contribs) 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. –Goandgoo ᐸ Talk Contribs Edits 11:49, 10 August 2014 (UTC)
Template needed
There is a template needed for the *Template:BlockLinkClock whatever that is , and it is needed now in the show red stone sectionShooter1166 (talk) 07:04, 18 August 2014 (UTC)Shooter1166
No, you just didn't put the vertical bar between {{BlockLink}} and Clock. Although a clock requires redstone to craft, it doesn't actually interact with redstone power, which is what the redstone navbox is about, so I removed the link. —munin · · 07:38, 18 August 2014 (UTC)
Thank you —munin –Preceding unsigned comment was added by Shooter1166 (talk • contribs) 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?
GunslingerN7, Technology and Gaming Freelancer (Talk) 20:06, 19 August 2014 (UTC)
That's maybe just in case the either fails. Naista2002 ♦ 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. –Majr ᐸ Talk Contribs
–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. Naista2002 ♦ 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. –Majr ᐸ Talk Contribs 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 Project or should I just keep cleaning up articles as I randomly find them? --KnightMiner 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. —munin · · 21:52, 25 August 2014 (UTC)
I've started the project. It divides the pages needing to be finished into sub-groups of blocks, items, and entities. --KnightMiner 17:57, 26 August 2014 (UTC)
Creating Structure Renders
Hello! I'm interesting how do you create images, like this, i want to update it, because from 1.8, 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. --109.68.237.19 04:49, 5 September 2014 (UTC)
The first edit you made to that talk page added the interwiki link. –Majr ᐸ Talk Contribs ⎜ 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... –Naista2002 ᐸ Talk Contribs 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? Meeples10t ~ c 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 Majr user scripts (User:Majr/editcounter.js), there was an additional link added to the tool box. --KnightMiner 23:44, 26 September 2014 (UTC)
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 Unimplemented features 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 Upcoming features.
I came up with a solution, although it requires a new rule, a revision to the Style guide, and a rewrite of both Unimplemented features and all versions Upcoming features. 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:
Features that are not currently in the game should be in the versions Upcoming features article.
This excludes features with have been removed, which may be noted in either their own article or in the proper articles history section.
This also excludes features from development versions, which may be noted on articles affected by the feature and the relevant upcoming version article.
I know this rule would remove the article 1.9, 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.
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.
Features planned for the next update, except features already noted on a upcoming version page, which will be linked to.
Features mentioned by mojang as upcoming. These are less likely to get added soon, so the section will be smaller.
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 Canceled features.
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.
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 cancelled features makes more sense.
Just for clarification, where would a page like Lantern go? There were plans for it but it was dropped, so what that be in cancelled features?
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. –Goandgoo ᐸ Talk Contribs Edits 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. –Goandgoo ᐸ Talk Contribs Edits 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. -- Orthotopetalk 06:52, 28 September 2014 (UTC)
@Goandgoo: 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 removed features 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 mentioned features, or on upcoming features which would list features mojang suggested, but are not currently adding.
@Orthotope: What about the features that are in the game, but currently do nothing? Such as we really don't need a whole article 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.
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 upcoming versions, 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 unimplemented features.
I agree with having a removed features article. Individual pages on things like crying obsidian (which was just an unused texture in a file for a couple of versions) are really unnecessary. –Majr ᐸ Talk Contribs ⎜ 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. –Goandgoo ᐸ Talk Contribs Edits 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. –Majr ᐸ Talk Contribs ⎜ 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 mentioned features page would be best, and simply use {{about}} to help readers searching for those, or renaming it to unused features. 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. --KnightMiner 04:48, 30 September 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? –Majr ᐸ Talk Contribs 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).
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 upcoming versions, as there really is no content to put on it. But other than that, there is mentioned features, unused features, and removed features. These pages will ultimately replace the various pages that simply described an idea of a developer or a sprite in the game.
Opinions? –KnightMiner 17:16, 25 October 2014 (UTC)
Looks good. Pages such as Crying Obsidian, Lanterns etc and anything in the Unimplemented category can also get redirected to these pages. –Goandgoo ᐸ Talk Contribs Edits 00:47, 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. –Majr ᐸ Talk Contribs 06:41, 26 October 2014 (UTC)
Put them on the same page and use {{pocket}}, etc.? –Majr ᐸ Talk Contribs 09:21, 26 October 2014 (UTC)
Agree with the proposed structure, but, KnightMiner, maybe make this project located where it belongs (say, at Minecraft Wiki:Projects/Upcoming, unimplemented and mentioned features rewriteMinecraft Wiki:Projects/Upcoming and unimplemented features rewrite), not in userspace? This would make more sense. --Naista2002 ♦ 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. –Majr ᐸ Talk Contribs 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 1.9 (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).
I have changed "Upcoming versions" to "Planned versions", 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 1.8, and it stopped most of the IPs from adding mentioned features as current features.
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.
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 mentioned features.
But what is defined as actual information? A signal screenshot was considered sufficient for slime block, 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 Plugin API 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.
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 1.3, which was released over two years ago. It can hardly be considered "upcoming".
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 mentioned features. 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 the rules talk page, since that was where the rule about tutorial existed; although, it may be a better idea to create something similar to WP:Notability, only describing required locations of content (mentioned on mentioned features, tutorial as subpages tutorials)
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.
We have one, Special:RandomPage. 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. --KnightMiner 01:55, 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? LB(T|C) 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. –Majr ᐸ Talk Contribs ⎜ 04:34, 30 September 2014 (UTC)
Woah, thanks! Why are there two different places for email settings? Oh well, problem solved. LB(T|C) 04:56, 30 September 2014 (UTC)
It seems curse disabled the location from echo, it is only in the profile now. --KnightMiner 04:59, 30 September 2014 (UTC)
Page merging and splitting policy
As brought up on Talk:Wet Sponge, 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, Sponge and Wet Sponge have a different function, while the different types of Flowers are all fundamentally the same. Dirt, Coarse Dirt, and Podzol are also rather inconsistent when it comes to merging.
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 – Sealbudsman (Aaron)T, C, 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 Talk:Wet Sponge. 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 Wet sponge will almost surely also want to read the contents of Sponge, and vice versa, because of the relationship between the two blocks and how they are used. A reader of Podzol would not really need much information from Dirt, if any, so this particular criteria would not apply (Though other criteria might).
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. —KnightMiner 18:02, 30 September 2014 (UTC)
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). —KnightMiner 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? – Sealbudsman (Aaron)T, C, 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.
As I've recently (and briefly) said on Talk:Red Sandstone, if blocks with different block IDs use block data/block states for minor things like orientation, their pages are allowed to merge (e.g. fences and doors). But if they use them for many different block variations (like sandstone and red sandstone), 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 wood.
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. –KnightMiner · talk 21:55, 20 November 2014 (UTC)
Reverting consecutive edits
How can I revert consecutive edits without editing text manually? —Naista2002 ♦ 06:15, 6 October 2014 (UTC)
Press edit on the revision you want to revert to, then save. –Majr ᐸ Talk Contribs 06:16, 6 October 2014 (UTC)
Thanks, let me try... —Naista2002 ♦ 06:34, 6 October 2014 (UTC)
Then, how the message like this can automatically appear in the edit summary?
You'd have to type it manually. –Majr ᐸ Talk Contribs 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.) --Naista2002 ᐸ Talk Contribs 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 Projects and Wiki Rules. -- Orthotopetalk 09:42, 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 Style guide) –KnightMiner 14:26, 29 October 2014 (UTC)
This has been proposed before, 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. –Majr ᐸ Talk Contribs 04:29, 5 November 2014 (UTC)
MCW: and MCT: namespace aliases can now be used. –Majr ᐸ Talk Contribs 06:02, 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 style guide shortcut is an exception as it is already in use and was made before we had the namespace shortcut. –Majr ᐸ Talk Contribs 05:21, 27 November 2014 (UTC)
There are some long names for project names. We can make a shortcut MCW:P for MCW:Projects, and then MCW:P/RFS for MCW:Projects/Rewrite for Style; MCW:P/ID for MCW:Projects/Indonesian translation (if it does not conflict with other shortcuts!) and so on. --Naista2002 (talk|contribs) 16:57, 27 November 2014 (UTC)
I suggest unite them, because they have not big difference, only texture. --Dand0 (talk) 12:03, 31 October 2014 (UTC)
I don't see any reason for merging them; 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. --Naista2002 ᐸ Talk Contribs 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 Red Sandstone. 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).
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. –Goandgoo ᐸ Talk Contribs Edits 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 sitenotice) –KnightMiner 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.) Rashkavar (talk) 18:27, 8 November 2014 (UTC)
I really don't see the point of such a page, as if you refer to data values, 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. –KnightMiner 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 User:Rashkavar/Obtainable items) and use it to experiment with learning MediaWiki syntax. If people like the results, it could be moved into the mainspace. -- Orthotopetalk 21:58, 8 November 2014 (UTC)
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 data values.
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?
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. —munin · · 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 zombies and chicken jockeys make infoboxes really long. (chicken jockeys have 14 possible drops). LauraFitalk 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.
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. –KnightMiner 15:21, 15 November 2014 (UTC)
Regarding drops: I think that they should be renamed common drops (as on the wither 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? -Sonicwavetalk 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). —munin · · 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) –KnightMiner 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 {{{drops}}}, leave {{{commondrops}}}, {{{raredrops}}} and {{{equipment}}} empty.
@Naista2002: 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. –Majr ᐸ Talk Contribs 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. LauraFitalk 01:59, 18 November 2014 (UTC)
All sounds are already documented at sounds.json, 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? —munin · · 02:10, 18 November 2014 (UTC)
munin295: that is a good idea, if we don't have any place to put sounds in block/item/entity pages. LauraFitalk 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 sound (disambig) page to include all of the sounds (as well as basic info such as sound range/distance, etc). -Sonicwavetalk 03:05, 18 November 2014 (UTC)
Or just create a sounds page. LauraFitalk 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. –KnightMiner · talk 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). -Sonicwavetalk 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. –KnightMiner · talk 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). -Sonicwave (talk) 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). –KnightMiner(t|c) 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"? –KnightMiner 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. –Goandgoo ᐸ Talk Contribs Edits 12:53, 15 November 2014 (UTC)
Outdated info in tutorials
I see that tutorials 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.
Yes, like that. Another example: Tutorials/Shelters#Other at some point states that carpets 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.
A project of this nature is a good idea, marking pages with Rewritten tutorial or something like that. –Goandgoo ᐸ Talk Contribs Edits 23:53, 15 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. -- Orthotopetalk 23:33, 20 November 2014 (UTC)
The project allows to keep track of done pages and manage them.
It seems that a lot of the mods listed in the Mods Category are very outdated (for example CamelOre 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? Sonicwave (talk) 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. –KnightMiner(t|c) 01:00, 13 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. –Goandgoo ᐸ Talk Contribs Edits 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 mods 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 MentalMouse42 was working on the Thaumcraft articles this summer -- he might want to save them to his userspace or something. —munin · · 00:21, 16 November 2014 (UTC)
I mostly agree with Munin. Thankfully, there are wikis on Wikia about Minecraft mods, e.g. here. Wikia is more maintained than this wiki, so there it might be more up-to-date. For listing mods, one could look into [[Category:Mods]]. --Naista2002 ᐸ Talk Contribs 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. --MentalMouse42 (talk) 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. –KnightMiner · talk 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. --MentalMouse42 (talk) 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. 「ディノ奴千？！」? · ☎ Dinoguy1000 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. -- Orthotopetalk 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. Xbony2 (talk) 22:59, 17 January 2015 (UTC)
Some mods are being moved over, such as ones done by TheWombatGuru. –KnightMiner · talk 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 exported with full history from here then imported on the FTB wiki. –Majr ᐸ Talk Contribs 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 :) Xbony2 (talk) 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)".— TheWombatGurut | c 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 Xbony2 (talk) 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. TheSatanicSanta (talk) 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. Xbony2 (talk) 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 FTB:. The page will then discuss what mods are, and link to FTB:. –KnightMiner · talk 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. — TheWombatGurut | c NL Admin 14:27, 20 January 2015 (UTC)
Kind of, like Stone on FTB. it would be nice to make this possible: FTB:Stone. (Which I now see is already possible) — TheWombatGurut | c 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 :) TheSatanicSanta (talk) 03:11, 21 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. -- Orthotopetalk 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. --GreenStone (talk) 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. Retep998 (talk) 07:04, 25 January 2015 (UTC)
2 questions
What does right translate do and what extension added it?
"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. dand0 (talk) 07:51, 20 November 2014 (UTC)
The group rights are from Extension:Translate, 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. -- Orthotopetalk 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: [2] or this: [3]? Please consider this, it would improve aesthetics of pages. Xeoxer (talk) 15:30, 22 November 2014 (UTC)
That would make some infoboxes very long. –LauraFi·talk 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. –KnightMiner · talk 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. —munin · · 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? --Naista2002 (talk|contribs) 14:01, 25 November 2014 (UTC)
From what I heard, allowing the values to sync is in progress, see Talk:Chunk format#Splitting the page into templates. munin295 and LB1 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. –KnightMiner · talk 16:31, 25 November 2014 (UTC)
(edit conflict) 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 Category:Entity would need to be updated. There's a proposal at Talk:Chunk format#Splitting the page into templates that would solve both problems, but I don't know if it's ready to implement yet. -- Orthotopetalk 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. —munin · · 17:57, 25 November 2014 (UTC)
I agree with Munin. Until LoadBox is fixed, we can use links. --Naista2002 (talk|contribs) 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? --ToonLucas22 (talk) 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. -- Orthotopetalk 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. --ToonLucas22 (talk) 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. -- Orthotopetalk 01:35, 6 December 2014 (UTC)
So are the 1.6.1, 1.7.2 and 1.8 development version downloads being linked? --ToonLucas22 (talk) 01:54, 6 December 2014 (UTC)
No response recieved since my last response, so i'm taking that as a yes. --ToonLucas22 (talk) 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 {{{clientdl}}}. –KnightMiner · talk 01:45, 7 December 2014 (UTC)
Well, maybe a {{{jsondl}}} parameter should be added, as the json files are also stored there. --ToonLucas22 (talk) 01:54, 7 December 2014 (UTC)
Nevermind, I'm just going to put the .json links in brackets in the {{{clientdl}}} parameter. --ToonLucas22 (talk) 17:40, 7 December 2014 (UTC)
Looks good. –KnightMiner · talk 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. --ToonLucas22 (talk) 22:05, 13 December 2014 (UTC)
Apparently, the error is also there when attempting to get to the Recent Change page or to backtrack. --ToonLucas22 (talk) 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 Admin noticeboard 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.
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).
–KnightMiner · talk 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. –Majr ᐸ Talk Contribs 10:00, 23 December 2014 (UTC)
In that case, I'd assume you would advise posting unanswered requests on the admin noticeboard? –KnightMiner · talk 14:42, 23 December 2014 (UTC)
If it requires admin attention, it goes on the admin noticeboard. That's what it's there for. –Majr ᐸ Talk Contribs 09:43, 24 December 2014 (UTC)
Well, by UTC time. Still have a few hours to go where I live.
Happy New Years! –KnightMiner · talk 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 --ToonLucas22 (talk) 00:33, 1 January 2015 (UTC)
I have to wait 35 minutes :) –LauraFi-talk 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. --ToonLucas22 (talk) 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 celebrate message on Russian wiki. 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. --Naista2002, now NickTheRed37 (talk) 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 Incredituber3011 (talk • contribs) at 10:41, 03 January 2015 (UTC). Please sign your posts with ~~~~
This is the English wiki, the Italian wiki is here. The whole point of a wiki is anyone can edit it, you don't need to ask to get started. --–Majr ᐸ Talk Contribs 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. - MinecraftPhotos4U (talk) 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. –KnightMiner · talk 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 - MinecraftPhotos4U (talk) 20:51, 7 January 2015 (UTC)
As a point of comparison, consider the fact that there is only one English version of Wikipedia (plus Simple Wikipedia, 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 Chinese Wikipedia, but I suspect developing that would be a very involved affair, and even after extensive development would have a lot of problems. 「ディノ奴千？！」? · ☎ Dinoguy1000 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."
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. –Majr ᐸ Talk Contribs 10:34, 11 January 2015 (UTC)
Userpages are useless in content categories, remove them on sight. 「ディノ奴千？！」? · ☎ Dinoguy1000 11:31, 11 January 2015 (UTC)
And I assume translation project pages should use the /lang version of categories instead of the main ones? –KnightMiner · talk 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. 「ディノ奴千？！」? · ☎ Dinoguy1000 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. –KnightMiner · talk 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 excessively expanding the infobox. Maybe within the blue infobox title using {{OS}} and titles?
Done. I also have made a separate template for editions. It allows you to show or hide the textual link to the edition too. –Nick the Red37 — ru.wiki moderator (talk) 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. –KnightMiner · talk 02:28, 13 January 2015 (UTC)
As an alternative here, Wikipedia has had a top icon 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. 「ディノ奴千？！」? · ☎ Dinoguy1000 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. –KnightMiner · talk 02:09, 13 January 2015 (UTC)
I've made an early version of the top icons in my sandbox, 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. –KnightMiner · talk 03:20, 13 January 2015 (UTC)
There may or may not be CSS in Wikipedia's Common.css 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. 「ディノ奴千？！」? · ☎ Dinoguy1000 05:10, 13 January 2015 (UTC)
Top icons don't work on mobile, while there are many players playing Pocket Edition. Nick the Red37 — ru.wiki moderator (talk) 06:44, 13 January 2015 (UTC)
Something in the mobile CSS is setting .content .topicon {display:none !important}, which might be the issue, but I can't figure out why without access to LocalSettings.php; it's not in MediaWiki:Mobile.css. Upgrading to MediaWiki 1.25 would add page status indicators, 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 Technical blocks or Bowl#Usage), so a single set of icons for the whole page doesn't make sense. -- Orthotopetalk 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: 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: 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 Technical blocks, and that already uses its own block template, that would be an easy fix. The rest multiblock should already note which are in each version.
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. –Nick the Red37 — ru.wiki moderator (talk) 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) –KnightMiner · talk 16:16, 13 January 2015 (UTC)
Months before this discussion started, Ivan-r of Russian Minecraft Wiki made a template that fulfills the same goal: ru:Шаблон:Версии. Example of usage. Aside from icon size, there are problems with clearance, 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 Gamma sandbox and do necessary fixes. I’m NicktheRed37, f.k.a. Naista2002 17:15, 30 January 2015 (UTC)
I’ve made a test fork of it here. Sorry for Russian text, but, for reference, parameters for it are пк (pc, computer edition), карман (pocket, Pocket Edition), консоль (console, Console Editions) and пи (pi, Pi Edition). I’m NicktheRed37, f.k.a. Naista2002 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. –KnightMiner · talk 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. I’m NicktheRed37, f.k.a. Naista2002 09:36, 31 January 2015 (UTC)
(User Page|Talk)
talk 13:42, 17 January 2014 (UTC)
17:35, 25 August 2014 (UTC)
T, C, b 17:52, 30 September 2014 (UTC)
.png){kind=link}
