Talk: Community portal/Archive 24

This page is an archive of past discussions. Do not edit the contents of this page.

If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Did these versions actually exist?

Following the recent rediscovery of Alpha v1.0.2 I've been in the process of adding evidence of existence of various versions from Alpha which are no longer available in the launcher. There is currently one remaining version which I am yet to find any proof for:

Alpha v1.0.14_01

I can't seem to find any particularly solid ground on this version's case. I've searched through various YouTube videos, but it appears to be elusive, and I'm not being too successful with finding sources on Notch's blog either. General googling also provides no relevant results, photographic or otherwise.

There's also a few versions that can be presumed to exist due to later patches, but don't have pages, and I have also had no success verifying:

Can anyone help provide proof (video, screenshot, blog post or otherwise) that any of these four versions existed? - MinecraftPhotos4U (talk) 14:35, 21 March 2018 (UTC)

I can provide some history from the wiki~~, which seems to show that it doesn't exist~~: a1.0.15 was added to version history in revision 13802 and included the changes given to a1.0.14_01. But it was put before multiplayer instead of after, so there were two a1.0.15 versions listed, and this was also an after-the-fact revision (dated 25 August 2010). (n.b. I bypassed the broken username in version history by just manually editing the date)

This was later converted into a table in revision 15910, and that changed the second a1.0.15 to a1.0.14 (probably by accident), so that there were two a1.0.14's listed; ~~this is also when it was given a release date of August 03 2010~~. This duplicate entry continues on for years, until the articles are split off in revision 212986. The alpha history was put here. And, it was eventually the unique _01 name in revision 370385 when Fenhl refactored the links in the article.

As one more point of evidence, check the history of Patch history. There is only Seecret Friday 7 (with the last edit on 31 July 2010) and Seecret Friday 8 on 20 August 2010. No a1.0.14_01. And, finally, it just doesn't make sense; the changes for a1.0.14_01 include "Can enter the IP for a server other than Mojang's server", yet a1.0.15 is supposed to be the version that introduced support for multiplayer.

~~Basically, it is pretty clear to me that this version doesn't actually exist, and all of the changes listed for it are actually part of a1.0.15~~. No comment for the other versions yet. --Pokechu22 (talk) 18:18, 21 March 2018 (UTC)

[{{fullurl:Alpha v1.0.14_01|}} Alpha v1.0.14_01] doesn't exist, the only blog post that would be fitting belongs to Alpha 1.0.15. The post is mislabeled as Alpha 1.0.14 though, but comparing the dates of the jars and the timestamps of various blog posts it becomes clear that this one is indeed for Alpha 1.0.15. – Fuzs 19:26, 21 March 2018 (UTC)

On a similar topic, it seems as though the versions 0.30_01, 0.30_02 and 0.30_03, as listed in Version history/Classic, are all misnomers/conjectural; these were all called 0.30 in the page's initial revision, and looking at the corresponding blog posts on Word of Notch showed that they also shared the 0.30 title ingame. The situation with the 0.24 versions is identical. Does this affect any other versions? - MinecraftPhotos4U (talk) 18:58, 22 March 2018 (UTC)

I appear to have found the proof that Alpha 1.0.17_01 does indeed exist, as per here: https://i.imgur.com/SAkZp.png sourced from here: https://www.reddit.com/r/Minecraft/comments/d3fmt/double_tree_what_does_this_mean/ 44trent2 (talk) 08:14, 25 April 2018 (UTC)

added! There's one that can be crossed off of the list.

Now that we're also keeping track of Classic versions now, here's an updated list of conjectural versions:

And the "no-proof-so-they-might-as-well-be-fakes":

Would this be better split off into its own project? - MinecraftPhotos4U (talk) 10:30, 25 April 2018 (UTC)

Probably, yes. – Nixinova 16 px 16 px 16 px 05:51, 26 April 2018 (UTC)

I'll get around to setting it up at somewhere along the lines of [{{fullurl:Minecraft Wiki:Projects/Proving missing versions|}} Minecraft Wiki:Projects/Proving missing versions] sooner or later. - MinecraftPhotos4U (talk) 15:22, 5 May 2018 (UTC)

I'm still having major difficulty finding proof for Alpha v1.2.3_03; looking through several old forum threads hasn't turned up any screenshots, and while I've found mentions of it none seem to imply strongly enough that it existed. - MinecraftPhotos4U (talk) 19:46, 12 July 2018 (UTC)

Page locks to signal protection

This was proposed about a week ago and it only got a few responses, so I'm starting a new community portal topic. The original discussion can be seen at Template talk:Protected.

So basically, AttemptToCallNil and I came up with the idea to have locks as indicators in the top right corner of any protected page. How it would work is for each level of protection, it will show a different lock color, title, link, and category. A demonstration of this can be seen in my sandbox. The reasons I think locks should be used is because the current {{protected}} template is kind of distracting and it's not really clear where to use it. It seems to be used on only a few pages, and is kind of big, making it distracting to readers. Also, it would be confusing if it were used on templates, as readers may think that it's the actual template, rather than signifying a state that applies to the template. However, using locks instead would solve all these problems - just simply add the template to pages that are protected in any way at any level. I haven't come across any problems so far with my experimenting, although I'm sure there's something.

Anybody who wants to discuss is welcome to do so either here or at Template talk:Protected. This will be quite a big change, so it would be nice to have some feedback and opinions. =)-- Madminecrafter12^{20pxTalk to me20px} 20:04, 2 June 2018 (UTC)

Support - Wikipedia does the exact same thing and I don't see why we shouldn't. --Marioprotvi (talk) 20:12, 2 June 2018 (UTC)

Well, this idea seems to be fully supported with no opposition. The question is, what do we do now? Should we wait till somebody finds a way to add the template to every page automatically, or go ahead and move it to the template namespace? (I support the second). But if we do the second, should we move it to a temporary title (such as [{{fullurl:Template:Protected 2|}} Template:Protected 2]) as a work-in-progress until we have the details worked out and possibly found an automatic way to add it? Or should we go ahead and delete the current Template:Protected (obviously removing the pages that use it as well) and move my sandbox to that title?-- Madminecrafter12^{20pxTalk to me20px} 14:07, 7 June 2018 (UTC)

Lets figure out first how to add the template to every page automatically. If a new template is introduced before it's achieved its goal, people will start using it wrongly, introducing even more overhead work. And removing the use of the current template from pages leaves those pages (as it currently works now) without any visual clue as to the protection level. So, how can a template be transcluded automatically on a page, depending on some parser function criteria? – Jack McKalling [ 16px 16px ] 14:20, 7 June 2018 (UTC)

By the way, page status indicators for protection levels are already limitedly used on the Russian wiki and even referenced in the page protection guidelines. I don’t think we will ever get a working automatic protection indicator only using wikitext/template means, in my vision it necessarily needs some JavaScript code (and I’m not used to program in JS). The question says: is using JS means worth it? Administrators can “hang the locks” while changing protection levels, and a specifically designed program can place these templates en masse automatically, if run via a bot account with admin privileges. — BabylonAS (talk | ru.Wiki Admin) 14:42, 7 June 2018 (UTC)

Agree with BabylonAS. I don't think we should be prevented from doing this just because we will need complicated JS code to add it automatically. Just noting, on Wikipedia all administrators are expected to add the locks as soon as they protect a page - though sometimes they forget. There are no bots that automatically add locks - but if a protection has expired, a bot will remove the lock from the page. However, this is solved with :Category:Unprotected pages using Template:Protected, and all admins would have to do is look through that category every now and then.-- Madminecrafter12^{20pxTalk to me20px} 14:56, 7 June 2018 (UTC)

It does indeed require complicated JS code. The indicator element is a virtual one in wikitext, you cannot append it to an existing page with JS, it has to be processed by the wikitext parser first (or simulated as such). I'm not saying "no" to the idea, however. I'd just really like to see this thing automated when protecting pages. It removes the need for an admin to manually edit the page to reflect the new protection level (as you've mentioned already, sometimes this is forgotten). A bot helps, but are there maybe more direct ways to make it automated? Similar to how you could show a form of message box during editing for particular situations by abusing system messages. I haven't got an idea myself, as I'm not familiar enough with all the options we got. – Jack McKalling [ 16px 16px ] 15:04, 7 June 2018 (UTC)

To change a large amount of pages at a time, we can use bots, but I am not sure if bots are allowed here... Lê Duy Quang (Make some words | Contributions)

New idea

This idea doesn't seem to currently be going anywhere, but I have a different but sort of related idea. Currently, when one edits a page they do not have permission they edit, they just get the following message: "The page has been protected to prevent editing and other actions." I'm thinking we kind of do closer to what Wikipedia does but omit the stuff about edit requests, etc. - mainly say the level of the protection, link to the protection log, and if it's a semi-protected page, suggest that the reader create an account. I think this would be very helpful. The great thing here is we wouldn't need a bot - it would automatically be generated with MediaWiki:Protectedpagetext. I'm going to experiment a bit with this in my sandbox.-- Madminecrafter12^{20pxTalk to me20px} 22:49, 16 June 2018 (UTC)

Anybody want to comment on this matter? You can see some demonstrations of this in my sandbox. Improvement suggestions are welcome.-- Madminecrafter12^{20pxTalk to me20px} 13:04, 27 June 2018 (UTC)

Message boxes are horrible IMO. They're centered on the screen (which means small boxes leave a lot of space on wide screens), and text inside them is also centered (which looks terrible on small screens, and on wide screens when the last word (or two) is the only one on its line. They also have quite a lot of margin and padding, which makes them take even more space. Why not just use plain text? --AttemptToCallNil (report bug, view backtrace) 13:20, 27 June 2018 (UTC)

Do you think what I have in my sandbox now is better?-- Madminecrafter12^{20pxTalk to me20px} 13:46, 27 June 2018 (UTC)

Better, though I would consider splitting the "if you think the page doesn't need to be protected anymore" part into its separate bullet point. Also: 1) "Directors are any user..." has inconsistent singular/plural; 2) the talk page is linked twice, this may be unnecessary. --AttemptToCallNil (report bug, view backtrace) 14:01, 27 June 2018 (UTC)

I still prefer the "Another idea"'s locks to these huge message boxes. And we could make some sort of expanding the details when the lock is clicked. Lê Duy Quang (Make some words | Contributions) 14:07, 27 June 2018 (UTC)

@AttemptToCallNil: Better now? Also, Leduyquang753, this wouldn't be huge message boxes anymore, just normal text - additionally, in case you didn't know, this would not actually show up when viewing the page normally; it would only show up in replace of the "This page has been protected to prevent editing or other actions" when editing an article that you don't have permission to edit.-- Madminecrafter12^{20pxTalk to me20px} 14:15, 27 June 2018 (UTC)

@Madminecrafter12: But still, we need a kind of indicator to add to the View mode that the page is locked. –Preceding unsigned comment was added by Leduyquang753 (talk • contribs) at 14:19, 27 June 2018 (UTC). Please sign your posts with ~~~~

@Madminecrafter12: Better, but it seems you are using the protection variable in your examples, and the variable is not defined. If that's the same as the reason variable, I have no further objections. --AttemptToCallNil (report bug, view backtrace) 14:21, 27 June 2018 (UTC)

When I changed the name of that defined variable, I forgot to update all of the cases in the template using it. :( Fixed that now.-- Madminecrafter12^{20pxTalk to me20px} 14:24, 27 June 2018 (UTC)

Jack McKalling - sorry for the ping, but because you didn't seem to think it would be a good idea to use locks to signal page protection until we can figure out a way to automate it, I would be curious to see what you think about this idea.-- Madminecrafter12^{20pxTalk to me20px} 18:58, 28 June 2018 (UTC)

I may make a script to automate this. Just need some learning about Lua and MediaWiki... Lê Duy Quang (Make some words | Contributions) 14:17, 29 June 2018 (UTC)

I definitively think what MadMinecrafter12 made on his sandbox page is a big step in the right direction. Locks on the main page are not really necessary, particularly if it's not possible to make it automatic. However, indicating to users why they cannot edit their pages is absolutely necessary, and giving them instructions to discuss about changes. It may sounds simple, but it's not something obvious for someone new. Perhaps you could reduce a bit the text length and link to the admin list for the third case — but otherwise, I really like his suggestion. JSBM (talk) 14:32, 29 June 2018 (UTC)

JSBM - I've added the text "or contact an administrator directly" linking to the list of administrators. Also, do you have any specific suggestions of how to reduce the text length?-- Madminecrafter12^{20pxTalk to me20px} 13:32, 30 June 2018 (UTC)

Ok, so, this is my take on the three messages:

This page is protected so that only registered users can edit it. To edit this page, you'll need to create an account. You can also request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard. (See the page's protection log for more details about the protection.)
This page is protected so that only directors can edit it. You can request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard. (See the page's protection log for more details about the protection.)
This page is protected so that only administrators can edit it. You can request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard. (See the page's protection log for more details about the protection.)

Yes, I'm too lazy to actually make links. Also, I feel some of the working (« You can request change ») isn't really working in English, so feel free to adapt as you want. But I feel a shorter version would do a better job at providing the information. JSBM (talk) 16:57, 30 June 2018 (UTC)

Just an overview of all the changes you made and what I think of them: I like having a bulleted list - it looks cleaner, so I'm opposed to changing that. I support making the intro text bigger, like you did. I also like how you were able to condense the "creating an account" and "requesting an edit" into 1 line, so I support that part as well. I am opposed to putting the protection log information just as small text in parentheses at the end - although perhaps we should move that down a bit from where it currently is, as I do think knowing how the page can be edited is more important than the reason for the protection. I'm neutral about removing the directors definition - it's certainly nice and convenient to have there, but it is a bit out of place and it does link to the MCW:Directors page right there, which contains an explanation.-- Madminecrafter12^{20pxTalk to me20px} 17:07, 30 June 2018 (UTC)

I've done this for the protected page text interface page on the RollerCoaster Tycoon World Wiki, another wiki I'm an administrator on. It works great, and actually looks fairly decent. You can see it in action here.-- Madminecrafter12^{20pxTalk to me20px} 13:44, 30 June 2018 (UTC)

It would have looked even better if the list bullets weren't barely distinguishable from the background. --AttemptToCallNil (report bug, view backtrace) 14:12, 30 June 2018 (UTC)

That's just exclusive to that wiki - wouldn't be a problem here. Yeah, there are a lot of CSS skin problems on that wiki.-- Madminecrafter12^{20pxTalk to me20px} 14:16, 30 June 2018 (UTC)

This looks good! I already implemented it on the German wiki. The old text really was not informative at all. | violine1101^(Talk) 15:41, 30 June 2018 (UTC)

So, this discussion has been up for 2 weeks. It seems that the clear consensus is to definitely give more of a description on the MediaWiki:Protectedpagetext page. This proposal has not gotten any strong objections and seems to have mostly support, and nobody seemed to think that what I had in my sandbox was problematic, after I had modified it to comply with what people thought about it. Also, remember that these actions are easily reversible - if a mob of users suddenly come and for some reason say that we should just have that one old non-descriptive sentence, I or another admin can just modify that page. Likewise, if a lot of people think a change needs to be made to this, which is something I'm definitely expecting, we can easily do that as well.

So, please comment if you think this needs to be changed, tweaked, removed, etc., but for now I've Done what I had in my sandbox.-- Madminecrafter12^{20pxTalk to me20px} 16:05, 30 June 2018 (UTC)

I think the padlocks we use as indicators at the top of protected pages, could be added to that page with the padlock and the text why the page is protected, and I could think the text could be:

Semi protected:

50px This page is protected so that only registered users can edit it.
To edit this page, you'll need to create an account or sign in. You can also request a change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

Full protected:

50px This page is protected so that only administrators can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

Directors only protected:

50px This page is protected so that only directors can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

- psl85 (☎ Talk | ✏️ Contribs) 06:33, 2 July 2018 (UTC)

@Madminecrafter12:, I definitely like the system message solution. It is automatic and doesn't need any additional admin action during protecting. I really like the more condensed version of JSBM as well. It is too much to read if there are 4 bullets below the main line, 2 lines would be ideal. That line about the protection log can be further simplified as a single link like this:

32px	This page is protected so that only registered users can edit it [protection log] To edit this page, you'll need to create an account. You can also request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard.

I believe this is enough for all three cases, only differing in the usergroup in the bold text, with a link for the directors. No need to explain what directors are, this message/page is not responsible or related to the definition of each usergroup. The link should be fine. I combined JSBM's table here with your bullets, because I really like the offset background so that it pops up and it definitely deserves that. It doesn't need to be centered but I think this way it shows the importance of the message, as opposed by regular text. I also added Psl85's padlocks, it provides a fast message at glance to reduce the need to read even more. But I'm not sure about the table border between. I don't want this to turn into a centered message box though, I agree this one needs to be left aligned along with the text there. – Jack McKalling [ 16px 16px ] 08:01, 2 July 2018 (UTC)

In my last few edits to the page, I went ahead and condensed the information into two bullet points. I also removed the protection log bullet point and added the link to the log in the first line instead. Finally, I made the "This page has been protected so that only [X] can edit it" text bigger. I'm not too sure about implementing it into a table. And as for the locks, I do think that would be a good idea. I like what Psl85 did, I just think they should probably be a little bit smaller. If we do end up using a table, I'm against putting the lock in a separate cell from the text - I just think it would look much better if the lock and the text are together.-- Madminecrafter12^{20pxTalk to me20px} 13:11, 2 July 2018 (UTC)

Here's kind of what I'm thinking for incorporating the locks:

30pxThis page is protected so that only registered users can edit it.(see the protection log)

To edit this page, you'll need to create an account. You can also request a change on the article's talk page.
You can discuss the protection on the article's talk page or the admin noticeboard.

-- Madminecrafter12^{20pxTalk to me20px} 13:22, 2 July 2018 (UTC)

Good message, but the text "to edit this page, you'll need to create an account." could be changed to "to edit this page, you'll need to create an account or sign in" to add a link to allow signing in from that link instead of only a link for creating an account, and I would also be able to edit those Mediawiki: messages instead of only admins and wiki guardians, this wiki and other Gamepedia wikis could add a interface editor user group and users in that group could be able to edit the Mediawiki: messages, and could be given through requesting the right, is this possible??? psl85 (☎ Talk | ✏️ Contribs) 17:43, 2 July 2018 (UTC)

Another idea

I have also a new idea - the padlocks could be replaced with blocks in Minecraft - iron block on semi-protected page, gold block on fully protected page, coal block on directors protected page, emerald block on move protected page, and lapis lazuli block on upload protected file, and those soes not needed to be uploaded, and only be used on the top right corner on protected page, and the Mediawiki:protectedtext could be a message box, with padlock/the blocks mentioned before image, and information about the protection, reason, and then add a link to suggest the reader to create an account/submit a edit request using a new template {{edit request}}, and a link to the admin noticeboard to remove the protection if the protection is not needed anymore, I planned to experiment with the edit request template and the new protection messages in my sandbox - psl85 (☎ Talk | ✏️ Contribs) 06:06, 27 June 2018 (UTC)

The Minecraft-themed protection locks would certainly be an interesting idea. It's still not addressing the problem about adding the locks automatically, which is something that many people seem to think is necessary (although I personally don't think it is). I've tried to see if MediaWiki:Protectedpagetext can detect protection levels on another wiki, and it definitely works! I'm not really that supportive of creating the edit request template, though - there's not really much need for it on such a small wiki, and we don't need to have all of the complex systems that Wikipedia has.-- Madminecrafter12^{20pxTalk to me20px} 12:50, 27 June 2018 (UTC)

Maintenance issue. We in general should not use images of game content as part of wiki design for the following reason:

If the depicted object's appearance is changed, the image has to be reuploaded. Allowing regular users upload system images is a risk due to potential severe harm from vandalism. Disallowing this would require administrators to upload the image, rendering them not uploadable by regular community members for essentially no good reason. Keeping duplicates used solely in the interface will make the engine unhappy (it will list the files as duplicates), or cause discrepancy between these two files, which would have to either be kept (for no reason) or fixed by having administrators upload the protected copy (creating a duplicate with restricted maintenance). Images which can never be updated, such as locks, solve all the aforementioned issues.

--AttemptToCallNil (report bug, view backtrace) 12:57, 27 June 2018 (UTC)

Definitely a good point. We don't want anybody who's logged in to be able to overwrite an important skin image, nor do we restrict the ability to reupload several images that would appear on Minecraft-related articles (that may need to be updated to comply with new versions), to administrators. Therefore, I have to withdraw my support to use Minecraft icons to signal page protection.-- Madminecrafter12^{20pxTalk to me20px} 13:01, 27 June 2018 (UTC)

I can try drawing 16x16 padlock icons to make them look like Minecraft... Lê Duy Quang (Make some words | Contributions) 14:27, 27 June 2018 (UTC)

For more appealing results you could just extract the padlock from this file and recolorize the body. Just a suggestion. – ItsPlantseed ⟨₰|₢⟩ 15:32, 27 June 2018 (UTC)

Madminecrafter12: See my sandbox now, I created some differently-coloured message boxes with the blocks I mentioned above, and some links on the message boxes to suggest the reader to create account/log in, request edit or unprotection, and I will now try to start working on the edit request template I mentioned above on the sandbox - psl85 (☎ Talk | ✏️ Contribs) 15:51, 27 June 2018 (UTC)

As you can see above, Nil pointed out that the message boxes are a bit disruptive and messy, and it would be better to use plain text. As shown in my sandbox, I've used plain text instead - as I agree with this. Also, note that GRASP aren't able to edit fully-protected pages - only admins and wiki guardians can. And I personally don't think an edit request template would be necessary, as I've said above. I do like where you're going with this, though. :)-- Madminecrafter12^{20pxTalk to me20px} 15:58, 27 June 2018 (UTC)

Madminecrafter12 I will use plain text, but I created some differently coloured message boxes, and I think those not was too messy an ugly, I can add the protection block and plain text- psl85 (☎ Talk | ✏️ Contribs) 16:04, 27 June 2018 (UTC)

@psl85: I have made the locks, which you can preview here:

400px

Lê Duy Quang (Make some words | Contributions) 16:14, 27 June 2018 (UTC)

Leduyquang753 Cool locks, and I would use those, the only need is only have one file/padlock - psl85 (☎ Talk | ✏️ Contribs) 16:22, 27 June 2018 (UTC)

I fail to understand the insistence on styling everything like Minecraft. The current locks are already perfectly functional, the choice is purely stylistic (following an unstated and pointless guideline), so creating new images where other already exist and are capable of doing their job is a wasted effort. --AttemptToCallNil (report bug, view backtrace) 16:55, 27 June 2018 (UTC)

psl85. Here are 10 icons in the preview colored according to Wikipedia's protection locks with description of what they do. You can try using them in your sandbox messages. And AttemptToCallNil, if this wiki doesn't need anything to look like Minecraft at all, why does the Hydra skin exist? And the icons near the links in the mainpage. They all have the same purpose to make this Wiki look more like a Minecraft wiki, don't they? Lê Duy Quang (Make some words | Contributions) 01:22, 28 June 2018 (UTC)

Comment I don't see the point of having that padlock template at all, it's just adding more workload to the admins who have to change the template every time they change the protection. Apart from that, it's rather obvious if a page is protected or not, protected pages have "View source", unprotected pages have "Edit" (and "Edit source" if you've enabled the visual editor).
My point is, we aren't Wikipedia. I don't see the point in creating meta-templates which add nothing to the contents of the page. It will just make everything messier.
Lastly, Leduyquang, I appreciate the work you put into pixeling the padlocks, but in my eyes, they don't fit to Minecraft at all and also look a little clumsy. As I mentioned on Discord before, it would make more sense and look better if you just used the padlock texture that's included in Minecraft anyway (given that it's decided that such a template is needed in the first place). | violine1101^(Talk) 09:45, 28 June 2018 (UTC)

"doesn't need anything to look like Minecraft at all" means "shouldn't have elements which look like Minecraft", the opposite of which is "may have elements which look like Minecraft". What you're trying to accomplish is "shouldn't have elements which don't look like Minecraft", which is not a valid opposite.

And yes, why bother adding locks if we can just change the protected edit message? --AttemptToCallNil (report bug, view backtrace) 10:05, 28 June 2018 (UTC)

Adding locks gives a nice, compact indicator to the users about the protection state of a page. Having a massive message box (a small one is still big and distracting in this case) at the top isn't good for focusing on the below content. And the difference between "Edit source" and "View source" only indicates whether the user can edit it or not. Lê Duy Quang (Make some words | Contributions) 14:05, 29 June 2018 (UTC)

And also using the vanilla's lock icon doesn't give a nice result because it needs to be recolored to indicate different protection states. The lock's texture looks like gray stone, so recoloring it makes it ugly. Lê Duy Quang (Make some words | Contributions) 14:08, 29 June 2018 (UTC)

My main point was that admins would have needed to update the template on the page every time. This problem has been solved with AttemptToCallNil's proposal below. Locks are fine with me, but to be honest, I still don't like your pixel arts.
The question now is, which indicators do we need? Should the colors mean something or should they be random? Let's take a look at your proposal from User:Leduyquang753/locks:

Color	Default	Your proposal	My proposal	Meaning	Notes
Gold	16px	16px	File:Minecraft protection lock full.png	Fully protected	Gold makes sense, but your color looks a little dull at the moment.
Green	16px	16px	--	Move protected	Do we really need a seperate lock for move protected pages?
Silver	16px	16px	File:Minecraft protection lock semi.png	Semi protected	Makes sense, but the gray is a little dark.
Pink	--	16px	--	Template protected	What's the difference to normal protection? Besides, this protection level doesn't exist here as far as I know. Also, the pink is too similar to the purple of the Upload Protected lock.
Purple	16px	16px	--	Upload protected	Again, what's the difference to normal protection? Why do we need a seperate lock for this? Do there actually exist pages which are upload protected. Also, the purple is too similar to the pink of the Template Protected lock.
Light blue	--	16px	--	Cascade protected	Every page which is cascade protected is also normally protected. Why do we need an extra lock for this? Also, the light blue is too similar to the cyan of the Create Protected Lock.
Cyan	--	16px	--	Create protected	Again. Why an extra lock? Also, the cyan is too similar to the light blue of the Cascade Protected Lock.
Blue	--	16px	--	Extended confirmed protected	What is this? I don't think this protection level exists here.
White	--	16px	--	Pending changes protected	No such protection level exists on the Minecraft wiki.
Black	16px	16px	File:Minecraft protection lock full.png	Office protected (directors and above)	I would use the same icon as for full protection; there's just a small amount of users to whom it matters whether a page is fully protected or protected on directors level.

| violine1101^(Talk) 14:57, 29 June 2018 (UTC)

Support your icons. They are exactly what we need, they are clear and stay Minecraft enough. (We just need them a bit bigger) (And yup, only 2 of them is enough, the other categories are really optional, they don't need a specific lock) JSBM (talk) 15:20, 29 June 2018 (UTC)

Cascade protection used to be used with the main page onto various templates, but in most cases its a bit difficult to tell why a page is protected if its just marked with regular protection (difference between "we think this page is a target" and "we think this page may be used to target another page") so it might be worth a separate lock to mark. Hard part is its slow to fetch anyways compared to regular protection data.

Otherwise, I prefer the locks that are actual sprites over the pixelated ones. Between the antialiasing and the black borders they don't really match Minecraft's style in my opinion. –KnightMiner · (t) 18:46, 29 June 2018 (UTC)

Yet another idea

JavaScript could be used to place locks on protected pages automatically. It saves the need for administrators to add a template every time a page is protected and remove the template when it expires or if it is removed. It could be implemented as a gadget.

This script I wrote (it's not exactly pretty, but I found no predefined functions to set indicators) uses the Wikipedia-style icons. As I have said before, these icons are perfectly functional, there's no point to create new ones as if just to conform with a nonexistent rule demanding we make every interface image Minecraft-styled. --AttemptToCallNil (report bug, view backtrace) 14:12, 29 June 2018 (UTC)

We should make a debate... Lê Duy Quang (Make some words | Contributions) 14:30, 29 June 2018 (UTC)

Support This works really well, nice script! | violine1101^(Talk) 14:57, 29 June 2018 (UTC)

Nice script. That's a kind of script what I meant above. Whould this script fit in Mediawiki:Common.js? This would work very well for the main view of a page, and the system message from the New idea above would work for the edit view. – Jack McKalling [ 16px 16px ] 08:48, 2 July 2018 (UTC)

"Twinkle" gadget on this wiki

Hello! I think that this wiki should have some new gadgets from Wikipedia, such as Twinkle, Navigation popups, wikEd (I edits with this gadget installed in the JavaScript subpage), and minor gadgets for syntax highlighting, mark blocked users and admins, and dropdown menu to easily choose edit summary while editing, think I to be added to this wiki, and I search for more gadgets, if Twinkle should be added, could it be customized for use on this wiki and its usage could be same as on Wikipedia, and it may need some lesser templates and only existing templates should be used by the gadget. psl85 ☎ Talk 14:14, 5 June 2018 (UTC)

Support. These could be great things to keep the Wiki fresh and clean. Lê Duy Quang (Make some words | Contributions) 01:21, 24 June 2018 (UTC)

Support twinkle and navigation popups. No opinion on wikEd as I generally don't use any type of visual editor, although I will note that the correct link is User:Cacycle/wikEd, not User:Azatoth. Also, I'll note that I tried to use twinkle via user JS and that didn't work, though that was a while ago; the module would be very nice (but it definitely would need editing for the list of templates). --Pokechu22 (talk) 01:41, 24 June 2018 (UTC)

What if Minecraft appears in another game?

What shall we do if Minecraft appears in another game, like the upcoming Super Smash Bros.? Should we create an article for the game? Hugman_76 [ 16px 16px 16px ] 16:07, 9 June 2018 (UTC)

There is a section about Minecraft references in other games (Minecraft#References_in_popular_culture) :) • Yanis48 (talk) 16:23, 9 June 2018 (UTC)

To give a more general answer, no. This wiki exists to document what's in Minecraft, not what's in other works. Besides, that "news" is just a rumor from DasVergeben, who isn't a particularly reliable source according to this GameRant article. – Auldrick (talk · contribs) 16:51, 9 June 2018 (UTC)

Development versions or current version for names, images, sprites, etc.

There seems to be some dispute as to whether the title of images, the texture of images, the texture of sprites, and the word used in articles for a certain title of a feature or texture of a feature, as to whether it should be the one in the latest development version or in the latest full-release version. It seems like the description of the actual functionality of features is always how they work in the current version (except for statements marked with {{upcoming}}), so it seems like the names and textures should be the same way. I've been trying to keep them as they are in the current version, because it seems to make the most sense - a few times this has gotten reverted, but most of the time it hasn't. Here are some examples:

In this edit, all instances of "fish" were replaced with "cod." I changed this back later, and this time it was actually undisputed. However, it had stayed at the 1.13 name for a long time.
As can be seen here, the image was reuploaded in February to comply with the new 1.13 texture. I reverted it back, explaining my reasoning. However, that was reverted again by somebody else, because [{{fullurl::File:Pufferfish 13w43a-18w08b.png|}} :File:Pufferfish 13w43a-18w08b.png] exists. I didn't re-revert, because I didn't want to start an upload war.
All of the fish textures and sprites were updated to the 1.13 textures. I changed them back after many months of being on the 1.13 names, and most of the changing back was undisputed; in fact, I actually got a few thanks for it. However, many of the sprites now seem to use the 1.13 name - but again, I don't want to start a sprite-edit war.

In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority. For images, the actual in-game names, such as :File:Water.png and :File:Pufferfish.png should be the texture of the current version, not the latest development version. However, I think there should also be separate files, e.g. [{{fullurl::File:Water in 18w15a.png|}} :File:Water in 18w15a.png] and [{{fullurl::File:Pufferfish 18w08b.png|}} :File:Pufferfish 18w08b.png], for the textures in the latest development version. For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now. For sprite textures I feel the same way as I do for the images - the main one should be of the texture in the current full version, but there should be an additional one with the texture in the latest dev.

My reason for this is, 1.12.2 is still the current version the game is on right now - so no matter what crazy features have been added in development versions, the names/textures in 1.12.2 are the names and textures in the game. Another reason is for consistency with the actual description of features. The descriptions of the features is mainly how it is in the current version - with upcoming changes marked with {{upcoming}}. I don't see why textures, names, and sprites should be any different. However, I do think it can't hurt to prepare for 1.13 - which is why I support adding the dev names as aliases in sprites, and upload the new textures as separate files.

I propose that we discuss this here so that we can come to a decision once and for all.-- Madminecrafter12^{20pxTalk to me20px} 13:49, 13 June 2018 (UTC)

I mostly agree. In my own words, I think all files and other assets that are named in-game, should always carry the same name as in the latest full release. Any new name for them introduced in development builds/snapshots/releases should be an alternate name with the relevant version in it. If the graphic was not changed, the development name should redirect, otherwise, it should be an alternate file/asset altogether. As for the text on the articles, this should always reflect the latest full release, with specific {{upcoming}} notations/history entries being the only exceptions to that. – Jack McKalling [ 16px 16px ] 14:34, 13 June 2018 (UTC)

In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority.

The highlight of the message, and I agree with it.

I think there should also be separate files, e.g. [{{fullurl::File:Water in 18w15a.png|}} :File:Water in 18w15a.png] and [{{fullurl::File:Pufferfish 18w08b.png|}} :File:Pufferfish 18w08b.png], for the textures in the latest development version.

Also agree.

For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now.

Agree with everything but one case. If development versions for one full version change both the name and the texture, no full version exists where the new name corresponds to an item with the old texture. This is why I think that, in such cases, the new name should be mapped only to the sprite with the new texture.

--AttemptToCallNil (report bug, view backtrace) 14:58, 13 June 2018 (UTC)

I agree that upcoming textures and names should both not be used until a release. In my opinion MCW:FUTURE already applies to feature names and textures as well direct information. At the very least we should add on the style guide that it specifically applies to textures and names as well. –KnightMiner · (t) 15:10, 13 June 2018 (UTC)

Ah yes, I was going to mention in the post but I forgot - whatever the consensus is, I think we should add it to the style guide. That way it will be clear to everybody that it is an official guideline, rather than just one user thinking that it makes sense one way.-- Madminecrafter12^{20pxTalk to me20px} 15:16, 13 June 2018 (UTC)

(Edit conflict) In the past, it clearly made better sense to stick to released versions' names and images, because those are familiar to everybody whereas updated versions might not be. Unfortunately, this rule is no longer tenable because there is no longer a clear line between released and development usage. You all may not have thought of this, given that you equate "1.12.2" with "released version" and "1.13" with "development version" (sadly, one of the many examples of insidious Java elitism among the editors on this wiki), but different editions have different chronologies and any feature can be in both states at the same time. For example, the new Pufferfish texture is already in the release version in Bedrock but still in development in Java. (The last time I looked, the Fish (mob) infobox bizarrely had the new texture but the old sprite.) Given this conflict, I think we need to be more flexible. I suggest that a texture or sprite be allowed if it has been released on any version, or used consistently across several development versions in one or more editions. – Auldrick (talk · contribs) 15:31, 13 June 2018 (UTC)

I say that makes sense to extend the idea to being released in any version. Since we can not easily just use all sprites, the one that makes most sense is whatever is the current texture, so a priority system to show the texture from the latest release makes sense. Just as long as we clearly show that it has not changed in all editions yet. –KnightMiner · (t) 15:49, 13 June 2018 (UTC)

Agree with the proposed edition-related amendment. What if an item has different names and/or textures in different editions? That case isn't covered. --AttemptToCallNil (report bug, view backtrace) 16:10, 13 June 2018 (UTC)

I think if we stick to just moving the images, it's fine (which is atthis moment basically already done (only Tall Grass -> Grass and Double Tallgrass -> Tall Grass left); the actual pages themselves shouldn't be moved yet until 1.13 release though. Without a doubt the bedrock (and possibly legacy console) editions will start following the new names soon. FVbico (talk) 18:40, 25 June 2018 (UTC)

Page name conflicts

As AttemptToCallNil mentioned 2 comments above this, at time of writing, what if the names and/or textures are different in different released editions? Currently relevant to the discussed on Talk:Monster_Spawner#Recent_Move_suggestion. I personally would be comfortable picking the name that any of the Minecraft team say is going to be going forward. For instance if two editions call it Fish, and one calls it Cod, but Helen for instance attests that they plan to rename it all Cod, that would be sufficient for me. Sufficient, but maybe not necessary. There may be other ways to decide it, and maybe there are counterarguments to that whole Helen thing. I only offer it here because FVBico offered it as a reason in the other discussion and I happened to agree. What do people think? – Sealbudsman talk | contribs 18:10, 17 July 2018 (UTC)

For article names, as long as the old article name is kept as a redirect to the renamed article, I'm fine with assuming the new name (like Cod instead of Fish). It's much easier than keeping a conflict between editions. However for the name occuring within text, I'm not sure. Would it be easy to understand what is meant with "Cod" in the middle of a sentence, where the reader is used to only know "Fish"? Of course they could click it and learn about it, but is that enough? – Jack McKalling [ 16px 16px ] 18:43, 17 July 2018 (UTC)

If a name is different between multiple full releases of the game, I am in favor of leaving the page name as-is, with a re-direct from the new name to the current page, moving the page only if the name is changed to be the same across all full releases. I believe this best avoids the controversy of prioritizing names from one version over the other. I also believe that, as of the Update Aquatic, Legacy Console editions besides the PS4 edition can be ignored when deciding when to move pages, as Mojang has officially stated that they will no longer focus on updating these versions in the future. – Bg samm (talk) 20:40, 7 August 2018 (UTC)

Zombie hurt.ogg

The file doesn't work on the Zombie page. –Preceding unsigned comment was added by Enderdespawnmite (talk • contribs) at 3:50, 17 June 2018 (UTC). Please sign your posts with ~~~~

Works fine for me. –KnightMiner · (t) 04:05, 17 June 2018 (UTC)

Moving mod files to a sprite sheet

Hi! In my desire to improve the mods part on the wiki, I wanted to find a solution about all these mod files, mainly grids, used only once. So I thought about making a sprite sheet for that. With the agreement and help of Madminecrafter12, I tested it and it works exactly like InvSprite. It is currently called ModSprite.png, with the corresponding template and module.

So, what do you think about that? Do you agree to move the maximum number of mod files into this sprite sheet? • Yanis48 (talk) 15:20, 17 June 2018 (UTC)

The Russian wiki creates a sprite sheet for every mod which contains sprites just for that mod. The English version of Module:Inventory slot should have similar support.

Note that some people have been moving to deprecate mod support and eventually migrate all mod articles from the wiki. --AttemptToCallNil (report bug, view backtrace) 15:33, 17 June 2018 (UTC)

I definitely that would be a good idea if we decide to keep mod content here, but there's not much point of working hard on a sprite for mods only to have all mods removed or migrated.-- Madminecrafter12^{20pxTalk to me20px} 15:50, 17 June 2018 (UTC)

Opinion Hi there. i personally think that we should keep mod articles here. Any objections or support?--TheCreeperStrikes (talk) 17:49, 17 June 2018 (UTC)

I personally would be in favour of removing mod content from this wiki, but setting up a sister wiki dedicated to mod, fandom, etc, content. - MinecraftPhotos4U (talk) 17:53, 17 June 2018 (UTC)

What should we do?, Anyone? - - TheCreeperStrikes (talk) 18:05, 17 June 2018 (UTC)

Its worth mentioning this wiki has an unofficial partnership with the Feed the Beast Gamepedia, which covers many mods both in Feed The Beast packs and some independent ones. I personally would rather just drop modded content in favor of not duplicating effort between this wiki and that one. They have a much better framework set up for mods (including support for Forge features like the oredictionary in modded recipes), plus it saves us from having to make a list of guidelines about what makes a mod notable. Additionally, with how poorly maintained the mod pages are here, I doubt we would have an easy time finding enough editors to handle all the mods, most editors tend to just handle a couple mods they personally play. –KnightMiner · (t) 18:23, 17 June 2018 (UTC)

😞 I spent so much effort uploading all those images and they’ll just get DROPPED? Like that?!, *deep breath* Sorry, just went a little overboard there *sigh*

-TheCreeperStrikes (talk) 18:33, 17 June 2018 (UTC)

Hmmm… maybe we could make a wiki for each individual mod (not everything)?-TheCreeperStrikes (talk) 07:52, 18 June 2018 (UTC)

Wiki for each individual mod? That's not really a great idea IMHO - seeing how much the FTB Wiki relies on some common stuff (common templates like infoboxes, navbox and oredict frameworks, vanilla Minecraft crafting templates and tilesheet, etc. - imagine syncing changes to that...) and that many mods have integration with other mods (copying a template for some machine across 10 wikis to show some mod integration?). Keeping that stuff in sync would me more trouble than it is worth. Also, you'd have a lot more than one recent changes page to keep track of. Modded content doesn't really have enough wiki manpower for splitting it like that in my opinion. --Hubry ^(talk) 08:24, 18 June 2018 (UTC)

Agreed with Hubry. We don't need another wiki for each mod on here. The Feed The Beast wiki already covers a great deal of the mods, it would not be a bad decision to relocate all our mod content over to that wiki, or delete if it's already there/outdated. Our wiki isn't really suitable for mods, we're just documenting the game itself. – Jack McKalling [ 16px 16px ] 09:46, 18 June 2018 (UTC)

Then we could just export {{ModSprite}} there.-TheCreeperStrikes (talk) 14:33, 18 June 2018 (UTC)

Project announcement

MCW:Projects/Refactoring edition specific information is a new project intended to explore ways we can structure edition-specific information to yield smooth, natural prose in articles, and later to clean up articles that need it. Interested editors are encouraged to join by adding their names to the Members list on the project page. – Auldrick (talk · contribs) 02:00, 20 June 2018 (UTC)

Elements and existing pages with the same name

Here's a couple of pages that I think should be moved to free up space for element redirects

Gold to [{{fullurl:Gold (disambiguation)|}} Gold (disambiguation)]
Iron to [{{fullurl:Iron (disambiguation)|}} Iron (disambiguation)]

I don't think there are any other pages like this, but I'd like some input before I (or someone else) move these. Kienan (talk • contribs) 19:20, 20 June 2018 (UTC)

No support for redirecting the pages to the element. I suspect that the majority of users entering Gold or Iron as a URL would not want to see the element, but instead a disambiguation. Maybe support moving the articles and having Gold redirect to Gold (disambiguation), and including the element on there. But maybe it's just better to leave it as-is. Wikipedia seems to just not use the (disambiguation) suffix in that case (in fact, they redirect the disambiguation page back); for instance Mercury and Mercury (disambiguation). In fact, that gives a fairly good case for it, in that mercury itself is an element. --Pokechu22 (talk) 19:32, 20 June 2018 (UTC)

Oppose moving. The primary meaning for non-Education Edition-oriented readers (which I expect to be the majority of the wiki's audience) would most likely be the resource in general, not the element. Redirecting Name to Name (disambiguation) would be completely pointless, same with the reverse redirect; or, to be more accurate, these redirects are only useful if some program code we can't modify handles "(disambiguation)" titles in a desirable special manner, and I am not aware of any such distinction. --AttemptToCallNil (report bug, view backtrace) 19:51, 20 June 2018 (UTC)

Weak oppose. If we were to be perfectly consistent and always use the in-game names, the pages should be moved, which is why my oppose is weak. However, I really think readers searching for gold are much, much more likely to want to go to gold ingot or gold ore than the element page. In my opinion, this is more important than being perfectly consistent and always using the in-game names.-- Madminecrafter12^{20pxTalk to me20px} 01:52, 21 June 2018 (UTC)

Oppose moving; while it has to be acknowledged that they are in-game names, they're not something from the core gameplay. The existing pages for gold and iron have to take precedence in ambiguous situations like this because they are based in the core gameplay. – Sealbudsman talk | contribs 02:46, 21 June 2018 (UTC)

Oppose move. The disambiguation suffix should only be used for pages like this when there are other articles with the same name, but as said above, the term "gold" and "iron" are only a partial use for in-game names. Those elements from Education Edition are basicaslly edition exclusive and that's not enough reason to override that partially used in-game name. Having a link to Gold (element) and Iron (element) on the Gold and Iron pages respectively is the best way here, IMO. – Jack McKalling [ 16px 16px ] 08:54, 21 June 2018 (UTC)

Oppose. We should instead keep the page Gold (element) for the element, like Clay (block), and leave the Gold page alone. Lê Duy Quang (Make some words | Contributions) 01:16, 24 June 2018 (UTC)

Item stack general format

So, when a high amount of item is expressed in the Wiki, it would be "x stack(s) and y item(s) (n total items)", which is a bit complicated. So I am thinking of a template that we could write it as for example "2s35" with the hover comment "2 stacks and 35 items (163 total)". Improvements can be made as long as they make sense, then this would make the Wiki more compact. Lê Duy Quang (Make some words | Contributions) 02:36, 24 June 2018 (UTC)

Question about sparklers

According to the text:"When lit, the sparkler will emit colored particles; the durability meter depletes while the sparkler is burning.",is that means sparklers have it's item durability? (In zh,it displays "?")--Wth213 (talk) 08:24, 28 June 2018 (UTC)

Absolutely, it only burns when you hold it in your hand though. – ItsPlantseed ⟨₰|₢⟩ 10:30, 28 June 2018 (UTC)

Well,how should we express it?If not,please tell me reasons.--Wth213 (talk) 02:56, 29 June 2018 (UTC)

Weird spacing and bullet formatting on templates

I'm not entirely sure where to post this so I guess I'll post this here: On navboxes, the formatting seems to be a bit bugged with creating additional bullet points - while it does make it in parentheses, at the end it has a weird space before the ")" and it creates a space between that and the next item. You can see this better on the Bedrock Edition versions template. It just seems off so if this can be fixed that would be great. --Marioprotvi (talk) 20:16, 28 June 2018 (UTC)

It's been the case since tidy was broken, and tidy is a requirement for hlists to work properly, so nothing we can do about it. –Majr ᐸ Talk
Contribs 07:52, 30 June 2018 (UTC)

Replace edition abbreviation links with templates

Replacing edition abbreviations links like BE with templates like {{BE}} would be useful as we can have the template link to the full page name, so the title says the full name rather than just the abbreviation to make it clearer to readers what it means. It also provides the opportunity to add some styling to the links (like a background colour or icon). –Majr ᐸ Talk
Contribs 08:01, 30 June 2018 (UTC)

Full support. This would really help infoboxes declaring differences between editions for for instance a block's ID, if different. That {{only}} template just takes up so much space of which there is little in an infobox, in addition to your argument. – Jack McKalling [ 16px 16px ] 13:03, 18 July 2018 (UTC)

Support. We clearly also need {{JE}} and I think {{EE}} (Education Edition; even with the toggle in Bedrock, it still has some exclusive features). Are there others? Also, note that somebody already created BE as a redirect to Bedrock Edition, and it has been used this way on nearly 200 pages. I don't think we want to have two different ways to do the same thing, and I prefer the template solution because it's more flexible, so if we do this we should change those links to template calls. – Auldrick (talk · contribs) 13:26, 18 July 2018 (UTC)

Some maintenance work to be done there to make everything consistent with these templates, but agreed. – Jack McKalling [ 16px 16px ] 13:34, 18 July 2018 (UTC)

File naming consensus

There doesn't seem to be any file naming consensus except for things from mods (suffixing with "(<mod name>)").
There's files in all different naming conventions:
runninglowercase
lowercase with spaces
Capitalrunning
Capital On Every Word
Capital on first word
etc.
Even file extensions have the FULLCAPS and nocaps variants used interchangably.
Alongside this inconsistent naming, there is no telling if the file is a user file by name (or from who it is in general).

I propose the following naming convention:
File:<user name in case it's a user file> Capital On Every Word (<mod name>).lowercase extension
Examples:

File:FVbico Some Funny Meme.gif
File:Computer (ComputerCraft).png
File:Skeleton Riding Spider.png

Of course, changing all existing files will take a long time, so when a naming convention is chosen, I (potentially others too) will go through all files and move to the proper naming. FVbico (talk) 12:51, 1 July 2018 (UTC)

I Support it, though I might take it a step further; for user files, call it like: File:User FVbico Some Funny Meme.gif. Just so that it's more obvious in case someone's username is something ambiguous like Indev. –Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 17:13, 1 July 2018‎ (UTC). Please sign your posts with ~~~~

Actually that’s a good point, didn’t think of that. FVbico (talk) 18:32, 1 July 2018 (UTC)

Neutral. I would be open to having a message when uploading a file, telling the uploader to give the file a detailed name that describes the image clearly, AND use whitespace where you normally would. We could also add that little bit to MCW:IMAGES. However, I don't think the userspace and capitalization restrictions would be necessary, so I'm against making that part a formal guideline.-- Madminecrafter12^{20pxTalk to me20px} 13:43, 3 July 2018 (UTC)

Neutral: I like the idea of consistent naming, but I really don't think there is much benefit to moving a bunch of old files just to match that as it just clutters the move log and potentially breaks usage on user/translation pages (as from what I have seen of recent moves users tend to ignore fixing those links). Most of the files get just use on one article so if its a poor name no one really needs to deal with it. I would be in favor of documenting a proper standard for new files, probably just having them use the article title rules at that, but I don't feel it should be enforced to heavily. –KnightMiner · (t) 21:04, 14 July 2018 (UTC)

Support, even if I'm not sure if it should be applied too much... We can let people have some liberty, for example with the capital at each words, and perhaps not change all previously uploaded files unless they are really too much different from that system. JSBM (talk) 21:23, 14 July 2018 (UTC)

Support partially. I'm fine with requesting lowercase extensions and requesting a file's name to be representative of its purpose. Among the provided conventions I'd favor the Capital on first word one. No word separator conventions are hard to read, extra uppercase letters add more effort to type, and you can't start file names with lowercase characters. --AttemptToCallNil (report bug, view backtrace) 13:51, 16 August 2018 (UTC)

Then how about block/item/entity/biome images? In-game their names are Title Case, not Sentence case. FVbico (talk) 13:53, 16 August 2018 (UTC)

We already don't use title case names anywhere outside article names, why not extend that to file names? I'd rather not see file names which (no offense) look like they've been written like a native speaker of German (Two Skeletons in a Forest attacking a Spider with their Bows). --AttemptToCallNil (report bug, view backtrace) 13:58, 16 August 2018 (UTC)

Disagree I don't really care how others name their files and it'd be annoying to have to comply to these rules; the file names aren't even that visible. Strong disagree for moving every single file with names you don't like. – Nixinova 16 px 16 px 04:39, 12 October 2018 (UTC)

It’s not about visibility, it’s about how easy it is to find these files, I’ve had numerous occasions where the file I wanted was in one of those different formats, and as such, I couldn’t find it. FVbico (talk) 06:32, 12 October 2018 (UTC)

I'm having trouble getting my opinion straight on this subject, hence why I chose not to reply/participate in the discussion for so long. I want to help, but I can't offer much other than my insight/opinion, which isn't much in the context of images, sadly. Although I'm a fan of systems, I don't want to say we need to be less strict on naming files. It does make sense that they aren't very visible, and finding files could be simplified by organizing better categories. But I am definitely in for consistency, and I really like prefixes to organize files in name. I can't decide. I want it to be easier for an editor to name their file, but I also want it to be easier for them to make up a fitting name in the first place. I just want everything to be easier. It's not a clean cut. There's still more to propose in this naming convention, as I'm missing other possibilities and scenarios. Lets say that for now. – Jack McKalling [ 16px 16px ] 22:13, 14 October 2018 (UTC)

Drowned and Zombie

The information for the Drowned is on the Zombie page, so why not merge the pages? 24px 24px 24px 02:34, 3 July 2018 (UTC)

If so, it should also applies to Husk. Hugman_76 [ 16px 16px 16px ] 14:27, 3 July 2018 (UTC)

Comment Husk has already been merged into the zombie page.-- Madminecrafter12^{20pxTalk to me20px} 14:29, 3 July 2018 (UTC)

Oppose. Drowned currently is actually quite a long page as far as content goes, with a lot of detail about spawning, drops, and behavior, much of which is very different than zombies. Merging the two would make the zombie page more cluttered, with little benefit.-- Madminecrafter12^{20pxTalk to me20px} 14:39, 3 July 2018 (UTC)

Oppose. It's pretty clear that they are different mobs. Also, merging all entities that could fit under the term "zombie" doesn't help much with adding more information to the wiki, but only clutters it up with so much information that it gets confusing. (Hence I also disagree with Husk and Zombie villager being part of the Zombie article. They aren't real zombies either and have their own special properties.)
On an unrelated note, this should be on Talk:Drowned, not here. | violine1101^(Talk) 15:32, 3 July 2018 (UTC)

Note - the same thing is currently being discussed here.-- Madminecrafter12^{20pxTalk to me20px} 12:46, 4 July 2018 (UTC)

Oppose - why is Husk on the same page as Zombie, anyway? - MinecraftPhotos4U (talk) 17:13, 5 July 2018 (UTC)

Oppose. Also, Note that the inverse thing is also being discussed on Talk:Zombie#Split Zombie variants off from this article, with unanimous support for splitting. --Pokechu22 (talk) 05:27, 14 July 2018 (UTC)

Using artworks instead of renders in some info boxes

Some entities got official artworks. I was wondering, why don't we use these in 'Entity Boxes'? I've put an example on the right side to prove you how it could render, but it can works with other mobs with official artworks, like 50px, 50px or even 50px. Hugman_76 [ 16px 16px 16px ] 17:51, 3 July 2018 (UTC)

While I can definitely understand the appeal of this, I'm not sure if this will fit well in an unofficial encyclopedic context (especially given these are not honest in-game appearances), and the fact that we don't have artworks for absolutely everything would cause major inconsistencies. I otherwise wouldn't mind this if it weren't for these problems. - MinecraftPhotos4U (talk) 15:40, 3 July 2018 (UTC)

Take the encyclopedic context out of the cage. Does other game wikis will choose a T-Pose of the mob in question? Nope, and we're litterally doing this. Also I don't think they aren't honest in-game appearances, and even so, again, the other wikis does this as well. For the inconsistencies, we could keep the 'T-Pose' renders under the first paragraph or something like that, or even make an image2 in the infobox. Hugman_76 [ 16px 16px 16px ] 17:51, 3 July 2018 (UTC)

My opinion: This looks nice, and arguably better than the renders from the game we have now. However, the wiki is supposed to document the game as it is. Ironically, Minecraft's artworks have a different artstyle than the actual game, it uses even more simplified textures for everything. Therefore, I don't think that it would be a good idea to change the images in the info boxes so that they are different from the game.
Also, there's the question of where to get the artworks from – we can make the renders by ourselves, for the artworks we would need to wait for Mojang or Microsoft to come along and create one. | violine1101^(Talk) 18:05, 3 July 2018 (UTC)

We could display these artworks somewhere else, like in the second image of the info box template to not remove the render. Or even add it under the first paragraph of the article. Hugman_76 [ 16px 16px 16px ] 18:48, 3 July 2018 (UTC)

I have to agree with Violine1101 here. I definitely see where you're going with this, and I like how they look - however, I really think it's better to use the exact in-game textures for infoboxes, as they are right now. Also, I don't really see much benefit for having the artwork as the second image in the infobox. However, I do like the idea of including the artworks in the gallery.-- Madminecrafter12^{20pxTalk to me20px} 12:50, 4 July 2018 (UTC)

A patroller user group

This was suggested on Discord and seemed to be supported. Pinging JSBM and MarkusRost, as both of these users participated and voiced their opinions in the discussion, so it would be great if they could do the same here.

So as you can see above a proposal was made to create a new user group that can semi-protect pages. However, there were a number of concerns raised about this on Discord that I agree with. First of all, I could easily see this being abused in edit wars even by an experienced user - one user thinks they're right so they just semi-protect the page. Second, many experienced users may semi-protect incorrectly - e.g., because of 2 IPs vandalizing twice in the last month, or one IP vandalizing 5 times. Also, protecting usually isn't the answer to vandalism - it's usually actually blocking. So if we give somebody the access to semi-protect, they may do that when blocking is really the answer - because they don't have permission to block. And if we allow them to protect AND block, then we might as well just go ahead and give them admin. Finally, I'm not sure if it's possible to allow editors to only protect pages for a short amount of time - we would likely have to create a whole new user permission, as currently it's just listed under one: protect. And is it really worth it, especially considering protecting really isn't usually the way to go in cases of vandalism? Many of these concerns I have are shared here.

However, I support creating a new user group called "Patrollers" that gives the following rights:

Mark others' edits as patrolled (patrol)
- What this does: It allows to click the button "Mark as patrolled" in a diff. In recent changes, any unpatrolled edits have a red exclamation mark next to them. This allows admins (and possibly soon patrollers) to see the edit, look over it, and know that it has not yet been reviewed, or the administrator who reviewed it doesn't know if the information is accurate or not. Although this isn't a necessary feature, I definitely think it would be helpful.
- Reason: The patrol backlog is very large right now. Dinoguy and I are pretty much the only ones patrolling, and about half of all edits remain unpatrolled by the end of the day. I could see this being very helpful for users who can't look at every edit in recent changes - they would be able to see which edits have been reviewed or not, so that the unpatrolled can take priority. Patrolling isn't a necessary feature, but I do think it's a good idea and helpful in many circumstances.

Quickly rollback the edits of the last user who edited a particular page (rollback)
- What this does: On the latest diff of a page, there is a "rollback" button. When this is clicked, it will revert all of the last consecutive edits by that user. This will also automatically mark the user's rolled-back edits as patrolled. Additionally, Majr created a wonderful script that allows for a custom rollback summary without having to load any new screens. This is very helpful for reverting bad edits that were likely made in good faith, which would usually warrant an edit summary
- Reason: Rollbacking is much, much quicker. Especially for multiple edits. If a normal user finds a user who made multiple vandal edits, they must navigate to the diff before their edits, reload several screens, click the edit button, wait for that screen to load, put in the edit summary something like "Rvv last 3 edits," click save changes, and wait for that to load. With rollback, all of that's in a single click. Additionally, you can revert multiple good faith edits using rollback much quicker as well, as long as you don't disable to editable rollback summary gadget. Instead of doing the same thing as for vandal edits except adding an extra custom edit summary, just click the pencil button next to the rollback link, quickly edit the summary, press save, and the edits will be reverted right away. Additionally, rollbacking automatically marks edits as patrolled, which is another reason why having a user group that can rollback edits would be helpful.

-- Madminecrafter12^{20pxTalk to me20px} 13:41, 5 July 2018 (UTC)

Support Frisk (Talk page) 13:46, 5 July 2018 (UTC)

Support david92003 (talk) 13:50, 5 July 2018 (UTC)

Support also --20px psl85 (profile | talk | contribs | send email) 14:25, 5 July 2018 (UTC)

Support 16px MarkusRost (talk) 14:38, 5 July 2018 (UTC)

Support And officially, I want to get all the credit for that idea! JSBM (talk) 17:21, 5 July 2018 (UTC)

Support sounds great. – Sealbudsman talk | contribs 03:47, 6 July 2018 (UTC)

Support. In addition, I see no reason for any user to have patrol and not autopatrol rights. Maybe we could also grant autopatrol rights to the group, or alternatively, make sure every member of the group is also a member of the autopatrolled group? --AttemptToCallNil (report bug, view backtrace) 14:49, 6 July 2018 (UTC)

I do think it would be better to keep them separate, just in case for some odd reason one may think a user could be trusted with patroller but not autopatrol, which would be rare. But yeah, in most cases, users would get both user rights - and there's not much of a problem with that; literately the only difference is a bureaucrat checking off one extra box when changing user rights.-- Madminecrafter12^{20pxTalk to me20px} 14:36, 8 July 2018 (UTC)

Support. I would really like to participate patrolling in my favourite set of pages. It's what I'm already doing basically anyway, without the actual applied hint. And this has nothing to do with my autopatrol usergroup, nor with achievements. I'd like to see it as guarding pages against all kinds of imperfections and what not that I could find as a voluntary task. Besides, it's a built-in feature already to actually patrol edits anyway, why not use it more if admins can't cover it enough. – Jack McKalling [ 16px 16px ] 23:23, 9 July 2018 (UTC)

Support as well. | violine1101^(Talk) 19:32, 12 July 2018 (UTC)

Group created and populated July 12, 2018 — Game widow ^(talk) 19:39, 12 July 2018 (UTC)

What should we patrol?

Since this proposal is heavily based on edits being patrolled, both manually and automatically during reverts, we should come to a consensus about what makes an edit worthy of being patrolled.

On one end of the spectrum, we could patrol everything as long as it isn't blatantly disruptive and/or against the rules. This will result in stealth vandalism being patrollable, not to count various errors.

On the other end, we could patrol only edits which don't require any further fixes, including spelling, grammar, facts... Needless to say, this effectively defeats the purpose of patrolling, making it massively difficult to patrol new edits.

I'm finding it difficult to even draft a proposal. Any suggestions? --AttemptToCallNil (report bug, view backtrace) 15:19, 6 July 2018 (UTC)

I definitely think that more than just blatant vandalism should be checked when patrolling, but I wouldn't necessarily say only edits don't require any further fixes should be patrolled. So I'm probably in between those two points, but closer to the second. Also, note that because I am an active editor of this wiki and have a lot of time to edit it, I often check for a lot more when patrolling than even what I personally think is necessary. I would say mainly check for and fix factual errors, wiki-code formatting errors (e.g., not closing a table causing the whole page to be messed up), and maybe very major prose issues, before patrolling. However, like I said, I have the time to be nitpicky, so I personally like to check for less important grammar errors, spelling errors, etc. as well.-- Madminecrafter12^{20pxTalk to me20px} 13:21, 10 July 2018 (UTC)

Rule violations, vandalism, invalid html structures (destruction of the webpage), wrong or misleading facts (false information), I think should all be checked. But stuff like rephrasing, spell checks, other maintenance, does not need patrolling. I imagine this from (humorously) analysing the picture that gamepedia gave to the patrolling achievements, namely an officer enforcing order. You basically patrol pages to check them off as being non-rule breaking. And if an edit violates something, to finish patrolling such edit you revert it or make another edit. And when you do, I believe this should not automatically mark all prior edits as patrolled (sometimes you check an edit that isn't necessarily the first unpatrolled one). However a quick rollback is most suitable to an automatic mark as patrolled for the related edits. – Jack McKalling [ 16px 16px ] 14:20, 10 July 2018 (UTC)

Also, I'm assuming the patrol mechanism requires the patroller to eventually mark all edits whatsoever as patrolled, disregarding whether they originally had rule-breaking content. In the case they had, you'd of course fix it by reverting or another edit, before you manually mark the edit as patrolled. – Jack McKalling [ 16px 16px ] 14:25, 10 July 2018 (UTC)

No edits are required to be patrolled. In fact, looking at the patrol log, the wiki didn't use the patrol feature hardly at all before December 2017, besides administrators having their edits automatically marked as patrolled. And even now, about half of the edits on the wiki remain unpatrolled, due to the huge backlog of edits and the very small number of administrators who actually patrol edits on a normal basis. However, it is definitely helpful to see what edits have been reviewed and which have not, specifically for people who may not have time to take a look at every single edit out there. Also, rollbacking edits automatically marks the rolled-back edits as patrolled (but undoing doesn't).-- Madminecrafter12^{20pxTalk to me20px} 14:39, 10 July 2018 (UTC)

One thing I will say, is that I do really think that major grammatical errors need to be fixed before marked as patrolled. For example, if somebody adds "Ghast fireball shoot players," I really think that marking it as patrolled as it is, and telling all other editors that it's been reviewed, doesn't seem quite right. A minor grammatical error, such as "Ghasts will shoot fireballs at player," is fine being marked as patrolled. Imo, a patrolled edit doesn't mean it's worded perfectly, but it should mean that the edit has been reviewed and any major problems have been fixed.-- Madminecrafter12^{20pxTalk to me20px} 15:46, 11 July 2018 (UTC)

I agree a certain level of grammatical fixes may need to be applied before the mark. But there is a serious issue in determining what classifies as such. So I would say to solve this no grammatics need be fixed before marking as patrolled, unless the grammatical error(s) cannot get the intention across of the content. If you can still determine the meaning and people can add more words to make it complete, it may be patrolled. But if the edit would break the information due to ambiguity, potential misinterpretation or false information, it should not be patrolled before fixing it. Would that be better? In other words, assume "patrolling" means making sure the content is "correct(ly interpreted)" (and also non-rule breaking, but we already established that). – Jack McKalling [ 16px 16px ] 10:27, 12 July 2018 (UTC)

With regards to "wrong or misleading facts (false information)": I think this is probably the most important use-case for patrolling. If an IP user (any user, but most recently it's been IPs that have been doing this) adds in some dubious information, it shouldn't be marked as patrolled until someone verifies that it's actually correct. That'd be an improvement over the current case, where such information can be added; someone will see it and thing "I should verify this"; and then they forget what they're doing and the information gets stuck. --Pokechu22 (talk) 16:37, 12 July 2018 (UTC)

Suggestions to the Minecraft Wiki

Here have I some suggestions to the Minecraft Wiki:

Make so autoconfirmed users can view abuse filters and the abuse log instead of only sysops, GRASP and wiki guardians
Make so the wiki have the "Minecraft" font or "Minecraft"-like font as default font
Some more skins, usually one "Minecraft" skin with the Minecraft font, stone background with white text, and other Minecraft items, and a skin with the sky as background and default font
Change the "Watch" tab to a Minecraft book instead of a default star
Add a "Interface editor" user group that users in that group can edit the MediaWiki: pages and create/edit editnotices
Make so users can create custom editnotices (as on Wikipedia [1]) for their user and talk spaces as notice while an editor trying to edit the page
More gadgets (wikEd, Twinkle (should be modified to use on this wiki), Navpops, dropdown menu to choose subject/edit summary while editing a page, ProtectionStatus (padlock on top right corner on protected pages), HotCat, a "AutoRefresh" tickbox on Special:RecentChanges to automatically refresh the page instead of reloading the page)
A "Translate" extension on this wiki (as on ftb wiki, mediawiki, meta wiki) instead of creating translation projects

Please add comments below --20px psl85 (profile | talk | contribs | send email) 16:02, 5 July 2018 (UTC)

No. --Pcj (talk) 16:14, 5 July 2018 (UTC)

I am going to go by number so its easier to reply to:

I see no reason to grant more people abuse filter rights, especially since some of the abuse filters apply to auto-confirmed users and they rarely need changes.
The Minecraft font would drastically decrease text readability, plus does not support many special characters. I would encourage you to enable this in your own custom CSS instead
Mostly neutral on alternate skins. They serve little benefit and require modifying templates to support them though (plus users may make visual changes to reflect their personal skin), so leaning against having them. You can easily make one in your custom CSS though.
I have that in my personal CSS and it looks pretty good, but when I proposed it before the consensus was it was not immediately clear the book represented watch.
I see no reason to have an interface editor group, they need rare enough edits that you can just ask one of our admins
I feel like custom edit notices has potential for abuse, but mostly neutral.
If you want a gadget here, feel free to port it using your custom JavaScript then propose the ported script. I personally would not use any of them so I don't see myself porting any of them.
The translate extension is terribly complicated to use and makes the markup terrible. I think it discourages edits from all users over encouraging translations.

–KnightMiner · (t) 16:22, 5 July 2018 (UTC)

Autoconfirmed users could only view abuse filters and the abuse log, not modify the filters. 20px psl85 (profile | talk | contribs | send email) 16:39, 5 July 2018 (UTC)

Just a thought - as you can see above I suggested that a new group called "Patrollers" be added, what if only this user group was allowed to view abuse filters and the abuse log (and not allow them to modify the filters)? Also, I may comment on the rest later - I just wanted to bring this up.-- Madminecrafter12^{20pxTalk to me20px} 16:42, 5 July 2018 (UTC)

To what end? There isn't really any reason for them to be able to view them. --Pcj (talk) 16:58, 5 July 2018 (UTC)

My opinions:

No. Users would be able to circumvent the abuse filters then. There's no reason for non-admins to see them. Besides, most filters are globally managed by Gamepedia anyway and can't even be seen by admins.
No. The font looks well ingame, but it is horrible for reading larger texts.
Neutral. But it doesn't really make much sense to have 10 different skins. There's a winter skin currently, so maybe we could add one or two more, but it's not really necessary. In my opinion, special skins for special occasions (such as Halloween) would be a great idea. (We do this on the German wiki)
Although I think the star doesn't really fit the skin, a book wouldn't be good to represent "watching". I think an ender pearl / an ender eye would be a good option too. But, really, it's just something visual that every editor should be able to decide for themselves.
No. Why? Just more maintenance work for basically no gain at all.
No. If you need them, add them to your personal JavaScript.
NO. This extension is horrible. (And breaks stuff.)

| violine1101^(Talk) 17:29, 5 July 2018 (UTC)

Here are my opinions:

Not for autoconfirmed users. Possibly for a patroller user group.
Agree with KnightMiner. Possibly make it a gadget for registered users to use, but I don't think it should be the default.
I do think more skins would be nice. I don't think having every possible skin imaginable would really be practical, but I do think a dark skin would be really nice.
Meh. I think people are used to the standard star, and I don't think it helps much making it a book or even an eye. Again, though, having it as a gadget not on by default might be nice.
Don't really see the point and doesn't seem necessary. Anybody can request for an admin to edit an interface page, and editing the interface seems like one of the most hazardous right that admins have.
Possibly, not really sure if it's worth it though.
Neutral.
I don't know much about it, but based on what I've heard, it doesn't seem popular! xD-- Madminecrafter12^{20pxTalk to me20px} 15:56, 6 July 2018 (UTC)

New wiki skin proposal

I'd like to propose my poorly written stylesheet to be used as the official wiki skin. I have created two themes such as the normal and the winter theme. It's been a long journey since the last time it was changed. So I figured that now is the perfect time to move on from the minecraft forum style. Any kind of suggestions are welcomed. Link to the image – ItsPlantseed ⟨₰|₢⟩ 07:37, 6 July 2018 (UTC)

Would you mind posting some screenshots so people don't have to modify their CSS to comment?

Also, what is the goal of the new skins? The only real difference I could see, apart from some font changes, was most of the background images are zoomed in more. I personally think the current wiki skin is pretty iconic and does not need to match Minecraft.net, since it is very recognizable as Minecraft. –KnightMiner · (t) 14:45, 6 July 2018 (UTC)

I agree with KnightMiner. We don't need to match the style of minecraft.net. We never even tried to match it, the wiki always had its unique design. | violine1101^(Talk) 14:58, 6 July 2018 (UTC)

Link to the image

The current theme is considerably "classic" from a certain perspective. I'm totally fine with the current design, there is nothing to blame about. However, this is not all about emulating the minecraft.net. This is just a minor change for what I called an improvement, that is aimed to make the web equalified with the metro style or whatever you may call it. There's always be a negative side of this and it might decrease the readability of an article. I understand if we don't really need a redesign, but there is always a room for improvement. – ItsPlantseed ⟨₰|₢⟩ 15:53, 6 July 2018 (UTC)

I think my biggest complaint is the inconsistency in the resolutions. The grass side is mostly the same scale as before, but the dirt is now four times the size and stone eight times, despite all connecting to each other directly. Also, I am not sure how I feel about the green links. It looks okay in the main text area, but clashes a bit with the edition boxes, plus I think most users these days are used to blue links so its not immediately obvious that green is a link. –KnightMiner · (t) 16:04, 6 July 2018 (UTC)

The inconsistency of the resolution is mostly intentional, I thought that the nonuniformity will devote a different feeling to readers. As for the green links, I'm not too proud of that either. I just wanted to see how that will look for a long period. That's all I can say right now. I might do another round by changing the links and include others suggestion. Thanks for the feedback anyways. – ItsPlantseed ⟨₰|₢⟩ 16:39, 6 July 2018 (UTC)

Support - I now have this skin on since almost 2 weeks an honestly feels very fitting. However, the background might have too much noise. - Hugman_76 [ 16px 16px 16px ] 13:49, 13 July 2018 (UTC)

Thank you! This helps me to improve my design even more. I'm glad you like it. – ItsPlantseed ⟨₰|₢⟩ 02:38, 14 July 2018 (UTC)

Oppose: the proposal and the author's comments are internally inconsistent; the proposal also fails to point out any specific objective issue with the current design, which makes the change unwarranted. --AttemptToCallNil (report bug, view backtrace) 16:25, 13 July 2018 (UTC)

You're not wrong. I didn't state the objections quite clearly. This requires public attention besides the community. Hence I can have the main issue more explicitly. – ItsPlantseed ⟨₰|₢⟩ 02:38, 14 July 2018 (UTC)

Oppose as well, the current skin is fine and the new skin doesn't have any advantages over it. Also, it's obviously unfinished and would require quite a lot of work before it could be implemented. Besides, the design of the wiki is iconic by now. We don't need to imitate minecraft.net as closely as possible. I also don't think that the different resolutions of the graphics look good, I find it quite annoying. It doesn't improve the current design in my eyes. | violine1101^(Talk) 16:51, 13 July 2018 (UTC)

Thanks for the feedback. I'll improve my current design as good as possible in the future (and make it appealing to your eyes). – ItsPlantseed ⟨₰|₢⟩ 02:38, 14 July 2018 (UTC)

Updating the Director page to show only the active directors.

Hi!

The directors' page is currently not updated at all and contain a lot of name of admins that are no longer active on their community, which is not really useful for the overall project and can actually make it more difficult to communicate with an admin from another language that will be able to answer to you, or whatever the director project do.

If you want, this page contain an update to this page where I removed inactive admins — if I made any mistake, point them out. We can simply use that page to replace the content of the real one.

For thos who feel it's important to know everyone on a Wiki who have the admins' rights, I just want to point out that a direct link to that list is placed on the template for every language to know this information. But I don't see any case where it could be useful.

Thanks! JSBM (talk) 03:51, 7 July 2018 (UTC)

I personally think it is still worth showing inactive administrators, but I am fine with distinguishing them. Maybe add an inactive background color or an inactive administrator header/section? –KnightMiner · (t) 05:00, 7 July 2018 (UTC)

That's a good suggestion, that could be a good compromise.

If I may ask, however, what interest so you find to show inactive ones?

JSBM (talk) 05:46, 7 July 2018 (UTC)

The Directors page is supposed to be an overview of everyone who has any special rights on the Minecraft wikis. Changing the page to not show inactive admins would not only mean way more work for us to keep the page updated, but would also mean that it wouldn't actually list all directors. Then, there's the question, when is an admin inactive? After a month? After a year? After ten years? We would need to draw a line. It's the job of the respective wikis to demote inactive admins, not ours. To sum it up, I don't see much benefit in only listing active admins, all it does is creating more work for us.
And also, I think that if only active admins should be shown, we should somehow mark them as inactive instead of removing them from the list altogether. | violine1101^(Talk) 09:09, 7 July 2018 (UTC)

I'm definitely not a fan of removing inactive admins completely. However, I'm not opposed to distinguishing them somehow, whether that's giving them a different color or putting them in a whole different section. But yeah, we would need to decide what counts as "inactive." 3 months maybe?-- Madminecrafter12^{20pxTalk to me20px} 13:12, 7 July 2018 (UTC)

I would suggest a longer period, as on a slow moving site maybe 3 months is enough for an admin. This is why I on Discord suggested displaying the last contribution date, which I understood would be hard to add sadly. I think maybe 1 year, would be better. Then you could update it quarterly, and not created as much extra work for the updating of this enhancement. With 3 months, you would need to update (bi-)/monthly. Holroy ^{talk◆contribs} 19:21, 7 July 2018 (UTC)

Would it be possible to generate this page in Lua based upon the various lists linked in the title sections? Or make a script to update it monthly? If that could be done, it would be a lot less work, and we could possibly add the last contribution date to the list, so that viewers could decide for themselves which admins are active or not. Holroy ^{talk◆contribs} 19:21, 7 July 2018 (UTC)

I think that the date of last contribution could be shown automatically with something along the lines of {{#explode:{{Special:Contributions/Jahunsbe|limit=1}}| (| 0}} However, #explode and other string functions don't seem to be able to parse templates passed as parameters. I am not sure how to fix that. Alternatively a lua function should be easily creatable. Jahunsbe (Talk) 01:52, 8 July 2018 (UTC)

It might be possible to make a template or module that can parse that, but it would only work for this wiki; there's no way to transclude pages from other wikis. I don't recall where the discussion of it is, but at least on this wiki there has been more effort to demote inactive admins recently. Rather than trying to create a policy for which users with directors permissions should be listed on the directors page, I think it would make more sense to focus on demoting inactive admins and updating the directors page to match actual permissions. -- Orthotope^talk 02:36, 8 July 2018 (UTC)

We are carrying out the inactive demotion process now (see Special:UserRights/IKJames, Special:UserRights/Kanegasi, and Special:UserRights/Hower64), but of course it does not apply to admins on other wikis. For reference, the original proposal can be found here.-- Madminecrafter12^{20pxTalk to me20px} 02:39, 8 July 2018 (UTC)

Block and unblock templates

Psl85 recently created {{Blocked}} and {{Unblock}}. If we are going to keep these templates, there are several things we have to do:

Make it clear to administrators to use {{Blocked}} after blocking a user.
Change the admin noticeboard message "If you believe you have been wrongfully blocked, please visit an admin's userpage and send them an email using the left sidebar" (which I personally disagree with, considering how most blocks are made to IPs) to mentioning the {{unblock}} template instead.
Actually create [{{fullurl::Category:Requests for unblock|}} :Category:Requests for unblock]
Decide whether we need {{unblock on hold}}, {{unblock reviewed}}, and {{Unblocked}}.
- If we don't decide to create these, we need to remove the part mentioning these from {{unblock}}

If we do these things, however, it will kind of make this an official guideline. Therefore, I do think it would be nice to get consensus from the community about this before making all of this official.

I personally weakly Support having {{blocked}}. I feel like this would be helpful for making it clear to editors why they were blocked and how long it is. For {{unblock}}, I'm a bit Neutral. I see the point of it, and it could be helpful, but is it really necessary? As for the others, I don't see the problem with admins just replying to the {{unblock}} template with whatever the result is - I don't see any reason why the template needs to be replaced or anything; it would just make it consistent with Wikipedia, which is not a good reason at all. And if we don't decide to create {{unblock}}, we definitely don't need them.-- Madminecrafter12^{20pxTalk to me20px} 14:32, 8 July 2018 (UTC)

Weak support {{blocked}}, for registered users only (we can't have this template with finite blocks due to maintenance complexity, and we can't block IPs indefinitely). removed on 15:41, 12 July 2018 (UTC) Oppose {{unblock}}: I would expect blocking administrators to watch the talk page of an indefinitely blocked user if some probability of an unblock exists (e. g. not a sockpuppet of an indefinitely blocked cross-wiki vandal). --AttemptToCallNil (report bug, view backtrace) 14:40, 8 July 2018 (UTC)

Could you clarify what you mean by "maintenance complexity?" It seems to work just fine in my sandbox when I set the first parameter to something non-infinite.-- Madminecrafter12^{20pxTalk to me20px} 14:44, 8 July 2018 (UTC)

I mean removing the template when the block expires. Unless you mean for the template to be the content of a message informing the user of a block instead of a state tag like the one for inactive users. --AttemptToCallNil (report bug, view backtrace) 14:53, 8 July 2018 (UTC)

Oh, I see what you mean now, but I actually was thinking for the template to be more like what you said about "content of a message informing the user of a block." Specifically, the block template stays on their until somebody removes it or archives it - informing the user of their block instead of a state tag.-- Madminecrafter12^{20pxTalk to me20px} 14:59, 8 July 2018 (UTC)

In that case, why is this even necessary? Blocked users get all this information whenever they try to perform a write action. --AttemptToCallNil (report bug, view backtrace) 15:27, 8 July 2018 (UTC)

Imo, although the blocked text does provide a bit of information, it seems better for users if they get a clear talk page message explaining everything from an actual user as soon as their blocked, rather than just one day they try to edit and for some strange reason they can't - and they just see something that says they've been blocked and gives them some information about it.-- Madminecrafter12^{20pxTalk to me20px} 15:33, 8 July 2018 (UTC)

Revoked my support for the template. I have reconsidered and Oppose it now. Messages to blocked users about blocks should include reasoning about why the block has been performed (which can't be made into a template), not duplicate information found in public logs and displayed whenever the blocked user tries to perform a write action. --AttemptToCallNil (report bug, view backtrace) 15:41, 12 July 2018 (UTC)

If I'm understanding correctly, you're saying that the reason why the block was performed can't be made into a template? It's actually in the template already, just use {{Blocked||[Reason here]}}, see the template's documentation.-- Madminecrafter12^{20pxTalk to me20px} 15:45, 12 July 2018 (UTC)

I would say the reason is the key thing this template is useful for, and given that it has to be a parameter, pretty much the rest of the entire template is superfluous. If we do implement it, we should definitely make it more lightweight, similar to the user warning template we already have. --AttemptToCallNil (report bug, view backtrace) 16:13, 12 July 2018 (UTC)

Oppose. On procedure: users should not be creating de facto policies that the rest of the wiki is expected to follow without any prior discussion. On principle: we don't need every complex bureaucratic process that Wikipedia has. On content: MediaWiki:blockedtext already contains more information than {{blocked}} does, and is displayed and removed automatically. If more information needs to be given to a user, admins can always leave a message on their talk page, though I think it's usually not needed. Most blocks are for deliberate vandalism, or are given to users who have been repeatedly warned about their behavior; in either case, being blocked should come as no surprise. -- Orthotope^talk 18:47, 8 July 2018 (UTC)

I would like to point out that I've seen several instances where users who were almost certainly acting in good faith were blocked for a while without any warnings. Fortunately, though, I haven't seen as much of this recently, and when I personally block users, I always try to warn first, especially when it's not blatant vandalism.-- Madminecrafter12^{20pxTalk to me20px} 18:58, 8 July 2018 (UTC)

@User:Madminecrafter12, User:Orthotope and User:AttemptToCallNil: I would think that we could still use the blocked template, and users could still request unblock using {{unblock}} instead of sending mail to the blocking administrator or another administrator. Current requests for unblock could administrators check periodly and review them, and I think to add a image to the top right corner on blocked user's pages to see if the user is blocked, instead of checking block log and so, and why do you not mention me by using @Psl85: or so, I would be notified about this event so I can easily respond here, 20px psl85 (profile | talk | contribs | send email) 06:31, 9 July 2018 (UTC)

I do think that we should modify the admin noticeboard text saying "If you believe you have been wrongfully blocked, please visit an admin's userpage and send them an email using the left sidebar." Most blocked users are IPs, and many registered users don't have email enabled. I think something like "If you believe you have been wrongfully blocked, please post your unblock reason on your talk page and notify the blocking admin using {{ping}}" or something similar, would be better.-- Madminecrafter12^{20pxTalk to me20px} 15:51, 11 July 2018 (UTC)

Oppose to both blocked and unblock templates. I agree with Madminecrafter, that a personal message (without any templates) explaining why they were blocked (in case it's not blatantly obvious) is better than inserting the big red blocked message box. A blocked user already gets lots of indications about it, and a personalized talk page message manually written anyways, feels more polite than a big boom attention area with automated text. The reason is the most important part, basically all that's needed. And when an (IP) user has been blocked, letting them post a ping message on their talk page is much better than maintenance categories, a whole policy about using templates, and all that ton of automated information that most often doesn't apply to a particular blocked user anyway. If an admin or the blocked user is going to communicate about a ban, it's better to stay straight forward and not confuse eachother with information that is not immediately relevant. – Jack McKalling [ 16px 16px ] 15:27, 24 July 2018 (UTC)

We could change the message box to instead to this text below and users need to subst: the template:

25px Your IP address or username has today, Friday April 2024, been blocked indefinitely from editing the Minecraft Wiki. A reason for this block is: None given. If you would to discuss the block, please discuss the block below with the blocking administrator, or send mail to the blocking administrator, and please do not remove this notice while blocked.

The notice above is better and clearer than the ugly message box, and could be subst:ed on user talk pages.

I have a comment: Where should any emails going on appealing blocks be sent? --20px psl85 (talk • contribs) 18:09, 24 July 2018 (UTC)

I've boldly rewritten {{blocked}}, to hopefully make it more useful. The rewrite makes it more like a personal warning message rather than a message box, and allows for a custom message as long as needed. Although I definitely like the idea of a template like this, it seems like a lot to have to apply the template to every single user who gets blocked. So I'm probably neutral for this one. As for unblock, I have to Oppose now. I really don't think a template is necessary at all there - there are constant patrollers of recent changes (including me), who would easily see users editing their talk pages to request an unblock, and I don't see how it's useful. I do agree that blocks should be discussed on the blocked user's talk page rather than via email, see the discussion here.-- Madminecrafter12^{20pxTalk to me20px} 13:44, 26 July 2018 (UTC)

I've deleted {{unblock}} now. Like I said, I see the use of it, but the clear consensus here seems to be to not use it. Also, it would probably be more trouble than it's worth to have to deal with {{unblock reviewed}}, {{unblock on hold}}, {{Requests for unblock}}, etc. I've kept {{blocked}} for now, as it would be nice to see what people think now that it's been rewritten to be more personal. I might even start using it for some of the users who I block and just see how it goes.-- Madminecrafter12^{20pxTalk to me20px} 15:22, 9 August 2018 (UTC)

Delete Norwegian translation project

As a Norwegian I've looked into MCW:Projects/Norwegian_translation, and it's obsolete and outdated, and I believe that this project could be deleted all together.

I've looked through :Category:Norwegian_translation, and checked each of them for the last edit date, and found that almost all of those pages were last edited in the period 2014-2016. Some of them have newer edit dates, but that is from two distinct reasons: 1) Fixing broken file links, and 2) Adding other translation links. In the few exceptions to being old edits, just very minor details has been changed since 2016.

To add to this, I would also argue that most Norwegians are proficient enough in English, that there really isn't a need for a Norwegian translation which is poorly translated and outdated. Therefore I suggest to close down this project, and cleanup/delete related pages. Holroy ^{talk◆contribs} 20:29, 8 July 2018 (UTC)

I think this should also be done on the Greek Minecraft Wiki. Every single one of the articles (excluding the main page) is in English, not Greek, and not a single translation attempt has been made to them. Also it isn't updated to reflect newer versions of Minecraft. --Giorgosarv18 (^talk/_contribs) 17:07, 11 October 2018 (UTC)

Deletion templates to redirects

This has been brought up a few times on Discord, but I've never gotten around to drafting a proposal. The proposal is that when adding {{delete}} to redirects, that it always goes BELOW the redirect, UNLESS it is a blatant violation of Rules #1 or #2. As many of you know, this will make the redirect actually functional, so that any readers searching for it will automatically be redirected to the target page, but the redirect will still show up in :Category:Pending deletion. Here are my reasons:

For alternate capitalization redirects, when a deletion template is on them, readers will be taken to the page that's pending deletion when they search for the title. However, if they are actually deleted, the reader will automatically be taken to the alternate capitalization page that EXISTS.
It's more confusing for newbie readers to come across a page with this giant red box and a link, than if they just searched for it. The second would be the case if the redirect were actually deleted, the first would be if it were just marked for deletion. Also, pages that are marked for deletion show up as search suggestions, so it's likely that readers would click on those.
Some redirects in the deletion category are marked because of a mistake, a misunderstanding, etc. and really should not be deleted at all.
As redirect links in categories appear italicized, this would be very helpful for marking what pages in the deletion category are redirects and which are not. I try to patrol and delete pages in the deletion category as often as possible, especially non-controversial ones (e.g. author's request), but it is difficult with all of the redirects clogging it up.

Curious what others think about this.-- Madminecrafter12^{20pxTalk to me20px} 16:54, 9 July 2018 (UTC)

Why would this be a question? I'd say that placing the redirection code somewhere other than at the very top should only be done when it is necessary to disrupt the redirect because the fact that A redirects to B is itself damaging (e. g. if someone redirected a page to Special:Logout). --AttemptToCallNil (report bug, view backtrace) 17:40, 9 July 2018 (UTC)

Are you suggesting a new template, aka {{redirectdelete}} or a new policy? If new template, would it be used? How to trigger it usage? If new policy, some of the same apply. In general, I do believe you've got some valid points, though. Holroy ^{talk◆contribs} 20:00, 9 July 2018 (UTC)

Holroy - actually, I'm not suggesting a new template. All I'm saying is that when people add the normal {{delete}} to a redirect page, they should add it below the actual redirect instead of above, so that the redirect is functional.-- Madminecrafter12^{20pxTalk to me20px} 20:03, 9 July 2018 (UTC)

In other words, you're trying to educate the users to do {{delete}} below the redirect, which is sound advice, but hard to get out to the people. Holroy ^{talk◆contribs} 21:25, 9 July 2018 (UTC)

If this gets mostly support, we can kindly tell users on their talk page to place {{delete}} below the actual redirect if they don't, and reference this discussion. We could also add it to the template's documentation.-- Madminecrafter12^{20pxTalk to me20px} 02:22, 10 July 2018 (UTC)

Yeah. The way I see it, a pending deletion is just that: pending. It's a maintenance request. Having {{delete}} break a redirect is just as damaging as if {{delete}} also wiped the content of a normal page, like Stone. So yeah, that would be a good rule on the template documentation. – Sealbudsman talk | contribs 02:19, 10 July 2018 (UTC)

Support all of the above. The template must go below the redirect. When the template is placed to break the mechanism of a redirect, it's like saying with arrogance that the request has to take effect immediately without waiting for input from the admin(s) that are notified by it. – Jack McKalling [ 16px 16px ] 11:18, 10 July 2018 (UTC)

I Agree with this as well, no point breaking a redirect until we decide whether to keep it or not. This is especially true of template redirects as that makes anything transcluding it now transclude {{delete}} and file redirects as it breaks anything linking the file (though none of these should be marked if still in use anyways).

Its also worth mentioning that the deletion pending redirects show up in Special:RandomRootPage which is not beneficial to the readers. –KnightMiner · (t) 15:03, 10 July 2018 (UTC)

Under the same principle of not breaking things, I'd like to add that when tagging pages for deletion, the page content should not be removed. The exception (similar to what AttemptToCallNil mentioned above) is if the presence of the page content is immediately harmful (personal information, abusive content, etc.). -- Orthotope^talk 01:32, 11 July 2018 (UTC)

Agree. Actually, after thinking about this more, I think that redirects should only be broken or pages blanked if they contain private/sensitive information (e.g. an 8 year old's address), solely attack a living person, or consists only of a copyright violation, rather than just any violation of rule #2. More or less, only pages that would require revision deletion if they were added to an existing page should be blanked. It's helpful for admins to know what the content of a page was without having to dig into the history.-- Madminecrafter12^{20pxTalk to me20px} 16:01, 11 July 2018 (UTC)

I know this proposal seems to be accepted, but I do have two more reasons I've come across:

5. If it really is a bad redirect, than adding {{delete}} above it will actually make it show up in the search suggestions in circumstances where it wouldn't if put below.

6. Many times people will add a deletion template to a redirect with the summary "Might should be deleted, but may still be useful." In these cases of ambiguity, it doesn't make sense to completely break the redirect.-- Madminecrafter12^{20pxTalk to me20px} 14:05, 13 July 2018 (UTC)

Image animation don't work in Template:Mod/Block

While you can do some animation with images in infoboxes by using, for example |image=White Wool.png;Red Wool.png with the Template:Block, this feature doesn't works in Template:Mod/Block. Could someone check in what's wrong and probably fix it? I can't easily manipulate this sort of code as some of you do. Thanks! - Hugman_76 [ 16px 16px 16px ] 13:14, 10 July 2018 (UTC)

Done 16px MarkusRost (talk) 13:17, 11 July 2018 (UTC)

Should completely untranslated pages in translation projects be deleted?

I've been marking some of these for deletion lately. It seems like many pages from translation projects (particularly Lithuanian and Vietnamese) have not seen a single attempt at any form of translation, despite existing for several years. Unlike redirects, these pages also clog up the search bar, and being taken to an outdated copy of an article from clicking one of these pages could end up being confusing to new users.

I see no benefit to keeping these pages - they clog up the search bar, are completely useless, are more than likely outdated in comparison to their current English counterparts which could be considerably harmful if someone were to try translating said outdated information, and by deleting them we're not losing anything important since they can be recreated with more up-to-date information. - MinecraftPhotos4U (talk) 20:41, 10 July 2018 (UTC)

In that specific case, it seems reasonnable to delete them, if and only if there is absolutely no translation made on it. JSBM (talk) 20:47, 10 July 2018 (UTC)

I Support deleting any translation pages under the following conditions: they were created over a year ago, and no translation, nor any attempt of translation, has been made to them, per the reasons provided.-- Madminecrafter12^{20pxTalk to me20px} 20:49, 10 July 2018 (UTC)

Support deletion of translation subpages inactive for over a month if there was no translated content on the page. I put a month instead of a year because such pages should only be works in progress, any reasonable work in translation subpages is made in the language of the translation project, and a month of no translation edits is more than enough to say there's no work in progress on that page. --AttemptToCallNil (report bug, view backtrace) 15:32, 12 July 2018 (UTC)

I agree with that. Also Support. Having all these basically (old) duplicates of pages deleted, cleans up a lot. – Jack McKalling [ 16px 16px ] 15:36, 12 July 2018 (UTC)

Makes sense. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 15:47, 12 July 2018 (UTC)

I'm currently deleting some of the more extreme cases - e.g., absolutely no translation at all, no links, and existed for over 1 year.-- Madminecrafter12^{20pxTalk to me20px} 18:22, 12 July 2018 (UTC)

Should whether a page is linked to or not really be that much of a factor worth considering in this situation? - MinecraftPhotos4U (talk) 19:45, 12 July 2018 (UTC)

I believe I've marked every untranslated Lithuanian page for deletion now, so that's that cleared up. Currently looking through other projects. - MinecraftPhotos4U (talk) 13:28, 14 July 2018 (UTC)

On minimally translated pages

There exist pages such as Data values/fin, where only the very first sentence has been translated. While this undoubtedly counts as "translation work", should these also be considered eligible for deletion, due to containing overwhelming amounts of outdated information (that page has existed since 2011), and not having any work done besides the first sentence? - MinecraftPhotos4U (talk) 16:22, 12 July 2018 (UTC)

I think such pages should be deleted on a case-by-case basis only. I agree with the provided reasoning, and I'd say this page scores rather high on my "delete" scale, but I find no way to formalize the criteria for deleting or keeping such cases. --AttemptToCallNil (report bug, view backtrace) 16:37, 12 July 2018 (UTC)

I agree with AttemptToCallNil, it should really depend on the page. In that specific case, a single sentence is not enough to show that the page was translated, and it could be deleted. JSBM (talk) 16:53, 12 July 2018 (UTC)

Archive this talk page

It's the 50th topic, it might need a clearup. - Hugman_76 [ 16px 16px 16px ] 12:01, 12 July 2018 (UTC)

Support, I thinked it also, this talk page is getting very very long and needs archiving. 20px psl85 (profile | talk | contribs | send email) 12:33, 12 July 2018 (UTC)

The thing is, a lot of these topics are actually quite active. I think at best we could archive the first 11 topics. Maybe we could create an archive for ~~July~~ May - August (I swear I had put May there, but apparently I had put July - anyways, I meant May) right now, and then slowly add inactive conversations to it. Usually MCW creates an archive all at once, but to me archiving topics one by one (or five by five, etc.) seems like our best option here.-- Madminecrafter12^{20pxTalk to me20px} 12:39, 12 July 2018 (UTC)

The first subject is last updated in May, so I'd start from there already. Besides, it's the next from the last archive. – Jack McKalling [ 16px 16px ] 14:49, 12 July 2018 (UTC)

I archived a bunch of topics that are no longer actively discussed; there have been way more posts on this community portal than usual during the last few months, so there's still a lot of topics that still might need comments. If those topics don't get any more comments, they can be added to the archive as well. | violine1101^(Talk) 10:49, 13 July 2018 (UTC)

I'm not sure if the proposal for classifying edits to other's user pages should have been archived. No action was made concerning that, and the discussion never really stopped, it just didn't seem to get much traffic.-- Madminecrafter12^{20pxTalk to me20px} 14:48, 14 July 2018 (UTC)

Indeed. Requesting extraction from the archive to the page itself. --AttemptToCallNil (report bug, view backtrace) 15:01, 14 July 2018 (UTC)

Go ahead, I just archived the topics that did not get any replies for the longest time, since this page was getting really long. But even if you unarchive this topic, I doubt it will get much more replies. | violine1101^(Talk) 15:08, 14 July 2018 (UTC)

In that case, maybe we should just go ahead and implement that proposal? --AttemptToCallNil (report bug, view backtrace) 15:25, 14 July 2018 (UTC)

Just to clarify, does maintenance edits mean fixing links and files as well?-- Madminecrafter12^{20pxTalk to me20px} 15:26, 14 July 2018 (UTC)

Maintenance edit would imply fixing any issue not intended by the owner which causes the user page to be added to any automatically generated list. Including the list of wanted pages or the category of pages with broken file links. --AttemptToCallNil (report bug, view backtrace) 15:34, 14 July 2018 (UTC)

Do black and light gray glow sticks exist or not?

[{{fullurl:Light Gray Glow Stick|}} Light Gray Glow Stick] was marked for deletion for not being in the game, but Dinoguy reverted it because of the links. However, Black Glow Stick was also marked for deletion, and this time Nakriin deleted it, while there are still many mainspace links to that page. So, do black and light gray glow sticks exist at all? If so, then Black Glow Stick needs to be restored. If not, then all the links and all of the crafting recipes for the 2 glow sticks need to be removed.-- Madminecrafter12^{20pxTalk to me20px} 14:50, 19 July 2018 (UTC)

I think it exists, both should be kept. It may not be one of the most recognized items, but removing them would be loss of content, in my point of view, mainly because it is an educational edition. --Iludido (talk) 15:55, 23 July 2018 (UTC)

I can verify that neither light gray glow stick nor black glow stick can be crafted, at least not with the same recipe as the others. I don't think you can gain glow sticks with /give, and they aren't in the creative inventory. It is possible they exist but are not used. Jahunsbe (Talk) 16:37, 23 July 2018 (UTC)

Other editors have verified this as well and came up with the same conclusion. Now that Module:Inventory slot/Aliases has been updated so that no pages (except this page) link to [{{fullurl:Light Gray Glow Stick|}} Light Gray Glow Stick], I have deleted it.-- Madminecrafter12^{20pxTalk to me20px} 02:24, 14 August 2018 (UTC)

Transfer outdated mods of Template:Mods to another proper template

The current template for mods (Template:Mods) contains many, many outdated mods. Following the placement of mods, those are sorted by their main features (Dimension, NPC...). The problem with that is the fact that outdated mods aren't sorted by this system and are only defined by their availability. Here's my request: Move every outdated mods to something like [{{fullurl:Template:Outdated Mods|}} Template:Outdated Mods] and class them by features like the current mods template. - Hugman_76 [ 16px 16px 16px ] 11:02, 22 July 2018 (UTC)

I believe I should bring up the unsolved archived discussion about mods on this wiki here, before conflicting conclusions occur. – Jack McKalling [ 16px 16px ] 11:31, 23 July 2018 (UTC)

Should we migrate mods to another wiki like FTB

Should we move all mod content on our wiki, possibly also including other third-party content, over to a wiki that is dedicated to documenting mods? The FeedTheBeast Wiki claims to accept other mods than included in FTB modpacks, so it does fit there. This wiki is more about the game itself in my opinion. The deletion of mod pages on this wiki will clean up a lot, and moving them to another wiki would give them the opportunity to get more, dedicated editors to work on them as they are more about mods than we are. I would suggest to add a new rule about not documenting third-party content here, but allowing to link to it cross-wiki style. But this would need to be worded better. – Jack McKalling [ 16px 16px ] 11:31, 23 July 2018 (UTC)

Support for moving mods to FTB, but where would non-mod third party content go, for example Programs and editors, or pages about command creations, like maps? FVbico (talk) 11:56, 23 July 2018 (UTC)

Pages about personal creations are within the namespaces of users. Would stay as is with the current description of the proposal, since users are very free to do what they want within their own user namespace. --Pepijn (talk) 12:01, 23 July 2018 (UTC)

We can't move anything without discussing this with the receiving wiki. --Pepijn (talk) 11:59, 23 July 2018 (UTC)

Okay, to clarify a few confusions and concerns that arise whenever this is discussed (because it's been discussed more than once, but it usually has never been extensive enough discussion for action):

The FTB Wiki would be happy to have content moved onto our wiki. We don't need an extensive discussion from our side I don't believe, just one from yours.
The FTB Wiki, despite being the "FTB" Wiki, allows and welcomes all mods and modpacks (even stuff like ftb:Tekkit). We officially "focus" on the FTB but have absolutely no rules on that and editors just document whatever they want to document pretty much. We have "merged" wikis/moved content from small mod wikis before.
We don't have restrictions on "old"/"outdated" mods or anything like that; our "ultimate goal" is to document all mods, regardless of version.
A lot of the mod pages on the Minecraft Wiki are pretty meh in terms of how much they would meet our manual of style and whatnot. A moving project might have to address that. However, "meh" pages are better than no pages, and are welcome.
We actually allow non-mod software stuff to be documented on the FTB Wiki (examples include ftb:Atom-MineTweaker, ftb:ModUpdater, ftb:MultiMC). We don't have extensive documentation for this sort of stuff but some is there and more is welcome.
If you guys have non-software stuff documented, like maps and resource packs, that might be more complicated. I'm not sure you do have that sort of stuff documented, though, so this may be a non-issue.
A decision to move mod content off the Minecraft Wiki and onto the FTB Wiki may not/does not apply to other language wikis. The Russian Minecraft Wiki wants to keep their mod content and everyone to my knowledge is completely fine with that. We are infamous for mw:Extension:Translate so moving translated content may be tricky anyway. Basically, stuff that is a mirror/translation of the Minecraft Wiki or FTB Wiki (apparently there's some of that?), such as :fr:Mods/AppleSkin, can be moved easily.
The FTB Wiki Discord is a cool place to be. I don't check this wiki often enough/don't get an email when pinged he so someone please poke me with updates/whatnot.

-Xbony2 (GRASP) (FTB Wiki Admin) (talk) 13:47, 23 July 2018 (UTC)

Support moving mod content to FTB. – Sealbudsman talk | contribs 01:00, 25 July 2018 (UTC)

Neutral, assuming somebody cares about my opinion. --AttemptToCallNil (report bug, view backtrace) 07:28, 25 July 2018 (UTC)

Support if this is a vote of some sort. If there's any concerns or questions that haven't been addressed yet please share them now. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 15:06, 25 July 2018 (UTC)

I should note, if approved, project pages should be made on both wikis for coordination. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 15:28, 25 July 2018 (UTC)

Support for moving content - If it's decided to go ahead however, would prefer to have exported files with full history to import, so a record of contributions can be maintained. DSquirrelGM𝓣𝓟𝓒 🗸 02:14, 26 July 2018 (UTC)

Of course. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 02:18, 26 July 2018 (UTC)

Any updates on this? -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 21:25, 30 July 2018 (UTC)

Support moving out. Mod content was always irritating me on the Minecraft Wiki. Frisk (Talk page) 08:25, 31 July 2018 (UTC)

Support A clear separation between vanilla and modded content is essential, which means using a namespace or subpage to keep the mods, which makes them more difficult to link to and search for, the obvious solution is to put them on a wiki dedicated to mods, and FTB is the only real contender. In many cases we can probably just convert the articles to link to there, as they probably already have better and more up-to-date content than ours. –Majr ᐸ Talk
Contribs 12:51, 31 July 2018 (UTC)

"A clear separation between vanilla and modded content is essential": why? And why would placing articles about mods into mainspace and making mod content articles subpages of respective mod articles not suffice? --AttemptToCallNil (report bug, view backtrace) 13:54, 31 July 2018 (UTC)

Change Mediawiki:Blockedtext

The current "blockedtext" Mediawiki message could we change from this default text:

Your username or IP address has been blocked.

The block was made by $1. The reason given is $2.

Start of block: $8
Expiration of block: $6
Intended blockee: $7

You can contact $1 or another administrator to discuss the block. This can be done on your talk page, which in most cases you should be able to edit, or by sending an email to an admin. Note that you cannot use the "email this user" feature unless you have a registered account, a valid email address is specified in your account preferences, and you have not been blocked from using it.

Your current IP address is $3, and the block ID is #$5. Please include all above details in any queries you make.

to this text:

Oops! Your username or IP address have been blocked.

The block was made by the administrator $1. The reason given for this block is: $2.

The block is valid from $8 until $6.

If you want to discuss the block, you can discuss with the blocking administrator, who is $1, or if it is made by mistake, add {{unblock|reason to be unblocked ~~~~}} to the bottom on your user talk page and replace your reason here with the reason to be unblocked. You can also send email to the blocking administrator, if you have an valid email address in your preferences.

If you cannot edit your talk page or are blocked from using the email function, please send an email to ... and an administrator will look on the email and reply.

Your current IP address is $3, and the block ID is #$5.

Comments:

Where should any emails about appealing blocks be sent? Please add them in the blocked notice, replace the ... with the email address

--20px psl85 (talk • contribs) 17:18, 24 July 2018 (UTC)

Oppose the use of {{unblock}} as by my arguments in discussion at #Block and unblock templates. – Jack McKalling [ 16px 16px ] 17:35, 24 July 2018 (UTC)

Why no {{unblock}}? The template is useful to use if it is ok, but it could be used if no email is available or the user has disabled email, and it could be used as on Wikipedia, notifying admins while it is used on any user talk page, 20px psl85 (talk • contribs) 17:39, 24 July 2018 (UTC)

I literally just linked you to my argument above. – Jack McKalling [ 16px 16px ] 17:42, 24 July 2018 (UTC)

New way of managing deprecated sprites

In User:Sealbudsman#Test you'll see a list of sprites currently deprecated from :Module:BlockSprite. Each is linked to a specific category page, listing pages with those sprite ids. Those pages, in turn, list those categories down at the bottom, which is nice because you can see exactly what sprites are deprecated on a given page.

The list is generated by the a new deprecated function, proposed to be used in :Module:Sprite, which I'm demoing for now in :Module:UserSealbudsmanSprite. Here is what I've changed.

I intend that the lists of deprecated sprites go on the {{BlockSprite}} (etc.) doc pages, probably under the "Full List" sections.

Caveat: for this test, User:Sealbudsman#Test is drawing the list from Module:Sprite, so it's listing every deprecated sprite id, but only Module:UserSealbudsmanSprite is setting the new categories, so only acacia-wood-planks and wooden-plank have anything listed when you follow the links. When it's live, these categories, I assume, would all be complete lists, and none would be empty.

What do people think? Pros, cons, code review are all welcome. – Sealbudsman talk | contribs 12:31, 25 July 2018 (UTC)

I don't know how modules or the sprite system work, but I understand it would otherwise without this, be very difficult to keep track of pages that use deprecated sprites, so I Support this concept. I'm glad there is a solution. – Jack McKalling [ 16px 16px ] 13:45, 25 July 2018 (UTC)

Madminecrafter12, you mentioned you'd like better visibility on deprecated sprites. What do you think of it? – Sealbudsman talk | contribs 19:50, 25 July 2018 (UTC)

Are you saying that there would be separate categories for pages using each individual deprecated sprite, rather than solely for pages using any deprecated sprites, like how it is currently?-- Madminecrafter12^{20pxTalk to me20px} 20:25, 25 July 2018 (UTC)

Yes.

These categories would be listed with other categories at the bottom of each page where the sprite IDs appear. See the wiki's sandbox for an example.
Links to these categories would also go on the BlockSprite ItemSprite etc pages, as part of a list of deprecated sprite IDs. See my user page for an example. – Sealbudsman talk | contribs 20:35, 25 July 2018 (UTC)

I Support the idea, but how would those categories be created and deleted as the sprites get removed, added, etc.? I assume it would have to be done manually?-- Madminecrafter12^{20pxTalk to me20px} 20:40, 25 July 2018 (UTC)

It's just categories with no pages at all, and it all still works. – Sealbudsman talk | contribs 01:12, 26 July 2018 (UTC)

Not trying to be dense, but could you clarify a bit what you mean by that? Are you saying that the categories wouldn't actually be created - they would just appear as red links?-- Madminecrafter12^{20pxTalk to me20px} 01:14, 26 July 2018 (UTC)

No problem. Yes, they'd be red links. But the trick is, a category where you haven't created its page still lists out what pages are in its category, when you follow the red link. – Sealbudsman talk | contribs 01:38, 26 July 2018 (UTC)

Alright, I see what you mean now. That would definitely be beneficial - one could look through :Category:pages using deprecated sprite names, and for every page, you could then easily see what deprecated sprites the page actually uses. Currently it's very difficult or tedious to figure out exactly what individual sprites on pages are deprecated. So yes, full Support. :)-- Madminecrafter12^{20pxTalk to me20px} 01:46, 26 July 2018 (UTC)

Note that they are added to Special:WantedCategories. If this is/becomes a problem, a bot could probably be made to create the categories. Jahunsbe (Talk) 02:04, 26 July 2018 (UTC)

I see that; that's interesting. Keep in mind also, the category also would naturally disappear from Special:WantedCategories once the sprite IDs were fixed. I'm trying to say I guess that these aren't actually "wanted categories", because these are unwanted sprites, the whole idea is to eliminate these categories as part of the deprecation job. I don't really know the motivation behind that special page though. – Sealbudsman talk | contribs 02:19, 26 July 2018 (UTC)

That special page is for identifying categories that do still need their page be created. Your solution is about maintenance categories, so you actually want to achieve none of them, but there are also categories that are the opposite, like listing pages of a particular type like :category:blocks. If a page is added to a new category (like that one) that doesn't have a page yet, the category is captured by the special page for convenience so you can create it. That's its motivation. – Jack McKalling [ 16px 16px ] 09:05, 26 July 2018 (UTC)

I would change this to use subcategories of :Category:Pages using deprecated sprite names and to replace spaces with _. Jahunsbe (Talk) 22:05, 25 July 2018 (UTC)

This method only creates categories, never any pages for them. Subcategories first require category pages be made. Keep in mind too, each of the Sprite templates would be keeping track of its own lists, so there's your master list right there.

Can I ask, why replace spaces with underscores? – Sealbudsman talk | contribs 01:12, 26 July 2018 (UTC)

I hadn't realized that to create a subcategory you had to add the category to a category unlike sub pages. For the underscores it just seems more consistent but it really could be either way. Jahunsbe (Talk) 01:44, 26 July 2018 (UTC)

Majr, I'd like to get your opinion as to whether this would be a burden on the server in some way, or whether creating categories without their pages creates some problem -- or anything you might forsee? – Sealbudsman talk | contribs 01:53, 26 July 2018 (UTC)

It's not a burden on the server, but the issue I'd have is the categories are going to be visible to readers and clutter the categories section, though if it's just temporary then it's not that big of a deal. Another option is to add a class to sprites that are deprecated so they can be highlighted on the page. –Majr ᐸ Talk
Contribs 08:11, 27 July 2018 (UTC)

Merge fish back together

The result of the discussion was do not merge.

I Disagree with the recent split up of the Fish (food) page. The split hasn't done away with parenthesized page names and has made things very inconsistent with the mob form, which is currently all merged. Therefore I propose that it be merged back together, but this time under the title Fish (item), which looks more natural. If this is done, people won't have to constantly switch between pages when they want to compare the items, and it also means there will be less pages to update and maintain. MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 05:58, 15 August 2018 (UTC)

I severely Oppose for all reasons mentioned that are for splitting and the severe lack of opposing arguments that was provided during the time the split proposal was made in the first place. FVbico (talk) 06:02, 15 August 2018 (UTC)

The opposing arguments simply failed to be mentioned. But now they're right above your very comment. MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 06:10, 15 August 2018 (UTC)

“during the time the split proposal was made in the first place.” This time spanned more than 2 weeks, there was no “failed to be mentioned”, there just wasn’t anyone (literally) opposing the split; and now there literally isn’t anybody supporting your merge request. As others have already stated, you can have several internet tabs open in order to compare, so that argument of yours is repelled. Additionally ALL other items have their own page, even cooked and raw food have their own pages, so if anything’s inconsistent right now, it’s the entity and block pages that (still) talk about several different entities/blocks.

As for the parenthesized names, that’s because item and entity are still on different pages; perhaps if the entity page got split, the cod mob and cod item page could be merged, the salmon mob and salmon one, pufferfish mob and pufferfish, and tropical fish mob and tropical fish, but for now it’s still better to have the parenthesized names until such time. FVbico (talk) 06:36, 16 August 2018 (UTC)

There are hundreds of active editors on this wiki, and yet how many of them were aware of, let alone took part in, the splitting discussion? The opposing arguments simply failed to be mentioned, period. And have you ever tried switching between tabs on mobile? It's quite a frustrating and time-consuming process. Contrast that to when the different information is right next to each other in the same article, and the comparison can be made in literally no time at all. MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 16:33, 17 August 2018 (UTC)

I switch/close tabs on mobile all the time, takes less than 2 seconds (1/2 second if you exclude looking which tab you need to select, that’s also an issue on pc/laptop), so again, that argument has been repelled.

After a being open for several weeks, it’s safe to assume that everybody who cares about the article saw it, and there’s been a lot of people who supported the split, even now; you don’t have a single person who supports merging it back together. It’s more than safe to say that nobody opposed (except for you). FVbico (talk) 17:10, 17 August 2018 (UTC)

Oppose merging fish item pages. They were split to separate the confusing mess of content. The same could be done for the fish mob page, if you so want consistency. The parenthesized names are fine, they make it clearer what the pages are about. – Jack McKalling [ 16px 16px ] 08:18, 15 August 2018 (UTC)

Well, if we merge it again, we can take the opportunity to ensure that it's less confusing. Right Jack? MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 01:32, 16 August 2018 (UTC)

Oppose — I have taken a look at the fish mob article and noticed that its content is cluttered by the description of pufferfish’s poison-inflicting self-defense and tropical fish’s varieties. Their respective item forms are similarly outstanding: tropical fish cannot be cooked, and pufferfish is very poisonous (and nauseating), is used as a brewing ingredient, and can’t be cooked as well. Cod and salmon also have specific traits regarding areal, behavior, drops, saturation and nourishment of their respective item forms etc. This justifies not only the separation of fish items, but also a potential split of the fish mob article. — BabylonAS (talk | ru.Wiki Admin) 16:18, 15 August 2018 (UTC)

I also fail to see how “less pages to update and maintain” can be a viable argument. The effective amount of content remains the same, including overlapping text on multiple articles: if it is to be edited, then on all articles simultaneously, which might not be a problem if the edits and edited texts are identical. Regarding having multiple pages to compare against each other: with modern multi-tab and multi-window browsers it isn’t much of a problem either (and even initially console-only operating systems like FreeBSD feature multiple switchable consoles). — BabylonAS (talk | ru.Wiki Admin) 16:23, 15 August 2018 (UTC)

Oppose. "(A) is done, but (B), which is similar to (A), isn't, therefore (A) should be reverted"? Uh... what? --AttemptToCallNil (report bug, view backtrace) 16:35, 15 August 2018 (UTC)

Do you have any better counterarguments than that? Just because it's been split doesn't mean it can't be merged back together! MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 01:36, 16 August 2018 (UTC)

(removed per request of the user who posted this comment -Madminecrafter12) — BabylonAS (talk | ru.Wiki Admin) 05:48, 16 August 2018 (UTC)

As per the wiki rules, please refrain from personal attacks against other users. -- Orthotope^talk 10:21, 16 August 2018 (UTC)

Where do you see an attack? Or am I not allowed to use adverbs in discussions? At least thanks for not removing the comment. — BabylonAS (talk | ru.Wiki Admin) 12:53, 16 August 2018 (UTC)

I addressed both of your arguments in favor of splitting in this proposal, and yet you still opposed. Since you haven't answered my above reply for almost a month, I'm going to assume you now Support. MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 23:18, 12 September 2018 (UTC)

Do not speak for others. This is still considered an Oppose. --Pepijn (talk) 01:47, 13 September 2018 (UTC)

No, it's a Support. And please stop being mean. MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 02:35, 13 September 2018 (UTC)

Oppose. Merging is often not helpful to the reader. You mention having to switch tabs to compare items, but what things are you wanting to compare that aren't covered by comparison pages such as food? –Majr ᐸ Talk
Contribs 08:01, 18 August 2018 (UTC)

It would obviously be information that isn't covered by those pages, such as obtaining and non-food usages. Now do you support? MarcelTheHippie (talk • contribs • logs • block log) 🐷🥕☮️ 20:46, 24 August 2018 (UTC)

"What things are you wanting to compare not covered by those pages?" "Obviously info that isn't covered by those pages" is not an answer. The food page also does cover obtaining, and what non-food usages are you needing to compare for food? Data values? Advancements? Trading? All seem to have pages. Only notable thing I can see is usage, which could totally be covered on the food page (which also seems to need updating in general). –Majr ᐸ Talk
Contribs 04:17, 3 September 2018 (UTC)

Judging by flaws in the proposer's argumentation, I suggest closing the fish item part of this discussion off, and switch exclusively to discussing splitting the fish mob article where it actually should be. — BabylonAS (talk | ru.Wiki Admin) 07:50, 18 August 2018 (UTC)

Considering this has gone absolutely nowhere, with a lot of opposition and no support, I would suggest to wrap this up for now. Things are just going in circles. In the end, it's just a page about virtual fish so no reason for people to take this so personal. This can always be brought up again in the future if people so desire but let it rest for now. --Pepijn (talk) 04:49, 13 September 2018 (UTC)